IRC log for #koha, 2005-08-01

All times shown according to UTC.

Time S 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.[…]loca.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[…]e=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 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 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:
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 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: , 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
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 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, 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:[…]ns_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:[…]ns_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[…]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, .
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
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,,, 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: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 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
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:
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.

| Channels | #koha index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary