IRC log for #koha, 2007-10-08

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
00:30 thd kados: why is biblioitems.ccode at the biblioitems level instead of at the items level?
00:31 kados: different collections then cannot share the same basic bibliographic record
00:42 kados thd: I'm here
00:42 good point
00:42 it should be at both levels
00:43 thd kados: why have it at the biblioitems level at all?
00:46 kados: also, why would you store cn_edition in the SQL tables unless what you actually meant was classification source: DDC, LCC, etc.?
00:48 kados: edition by itself should not be relevant for sorting, it is significant for knowing the meaning in case of changes between editions.
00:50 kados thd: i'm here
00:50 thd did you see the 2 additional questions?
00:51 kados yes
00:51 I'm thinking :-)
00:51 thd kados: also what I said about ccode applies equally to classification
00:52 kados: different library consortia members, branches or collections might have different classification for the same material
00:53 kados: you could specify that a different bib record should be used if the classification is different for an item but is that what you really want?
00:53 kados hmmm
00:54 I need a few minutes
00:54 having a chat with ryan
00:57 thd or you could have actually repeatable classification in 942 with an additional entry if multiple classification is used between different items
01:40 kados thd: OK, I agree about ccode (Collection Code)
01:40 thd: it belongs at the items level
01:41 and not at the biblioitems level
01:41 cn_edition, that is from the spec
01:41 thd: it's for dewey only
01:42 thd: http://www.loc.gov/marc/biblio[…]clas.html#mrcb082
01:43 thd: I forgot about classification source
01:43 thd: that does belong at both bib and item level
01:43 cn_source
01:44 items.cn_source
01:44 biblioitems.cn_source
01:44 classification IS at the bib and item level
01:59 thd kados: why would you store cn_edition in the SQL tables?  I certainly understand the advantage of storing it in the record but why in SQL?.
02:01 kados hmmm
02:01 well for one it will be easier to display that way
02:06 thd ok but if we add cn_edition as separate and distinct from cn_source in which it would be included in MARC then after also adding cn_sort and ccode to items mappings we have to loose something
02:07 for storing in the record in 952 or for mapping
02:08 kados good point
02:08 ahh, wait
02:08 remember, we're not doing it item-leve in the sql
02:08 just biblioitem level
02:08 remember, I got shot down on that proposal :-)
02:08 thd unless call number prefix is the equivalent of collection which does not seen necessarily true
02:10 kados my feeling is that call number prefix could be any field they want it to be
02:10 thd Oh, I was reading your statement "classification IS at the bib and item level" and assuming that you had now been shot up
02:10 kados well, it's there, just not in the SQL
02:10 you already mapped it to the 952
02:12 thd kados: Wat do you do about different library consortia members, branches or collections might have different classification for the same material?
02:14 kados: if they share the same biblio with different classification systems then cn_sort needs to be at the item level does it not?
02:14 kados yes, I"ve added it to the item level
02:15 biblioitems.cn_source (needs auth value)
02:15 biblioitems.cn_class
02:15 biblioitems.cn_item
02:15 biblioitems.cn_edition
02:15 biblioitems.cn_suffix
02:15 biblioitems.cn_sort
02:15 items.itemcallnumber
02:15 items.cn_source
02:15 items.cn_sort
02:15 items.ccode
02:16 make the cn_class a plugin
02:16 that plugin will fill values for all of the others
02:16 also make itemcallnumber a plugin
02:17 and make ccode a authorized value with CCODE
02:17 thd kados: ok so we loose 952 $6 and $8 to add cn_sort and ccode
02:17 kados ok
02:17 thd cn_source already has a place at 952 $2
02:18 kados: why two plugins when one would do at the items level?
02:19 kados we need one at the bib level
02:19 to decide what belongs in 942 in the first place
02:19 there may be nlm, ddc, and lcc call numbers
02:19 in the record
02:20 but what belongs in the 'official' call number for koha
02:20 that's whaty we need the plugin
02:20 thd kados: is that not double effort of even tabbing through the 942 field for the cataloguer?
02:20 kados yes, but I also have to release 3.0 soon :-)
02:20 thd kados: so you are only going to sort on one?
02:20 kados this will do the job
02:21 thd kados: as long as the LCC and DDC libraries in your consortia are happy :)
02:22 kados exactly :-)
02:22 thd they should be happy just using 3.0 of course
02:23 kados :-)
02:23 ok, I'll send you these revisions
02:26 thd: sent
02:30 thd kados: cn_edition should also have a value list
02:31 kados: in MARC 21 source and edition are unfortunately often combined for fields like 055 and 852
02:31 kados sure, give it a auth value for CN_EDITION
02:31 since it's a DCC-specific one that's easy
02:32 ahh, well hang on
02:32 the same subfield is used for source
02:32 we can't do that this time around
02:32 that'll have to wait for 3.2
02:33 thd kados: if it was always filled with a plugin you could easily distinguish source from edition inside the plugin
02:34 kados make sure that the sort fields are hidden from everything
02:34 thd kados: that is an easy plugin :)
02:34 kados they are strictly internal
02:34 thd: you underestimate how much time I have :-)
02:34 overestimat I mean :-)
02:35 thd kados: no I don't.  I presume that you only have negative time borrowed against the future :)
02:35 kados hehe, yea, that's abotu right
02:52 thd thinking about using items.issues, etc. for popularity.  Popular books with many copies will be under represented.  Popularity should accumulate at the by branch or library wide and be represented at the biblio level for sorting by popularity.
02:52 kados I agree
02:52 in fact, I have already done something like that
02:52 it requires a batch process though
02:53 biblios can't be updated with every circ
02:53 it's too proc intensive
02:54 thd kados: so I question the utility of mapping items.issues, items.renewals, and items.reserves because you are only measuring barcodes
02:54 kados at least map issues
02:54 renewals and reserves you can skip
02:55 thd: one thing to keep in mind
02:55 if something is not mapped to items, and it's in the items marc data, it's wiped out on update
02:56 so any extranous marc holdings fields will just be deleted anyway
02:56 that's how 3.0 works
02:56 if it's not in the items table, it doesn't exist :-)
02:56 we need to do it that way to ensure that there is an authoritative spot for items data
02:57 as opposed to the 2.2 method, where depending on context, items table or marc data was authoritative
02:57 thd kados: the authoritative spot being SQL?
02:57 kados yes, for items data
02:57 (for bib data, the authority for everything but the biblionumber is the marc record)
02:57 that's not something we can change this late in the game either
02:58 thd: so no sense in putting up a fight for those missing bits of data :-)
02:58 it does indicate that we probably still need cn_editions
02:59 thd kados: so if anyone would use the new URI 952 $u equivalent to the new 852 $u for a URL for item location then we need items.uri
03:00 kados good point
03:03 thd I favour using the items.renewals and items.requests places in 952 for items.cn_sort and items.ccode
03:03 kados sounds good to me
03:05 thd kados: that would allow the crazy people trying to sync with standard MARC to use 952 $6 with items.link and 952 $8 with items.sequence
03:05 kados we dont' have link or sequence
03:06 thd kados; and you should have biblioitems.totalissues for periodically adding items.issues collectively
03:07 kados yep
03:07 thd: add that to 942 :-)
03:07 thd kados: if you had link and sequence it would be technically possible highly motivated cataloguers do record standard holdings in sync with 952
03:08 kados thd: we have another plan for that already
03:08 thd: but that won't make it into 3.0
03:09 thd kados:, I know but libraries could adopt 3.0 while  waiting if they could maintain things in manner close to standard
03:09 kados thd: 3.2 will be released shortly after 3.0 :-)
03:09 thd items.link and items.sequence would make that possible
03:10 kados they don't belong at the items level
03:10 or the record level
03:10 and I don't have time to discuss it right now :-)
03:17 thd kados: we also need to record all the classification parts in items merely to preserve them from loss
03:18 kados thd: can't do that for 3.0
03:18 sorry
03:18 it'll have to be in itemcallnumber
03:18 as a concatenated string
03:18 thd kados: just to store them
03:19 kados: I understand that the code may not support sorting them but the code should be able to preserve the parts in SQL instead of losing them on update
03:21 kados actually, the framework shouldn't support those fields, they give the false impression that Koha will save them :-)
03:21 thd kados: Koha could easily save them just to save them
03:32 kados thd: biblioitems.lccn needs to be mapped to the LC Call Number
03:32 thd: if it's not already
03:32 ahh, it is already
03:33 thd you mean LCCN 010 $a
03:33 kados yes
03:33 thd always was
04:29 kados: what in the items table is preserving materials specified 952 $3 for the text string for a bound volume of a serial or other particular of a biblio which has its own separate bar code?  items.material
04:29 ?
04:29 or items.materials ?
04:40 kados: is cn_class for the classification part only?  Does marc21_callnumber.pl fill all the cn_.* values?
04:42 kados: call number prefix in 942 should still have a value list so the cataloguer is not typing JVU when JUV was intended and working too fast to notice
05:06 kados: is both a value list and a plugin allowed?
05:07 kados: we have that now for CN_SOURCE and marc21_classcodes.pl
05:09 kados: can a plugin read values from CN_SOURCE to use for populating the plugin values?
05:10 kados hi thd
05:10 thd hello
05:10 kados at the moment, value lists and plugins are mutually exclusive
05:10 but a plugin can read values from an authorized value
05:11 and you wouldn't need to put the authorized value in the framework for that to happen
05:11 a plugin can basically do anything you need it to do
05:11 except provide a drop-down :-)
05:12 thd I assumed that but just to be certain there was no strange isolation
05:12 a popup is almost as good as a drop down
05:12 kados yep
05:37 thd: received
05:37 thd: thanks!
05:37 thd sent with a note suggesting preserving $t because it is universally used by libraries I have seen
05:45 kados *nod*
05:48 thd I left out biblioitems.totalissues
05:48 preparing to send again now
05:54 kados: sent with correction
05:58 kados thanks
06:42 thd kados: I missed a field for items
06:43 kados: there is nothing preserving 952 $f coded location qualifier
06:50 and I mislabelled a plugin
08:10 chris hi paul and hdl
08:10 paul hi crhis
08:10 chris even ;-)
08:10 chris going to be a north vs south final it seems
08:11 paul yep
08:11 chris maybe france vs argentina .. the revenge :)
08:11 paul france saf I bet
08:11 hdl GB SAF
08:11 chris yes i think so too, altho ... fiji troubled SAF more than i thought
08:12 so maybe argentina can beat them
08:12 hdl But maybe SAF were too much confident.
08:12 chris yeah
08:12 hdl And they will be more cautious next time
08:13 chris i think so
08:13 hdl (This may explain why NZ lost the game :D )
08:13 chris i think they just hadnt played together enough
08:14 too much of this rotation policy
08:14 hdl (NZ players affected to disregard French team )
08:16 chris yeah, i think a little bit of that, but i think also not enough hard games leading up
08:18 have you seen this ? http://www.icikm-2008.com.np/index.php?p=tutorial
08:19 if you want to do a paper http://www.icikm-2008.com.np/i[…]x.php?p=forpapers
08:20 im a reviewer :) http://www.icikm-2008.com.np/i[…]x.php?p=reviewers
08:31 hdl Are YOU doing a paper ?
08:35 chris i dont think i can if im reviewing :)
08:35 im doing a 3 day tutorial on using Koha though
08:35 using, submitting patches, adminstering etc
08:39 i hope to teach people not only how to use koha, but how to fix bugs :-) with the new sending patches in, its quite easy for someone to do if they want too
08:52 hdl chris : but then, ppl would still need an IT guy.
08:58 chris yep, i think a few of the people coming to the conference will be IT guys
08:58 so ill try to teach them things about how to backup koha, mysql configuration tweaks etc
08:59 and try to teach the librarian type ppl about how to use Koha

← Previous day | Today | Next day → | Search | Index

koha1