Time Nick Message 12:15 kados thd: I think so 12:15 kados thd: they have some dewey stuff in $h 12:15 kados thd: and some LOC in 092 12:15 kados $a 12:16 kados I just spoke with them and they only recently started using LOC 12:16 kados most stuff is dewey and some is internal classification 12:16 kados with the order of 852$k$h$i$m 12:18 kados owen: quick question 12:18 owen Yeah 12:18 kados owen: so ideally you'd keep the call number/classification separate right? 12:18 owen Uh... I don't know what you're asking 12:19 kados yea ... not sure if I do either 12:19 kados say you've got three or four classification types in a single collection 12:19 kados some items are dewey 12:19 kados some are internal 12:19 kados would you want to differentiate betweeen them on the OPAC 12:19 kados say have the dewey ones in a different column 12:19 kados and the internal classification somewhere else? 12:19 kados (another column) 12:20 owen I guess I'd try to figure out what dewey gets you. Is there an advantage to using it? 12:20 owen Why not just use classification for everything? 12:20 kados cause they started out using an internal system ... then switched to dewey 12:20 kados some stuff uses the internal and some uses dewey 12:20 kados long term they want to switch to LOC 12:20 thd kados: 852 indicator 1 specifies classification scheme used. 0 is LC, 1 is DDC, etc. http://www.loc.gov/marc/holdings/echdloca.html#mrch852 12:20 kados talk about a mess! 12:21 kados thd: that's useful ... what's '4'? 12:21 thd 4 is shelving control number 12:21 kados weird 12:21 thd not a universal scheme 12:22 kados I'm still not really groking this classification/call number stuff 12:22 kados in Koha we have biblioitems 12:22 thd kados: That is where all the fun is :) 12:22 kados classification, dewey, subclass, lccn 12:22 kados that's in biblioitems 12:23 kados then in items we have 12:23 kados barcode, itemcallnumber, location 12:23 kados thd: those are the relevant fields right? 12:24 thd chris told me that he had nothing to do with items.callnumber and did not know what it did if anything 12:24 thd he told me to ask paul about items.callnumber 12:24 thd about items.itemcallnumber 12:24 kados you mean items.itemcallnumber? 12:25 kados right ... ok ... well I guess in some cases you'd have the same info in the MARC record apart from the item info (in a non repeatable field?) 12:25 thd kados: how does NPL use biblioitems.classification 12:25 kados it's the dewey 12:26 thd they are always identical? 12:26 kados no ... some classification isn't dewey ... it's our own strange amalgam of a standard 12:26 kados fiction for instance 12:26 thd Are they linked to the same MARC subfield? 12:26 kados is organized lastname, firstname, etc. 12:26 kados yea 12:27 kados 942 $k 12:27 kados here's a good example: 12:27 kados http://search.athenscounty.lib.oh.us/cgi-bin/koha/opac-search.pl?op=do_search&type=opac&marclist=&and_or=and&excluding=&operator=contains&value=neal+stephenson 12:27 kados you can see call numbers for fiction and non-fiction works side-by-side 12:28 kados (well, one non-fiction) 12:28 kados :-) 12:29 kados there are some other seemingly useful things in items 12:29 thd So, for fiction NPL has author shelving for call number instead of 8XX? 12:30 kados like stack, itemlost, wthdrawn, issues, renewals reserves 12:30 kados thd: yep 12:30 kados binding, paidfor, location 12:30 kados I'd love to be able to use those fields but I'm not sure if they are used in Koha these days 12:30 thd kados: I discussed this extensively with chris 12:31 kados thd: really? what did he say? 12:31 thd binding is an orphaned field 12:31 kados damn 12:31 kados it could be so useful 12:31 thd well it is not doing anything at the moment 12:33 kados I'm also not sure if biblioitemnumber in items should be populated ... it might be a useful thing to keep track of at the item level (in MARC) 12:33 kados at least for when we move to zebra 12:33 thd however, for what I imagine you want it do for non-MARC Koha uses biblioitems.mediatype 12:33 kados for deep linking 12:36 thd For MARC Koha, paul disabled the possibility of multiple biblioitems.mediatype which is needed at least once for determining circulation rules. 12:37 thd what woud happen to multiple copies of the same item if you reduced MARC Koha to item level only? 12:38 thd s/same item/same biblio/ 12:41 kados so not sure I completely understand ... are you talking about determing the itemtypes? 12:41 kados are you suggesting that itemtypes should be determined on the item level rather than on the biblioitem level? 12:41 thd kados: Sorry, I confused myself :) Koha already does track item level in MARC with MARC 21 952 at NPL and 995 in UNIMARC. 12:42 kados right 12:42 thd oh yes, I had meant biblioitems.itemtype :) 12:44 kados so I think that in standard marc practice a different format/itemtype goes in a separate MARC record 12:45 kados so you don't really need to specify a itemtype at the item level (ideally) 12:45 kados but I'm not a MARC expert 12:45 thd So, in non-MARC Koha libraries can have multiple biblioitems.itemtype assigned to a single item. One can designate binding while another designates whatever is useful for setting circ control rules from. 12:49 kados but there's also a items.binding 12:49 thd well in common MARC 21 practise a single MARC 21 bibliographic record is used for the same manifestation where the softcover and hardcover versions share the same record with multiple ISBNs, assuming the manifestation is the same under the usual current publishing practise both bindings coming from the same publisher with the same features except for cover 12:49 kados yea ... and even that's confusing 12:49 kados Koha's internal system is a bit more sane than that 12:49 kados and FRBR is even closer 12:50 thd Libraries often only have the hardover, so in practise there is less confusion overall. 12:52 thd kados: The multiple formats in one record is consistent with FRBR where only the binding not the type changes then the manifestation is the same. 12:55 thd In UNIMARC there is one binding per record consistent with FRBR manifestation because publisher, type, and pagination usually change in France between the broché format and poche format. 12:58 thd Koha was never a perfect match for FRBR but some sort of abridged variation that fit a practical problem. The relational DB model was a common source inspiration for both FRBR and Koha. 13:02 thd kados: If you do not populate biblioitemsnumber, then you loose non-MARC Koha. 13:07 thd kados: I would like some distant future version of non-MARC Koha to allow MARC underneath with only minimal field use, and hide MARC from the user so that they do not have to know or care much about the difference. 13:07 kados yea ... that'd be nice 13:07 kados remember that Koha's original design predated FRBR by a couple of years 13:11 thd FRBR is a natural concept of relations between bibliographic entities that was always around before an explicit definition, but had never explicitly catalogued so impelmenting FRBR with existing records is difficult. 13:12 thd kados: have you read Martha Yee's FRBRization paper yet? 13:13 kados thd: as soon as I'm done with this import ;-) 13:13 kados thd: hopefully by tonight ;-) 13:13 thd So: what problems are you having with the import? 13:16 kados well I'm not sure yet ... the biggest problem is getting used to the MARC records 13:16 kados there are three generations of records 13:16 kados all with different ways of doing things 13:18 kados it seems like I should be paying attention mainly to the 852 tag 13:18 kados and looking at the indicators to see what classification is being used 13:18 kados (hopefully it's done correctly) 13:22 kados thd: on the loc.gov holdings site ... what does the (NR) and (R) stand for? 13:24 thd items.stack, items.binding, items.multivolume, items.multivolumepart were for old ideas that were never implemented 13:24 thd repeatable and not repeatable 13:25 kados ahh 13:25 kados thd: they were probably good ideas 13:25 thd kados: did you see the last section of my latest post to koha-devel? 13:26 thd items.paidfor is for when a borrower pays a replacement fine 13:27 kados I"m looking now 13:27 thd kados: Marc Hlings, Koha, and Migraton 13:28 thd kados: tying again :) MARC Holdings, Koha, and Migration 13:28 kados found it 13:28 kados I had it flagged as important ;-) 13:30 owen kados: itemcallnumber is an addition Paul made. He tried to explain it to us when he was here, but I don't think I retained much 13:31 kados I didn't even remember that we discussed it ;-) 13:31 kados what do you remember? 13:33 thd The last section may relate to your import issues, the mnor corrections from my IRC communication with chris that evening after a few evenings of not getting his attention should not affect your present import issues as they mostly related to the 3 values that items.itemlost can have. 13:33 kados thd: I'm not sure I follow that last section 13:33 kados Map 852 $t, 876 $t, 877 $t, and 878 $t to 952 $t for items.copynumber. (If 13:33 kados you have been using $3, you should find some way of combining $t with $3 to 13:33 kados form a unique whole number.) 13:33 kados thd: what did you use to determine the order of the mappings 13:34 kados thd: why is 852 $t before 876 $t 13:34 thd kados: I have not had the chance to ask paul about ites.itemscallnumber yet. 13:34 kados and what if data exists in more than one of those fields? 13:35 kados owen: do you remember anything about items.itemcallnumber? 13:35 thd Preface everything with I have not tested this on a real system. I was trying to lay everything down for that possibility. 13:35 kados right I get that 13:36 kados under what circumstances would I want more than one framwork for MARC? 13:37 owen Frameworks define what fields you see during MARC entry 13:38 owen You could set up a specific framework for each kind of material with all the relevant tags, leaving out tags that weren't important for that type of item 13:38 thd $t is the same for the same copy so where you get it from does not matter 13:38 owen We don't use frameworks right now because the NPL template for setting up marc subfields is buggy 13:39 thd owen: do you mean the cataloguing template or the frameworks subfield addition template? 13:41 thd kados: 876-878 sometimes modify and override location information from 852 13:41 kados thd: so which is authoritative? 13:43 owen thd: the NPL template for marc_subfields_structure.pl is buggy 13:44 thd kados: your records may not even have 876-878, however, if they do then the 876-878 values should be the current ones. 852 has the default or may not be present for a particular copy. 13:45 kados owen: is there a way to specify a framework withing the MARC record? 13:45 kados thd: so amont 876-878, which ones normally take precedence (and where would I find out about this in the first place?) 13:46 kados thd: s/amont/among/ 13:50 thd kados: Be careful of 877 and 878. 876 is for the basic bibliographic unit, 877 is for supplements, and 877 is for indices. If 877 or 878 were present, because you are only mapping all to one subfield, 876 should be used instead if present while the other information is preserved. 13:50 thd kados: http://www.loc.gov/marc/holdings/echditem.html 13:54 thd kados: In holdings materials specified $3, if you find it, is for special treatment of some elements for a particular copy number $t. 13:56 thd kados: why would you need the MARC record to specify a framework? 14:00 owen I think the framework information is in the MARC record somewhere 14:01 kados thd: for import purposes it would be useful to put types of records 'into' frameworks 14:01 owen It's listed in marc_biblio 14:03 thd kados: the concise MARC 21 documentation linked from http://www.loc.gov/marc/ has the holdings fields for MARC 21 bibliographic in MARC 21 holdings where the MARC 21 bibliographic format shares the same holdings fields with MARC 21 holdings. 14:04 kados thd: I can't quite parse that sentence ;-) 14:05 kados thd: I'm unclear as to why some of the 952 subfields are repeatable 14:05 kados like $c Shelving location 14:05 kados or $e Address 14:05 kados oops ... I meant 852 subfields 14:07 thd kados: Well, I observed that and wondered. I do not have any actual examples of that to see but for multipart items held in multiple locations that may be useful. 14:08 kados it becomes problematic in some cases ... like take $i for instance 14:08 kados and $k, $m 14:08 thd kados: What do you mean by 'types of records' for frameworks? 14:08 kados because if I'm building a new classification number by concatenating k, h, i, m 14:09 kados and some of those are repeatable ... how can I possible do that? 14:09 owen You might have a whole section just of periodicals, for instance, which corresponded to a particular framework. If you're importing those fresh into Koha, it would be good to associate them with that framework right away 14:09 kados thd: I was under the impression that you might want to have a framework for books, another for periodicals 14:09 kados what he said ;-) 14:09 owen Otherwise when you go to edit those records, they would open with the default MARC template 14:10 kados right ... exactly 14:11 thd Why not one framework with multiple implementations depending on various factors, but that has yet to be developed. 14:11 owen the 'yet to be developed' part is the sticking point 14:11 thd kados: You want something to use today, right? 14:12 kados thd: well I'm writing a program to grab the 852s ... work some magic, create a new 942 and 952 (for biblioitems and items) and fix the 852s while I'm at it 14:13 kados thd: I'm just not sure what to do when I encounter a repeatable subfield within 852 ... is it important? 14:15 kados thd: I'm also not sure whether it's a part of MARC to track which repeatable subfields go with other repeatable subfields (if you know what I mean) 14:16 thd kados: If you are lucky there will not be multiple subfields in 852 to bother with but I would suggest concatenating them if there were any to fit the into Koha today. 14:16 kados thd: it's not hard to do I suppose 14:16 kados thd: but are you sure they should be concatenated? 14:17 kados thd: can you think of a real world example of what this would look like? 14:18 thd kados: actually, they should be treated separately to form a separate call number. 14:19 kados hmmm ... and that's problematic too 14:20 kados because k, i and m are Repeatable but H isn't 14:20 kados maybe that's where 'i' comes in? it's listed in Sagebrush as the Call Number Cutter 14:20 kados thd: is that meaningful to you? 14:20 thd $h is the common general part as it should be and does not vary 14:21 thd kados: yes, $i is the cutter number. 14:22 kados thd: so how does the cutter number work? 14:23 thd kados: Tables are used to assing a more detailed number to a work than the general number. The author's last name is an important factor in the tables. 14:26 thd kados: LC cutter tables are rather complex, along with the whole LC classification scheme. 14:29 kados thd: are there any good docs explaining it? 14:30 kados thd: if I'm going to go through the trouble to write this script I may as well do it right the first time 14:31 thd kados: wel, I just spent a few minutes googling for the cutter tables but need a better query. 14:33 thd kados: I mostly come up with information about programs, on OCLC that construct the cutter number for you. 14:34 thd kados: Or very brief non-exlanations of cutter numbers. 14:36 kados so it looks like there are some undefined subfields in 952: o, r, u, v, w, y, 0, 1, 4, 5, 7 14:36 kados thd: anything to be done with those? 14:36 thd kados: Do you mean 852? 14:36 kados I guess 9 is undefined too but this dataset uses it for 'cost' 14:36 kados thd: yes 14:36 kados thd: sorry ;-) 14:36 kados thd: I keep doing that 14:38 thd kados: If you read earlier in my koha-devel post, paul had a suggestion, but NPL wisely used 952 instead. 14:38 kados I noticed that ... just wondering if you had anything more to say about it 14:39 kados I just found the 'copies field values' in Sagebrush 14:39 kados it has categories: location, format, currency, vendor, fund, prefix 14:40 kados location: Archive, Education Lap, Faculty Course materials, main Collection, Periodical Storage, Reference 14:41 thd kados: Assigning your own use to anything other than $9, XX9, X9X, or 9XX is dangerous in case a new assingment is made for the MARC standard and you need to make an untimely change. 14:41 kados Format: Book, Bulletin Brd. Fabric, Cassette, CD, Children's Fiction, DVD, Ed Lab Spanish, Ed. Curriculum, Periodical, Reference Book, Reserve Book Sys. Theo, Video 14:41 thd kados: what field are they in? 14:42 kados thd: ok ... so what I'm thinking is ... I read the 952s, fix them if they are missing things (like a, etc) then construct a 942 and 952 for Koha items and biblioitems 14:42 kados thd: it doesn't say the MARC fields 14:43 thd kados: Wha doesn't say the MARC fields. I do not understand that sentence. 14:44 kados sorry ... I'm just looking at the Sagebrush interface 14:44 thd kados: What doesn't say the MARC fields? I do not understand that sentence, or how to make my own sentences :) 14:44 kados and it has a 'copies field values' 14:44 kados and it allows you to add or deleve values within each of the categories 14:44 kados so for Format, the values are Book, etc. 14:45 kados the upper level categories are location, format, currency, etc. 14:46 thd kados: Are you saying that these values may not even be stored in a local use field? 14:46 thd or $9 subfield 14:46 kados I think they are stored in 852 somewhere but I'm unsure 14:46 kados I'm trying to find them now 14:47 thd kados look at the mapping from my koha-devel post 14:48 kados ok ... so Location is in 852b 14:48 kados Vendor is in 8525 14:49 thd $b - Sublocation or collection (R) 14:49 thd The specific department, library, collection, etc., within the holding organization in which the item is located or from which it is available. 14:49 kados Format is in 6, 14:50 kados Fund is in 7 14:50 kados Prefix is k (of course) 14:50 kados I don't see Currency listed in 852 14:50 thd kados: do you mean they put binding format in the standard 852 linkage $6 subfield? 14:51 kados hmmm ... here are some of the values: 14:51 kados Sunday School Curriculum 14:51 kados Pamphlet 14:52 kados Book 14:52 kados etc. 14:52 kados so I'm not sure if those are binding formats 14:53 kados they could almost be itemtypes 14:54 kados so I take it that's nonstandard then 14:54 thd kados: currency is in 365 $c, if anyone uses the MARC 21 standard for that. 14:55 kados Sagebrush Athena doesn't have currency in 365 $c ... I don't see it listed in the MARC mappings (course it's only in the documentation ... I can't look at the actual mappings through the program) 14:56 kados so I'm thinking maybe that's a locally defined field internal to Sagebrush 14:56 thd kados: $6 in holdings fields is supposed to be used for complex holdings of that Koha does not support yet. Your examples are certainly not standard so that is not a problem. 14:57 kados so the part I'm still confused about ... is how do associate subfields 14:57 kados s/do/to/ 14:58 thd which subfields with what? 15:00 kados so take a single record's 852 field 15:00 kados there are several repeatable subfields within that 852 tag 15:01 kados specifically, b, c, e, f, g, i, k, m, s, x, and z 15:01 kados so if we're taking our cue from the way that repeatable tags work 15:02 kados we'd assume that if one of the subfields repeats then all the populated subfields should repeat 15:02 kados and that there is some way to map all the associated subfield sets 15:02 kados am I making sense? 15:03 kados I don't know if that's the role of the cutter, or $8, or what 15:03 kados do you have any ideas? 15:03 thd kados: Yes, that makes perfect sense. 15:05 thd kados: My understanding of $8 is poor as it is not well documented in standard documentation and cataloguing books that I have, however most examples show it linking between different fields not subfields within the same field. 15:06 kados so ... assuming that there is some way to map them, we have another question about how to display them to the user ... if we're dealing with sets of subfields then does each set of subfields refer to a item? or can an item have multiple sets of subfields ? 15:06 kados it's confusing 15:06 thd kados: If you assigned a sequence to the repeated subfields based on the sequence appearing in the field would they match correctly? 15:07 kados well the thing is I'm not even sure if MARC::Record supports sub-subfields ;-) 15:09 thd kados: For display, I imagine the best that Koha can do now is multiple assignments from 852 to the same 952 subfield separated by a space, if that would even work. 15:10 kados maybe one way to do it would be to highlight the relevant 'linked' subfields if you roll the mouse over one if them 15:10 thd kados: I have very limited experience with MARC::Record, which does not go to solving this type of problem. 15:11 thd kados: how would that work exactly? 15:11 kados so you click on marc display 15:11 kados it brings up all the tags/subfields 15:11 kados scroll down to the first 952 15:12 kados you have: 15:12 kados a 15:12 kados b 15:12 kados b 15:12 kados c 15:12 kados c 15:12 kados e 15:12 kados e 15:12 kados f 15:12 kados f 15:12 kados g 15:12 kados g 15:12 kados etc. 15:12 kados when you roll over the first b or c, etc., the other members of that set are 'highlighted' 15:12 kados so you can tell that they are related 15:13 kados you could do it in CSS 15:13 kados does that make sense? (or does it betray a missunderstanding of what's going on here? ;-)) 15:14 thd kados: Would not the patrons prefer record detail instead of MARC view? 15:14 kados yea ... and that's the default 15:14 kados which is why I specified first ... click on marc display ;-) 15:15 thd kados: What would happen in the record detail display? 15:15 kados I wish there was an easy way to test a record set for repeating sub-subfields in 952 15:15 kados no idea 15:15 kados maybe I should build MARC::Batch script that checks 15:15 kados then we'd know whether our musings were moot or not ;-) 15:15 kados I suspect they are ;-) 15:16 thd kados: What would the MARC::Batch script check for? 15:16 kados thd: repeating sub-subfields in 952 15:17 kados sorry ... 852 15:17 kados I keep doing that ;-) 15:17 thd But I was assuming that you had found them already. 15:19 kados no ... it was a theoretical question ;-) 15:19 kados because I didn't realize that it could happen before I began the script 15:20 thd kados: The usual cases would be minor unless this was a large library many instances or the collection was of a special type. 15:25 thd kados: Usually there would be cases such as an reference work on the reference work shelf with the index held at the indexing table, bound periodicals on the shelf if older than X otherwise at the current periodicals section, a multivolume set where one volume is a large folio and held on the special large folio shelving.,etc. 15:27 kados gotcha 15:27 thd kados: Therefore, unless these types of instances were a very numerous part of the whole this should not be a significant problem. 15:27 kados right ... so if you're LOC it matters ;-) 15:27 thd :) 15:30 kados thd: so ... what do you think about 852$p being the barcode for the item 15:31 kados it seems to be like it's not quite right 15:31 thd Any large enough library, has this issue in great numbers or special libraries heavily concentrated on serials with microform, database, bound, etc.; or pamphlets and such with material held in folders and boxes. 15:31 thd kados: that is a common usage for piece designation. 15:32 kados thd: what about 'i' as 'cutter' instead of 'Item part'? 15:33 kados thd: I can't seem to find anything on cutter anyway ... what the heck is it? 15:34 thd kados: Cutter is the item part as opposed to the general part of the call number. 15:35 kados ahh ... so if you had multiple copies of an item you might designate a cutter? 15:35 thd kados: Many items about the same subject to the finest detail used for the classification scheme have the same general call number yet need a unique number to tell them apart. 15:35 kados shouldn't that go at the end? 15:36 kados should it go k, h, i, m or k, h, m, i ? 15:36 thd copy numbers would go after cutter numbers 15:38 kados 852 1 _bMain Collection 15:38 kados _h92SHE SHE 15:38 kados _p10687 15:38 kados _6Book 15:38 kados _9p3.00 15:38 kados _p10687 15:38 kados _819990116 15:38 kados so in this example 15:38 kados the call number should be: 15:39 kados 92SHE SHE 15:39 thd $k juvenile $h 941.32 $ A47 $t copy2 $m whatever you need that for unless populated by $t when copies exceed one 15:40 kados in this example: 15:40 kados 852 1 _bMain Collection 15:40 kados _h372.19 15:40 kados _p10967 15:40 kados _6Ed. Curriculum 15:40 kados _9p100.00 15:40 kados _p10967 15:40 kados _819990118 15:40 kados _kED 15:40 kados _iBEK 15:40 kados _mTEd/Gr1 15:40 kados _5Publisher 15:40 kados _7General 15:40 kados the call number is: 15:41 kados ED 372.19 BEK TEd/Gr1 15:42 kados thd: does that seem right? 15:42 thd yes 15:43 kados but there are two levels here 15:43 kados there's the biblioitem level 15:43 kados and the item level 15:43 kados so what's the correct sequence for the biblioitem level? 15:44 kados 'i' is ommitted for that right? 15:45 thd kados: $i is needed for all copies 15:46 kados but for mapping purposes $i shouldn't be included in biblioitems.classification 15:46 thd kados: $t if more than one copy existed, and $m would be ommitted. 15:46 kados but it should be in items.itemcallnumber 15:46 thd yes 15:46 thd retract my last yes :) 15:47 kados now I'm very confused ... $t is Copy 15:47 kados but what does that mean? 15:47 thd for biblioitems.classification you would want $k$h$i 15:47 kados I guess $t is the biblioitems level 15:48 thd $t is the copy number which you only need to display if there is more than one copy at the same branch 15:49 kados in a one-branch system that happens all the time 15:49 kados I wonder if Koha keeps track of this number 15:51 kados w 15:51 kados oops ;-) 15:52 thd $t is items level so you would have items.itemcallnumber as $k$h$i$m unless there is more than one copy at the same branch such that $k$h$i$t$m would be helpful. 15:53 thd kados: Are ther any examples of very popular titles held in multiples that you could check to see how that works on NPL? 15:54 kados thd: harry potter's always a good one ... or lord of the rings 15:55 thd From LC this example shows $m. 852##$aDLC$bc-G & M$hG3820 1687$i.H62$mVault 15:59 kados where's that ? 16:01 thd kados: fiction may be an odd example but certainly the one with greatest demand for multiple copies generally and I find the same call number with no copy differentiation in the call number in detail view at NPL 16:01 kados well NPL probably isn't the greatest example 16:02 thd kodos: http://www.loc.gov/marc/holdings/echdloca.html , I do not know what book that example came from. 16:04 thd note: the indicators are both blank in the LC example. I guess they always know that they are using LC classification at LC :) 16:06 thd kados: what is the largest library where paul has installed Koha? 16:09 kados thd: not sure of the name ... but it's about 44,000 records IIRC 16:11 thd I was just wondering about seeing how copy number might be represented in the OPAC there. 16:13 thd Maybe the patron need not consider the copy number mportant as long as it is available and undamaged. 16:15 kados thd: I'm concerned that with a data import from Athena ... if Athena tracks sub-subfields and Koha loses that data some clients won't like that ;-) 16:15 kados thd: probably not an issue with this client 16:15 thd Just because copy 2 maybe on a spine label is no reason for it to appear differentiated in the OPAC unless it is a special copy with the author's own doodles or something. 16:15 kados thd: but I'd rather not be surprised ;-) 16:16 thd kaodos: Does the existing Athena system you are migrating ever show copy numbers in the OPAC? 16:18 kados thd: I'm in the middle of something else so I can't check the OPAC 16:18 kados thd: and I don't want to lose my place ;-) 16:18 kados thd: but I don't recall seeing them 16:18 kados thd: do you think it's useful to distinguish Format and Itemtype? 16:18 kados I've always been confused about that 16:19 kados like take NPL for instance 16:19 kados if you go to search.athenscounty.lib.oh.us 16:19 kados and click on 'search by format and data' 16:19 kados I've always found the formats to be strangely grouped 16:20 kados I can see distinguishing between Audiobook and CD 16:20 kados but audiobook vs. Juvinile Audiobook is a harder case to make 16:20 kados taxonemically I mean 16:21 kados it's like comparing apples to oranges in my book 16:26 thd kados: The problem is the loss of functionality for multiple biblioitems.itemtype for the same items.itemnumber when a one to one relationship was established between biblioitems.biblioitemnumber and the MARC record for MARC Koha. This is not a problem for non-MARC Koha. 16:29 thd kados: I would suggest adding more columns or some other solution from reading indexed values held in a MARC record would address this issue. 16:31 thd kados: are you clear about why you need 852 $i as part of the call number in biblioitems.classification? 16:33 kados I thought I didn't need it 16:33 kados I thought $i was for items.itemcallnumber 16:38 thd kados: you should use $i in both cases where $i is the last part in biblioitems.classification but not necessarily the last part in items.itemsitemcallnumber . 16:40 kados ? 16:40 thd kados: The cutter number distinguishes authors and titles in the same general classification but it does not distinguish copies of the same author title. 16:40 kados right 16:41 kados so in biblioitems.classification I have: $k $h $i 16:41 thd kados: exactly 16:41 kados and in items.itemcallnumber I have: $k $h $i $t $m 16:41 kados right? 16:44 thd $t is probably not needed. It does not need to appear for the user and Koha has no problem distinguishing copies without $t in the call number. 16:46 thd $t or a substituted value is definitely need for items.itemnumber. 16:48 thd kados: After, a few IRC chats with chris and rach, I started to grok Koha and became much happier. 16:49 kados thd: Koha takes care of items.itemnumber 16:50 thd kados: yes, but does it do so consistently with existing holdings where you may have multiple 852 fields to import for multiple copies. 16:51 kados ahh ... I see ... I'm not sure about that 16:52 kados it may be moot for this data since I don't see a $t even when multiple 852s exist 16:53 thd kados: I assume bulkmarkimport.pl addresses that issue in some way when linked correctly in the MARC to Koha links for items. 16:53 thd kados: So how does the system distinguish the two 852s? 16:54 kados no idea :-) 16:54 kados it's a question for paul I guess 16:54 kados IIRC there is a subfieldid in marc_subfield_table 16:54 kados so that explains how it's handled internally 16:55 kados but I have no idea how it's done when importing/exporting ... how does it know what goes where? 16:55 thd kados: If the Athena system is only using one holdings field, like Koha, then $t would not be needed to match to other fields. 16:57 thd kados: $t is only needed when 852 has some information such as branch and 876 has other information such as cost. 16:58 kados I understand now 17:01 thd kados: Koha puts it all in one place as many simple systems might like those following French Recommendation 995. So, after everything is correctly mapped to 952 or whatever for import into Koha, $t is not needed but it is certainly good to have all the data in the MARC record somewhere even if it is also in the Koha tables otherwise. 17:05 thd kados: presumably, bulkmarkimport.pl does something useful to populate a value in 952$t for example, if 952$t is blank in the import records but linked to items.itemnumber in the MARC to Koha links. 17:12 thd kados: What would happen in my 952 $t linked to items.itemnumber import example where 952 $t is blank or where 952 $t not present in the import record? 17:13 kados it seems problematic 17:13 kados I'm not really sure 17:13 kados what we need to do 17:13 kados is ask paul when he gets back 17:14 thd kados: haven't you done this many times before :) 17:14 kados what ... ask paul? 17:14 kados :-) 17:15 thd no, migrate holdings for libraries :) 17:16 thd kados: You know, Liblime's business. 17:16 kados :-) 17:16 kados yea ... I've done it a bit 17:17 kados but never really delved into the MARC so deeply 17:17 thd Did you cheat before and use SQL to populate the holdings data? :) 17:18 kados :-) 17:18 thd Is that :-) a yes to cheating with SQL? :) 17:18 kados well this is the first time I've had to play with the data before importing with bulkmarcimport 17:18 kados i.e., it's the first time 952 wasn't already the default 17:19 kados so I've never really had to learn the 852 conventions 17:20 kados because 9xx is so flexible it's not hard to figure out 17:20 kados but 852 adds complexity because it's rigidly defined 17:20 thd kados: I would certainly map the 852 stuff to 952 first. Then, you should be able to do what you had done before. 17:20 kados way too much coffee :-) 17:20 kados thd: you gonna be around in a hour or so? 17:21 kados thd: yea ... I'm mapping 852 to 952 right now ... 17:21 thd kados: yes kados, I will be here. 17:21 kados thd: ok ... talk to you soon ;-) 19:07 kados thd: I'm back 19:09 thd kados: I am still here, having forgotten to eat :) I have been working on perl script example of what Zebra and CQL should do to find media type a few levels deep, past the leader and into 008. 19:09 kados neat 19:10 thd actually I have had this mapped in Zope for 007 and 008 as well but for MARC 21 only. 19:12 kados thd: I'm still not sure of the sanity of mapping the $t before importing records into Koha 19:13 thd I made the Zope mapping over a year ago. I am adding UNIMARC and leaving out a lot of detail that is not needed fo a simple example. UNIMARC is different but very close with the leader or record label as it is known in UNIMARC. 19:14 thd kados: I would suspect that $t does not need to be present in 952. 19:16 thd kados: Maybe Koha MARC Check does not even raise an error if items.itemtyp is not mapped to a MARC subfield. 19:16 kados I don't think it does 19:16 thd s/itemtyp/itemnumber/ 19:16 kados but it's a major problem for KOha 19:16 kados ahh ... yea it definitely doesn't in that case 19:17 thd kados: What is a major problem for Koha? 19:17 kados Koha needs every item to have an itemtype 19:17 kados or else it doesn't know what to do with it 19:17 kados when you try to run a transaction 19:18 thd kados: Why is that a problem in itself? 19:19 kados it's not 19:19 kados but if you import without getting your itemtypes mapped you'll have a problem 19:19 kados and I think I found a bug in the rebuildnonmarc script 19:20 kados for some reason it was putting a | in some of the itemtypes after I ran it 19:20 kados this is interesting: 19:20 thd kados: sorry, I guess my mistyping had confused the issue :) 19:20 kados "Do not expect to have every Koha table.column mapped to a MARC subfield. Some (such as biblionumber, biblioitemnumber, and itemnumber) are values generated by Koha and will probably be automatically mapped. Others are flags which are set in the course of normal circulation activities and will contain information that is not part of your MARC record." 19:22 thd kados: It would be nice if there was an explicit list about what is automatically mapped and to where. 19:22 kados that would be nice 19:23 kados we need to start a list of things to ask paul about 19:23 kados :-) 19:24 thd kados: I have frequently had dfficulty getting attention on IRC. 19:24 thd his attention 19:24 kados yea ... he's a busy guy 19:24 kados thd: got a question about your email to koha-devel 19:24 thd yes 19:25 kados you say that Location should be 952$c and that it should be generated from 852$c 19:26 kados in my data, it looks like 852 $b is what's being used 19:26 kados 852 $c is unused as it $a 19:26 kados as is $a 19:26 thd what values do you find for those fields/ 19:26 thd ? 19:26 kados Main Library 19:26 kados Periodical Room 19:27 kados Archive 19:27 kados Education Lab 19:27 kados Reference 19:27 kados Faculty Course Materials 19:27 kados etc. 19:28 thd In what subfield are those? 19:28 kados 852 $b 19:31 thd an example form concise MARC 21 holdings is 852 81$a[location identifier]$bMain$cmezzanine stacks 19:31 rach howdy 19:31 kados hey rach 19:31 thd hello rach 19:31 kados thd: that's clearly an idealized record ;-) 19:31 thd :) 19:32 kados so the thing is, I know what the proper value for $a is 19:32 thd mostly they seem to use real records as examples. 19:32 kados it's the institutional code for their library (which I know) 19:33 kados and I'm not clear whether Koha's 'Location' is meant to be $b or $c or a concatenation of the both of them 19:33 kados thd: do you have any ideas on that? 19:33 kados rach: you might too 19:33 kados $a Location is the Institution 19:34 kados $b is the specific department, library, collection, etc., within the holding organization in which the item is located or from which it is available. 19:34 kados $c is the Shelving location 19:34 kados rach: do you happen to know which of these is most appropriate for Koha's 'Location' field? 19:34 rach hmm b or c I would think - not the branch 19:34 kados chris: or do you? 19:34 thd rach chris: what does items.location do? 19:35 rach I doubt chris is here, it's sunday lunch time 19:35 kados right .. prolly still sleeping ;-) 19:36 rach From my discussions with Paul, I think it's the department or collection 19:37 kados so that would probably be $b then 19:37 rach but you could use it for a department-shelf joined thing I guess, 19:37 kados maybe ... was that a Katipo-created or a Paul-created field? 19:37 kados location I mean 19:38 rach no that's paul - and so it's not well represented outside of the marc "view" 19:38 thd kados: Is the library you are migrating a one branch library? 19:38 kados thd: yes 19:38 rach it's one of the things I would like to get generalised 19:39 kados thd: do you happen to know whether the $2 is always generated from the First indicator in the record? 19:39 rach the libraries we work with use class - which is a construct from dewey and something else actually in the display 19:39 kados rach: yep 19:39 kados rach: we need to handle the seperate classification elements separately in Koha 19:40 kados rach: rather than munging them together 19:40 rach well yep, I'm kinda surprised there isn't something for shelf as well as location 19:40 kados rach: that means getting more specialized and standards compliant with LOC and Dewey while still allowing for local stuff 19:40 kados rach: there is ... but only in MARC ;-) 19:40 kados rach: it's not in the Koha tables 19:41 rach I wonder if there is a reason for that 19:41 thd kados: commonly 852 $a might be institution, $b might be branch, $c might be shelf location. However, if the library has no branches then $b would be available for alternate assignment. 19:42 kados thd: makes sense 19:42 rach so are there only 3 levels? 19:42 kados rach: no 19:42 rach in which case we have the 3 levels? 19:42 kados rach: there are more than three in MARC21 19:42 thd what 3 levels? 19:43 kados in fact if I"m reading this right the levels are pretty much unlimited 19:43 thd 3 levels of what? 19:43 kados in MARC21 19:43 kados because you've got b and c and f and g all of which are repeatable 19:43 kados f and g qualify a b and c 19:44 kados then you've still got the levels of classification in h, i, j, k, and l 19:44 kados each of which further qualify either the classification of the location 19:45 kados or the location 19:45 rach oh ok - that was my question - wether there was only 1,b, c 19:45 rach a,b,c, 19:45 rach you could write what I know about marc on a postage stamp :-) 19:46 kados I don't have a very good working knowledge of MARC 19:46 kados but I'm hoping that will change 19:46 kados thd has been a big help 19:46 rach I'm trying to employ someone to know this stuff for me 19:46 kados :-) 19:46 thd kados: I had omitted mapping $f and $g, assuming that Koha was not ready yet for libraries that used them, although, $f and $g could be concatenated with $c. 19:47 kados thd: right ... I figured that ... Athena doesnt use them so it's not a problem in this case 19:48 kados thd: what about my question about $2 19:48 kados thd: do you happen to know whether the $2 is always generated from the First indicator in the record? 19:48 thd libraries know things for everyone if everyone knows how to find things in them. 19:49 thd kados: sorry, I had forgotten that question. 19:49 rach kados - just looking through mail - I would say we (katipo) have the biggest interest in acquisitions 19:50 kados rach: cool ... 19:50 rach as all our clients use one or other of the acquisitions packages 19:50 kados rach: we'll have to get Chris to take a look at EDI, Soap and Web Services 19:50 kados rach: to see if they have anything to offer your clients 19:50 rach we don't have anyone who does acquisitions through something else 19:50 thd kados: 852 $2 should be present only when 852 first indicator is set to 7. 19:50 kados rach: maybe your clients would be willing to sponsor development? 19:51 kados thd: bummer 19:51 thd kados: otherwise, 852 first indicator is controlling. 19:52 rach I guess if anything looks compelling they may 19:52 kados thd: what do you think about using the 852 first indicator to categorize record classifications 19:52 rach generally they are really happy to stop using excel :-) 19:52 kados rach: :-) 19:52 kados rach: well I was really surprised when I first looked at EDI 19:52 kados rach: it pretty much automates the whole buying process ... including cataloging 19:53 kados rach: did you see my review of it on the liblime wiki? 19:53 rach nope 19:53 thd kados: do your records have 852 $2 with 852 first indicator set to something other than 7? 19:53 kados rach: http://wiki.liblime.com/doku.php?id=koha24rmnotes#acquisitions_and_cataloging 19:53 kados thd: haven't checked yet 19:53 rach you can't get to the wiki from the liblime site tho? 19:54 kados rach: no ... it's an 'internal' wiki sofar 19:54 kados rach: where 'internal' includes the Koha community ;-) 19:54 kados rach: but it's not really good for sales ;-) 19:54 kados rach: wikis rarely are ;-) 19:54 kados rach: http://wiki.liblime.com/doku.php?id=koha24rmnotes#acquisitions_and_cataloging 19:55 kados rach: there's a good link there as well 19:55 kados rach: that explains the process in more details 19:55 kados rach: yep ... entirely 19:56 thd kados: EDI is not one international standard, I have a lot of info about that and have interrupted my quest to add more while working wiht Koha. 19:56 kados rach: but these days most book vendors are going with either EDI or some form of Web Services 19:56 kados thd: yep 19:56 rach we should get rosalie to keep an eye out for her suppliers offering that sort of service 19:56 rach we did moot the idea a few years ago and they decided it wasn't worth their while 19:57 rach but it would be worth revisiting 19:57 thd rach: Is there a particular EDI system widely adopted in New Zealand and / or Australia? 19:57 rach I've no idea - I haven't heard of one 19:58 rach there aren't a lot of book sellers in NZ 19:58 rach the libraries are buying direct from england and the states 19:58 rach we are a tiny market, so only a small number of NZ publishers would be selling NZ books 19:58 kados thd: right 19:59 thd In many countries every vendor has his own system, and some vendors even think simple email is sufficient. 20:00 rach Yeah, we don't tend to get libraries buying all their supplies from one vendor - there are orgs trying to be "book brokers" basically but I don't know how successful they are 20:00 rach so there are offerings to sell books + records + already covered in plastic etc, but the libraries we work with aren't taking them up on it 20:02 rach anyway si is home with lunch, I'll let you get back to your discussion :-) 20:02 rach catch ya later 20:02 kados cya 20:02 thd rach: In the US, libraries generally will not buy from any vendor that does not supply extra services such as MARC records, etc. with their purchase, because the library labour costs are too high otherwise. 20:04 kados thd: so what do you think about this 20:04 thd kados: EDI was first created by the US government, just like the internet. 20:04 kados koha needs 20:04 kados Location 20:04 kados Call number 20:04 kados Status 20:04 kados Location is concatenated from the 852 $a, b, c, g, f etc. 20:05 kados Call number is concatenated as we've already discussed 20:05 kados but what about Status? 20:05 kados shouldn't a library be able to define their statuses just like they can define location and call number? 20:06 thd kados: status is not part of MARC 21 or UNIMARC holdings except for lost, access restrictions, etc.; but not charged out or charged in. 20:07 kados so MARC21 does define lost and access restrictions? 20:07 kados I don't seee that in the 952s 20:07 thd kados: yes, extensively. 20:09 thd 876-878 $h and very thoroughly in 506 20:11 kados I don't think sagebrush Athena uses any of those fields 20:11 thd kados: many institutions must use something much simpler and non-standard. 20:13 thd kados: Most systems use local use fields for holdings and ignore large parts of the standard. That makes for por record exchange and expensive conversions and must really complicate ILL. 20:13 kados I can't find anything on 506 on the loc site 20:14 kados I guess it's not 'concise' 20:15 thd kados: Incompatibility, is probably considered a revenue enhancing feature for ILS companies :) 20:15 kados :-) 20:15 thd kados: 506 - RESTRICTIONS ON ACCESS NOTE (R) 20:17 thd http://www.loc.gov/marc/bibliographic/ecbdnot1.html#mrcb506 20:18 kados thx 20:23 thd TLC has the public domain content of the full format information in what is probarly a proprietary arrangement of the material. Well you do not need a subscription to the information from LC or copy of ITS MARC for windows to get to it, http://www.itsmarc.com/crs/CRS0000.htm . 20:26 thd kados: lost other long term status information is in 876-878 $j. 20:27 kados cool 20:27 kados thanks! 20:28 kados thd: in Biblio mappings ... I think 520a is correct for 'abstract' do you concur? 20:29 kados thd: I don't see that covered in your email 20:30 thd kados: yes, but my email was only about holdings not all MARC to Koha table mappings 20:30 kados thd: right ... 20:31 kados thd: do you have any thoughts on 'serial' in the Koha field? 20:31 kados thd: is there a koha field to map 'serial' to? (I can't find one) 20:31 thd kados: serial is a problem in MARC :) 20:31 kados :-) 20:32 kados thd: is there any way to distinguish between a 'serial' record and a 'non-serial' record? 20:32 thd yes 20:33 thd If the leader position 07 is b or s in MARC 21 or record label position 07 is s in UNIMARC then the item is a serial. 20:35 kados interesting 20:35 thd kados: identifying a book or text requires first knowing that it is not a serial. 20:36 kados that seems closely linked to itemtype 20:36 kados meaning it would make sense to have a 'serials' or a 'periodicals' itemtype (they are the same right?) 20:37 thd all periodical are serials but not all serials are periodicals 20:38 kados gotcha 20:38 thd For the most basic media types look at the table http://www.itsmarc.com/crs/Bib0021.htm 20:41 kados thd: I guess many libraries aren't satisfied with the leader for itemtypes eh? 20:45 kados thd: not to beat a dead horse 20:46 thd kados: well, there is more information in 008, maybe 007 or 006, as well as 245 general material designation (if present) $h, and 300 :) 20:46 kados thd: but do you suppose 'dewey' and 'subclass' should be mapped to 852 fields? 20:46 thd For serials 008, position 21 - Type of continuing resource 20:46 thd # - None of the following 20:46 thd d - Updating database 20:46 thd l - Updating loose-leaf 20:46 thd m - Monographic series 20:46 thd n - Newspaper 20:46 thd p - Periodical 20:46 thd w - Updating Web site 20:47 thd | - No attempt to code 20:48 kados thd: maybe instead of just using 'classification' we should start using classification, dewey, and subclass 20:48 kados thd: for 852 $k, $h, $i 20:48 kados thd: what do you think? 20:50 thd kados: What does biblioitems.subclass do in Koha? 20:51 kados thd: dunno ... but I assume it's available from the OPAC as a variable 20:51 kados i was thinking it might be subclassification 20:51 kados like maybe the 'suffix' for classification 20:53 thd kados: That makes sense. I know biblioitems.dewey does something, as I can see from the NPL OPAC. 20:54 thd kados: How is biblioitems.subclass linked to MARC at NPL? 20:54 kados thd: it's not 20:55 thd I am going to grep the source, if that may help. 20:55 kados thd: biblioitems.dewey is 'classification' and is just 942 $k 20:55 kados thd: in NPL 20:56 kados thd: it probably won't ... 20:56 kados thd: I think it just pulls out the column names as a variable and sends that variable to the template 20:56 kados thd: so the actual columns probably don't appear anywhere in the source 20:57 kados thd: and I don't think any template designers are putting seriestitle in 20:57 kados thd: so i doubt it's in the templates either ;-) 20:57 kados thd: I'm not actually sure what the advantage of seperating the classification is ... 20:58 kados thd: just knowing it can be done has me wondering if it should be ... 20:58 kados thd: what do you think? 20:58 thd It should be of course, the problem is knowing what it was designed to do exactly. 21:01 kados what's the advantage of it being separate? 21:01 kados I can't think of one 21:02 thd It is in Biblio.pm, Search.pm, opac-moredetail.pl, opac-moredetail.tmpl, etc. 21:03 thd The advantage depends on its exact function. 21:04 thd If it is meant to store detailed classification or a cutter number then it may aid matching only the general number in a search. 21:05 kados right 21:06 kados ok ... so MARC surely MARC distinguishes between publication date and copyright date right? 21:06 kados thd: i see 046 $c maybe? 21:08 thd Maybe dewey is meant to hold the base 3 digit dewey number and subclass would be the decimal values after that. 21:08 thd kados: 046 ? 21:09 kados thd: for sorry ... 045 21:09 kados thd: for the copyright date? ... publication date is in 260 $c 21:10 kados thd: but I have no idea where to find copyright date 21:10 kados thd: also ... what should the date formats be? 21:10 thd 046 - SPECIAL CODED DATES (R), 045 - TIME PERIOD OF CONTENT (NR) 21:11 thd now I understand your question I thought you were still asking about bibblioitems.dewey and biblioitems.subclass 21:11 kados thd: :-) 21:11 kados thd: sorry for not indicating a change in topic ;-) 21:12 kados thd: I can't really see a reason to keep them split up for this particular client though it's useful to know it can probably be done 21:12 kados and I doubt they will care about differentiating between publication and copyright date 21:12 kados but I'd be interested if MARC did ... it doesnt' look like it does fromt he docs on 046 21:15 thd kados: copyright dates may be thought more important for identifying an edition but that is an AACR2 question rater than a MARC question. 260 $c - Date of publication, distribution, etc. (R) May contain multiple dates (e.g., dates of publication and copyright). 21:16 kados thd: gotcha ... so basically we'd have to play with the MARC data to differentiate between them 21:16 thd kados: I have extensive experience writing regular expressions to disentangle copyright and publication dates in MARC records. 21:16 kados thd: :-) 21:16 kados thd: quick regresion (sorry) 21:17 kados thd: since my client is using dewey 21:17 thd kados: Stephen has a simple script in the Koha diary in Perl 21:17 kados thd: i think i'll be using Koha's 'dewey' to map to 942$k (which will be a concatenation of 852 $k $h $i) 21:18 kados thd: that means that I can map classification to either 010 or 050 ... 21:18 kados thd: I'm confused about the difference between the two 21:19 kados thd: 010 is LOC Control Number and 050 is LOC Classification (Call no.) 21:19 thd kados: my scripts used a Perl like regular exression language for MSDOS, otherwise I would have a lot of good code to contribute. At least I can consult my old code if it is necessary. 21:19 kados thd: cool ... I think I'll ask the client if they care before I embark on that (I've added it to my list of things to add) 21:19 thd In an LC record 001 and 010 are usually the same or the same in all improtant respects. 21:20 kados thd: the client expressed an interest in moving to LOC from Dewey 21:21 kados thd: so I figure if I keep Koha's 'classification' mapped to the correct MARC field that will be 'a good thing'TM 21:21 thd 001 is the control number, 010 is the LCCN which is the LIbrary of Congress Card Number or Library of Congress Control Number but is not the classification number. 21:23 kados so 050 $a it is 21:23 thd 050 is the Library of Congress Classification Number 21:24 thd yes but $b is the cutter number 21:25 kados thd: so that'd probably be a good link for 'subclass' eh? 21:25 thd Actually I suspect my suggestion before is right about subclass 21:25 kados thd: BTW: what's up with 082 $a being the Dewey classification 21:26 kados thd: it's in 082 and 952? 21:26 kados thd: erp ... 082 and 852? 21:26 thd you mean 852 21:26 kados almost always ;-) 21:27 kados except when I mean 952 ;-) 21:27 thd :-) 21:28 thd 852 is for the item 050-088 is the assignment for the MARC record generally. 21:31 kados so I suppose I should create a hybrid LOC classification from 050$a, $b eh? 21:31 kados put that in the 900s somewhere 21:32 kados and use that as the 'classification' mapping 21:32 thd For the biblioitems.dewey biblioitems.subclass distinction, I suspect that would be in the case of 942.32 A47 for example, 942 would be dewey and .32 would be subclass and A47 would be cutter and not count. 21:36 thd The above example is Dewey, LCC might be 050 10$aBJ1533.C4$bL49 where BJ1533 is dewey and .C4 is subclass and L49 is cutter and not counted in the dewy subclass distinction. 21:39 kados thd: so I think I'm going to stick with 'dewey' as a concatenated 852 $k $h $i 21:40 kados thd: and classification as 050 $a 21:40 thd yes, you could concatenate 852$k, 050 $a, 050 $b, and 852 $m to use for items.itemcallnumber. 21:41 kados thd: why add the 050 if they are using dewey? 21:41 thd As a reserve somewher for when they convert 21:42 kados thd: ahh ... but I think that items.itemcallnumber is displayed in the OPAC 21:42 kados thd: and 952$k is a dewey number so you'd get $dewey $LOC $dewey :-( 21:43 kados thd: unless I'm not understanding 21:43 thd LC cuttering is different from Dewey cuttering but ultimately it is an instituional number that is used to distinguish from other items with the same general call number. 21:44 thd s/items/records/ 21:44 thd or s/items/titles/ 21:45 thd 852 $k is the call number prefix and $852 $m is the call number suffix. 21:46 thd They are not necessarily related to the classification scheme in use. 21:48 thd Common examples of $k may be JUV for juvenile, and we had an example of $m from LC with vault to specify a particular location. 21:48 kados thd: right ... I see that now since the indicator determines the classification scheme 21:50 thd :) 21:52 thd not in one 852 example from LC but everyone knows which classification LC uses :) 21:55 thd Actually, outside the reading room etc. LC cannot use the LCC to shelve because that would require too much shifting for the flood of new material. They just use a time of accession based number similar to LCCN, if not LCCN. So they add nwe books to the empty stacks sequentially. 21:57 thd Outside the reading room etc. LC stacks are closed so you have no direct browsing advantage from the classification scheme in LC stacks themselves. 22:05 thd Distinguishing copyright date form publication date in a diverse collection of real records can be very tricky. Stephen's approach in Koha Diary may work well. A 'c' for copyright is good clue. The variance in usage convetions and cataloguers individual practises over 100 years of records including the retrospectively convererted PREMARC file is enormous but a good set of regular expressions can catch almost every instance. 22:29 thd kados: The copyright vs. publication date problem is a problem with full MARC records. After converting to something like MODS, similar issues are much worse for many fields that are no problem if you always have access to the original MARC record. 22:30 thd kados: are you still there? I have observed something about your proposed dewey mapping. 22:59 kados thd: I'm still here 23:00 kados thd: what have you observerd? 23:03 thd If my surmise about the use of biblioitems.dewey and biblioitems.subclass is correct 852 $k $i should not be used in biblioitems.dewey 23:05 thd kados: they should, however, be used in biblioitems.classification. 23:07 kados thd: so what do you propose for the mapping scheme? 23:09 thd kados: This may be unimportant today if you have no dewy or subclass in the NPL template, unless they are still used in the search in a hidden way. 23:09 kados thd: dewey and subclass aren't there ... but it would be trivial to add them 23:10 kados thd: if there was some advantage to it 23:10 kados thd: but I can't really see one 23:10 kados thd: I've got to get to bed now 23:10 kados thd: I'll be around tomorrow if you'd like to continue :-) 23:10 thd kados: I think they may be for more natural searching. 23:10 thd kados: no rest for coders and the wicked 23:10 kados thd: :-) 23:11 kados thd: (BTW: I tried paul's suggestion about the leader and it doesnt' look like it worked ... 23:11 kados thd: I'll have to bug him about it tomorrow morning (if he's around)) 23:11 thd kados: What part did not work? 23:12 kados thd: the leader doesnt' show up at all in the 000 $@ field ... it's just blank 23:12 kados thd: g'night ;-) 23:12 thd kados: using what method of import 23:13 kados thd: bulkmarcimport 23:14 thd kados: I do not think that paul added support for bulkmarkimport.pl for the leader yet unless you know otherwise. 23:14 kados so where did he add support for the leader? 23:14 thd kados: Had not Paul directed you to add 000 to the MARC framework? 23:15 kados thd: that's what I did! 23:15 kados thd: 000 with subfield @ 23:15 kados thd: I assumed that the leader would automatically import using bulkmarcimport.pl 23:15 kados thd: after adding that to the framework 23:15 kados thd: and indeed, a 000 does show up 23:16 kados thd: with a subfield of @ 23:16 kados thd: but it's blank 23:16 thd kados: paul explained to me that other import methods use the framework, while bulkmarcimport uses the framework. 23:16 kados huh? 23:16 thd kados: paul explained to me that other import methods use the framework, while bulkmarcimport does not use the frramework.. 23:17 kados ahh :-) 23:18 thd so, if bulkmarcimport is still unchanged ... 23:18 thd good night kados 23:18 kados :-) 23:19 kados thd: If you're still awake this should keep you busy: http://www.ifla.org/VII/d4/wg-franar.htm 23:19 kados thd: The IFLA Working Group on Functional Requirements and Numbering of 23:19 kados Authority Records announces that a draft of "Functional 23:19 kados Requirements for Authority Records" is now available for worldwide 23:19 kados review. 23:21 thd wow, IFLA Guidelines for OPAC displays has been completed in final form but not yet published. 23:26 thd I have never seen a spelt month in ISO format. "Please send your comments by 2005 October 28" 06:50 kados thd: morning ;-) 10:56 thd kados: good morning 11:28 kados thd: :-) 11:28 kados thd: so here's an interesting puzzle 11:28 thd kados: yes 11:28 kados thd: for every 952 there should be a 852 in a record 11:29 kados thd: but there should only be 1 942 per record right? 11:29 kados because 952 is at the item level and 942 is at the biblioitem level 11:29 kados thd: does that sound right? 11:32 thd kados: well in MARC 21 ther mat be 863-865 instead of 852. However those libraries would not be migrating to Koha yet. 11:35 thd There is certainly only 1 field mapped from MARC to the items table if Koha is working as it does now. 11:41 thd kados: Many MARC fields can be linked between MARC and other Koha tables such as biblioitems. Only the Koha items table demands a 1 to 1 correspondence between a single MARC field and a single Koha table. 11:45 kados thd: really? but biblioitems isnt' a repeatable field in the Koha tables 11:45 kados thd: so really, there's only one tag/subfield combo mapped to it 11:45 kados thd: biblioitemnumber I mean 11:45 kados thd: scratch that ... 11:45 kados thd: brain fart ;-) 11:46 kados thd: I guess what I mean to say 11:46 kados thd: is that only one tag/subfield combo can be mapped to each Koha table field 11:46 thd kados: everything could be fit into 952 for linking to Koha if there were enough subfields for all the required mappings. 9 numeric subfields and 26 letter subfields might not be enough for everything you might potentially want to make a column for in the items table. 11:47 thd yes 11:47 kados thd: so I'm trying to figure out whether to add a single 952 ... or a 952 for each existing 852 11:47 kados because as we know, there are multiple 852s 11:48 kados this may reveal an underlying problem with the data model 11:48 thd multiple 852s give you multiple 952s, 1 for each copy of the biblio 11:48 kados for export purposes 11:48 kados thd: but only _one_ of those 952s can be mapped in a useful way to a koha field 11:49 thd kados: what goes wrong with the export? 11:49 kados thd: well say that you map _one_ 952 to Koha fields 11:49 kados thd: you run Koha for several years 11:49 kados thd: during that time, you modify the record ... add items, edit items, subtract items 11:50 kados thd: only the one 952 that is mapped to the Koha fields is modified 11:50 kados thd: meaning that the other 952s are 'bogus' as is the 852 11:50 kados thd: so when you export your data 11:50 kados thd: you don't have accurate holdings data 11:50 kados thd: does that make sense? 11:53 thd a field/subfield combo is linked so that repeating 952 fields are read as additional items on import. If koha can do that on import, it should also be able to add and delete the correct repeated field. 11:54 kados true ... I hadn't thought of that 11:54 kados thd: well what about 942 mappings then ... should there be one per record or one per item? 11:54 kados thd: my guess is one per record 11:55 thd kados: biblioitems are not item dependent. 11:59 thd so, biblioitems can be mapped all over the MARC record, as long as only one value were being read and written to the biblioitems columns. Biblioitems exist in multiples in non-MARC but not MARC Koha.