← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:15 | kados | thd: I think so |
| 12:15 | thd: they have some dewey stuff in $h | |
| 12:15 | thd: and some LOC in 092 | |
| 12:15 | $a | |
| 12:16 | I just spoke with them and they only recently started using LOC | |
| 12:16 | most stuff is dewey and some is internal classification | |
| 12:16 | with the order of 852$k$h$i$m | |
| 12:18 | 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 | say you've got three or four classification types in a single collection | |
| 12:19 | some items are dewey | |
| 12:19 | some are internal | |
| 12:19 | would you want to differentiate betweeen them on the OPAC | |
| 12:19 | say have the dewey ones in a different column | |
| 12:19 | and the internal classification somewhere else? | |
| 12:19 | (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 | Why not just use classification for everything? | |
| 12:20 | kados | cause they started out using an internal system ... then switched to dewey |
| 12:20 | some stuff uses the internal and some uses dewey | |
| 12:20 | 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/holdin[…]loca.html#mrch852 |
| 12:20 | kados | talk about a mess! |
| 12:21 | 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 | 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 | that's in biblioitems | |
| 12:23 | then in items we have | |
| 12:23 | barcode, itemcallnumber, location | |
| 12:23 | 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 | he told me to ask paul about items.callnumber | |
| 12:24 | about items.itemcallnumber | |
| 12:24 | kados | you mean items.itemcallnumber? |
| 12:25 | 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 | fiction for instance | |
| 12:26 | thd | Are they linked to the same MARC subfield? |
| 12:26 | kados | is organized lastname, firstname, etc. |
| 12:26 | yea | |
| 12:27 | 942 $k | |
| 12:27 | here's a good example: | |
| 12:27 | http://search.athenscounty.lib[…]e=neal+stephenson | |
| 12:27 | you can see call numbers for fiction and non-fiction works side-by-side | |
| 12:28 | (well, one non-fiction) | |
| 12:28 | :-) | |
| 12:29 | 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 | thd: yep | |
| 12:30 | binding, paidfor, location | |
| 12:30 | 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 | 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 | 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 | what woud happen to multiple copies of the same item if you reduced MARC Koha to item level only? | |
| 12:38 | s/same item/same biblio/ | |
| 12:41 | kados | so not sure I completely understand ... are you talking about determing the itemtypes? |
| 12:41 | 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 | so you don't really need to specify a itemtype at the item level (ideally) | |
| 12:45 | 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 | Koha's internal system is a bit more sane than that | |
| 12:49 | and FRBR is even closer | |
| 12:50 | thd | Libraries often only have the hardover, so in practise there is less confusion overall. |
| 12:52 | 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 | 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 | 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 | kados: If you do not populate biblioitemsnumber, then you loose non-MARC Koha. | |
| 13:07 | 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 | 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 | 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 | 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 | there are three generations of records | |
| 13:16 | all with different ways of doing things | |
| 13:18 | it seems like I should be paying attention mainly to the 852 tag | |
| 13:18 | and looking at the indicators to see what classification is being used | |
| 13:18 | (hopefully it's done correctly) | |
| 13:22 | 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 | repeatable and not repeatable | |
| 13:25 | kados | ahh |
| 13:25 | 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 | 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 | kados: tying again :) MARC Holdings, Koha, and Migration | |
| 13:28 | kados | found it |
| 13:28 | 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 | 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 | Map 852 $t, 876 $t, 877 $t, and 878 $t to 952 $t for items.copynumber. (If | |
| 13:33 | you have been using $3, you should find some way of combining $t with $3 to | |
| 13:33 | form a unique whole number.) | |
| 13:33 | thd: what did you use to determine the order of the mappings | |
| 13:34 | 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 | 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 | 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 | 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 | 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 | thd: so amont 876-878, which ones normally take precedence (and where would I find out about this in the first place?) | |
| 13:46 | 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 | kados: http://www.loc.gov/marc/holdings/echditem.html | |
| 13:54 | 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 | 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 | thd: I'm unclear as to why some of the 952 subfields are repeatable | |
| 14:05 | like $c Shelving location | |
| 14:05 | or $e Address | |
| 14:05 | 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 | 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 | 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 | 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 | thd: I'm just not sure what to do when I encounter a repeatable subfield within 852 ... is it important? | |
| 14:15 | 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 | thd: but are you sure they should be concatenated? | |
| 14:17 | 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 | because k, i and m are Repeatable but H isn't | |
| 14:20 | maybe that's where 'i' comes in? it's listed in Sagebrush as the Call Number Cutter | |
| 14:20 | 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 | 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 | 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 | 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 | kados: I mostly come up with information about programs, on OCLC that construct the cutter number for you. | |
| 14:34 | 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 | 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 | thd: yes | |
| 14:36 | thd: sorry ;-) | |
| 14:36 | 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 | I just found the 'copies field values' in Sagebrush | |
| 14:39 | it has categories: location, format, currency, vendor, fund, prefix | |
| 14:40 | 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 | 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 | and it allows you to add or deleve values within each of the categories | |
| 14:44 | so for Format, the values are Book, etc. | |
| 14:45 | 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 | or $9 subfield | |
| 14:46 | kados | I think they are stored in 852 somewhere but I'm unsure |
| 14:46 | 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 | Vendor is in 8525 | |
| 14:49 | thd | $b - Sublocation or collection (R) |
| 14:49 | 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 | Fund is in 7 | |
| 14:50 | Prefix is k (of course) | |
| 14:50 | 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 | Sunday School Curriculum | |
| 14:51 | Pamphlet | |
| 14:52 | Book | |
| 14:52 | etc. | |
| 14:52 | so I'm not sure if those are binding formats | |
| 14:53 | they could almost be itemtypes | |
| 14:54 | 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 | 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 | s/do/to/ | |
| 14:58 | thd | which subfields with what? |
| 15:00 | kados | so take a single record's 852 field |
| 15:00 | there are several repeatable subfields within that 852 tag | |
| 15:01 | specifically, b, c, e, f, g, i, k, m, s, x, and z | |
| 15:01 | so if we're taking our cue from the way that repeatable tags work | |
| 15:02 | we'd assume that if one of the subfields repeats then all the populated subfields should repeat | |
| 15:02 | and that there is some way to map all the associated subfield sets | |
| 15:02 | am I making sense? | |
| 15:03 | I don't know if that's the role of the cutter, or $8, or what | |
| 15:03 | do you have any ideas? | |
| 15:03 | thd | kados: Yes, that makes perfect sense. |
| 15:05 | 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 | 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 | kados: how would that work exactly? | |
| 15:11 | kados | so you click on marc display |
| 15:11 | it brings up all the tags/subfields | |
| 15:11 | scroll down to the first 952 | |
| 15:12 | you have: | |
| 15:12 | a | |
| 15:12 | b | |
| 15:12 | b | |
| 15:12 | c | |
| 15:12 | c | |
| 15:12 | e | |
| 15:12 | e | |
| 15:12 | f | |
| 15:12 | f | |
| 15:12 | g | |
| 15:12 | g | |
| 15:12 | etc. | |
| 15:12 | when you roll over the first b or c, etc., the other members of that set are 'highlighted' | |
| 15:12 | so you can tell that they are related | |
| 15:13 | you could do it in CSS | |
| 15:13 | 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 | 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 | no idea | |
| 15:15 | maybe I should build MARC::Batch script that checks | |
| 15:15 | then we'd know whether our musings were moot or not ;-) | |
| 15:15 | 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 | sorry ... 852 | |
| 15:17 | 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 | 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 | 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 | 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 | kados: that is a common usage for piece designation. | |
| 15:32 | kados | thd: what about 'i' as 'cutter' instead of 'Item part'? |
| 15:33 | 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 | 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 | _h92SHE SHE | |
| 15:38 | _p10687 | |
| 15:38 | _6Book | |
| 15:38 | _9p3.00 | |
| 15:38 | _p10687 | |
| 15:38 | _819990116 | |
| 15:38 | so in this example | |
| 15:38 | the call number should be: | |
| 15:39 | 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 | 852 1 _bMain Collection | |
| 15:40 | _h372.19 | |
| 15:40 | _p10967 | |
| 15:40 | _6Ed. Curriculum | |
| 15:40 | _9p100.00 | |
| 15:40 | _p10967 | |
| 15:40 | _819990118 | |
| 15:40 | _kED | |
| 15:40 | _iBEK | |
| 15:40 | _mTEd/Gr1 | |
| 15:40 | _5Publisher | |
| 15:40 | _7General | |
| 15:40 | the call number is: | |
| 15:41 | ED 372.19 BEK TEd/Gr1 | |
| 15:42 | thd: does that seem right? | |
| 15:42 | thd | yes |
| 15:43 | kados | but there are two levels here |
| 15:43 | there's the biblioitem level | |
| 15:43 | and the item level | |
| 15:43 | so what's the correct sequence for the biblioitem level? | |
| 15:44 | '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 | retract my last yes :) | |
| 15:47 | kados | now I'm very confused ... $t is Copy |
| 15:47 | 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 | I wonder if Koha keeps track of this number | |
| 15:51 | w | |
| 15:51 | 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 | 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 | 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 | 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 | 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 | 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 | thd: and I don't want to lose my place ;-) | |
| 16:18 | thd: but I don't recall seeing them | |
| 16:18 | thd: do you think it's useful to distinguish Format and Itemtype? | |
| 16:18 | I've always been confused about that | |
| 16:19 | like take NPL for instance | |
| 16:19 | if you go to search.athenscounty.lib.oh.us | |
| 16:19 | and click on 'search by format and data' | |
| 16:19 | I've always found the formats to be strangely grouped | |
| 16:20 | I can see distinguishing between Audiobook and CD | |
| 16:20 | but audiobook vs. Juvinile Audiobook is a harder case to make | |
| 16:20 | taxonemically I mean | |
| 16:21 | 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 | 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 | 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 | 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 | 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 | 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 | $t or a substituted value is definitely need for items.itemnumber. | |
| 16:48 | 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 | 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 | kados: So how does the system distinguish the two 852s? | |
| 16:54 | kados | no idea :-) |
| 16:54 | it's a question for paul I guess | |
| 16:54 | IIRC there is a subfieldid in marc_subfield_table | |
| 16:54 | so that explains how it's handled internally | |
| 16:55 | 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 | 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 | 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 | 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 | I'm not really sure | |
| 17:13 | what we need to do | |
| 17:13 | 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 | :-) | |
| 17:15 | thd | no, migrate holdings for libraries :) |
| 17:16 | kados: You know, Liblime's business. | |
| 17:16 | kados | :-) |
| 17:16 | yea ... I've done it a bit | |
| 17:17 | 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 | i.e., it's the first time 952 wasn't already the default | |
| 17:19 | so I've never really had to learn the 852 conventions | |
| 17:20 | because 9xx is so flexible it's not hard to figure out | |
| 17:20 | 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 | thd: you gonna be around in a hour or so? | |
| 17:21 | 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 | 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 | kados: I would suspect that $t does not need to be present in 952. | |
| 19:16 | 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 | 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 | or else it doesn't know what to do with it | |
| 19:17 | 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 | but if you import without getting your itemtypes mapped you'll have a problem | |
| 19:19 | and I think I found a bug in the rebuildnonmarc script | |
| 19:20 | for some reason it was putting a | in some of the itemtypes after I ran it | |
| 19:20 | 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 | we need to start a list of things to ask paul about | |
| 19:23 | :-) | |
| 19:24 | thd | kados: I have frequently had dfficulty getting attention on IRC. |
| 19:24 | his attention | |
| 19:24 | kados | yea ... he's a busy guy |
| 19:24 | 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 | in my data, it looks like 852 $b is what's being used | |
| 19:26 | 852 $c is unused as it $a | |
| 19:26 | as is $a | |
| 19:26 | thd | what values do you find for those fields/ |
| 19:26 | ? | |
| 19:26 | kados | Main Library |
| 19:26 | Periodical Room | |
| 19:27 | Archive | |
| 19:27 | Education Lab | |
| 19:27 | Reference | |
| 19:27 | Faculty Course Materials | |
| 19:27 | 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 | 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 | thd: do you have any ideas on that? | |
| 19:33 | rach: you might too | |
| 19:33 | $a Location is the Institution | |
| 19:34 | $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 | $c is the Shelving location | |
| 19:34 | 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 | 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 | rach: we need to handle the seperate classification elements separately in Koha | |
| 19:40 | 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 | rach: there is ... but only in MARC ;-) | |
| 19:40 | 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 | because you've got b and c and f and g all of which are repeatable | |
| 19:43 | f and g qualify a b and c | |
| 19:44 | then you've still got the levels of classification in h, i, j, k, and l | |
| 19:44 | each of which further qualify either the classification of the location | |
| 19:45 | or the location | |
| 19:45 | rach | oh ok - that was my question - wether there was only 1,b, c |
| 19:45 | a,b,c, | |
| 19:45 | 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 | but I'm hoping that will change | |
| 19:46 | 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 | thd: what about my question about $2 | |
| 19:48 | 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 | 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 | 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 | 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 | rach: well I was really surprised when I first looked at EDI | |
| 19:52 | rach: it pretty much automates the whole buying process ... including cataloging | |
| 19:53 | 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.p[…]ns_and_cataloging |
| 19:53 | 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 | rach: where 'internal' includes the Koha community ;-) | |
| 19:54 | rach: but it's not really good for sales ;-) | |
| 19:54 | rach: wikis rarely are ;-) | |
| 19:54 | rach: http://wiki.liblime.com/doku.p[…]ns_and_cataloging | |
| 19:55 | rach: there's a good link there as well | |
| 19:55 | rach: that explains the process in more details | |
| 19:55 | 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 | thd: yep | |
| 19:56 | rach | we should get rosalie to keep an eye out for her suppliers offering that sort of service |
| 19:56 | we did moot the idea a few years ago and they decided it wasn't worth their while | |
| 19:57 | 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 | there aren't a lot of book sellers in NZ | |
| 19:58 | the libraries are buying direct from england and the states | |
| 19:58 | 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 | 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 | anyway si is home with lunch, I'll let you get back to your discussion :-) | |
| 20:02 | 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 | Location | |
| 20:04 | Call number | |
| 20:04 | Status | |
| 20:04 | Location is concatenated from the 852 $a, b, c, g, f etc. | |
| 20:05 | Call number is concatenated as we've already discussed | |
| 20:05 | but what about Status? | |
| 20:05 | 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 | I don't seee that in the 952s | |
| 20:07 | thd | kados: yes, extensively. |
| 20:09 | 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 | 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 | 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 | http://www.loc.gov/marc/biblio[…]not1.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 | kados: lost other long term status information is in 876-878 $j. | |
| 20:27 | kados | cool |
| 20:27 | thanks! | |
| 20:28 | thd: in Biblio mappings ... I think 520a is correct for 'abstract' do you concur? | |
| 20:29 | 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 | thd: do you have any thoughts on 'serial' in the Koha field? | |
| 20:31 | 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 | thd: is there any way to distinguish between a 'serial' record and a 'non-serial' record? | |
| 20:32 | thd | yes |
| 20:33 | 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 | 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 | 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 | # - None of the following | |
| 20:46 | d - Updating database | |
| 20:46 | l - Updating loose-leaf | |
| 20:46 | m - Monographic series | |
| 20:46 | n - Newspaper | |
| 20:46 | p - Periodical | |
| 20:46 | w - Updating Web site | |
| 20:47 | | - No attempt to code | |
| 20:48 | kados | thd: maybe instead of just using 'classification' we should start using classification, dewey, and subclass |
| 20:48 | thd: for 852 $k, $h, $i | |
| 20:48 | 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 | i was thinking it might be subclassification | |
| 20:51 | 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 | 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 | thd: in NPL | |
| 20:56 | thd: it probably won't ... | |
| 20:56 | thd: I think it just pulls out the column names as a variable and sends that variable to the template | |
| 20:56 | thd: so the actual columns probably don't appear anywhere in the source | |
| 20:57 | thd: and I don't think any template designers are putting seriestitle in | |
| 20:57 | thd: so i doubt it's in the templates either ;-) | |
| 20:57 | thd: I'm not actually sure what the advantage of seperating the classification is ... | |
| 20:58 | thd: just knowing it can be done has me wondering if it should be ... | |
| 20:58 | 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 | 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 | The advantage depends on its exact function. | |
| 21:04 | 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 | ok ... so MARC surely MARC distinguishes between publication date and copyright date right? | |
| 21:06 | 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 | kados: 046 ? | |
| 21:09 | kados | thd: for sorry ... 045 |
| 21:09 | thd: for the copyright date? ... publication date is in 260 $c | |
| 21:10 | thd: but I have no idea where to find copyright date | |
| 21:10 | thd: also ... what should the date formats be? | |
| 21:10 | thd | 046 - SPECIAL CODED DATES (R), 045 - TIME PERIOD OF CONTENT (NR) |
| 21:11 | now I understand your question I thought you were still asking about bibblioitems.dewey and biblioitems.subclass | |
| 21:11 | kados | thd: :-) |
| 21:11 | thd: sorry for not indicating a change in topic ;-) | |
| 21:12 | 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 | and I doubt they will care about differentiating between publication and copyright date | |
| 21:12 | 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 | thd: quick regresion (sorry) | |
| 21:17 | 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 | thd: that means that I can map classification to either 010 or 050 ... | |
| 21:18 | thd: I'm confused about the difference between the two | |
| 21:19 | 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 | 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 | 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 | thd: it's in 082 and 952? | |
| 21:26 | thd: erp ... 082 and 852? | |
| 21:26 | thd | you mean 852 |
| 21:26 | kados | almost always ;-) |
| 21:27 | except when I mean 952 ;-) | |
| 21:27 | thd | :-) |
| 21:28 | 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 | put that in the 900s somewhere | |
| 21:32 | 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 | 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 | 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 | thd: and 952$k is a dewey number so you'd get $dewey $LOC $dewey :-( | |
| 21:43 | 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 | s/items/records/ | |
| 21:44 | or s/items/titles/ | |
| 21:45 | 852 $k is the call number prefix and $852 $m is the call number suffix. | |
| 21:46 | They are not necessarily related to the classification scheme in use. | |
| 21:48 | 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 | not in one 852 example from LC but everyone knows which classification LC uses :) | |
| 21:55 | 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 | 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 | 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 | 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 | kados: are you still there? I have observed something about your proposed dewey mapping. | |
| 22:59 | kados | thd: I'm still here |
| 23:00 | 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 | 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 | thd: if there was some advantage to it | |
| 23:10 | thd: but I can't really see one | |
| 23:10 | thd: I've got to get to bed now | |
| 23:10 | 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 | kados: no rest for coders and the wicked | |
| 23:10 | kados | thd: :-) |
| 23:11 | thd: (BTW: I tried paul's suggestion about the leader and it doesnt' look like it worked ... | |
| 23:11 | 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 | 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 | thd: 000 with subfield @ | |
| 23:15 | thd: I assumed that the leader would automatically import using bulkmarcimport.pl | |
| 23:15 | thd: after adding that to the framework | |
| 23:15 | thd: and indeed, a 000 does show up | |
| 23:16 | thd: with a subfield of @ | |
| 23:16 | 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 | good night kados | |
| 23:18 | kados | :-) |
| 23:19 | thd: If you're still awake this should keep you busy: http://www.ifla.org/VII/d4/wg-franar.htm | |
| 23:19 | thd: The IFLA Working Group on Functional Requirements and Numbering of | |
| 23:19 | Authority Records announces that a draft of "Functional | |
| 23:19 | Requirements for Authority Records" is now available for worldwide | |
| 23:19 | review. | |
| 23:21 | thd | wow, IFLA Guidelines for OPAC displays has been completed in final form but not yet published. |
| 23:26 | 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 | 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 | thd: but there should only be 1 942 per record right? | |
| 11:29 | because 952 is at the item level and 942 is at the biblioitem level | |
| 11:29 | 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 | There is certainly only 1 field mapped from MARC to the items table if Koha is working as it does now. | |
| 11:41 | 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 | thd: so really, there's only one tag/subfield combo mapped to it | |
| 11:45 | thd: biblioitemnumber I mean | |
| 11:45 | thd: scratch that ... | |
| 11:45 | thd: brain fart ;-) | |
| 11:46 | thd: I guess what I mean to say | |
| 11:46 | 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 | 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 | because as we know, there are multiple 852s | |
| 11:48 | 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 | 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 | thd: you run Koha for several years | |
| 11:49 | thd: during that time, you modify the record ... add items, edit items, subtract items | |
| 11:50 | thd: only the one 952 that is mapped to the Koha fields is modified | |
| 11:50 | thd: meaning that the other 952s are 'bogus' as is the 852 | |
| 11:50 | thd: so when you export your data | |
| 11:50 | thd: you don't have accurate holdings data | |
| 11:50 | 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 | thd: well what about 942 mappings then ... should there be one per record or one per item? | |
| 11:54 | thd: my guess is one per record | |
| 11:55 | thd | kados: biblioitems are not item dependent. |
| 11:59 | 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. |
← Previous day | Today | Next day → | Search | Index