IRC log for #koha, 2005-08-01

← 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

koha1