Time Nick Message 00:30 thd kados: why is biblioitems.ccode at the biblioitems level instead of at the items level? 00:31 thd kados: different collections then cannot share the same basic bibliographic record 00:42 kados thd: I'm here 00:42 kados good point 00:42 kados it should be at both levels 00:43 thd kados: why have it at the biblioitems level at all? 00:46 thd 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 thd 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 kados I'm thinking :-) 00:51 thd kados: also what I said about ccode applies equally to classification 00:52 thd kados: different library consortia members, branches or collections might have different classification for the same material 00:53 thd 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 kados I need a few minutes 00:54 kados 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 kados thd: it belongs at the items level 01:41 kados and not at the biblioitems level 01:41 kados cn_edition, that is from the spec 01:41 kados thd: it's for dewey only 01:42 kados thd: http://www.loc.gov/marc/bibliographic/ecbdclas.html#mrcb082 01:43 kados thd: I forgot about classification source 01:43 kados thd: that does belong at both bib and item level 01:43 kados cn_source 01:44 kados items.cn_source 01:44 kados biblioitems.cn_source 01:44 kados 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 kados 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 thd for storing in the record in 952 or for mapping 02:08 kados good point 02:08 kados ahh, wait 02:08 kados remember, we're not doing it item-leve in the sql 02:08 kados just biblioitem level 02:08 kados 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 kados 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 thd 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 kados biblioitems.cn_source (needs auth value) 02:15 kados biblioitems.cn_class 02:15 kados biblioitems.cn_item 02:15 kados biblioitems.cn_edition 02:15 kados biblioitems.cn_suffix 02:15 kados biblioitems.cn_sort 02:15 kados items.itemcallnumber 02:15 kados items.cn_source 02:15 kados items.cn_sort 02:15 kados items.ccode 02:16 kados make the cn_class a plugin 02:16 kados that plugin will fill values for all of the others 02:16 kados also make itemcallnumber a plugin 02:17 kados 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 thd kados: why two plugins when one would do at the items level? 02:19 kados we need one at the bib level 02:19 kados to decide what belongs in 942 in the first place 02:19 kados there may be nlm, ddc, and lcc call numbers 02:19 kados in the record 02:20 kados but what belongs in the 'official' call number for koha 02:20 kados 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 kados ok, I'll send you these revisions 02:26 kados thd: sent 02:30 thd kados: cn_edition should also have a value list 02:31 thd 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 kados since it's a DCC-specific one that's easy 02:32 kados ahh, well hang on 02:32 kados the same subfield is used for source 02:32 kados we can't do that this time around 02:32 kados 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 kados thd: you underestimate how much time I have :-) 02:34 kados 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 kados in fact, I have already done something like that 02:52 kados it requires a batch process though 02:53 kados biblios can't be updated with every circ 02:53 kados 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 kados renewals and reserves you can skip 02:55 kados thd: one thing to keep in mind 02:55 kados if something is not mapped to items, and it's in the items marc data, it's wiped out on update 02:56 kados so any extranous marc holdings fields will just be deleted anyway 02:56 kados that's how 3.0 works 02:56 kados if it's not in the items table, it doesn't exist :-) 02:56 kados we need to do it that way to ensure that there is an authoritative spot for items data 02:57 kados 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 kados (for bib data, the authority for everything but the biblionumber is the marc record) 02:57 kados that's not something we can change this late in the game either 02:58 kados thd: so no sense in putting up a fight for those missing bits of data :-) 02:58 kados 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 kados 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 kados 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 kados or the record level 03:10 kados 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 kados sorry 03:18 kados it'll have to be in itemcallnumber 03:18 kados as a concatenated string 03:18 thd kados: just to store them 03:19 thd 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 kados thd: if it's not already 03:32 kados ahh, it is already 03:33 thd you mean LCCN 010 $a 03:33 kados yes 03:33 thd always was 04:29 thd 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 thd ? 04:29 thd or items.materials ? 04:40 thd kados: is cn_class for the classification part only? Does marc21_callnumber.pl fill all the cn_.* values? 04:42 thd 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 thd kados: is both a value list and a plugin allowed? 05:07 thd kados: we have that now for CN_SOURCE and marc21_classcodes.pl 05:09 thd 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 kados but a plugin can read values from an authorized value 05:11 kados and you wouldn't need to put the authorized value in the framework for that to happen 05:11 kados a plugin can basically do anything you need it to do 05:11 kados except provide a drop-down :-) 05:12 thd I assumed that but just to be certain there was no strange isolation 05:12 thd a popup is almost as good as a drop down 05:12 kados yep 05:37 kados thd: received 05:37 kados 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 thd preparing to send again now 05:54 thd kados: sent with correction 05:58 kados thanks 06:42 thd kados: I missed a field for items 06:43 thd kados: there is nothing preserving 952 $f coded location qualifier 06:50 thd and I mislabelled a plugin 08:10 chris hi paul and hdl 08:10 paul hi crhis 08:10 paul 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 chris 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 chris 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 chris have you seen this ? http://www.icikm-2008.com.np/index.php?p=tutorial 08:19 chris if you want to do a paper http://www.icikm-2008.com.np/index.php?p=forpapers 08:20 chris im a reviewer :) http://www.icikm-2008.com.np/index.php?p=reviewers 08:31 hdl Are YOU doing a paper ? 08:35 chris i dont think i can if im reviewing :) 08:35 chris im doing a 3 day tutorial on using Koha though 08:35 chris using, submitting patches, adminstering etc 08:39 chris 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 chris so ill try to teach them things about how to backup koha, mysql configuration tweaks etc 08:59 chris and try to teach the librarian type ppl about how to use Koha