Time  Nick  Message
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.
11:55 thd   kados: biblioitems are not item dependent.
11:54 kados thd: my guess is one per record
11:54 kados thd: well what about 942 mappings then ... should there be one per record or one per item?
11:54 kados true ... I hadn't thought of that
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:50 kados thd: does that make sense?
11:50 kados thd: you don't have accurate holdings data
11:50 kados thd: so when you export your data
11:50 kados thd: meaning that the other 952s are 'bogus' as is the 852
11:50 kados thd: only the one 952 that is mapped to the Koha fields is modified
11:49 kados thd: during that time, you modify the record ... add items, edit items, subtract items
11:49 kados thd: you run Koha for several years
11:49 kados thd: well say that you map _one_ 952 to Koha fields
11:49 thd   kados: what goes wrong with the export?
11:48 kados thd: but only _one_ of those 952s can be mapped in a useful way to a koha field
11:48 kados for export purposes
11:48 thd   multiple 852s give you multiple 952s, 1 for each copy of the biblio
11:48 kados this may reveal an underlying problem with the data model
11:47 kados because as we know, there are multiple 852s
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 thd   yes
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:46 kados thd: is that only one tag/subfield combo can be mapped to each Koha table field
11:46 kados thd: I guess what I mean to say
11:45 kados thd: brain fart ;-)
11:45 kados thd: scratch that ...
11:45 kados thd: biblioitemnumber I mean
11:45 kados thd: so really, there's only one tag/subfield combo mapped to it
11:45 kados thd: really? but biblioitems isnt' a repeatable field in the Koha tables
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:35 thd   There is certainly only 1 field mapped from MARC to the items table if Koha is working as it does now.
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:29 kados thd: does that sound right?
11:29 kados because 952 is at the item level and 942 is at the biblioitem level
11:29 kados thd: but there should only be 1 942 per record right?
11:28 kados thd: for every 952 there should be a 852 in a record
11:28 thd   kados: yes
11:28 kados thd: so here's an interesting puzzle
11:28 kados thd: :-)
10:56 thd   kados: good morning
06:50 kados thd: morning ;-)
23:26 thd   I have never seen a spelt month in ISO format.  "Please send your comments by 2005 October 28"
23:21 thd   wow, IFLA Guidelines for OPAC displays has been completed in final form but not yet published.
23:19 kados review.
23:19 kados Requirements for Authority Records" is now available for worldwide
23:19 kados Authority Records announces that a draft of "Functional
23:19 kados thd: The IFLA Working Group on Functional Requirements and Numbering of
23:19 kados thd: If you're still awake this should keep you busy: http://www.ifla.org/VII/d4/wg-franar.htm
23:18 kados :-)
23:18 thd   good night kados
23:18 thd   so, if bulkmarcimport is still unchanged ...
23:17 kados ahh :-)
23:16 thd   kados: paul explained to me that other import methods use the framework, while bulkmarcimport does not use the frramework..
23:16 kados huh?
23:16 thd   kados: paul explained to me that other import methods use the framework, while bulkmarcimport uses the framework.
23:16 kados thd: but it's blank
23:16 kados thd: with a subfield of @
23:15 kados thd: and indeed, a 000 does show up
23:15 kados thd: after adding that to the framework
23:15 kados thd: I assumed that the leader would automatically import using bulkmarcimport.pl
23:15 kados thd: 000 with subfield @
23:15 kados thd: that's what I did!
23:14 thd   kados: Had not Paul directed you to add 000 to the MARC framework?
23:14 kados so where did he add support for the leader?
23:14 thd   kados: I do not think that paul added support for bulkmarkimport.pl for the leader yet unless you know otherwise.
23:13 kados thd: bulkmarcimport
23:12 thd   kados: using what method of import
23:12 kados thd: g'night ;-)
23:12 kados thd: the leader doesnt' show up at all in the 000 $@ field ... it's just blank
23:11 thd   kados: What part did not work?
23:11 kados thd: I'll have to bug him about it tomorrow morning (if he's around))
23:11 kados thd: (BTW: I tried paul's suggestion about the leader and it doesnt' look like it worked ...
23:10 kados thd: :-)
23:10 thd   kados: no rest for coders and the wicked
23:10 thd   kados:  I think they may be for more natural searching.
23:10 kados thd: I'll be around tomorrow if you'd like to continue :-)
23:10 kados thd: I've got to get to bed now
23:10 kados thd: but I can't really see one
23:10 kados thd: if there was some advantage to it
23:09 kados thd: dewey and subclass aren't there ... but it would be trivial to add them
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:07 kados thd: so what do you propose for the mapping scheme?
23:05 thd   kados: they should, however, be used in biblioitems.classification.
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:00 kados thd: what have you observerd?
22:59 kados thd: I'm still here
22:30 thd   kados: are you still there?  I have observed something about your proposed dewey mapping.
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: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.
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.
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:52 thd   not in one 852 example from LC but everyone knows which classification LC uses :)
21:50 thd   :)
21:48 kados thd: right ... I see that now since the indicator determines the classification scheme
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:46 thd   They are not necessarily related to the classification scheme in use.
21:45 thd   852 $k is the call number prefix and $852 $m is the call number suffix.
21:44 thd   or s/items/titles/
21:44 thd   s/items/records/
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:43 kados thd: unless I'm not understanding
21:42 kados thd: and 952$k is a dewey number so you'd get $dewey $LOC $dewey :-(
21:42 kados thd: ahh ... but I think that items.itemcallnumber is displayed in the OPAC
21:41 thd   As a reserve somewher for when they convert
21:41 kados thd: why add the 050 if they are using dewey?
21:40 thd   yes, you could concatenate 852$k, 050 $a, 050 $b, and 852 $m to use for items.itemcallnumber.
21:40 kados thd: and classification as 050 $a
21:39 kados thd: so I think I'm going to stick with 'dewey' as a concatenated 852 $k $h $i
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: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:32 kados and use that as the 'classification' mapping
21:31 kados put that in the 900s somewhere
21:31 kados so I suppose I should create a hybrid LOC classification from 050$a, $b eh?
21:28 thd   852 is for the item 050-088 is the assignment for the MARC record generally.
21:27 thd   :-)
21:27 kados except when I mean 952 ;-)
21:26 kados almost always ;-)
21:26 thd   you mean 852
21:26 kados thd: erp ... 082 and 852?
21:26 kados thd: it's in 082 and 952?
21:25 kados thd: BTW: what's up with 082 $a being the Dewey classification
21:25 thd   Actually I suspect my suggestion before is right about subclass
21:25 kados thd: so that'd probably be a good link for 'subclass' eh?
21:24 thd   yes but $b is the cutter number
21:23 thd   050 is the Library of Congress Classification Number
21:23 kados so 050 $a it is
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: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:20 kados thd: the client expressed an interest in moving to LOC from Dewey
21:19 thd   In an LC record 001 and 010 are usually the same or the same in all improtant respects.
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   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: 010 is LOC Control Number and 050 is LOC Classification (Call no.)
21:18 kados thd: I'm confused about the difference between the two
21:18 kados thd: that means that I can map classification to either 010 or 050 ...
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:17 thd   kados: Stephen has a simple script in the Koha diary in Perl
21:17 kados thd: since my client is using dewey
21:16 kados thd: quick regresion (sorry)
21:16 kados thd: :-)
21:16 thd   kados: I have extensive experience writing regular expressions to disentangle copyright and publication dates in MARC records.
21:16 kados thd: gotcha ... so basically we'd have to play with the MARC data to differentiate between them
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:12 kados but I'd be interested if MARC did ... it doesnt' look like it does fromt he docs on 046
21:12 kados and I doubt they will care about differentiating between publication and copyright date
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:11 kados thd: sorry for not indicating a change in topic ;-)
21:11 kados thd: :-)
21:11 thd   now I understand your question I thought you were still asking about bibblioitems.dewey and biblioitems.subclass
21:10 thd   046 - SPECIAL CODED DATES (R), 045 - TIME PERIOD OF CONTENT (NR)
21:10 kados thd: also ... what should the date formats be?
21:10 kados thd: but I have no idea where to find copyright date
21:09 kados thd: for the copyright date? ... publication date is in 260 $c
21:09 kados thd: for sorry ... 045
21:08 thd   kados: 046 ?
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:06 kados thd: i see 046 $c maybe?
21:06 kados ok ... so MARC surely MARC distinguishes between publication date and copyright date right?
21:05 kados right
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:03 thd   The advantage depends on its exact function.
21:02 thd   It is in Biblio.pm, Search.pm, opac-moredetail.pl, opac-moredetail.tmpl, etc.
21:01 kados I can't think of one
21:01 kados what's the advantage of it being separate?
20:58 thd   It should be of course, the problem is knowing what it was designed to do exactly.
20:58 kados thd: what do you think?
20:58 kados thd: just knowing it can be done has me wondering if it should be ...
20:57 kados thd: I'm not actually sure what the advantage of seperating the classification is ...
20:57 kados thd: so i doubt it's in the templates either ;-)
20:57 kados thd: and I don't think any template designers are putting seriestitle in
20:56 kados thd: so the actual columns probably don't appear anywhere in the source
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: it probably won't ...
20:55 kados thd: in NPL
20:55 kados thd: biblioitems.dewey is 'classification' and is just 942 $k
20:55 thd   I am going to grep the source, if that may help.
20:54 kados thd: it's not
20:54 thd   kados: How is biblioitems.subclass linked to MARC at NPL?
20:53 thd   kados: That makes sense.  I know biblioitems.dewey does something, as I can see from the NPL OPAC.
20:51 kados like maybe the 'suffix' for classification
20:51 kados i was thinking it might be subclassification
20:51 kados thd: dunno ... but I assume it's available from the OPAC as a variable
20:50 thd   kados: What does biblioitems.subclass do in Koha?
20:48 kados thd: what do you think?
20:48 kados thd: for 852 $k, $h, $i
20:48 kados thd: maybe instead of just using 'classification' we should start using classification, dewey, and subclass
20:47 thd            | - No attempt to code
20:46 thd            w - Updating Web site
20:46 thd            p - Periodical
20:46 thd            n - Newspaper
20:46 thd            m - Monographic series
20:46 thd            l - Updating loose-leaf
20:46 thd            d - Updating database
20:46 thd            # - None of the following
20:46 thd   For serials 008, position 21 - Type of continuing resource
20:46 kados thd: but do you suppose 'dewey' and 'subclass' should be mapped to 852 fields?
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:45 kados thd: not to beat a dead horse
20:41 kados thd: I guess many libraries aren't satisfied with the leader for itemtypes eh?
20:38 thd   For the most basic media types look at the table http://www.itsmarc.com/crs/Bib0021.htm
20:38 kados gotcha
20:37 thd   all periodical are serials but not all serials are periodicals
20:36 kados meaning it would make sense to have a 'serials' or a 'periodicals' itemtype (they are the same right?)
20:36 kados that seems closely linked to itemtype
20:35 thd   kados: identifying a book or text requires first knowing that it is not a serial.
20:35 kados interesting
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:32 thd   yes
20:32 kados thd: is there any way to distinguish between a 'serial' record and a 'non-serial' record?
20:31 kados :-)
20:31 thd   kados: serial is a problem in MARC :)
20:31 kados thd: is there a koha field to map 'serial' to? (I can't find one)
20:31 kados thd: do you have any thoughts on 'serial' in the Koha field?
20:30 kados thd: right ...
20:30 thd   kados: yes, but my email was only about holdings not all MARC to Koha table mappings
20:29 kados thd: I don't see that covered in your email
20:28 kados thd: in Biblio mappings ... I think 520a is correct for 'abstract' do you concur?
20:27 kados thanks!
20:27 kados cool
20:26 thd   kados: lost other long term status information is in 876-878 $j.
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:18 kados thx
20:17 thd   http://www.loc.gov/marc/bibliographic/ecbdnot1.html#mrcb506
20:15 thd   kados: 506 - RESTRICTIONS ON ACCESS NOTE (R)
20:15 kados :-)
20:15 thd   kados: Incompatibility, is probably considered a revenue enhancing feature for ILS companies :)
20:14 kados I guess it's not 'concise'
20:13 kados I can't find anything on 506 on the loc site
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:11 thd   kados: many institutions must use something much simpler and non-standard.
20:11 kados I don't think sagebrush Athena uses any of those fields
20:09 thd   876-878 $h and very thoroughly in 506
20:07 thd   kados: yes, extensively.
20:07 kados I don't seee that in the 952s
20:07 kados so MARC21 does define lost and access restrictions?
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:05 kados shouldn't a library be able to define their statuses just like they can define location and call number?
20:05 kados but what about Status?
20:05 kados Call number is concatenated as we've already discussed
20:04 kados Location is concatenated from the 852 $a, b, c, g, f etc.
20:04 kados Status
20:04 kados Call number
20:04 kados Location
20:04 kados koha needs
20:04 thd   kados: EDI was first created by the US government, just like the internet.
20:04 kados thd: so what do you think about this
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:02 kados cya
20:02 rach  catch ya later
20:02 rach  anyway si is home with lunch, I'll let you get back to your discussion :-)
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: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
19:59 thd   In many countries every vendor has his own system, and some vendors even think simple email is sufficient.
19:58 kados thd: right
19:58 rach  we are a tiny market, so only a small number of NZ publishers would be selling NZ books
19:58 rach  the libraries are buying direct from england and the states
19:58 rach  there aren't a lot of book sellers in NZ
19:57 rach  I've no idea - I haven't heard of one
19:57 thd   rach: Is there a particular EDI system widely adopted in New Zealand and / or Australia?
19:57 rach  but it would be worth revisiting
19:56 rach  we did moot the idea a few years ago and they decided it wasn't worth their while
19:56 rach  we should get rosalie to keep an eye out for her suppliers offering that sort of service
19:56 kados thd: yep
19:56 kados rach: but these days most book vendors are going with either EDI or some form of Web Services
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:55 kados rach: yep ... entirely
19:55 kados rach: that explains the process in more details
19:55 kados rach: there's a good link there as well
19:54 kados rach: http://wiki.liblime.com/doku.php?id=koha24rmnotes#acquisitions_and_cataloging
19:54 kados rach: wikis rarely are ;-)
19:54 kados rach: but it's not really good for sales ;-)
19:54 kados rach: where 'internal' includes the Koha community ;-)
19:54 kados rach: no ... it's an 'internal' wiki sofar
19:53 rach  you can't get to the wiki from the liblime site tho?
19:53 kados thd: haven't checked yet
19:53 kados rach: http://wiki.liblime.com/doku.php?id=koha24rmnotes#acquisitions_and_cataloging
19:53 thd   kados: do your records have 852 $2 with 852 first indicator set to something other than 7?
19:53 rach  nope
19:53 kados rach: did you see my review of it on the liblime wiki?
19:52 kados rach: it pretty much automates the whole buying process ... including cataloging
19:52 kados rach: well I was really surprised when I first looked at EDI
19:52 kados rach: :-)
19:52 rach  generally they are really happy to stop using excel :-)
19:52 kados thd: what do you think about using the 852 first indicator to categorize record classifications
19:52 rach  I guess if anything looks compelling they may
19:51 thd   kados: otherwise, 852 first indicator is controlling.
19:51 kados thd: bummer
19:50 kados rach: maybe your clients would be willing to sponsor development?
19:50 thd   kados: 852 $2 should be present only when 852 first indicator is set to 7.
19:50 rach  we don't have anyone who does acquisitions through something else
19:50 kados rach: to see if they have anything to offer your clients
19:50 kados rach: we'll have to get Chris to take a look at EDI, Soap and Web Services
19:50 rach  as all our clients use one or other of the acquisitions packages
19:50 kados rach: cool ...
19:49 rach  kados - just looking through mail - I would say we (katipo) have the biggest interest in acquisitions
19:49 thd   kados: sorry, I had forgotten that question.
19:48 thd   libraries know things for everyone if everyone knows how to find things in them.
19:48 kados thd: do you happen to know whether the $2 is always generated from the First indicator in the record?
19:48 kados thd: what about my question about $2
19:47 kados thd: right ... I figured that ... Athena doesnt use them so it's not a problem in this case
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:46 kados :-)
19:46 rach  I'm trying to employ someone to know this stuff for me
19:46 kados thd has been a big help
19:46 kados but I'm hoping that will change
19:46 kados I don't have a very good working knowledge of MARC
19:45 rach  you could write what I know about marc on a postage stamp :-)
19:45 rach  a,b,c,
19:45 rach  oh ok - that was my question - wether there was only 1,b, c
19:45 kados or the location
19:44 kados each of which further qualify either the classification of the location
19:44 kados then you've still got the levels of classification in h, i, j, k, and l
19:43 kados f and g qualify a b and c
19:43 kados because you've got b and c and f and g all of which are repeatable
19:43 kados in MARC21
19:43 thd   3 levels of what?
19:43 kados in fact if I"m reading this right the levels are pretty much unlimited
19:42 thd   what 3 levels?
19:42 kados rach: there are more than three in MARC21
19:42 rach  in which case we have the 3 levels?
19:42 kados rach: no
19:42 rach  so are there only 3 levels?
19:42 kados thd: makes sense
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:41 rach  I wonder if there is a reason for that
19:40 kados rach: it's not in the Koha tables
19:40 kados rach: there is ... but only in MARC ;-)
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  well yep, I'm kinda surprised there isn't something for shelf as well as location
19:40 kados rach: rather than munging them together
19:39 kados rach: we need to handle the seperate classification elements separately in Koha
19:39 kados rach: yep
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 thd: do you happen to know whether the $2 is always generated from the First indicator in the record?
19:38 rach  it's one of the things I would like to get generalised
19:38 kados thd: yes
19:38 thd   kados: Is the library you are migrating a one branch library?
19:38 rach  no that's paul - and so it's not well represented outside of the marc "view"
19:37 kados location I mean
19:37 kados maybe ... was that a Katipo-created or a Paul-created field?
19:37 rach  but you could use it for a department-shelf  joined thing I guess,
19:37 kados so that would probably be $b then
19:36 rach  From my discussions with Paul, I think it's the department or collection
19:35 kados right .. prolly still sleeping ;-)
19:35 rach  I doubt chris is here, it's sunday lunch time
19:34 thd   rach chris: what does items.location do?
19:34 kados chris: or do you?
19:34 rach  hmm b or c I would think - not the branch
19:34 kados rach: do you happen to know which of these is most appropriate for Koha's 'Location' field?
19:34 kados $c is the Shelving location
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:33 kados $a Location is the Institution
19:33 kados rach: you might too
19:33 kados thd: do you have any ideas on that?
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:32 kados it's the institutional code for their library (which I know)
19:32 thd   mostly they seem to use real records as examples.
19:32 kados so the thing is, I know what the proper value for $a is
19:31 thd   :)
19:31 kados thd: that's clearly an idealized record ;-)
19:31 thd   hello rach
19:31 kados hey rach
19:31 rach  howdy
19:31 thd   an example form concise MARC 21 holdings is 852 	81$a[location identifier]$bMain$cmezzanine stacks
19:28 kados 852 $b
19:28 thd   In what subfield are those?
19:27 kados etc.
19:27 kados Faculty Course Materials
19:27 kados Reference
19:27 kados Education  Lab
19:27 kados Archive
19:26 kados Periodical Room
19:26 kados Main Library
19:26 thd   ?
19:26 thd   what values do you find for those fields/
19:26 kados as is $a
19:26 kados 852 $c is unused as it $a
19:26 kados in my data, it looks like 852 $b is what's being used
19:25 kados you say that Location should be 952$c and that it should be generated from 852$c
19:24 thd   yes
19:24 kados thd: got a question about your email to koha-devel
19:24 kados yea ... he's a busy guy
19:24 thd   his attention
19:24 thd   kados: I have frequently had dfficulty getting attention on IRC.
19:23 kados :-)
19:23 kados we need to start a list of things to ask paul about
19:22 kados that would be nice
19:22 thd   kados: It would be nice if there was an explicit list about what is automatically mapped and to where.
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:20 thd   kados: sorry, I guess my mistyping had confused the issue :)
19:20 kados this is interesting:
19:20 kados for some reason it was putting a | in some of the itemtypes after I ran it
19:19 kados and I think I found a bug in the rebuildnonmarc script
19:19 kados but if you import without getting your itemtypes mapped you'll have a problem
19:19 kados it's not
19:18 thd   kados: Why is that a problem in itself?
19:17 kados when you try to run a transaction
19:17 kados or else it doesn't know what to do with it
19:17 kados Koha needs every item to have an itemtype
19:17 thd   kados: What is a major problem for Koha?
19:16 kados ahh ... yea it definitely doesn't in that case
19:16 kados but it's a major problem for KOha
19:16 thd   s/itemtyp/itemnumber/
19:16 kados I don't think it does
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:14 thd   kados: I would suspect that $t does not need to be present in 952.
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:12 kados thd: I'm still not sure of the sanity of mapping the $t before importing records into Koha
19:10 thd   actually I have had this mapped in Zope for 007 and 008 as well but for MARC 21 only.
19:09 kados neat
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:07 kados thd: I'm back
17:21 kados thd: ok ... talk to you soon ;-)
17:21 thd   kados: yes kados, I will be here.
17:21 kados thd: yea ... I'm mapping 852 to 952 right now ...
17:20 kados thd: you gonna be around in a hour or so?
17:20 kados way too much coffee :-)
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 but 852 adds complexity because it's rigidly defined
17:20 kados because 9xx is so flexible it's not hard to figure out
17:19 kados so I've never really had to learn the 852 conventions
17:18 kados i.e., it's the first time 952 wasn't already the default
17:18 kados well this is the first time I've had to play with the data before importing with bulkmarcimport
17:18 thd   Is that :-) a yes to cheating with SQL? :)
17:18 kados :-)
17:17 thd   Did you cheat before and use SQL to populate the holdings data? :)
17:17 kados but never really delved into the MARC so deeply
17:16 kados yea ... I've done it a bit
17:16 kados :-)
17:16 thd   kados: You know, Liblime's business.
17:15 thd   no, migrate holdings for libraries :)
17:14 kados :-)
17:14 kados what ... ask paul?
17:14 thd   kados: haven't you done this many times before :)
17:13 kados is ask paul when he gets back
17:13 kados what we need to do
17:13 kados I'm not really sure
17:13 kados it seems problematic
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:05 thd   kados: presumably, bulkmarkimport.pl does something useful to populate a value in 952$t for example, if 952$t is blank in the import records but linked to items.itemnumber in the MARC to Koha links.
17: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.
16:58 kados I understand now
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: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:55 kados but I have no idea how it's done when importing/exporting ... how does it know what goes where?
16:54 kados so that explains how it's handled internally
16:54 kados IIRC there is a subfieldid in marc_subfield_table
16:54 kados it's a question for paul I guess
16:54 kados no idea :-)
16:53 thd   kados: So how does the system distinguish the two 852s?
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:52 kados it may be moot for this data since I don't see a $t even when multiple 852s exist
16:51 kados ahh ... I see ... I'm not sure about that
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:49 kados thd: Koha takes care of 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:46 thd   $t or a substituted value is definitely need for items.itemnumber.
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:41 kados right?
16:41 kados and in items.itemcallnumber I have: $k $h $i $t $m
16:41 thd   kados: exactly
16:41 kados so in biblioitems.classification I have: $k $h $i
16:40 kados right
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 ?
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:33 kados I thought $i was for items.itemcallnumber
16:33 kados I thought I didn't need it
16:31 thd   kados: are you clear about why you need 852 $i as part of the call number in biblioitems.classification?
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: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:21 kados it's like comparing apples to oranges in my book
16:20 kados taxonemically I mean
16:20 kados but audiobook vs. Juvinile Audiobook is a harder case to make
16:20 kados I can see distinguishing between Audiobook and CD
16:19 kados I've always found the formats to be strangely grouped
16:19 kados and click on 'search by format and data'
16:19 kados if you go to search.athenscounty.lib.oh.us
16:19 kados like take NPL for instance
16:18 kados I've always been confused about that
16:18 kados thd: do you think it's useful to distinguish Format and Itemtype?
16:18 kados thd: but I don't recall seeing them
16:18 kados thd: and I don't want to lose my place ;-)
16:18 kados thd: I'm in the middle of something else so I can't check the OPAC
16:16 thd   kaodos: Does the existing Athena system you are migrating ever show copy numbers in the OPAC?
16:15 kados thd: but I'd rather not be surprised ;-)
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: probably not an issue with this client
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:13 thd   Maybe the patron need not consider the copy number mportant as long as it is available and undamaged.
16:11 thd   I was just wondering about seeing how copy number might be represented in the OPAC there.
16:09 kados thd: not sure of the name ... but it's about 44,000 records IIRC
16:06 thd   kados: what is the largest library where paul has installed Koha?
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:02 thd   kodos: http://www.loc.gov/marc/holdings/echdloca.html , I do not know what book that example came from.
16:01 kados well NPL probably isn't the greatest example
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
15:59 kados where's that ?
15:55 thd   From LC this example shows $m.  852##$aDLC$bc-G & M$hG3820 1687$i.H62$mVault
15:54 kados thd: harry potter's always a good one ... or lord of the rings
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: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:51 kados oops ;-)
15:51 kados w
15:49 kados I wonder if Koha keeps track of this number
15:49 kados in a one-branch system that happens all the time
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:47 kados I guess $t is the biblioitems level
15:47 thd   for biblioitems.classification you would want $k$h$i
15:47 kados but what does that mean?
15:47 kados now I'm very confused ... $t is Copy
15:46 thd   retract my last yes :)
15:46 thd   yes
15:46 kados but it should be in items.itemcallnumber
15:46 thd   kados: $t if more than one copy existed, and $m would be ommitted.
15:46 kados but for mapping purposes $i shouldn't be included in biblioitems.classification
15:45 thd   kados: $i is needed for all copies
15:44 kados 'i' is ommitted for that right?
15:43 kados so what's the correct sequence for the biblioitem level?
15:43 kados and the item level
15:43 kados there's the biblioitem level
15:43 kados but there are two levels here
15:42 thd   yes
15:42 kados thd: does that seem right?
15:41 kados ED 372.19 BEK TEd/Gr1
15:40 kados the call number is:
15:40 kados        _7General
15:40 kados        _5Publisher
15:40 kados        _mTEd/Gr1
15:40 kados        _iBEK
15:40 kados        _kED
15:40 kados        _819990118
15:40 kados        _p10967
15:40 kados        _9p100.00
15:40 kados        _6Ed. Curriculum
15:40 kados        _p10967
15:40 kados        _h372.19
15:40 kados 852 1  _bMain Collection
15:40 kados in this example:
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:39 kados 92SHE  SHE
15:38 kados the call number should be:
15:38 kados so in this example
15:38 kados        _819990116
15:38 kados        _p10687
15:38 kados        _9p3.00
15:38 kados        _6Book
15:38 kados        _p10687
15:38 kados        _h92SHE  SHE
15:38 kados 852 1  _bMain Collection
15:36 thd   copy numbers would go after cutter numbers
15:36 kados should it go k, h, i, m or k, h, m, i ?
15:35 kados shouldn't that go at the end?
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 ahh ... so if you had multiple copies of an item you might designate a cutter?
15:34 thd   kados: Cutter is the item part as opposed to the general part of the call number.
15:33 kados thd: I can't seem to find anything on cutter anyway ... what the heck is it?
15:32 kados thd: what about 'i' as 'cutter' instead of 'Item part'?
15:31 thd   kados: that is a common usage for piece designation.
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 it seems to be like it's not quite right
15:30 kados thd: so ... what do you think about 852$p being the barcode for the item
15:27 thd   :)
15:27 kados right ... so if you're LOC it matters ;-)
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 gotcha
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: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:19 kados because I didn't realize that it could happen before I began the script
15:19 kados no ... it was a theoretical question ;-)
15:17 thd   But I was assuming that you had found them already.
15:17 kados I keep doing that ;-)
15:17 kados sorry ... 852
15:16 kados thd: repeating sub-subfields in 952
15:16 thd   kados: What would the MARC::Batch script check for?
15:15 kados I suspect they are ;-)
15:15 kados then we'd know whether our musings were moot or not ;-)
15:15 kados maybe I should build MARC::Batch script that checks
15:15 kados no idea
15:15 kados I wish there was an easy way to test a record set for repeating sub-subfields in 952
15:15 thd   kados: What would happen in the record detail display?
15:14 kados which is why I specified first ... click on marc display ;-)
15:14 kados yea ... and that's the default
15:14 thd   kados: Would not the patrons prefer record detail instead of MARC view?
15:13 kados does that make sense? (or does it betray a missunderstanding of what's going on here? ;-))
15:13 kados you could do it in CSS
15:12 kados so you can tell that they are related
15:12 kados when you roll over the first b or c, etc., the other members of that set are 'highlighted'
15:12 kados etc.
15:12 kados g
15:12 kados g
15:12 kados f
15:12 kados f
15:12 kados e
15:12 kados e
15:12 kados c
15:12 kados c
15:12 kados b
15:12 kados b
15:12 kados a
15:12 kados you have:
15:11 kados scroll down to the first 952
15:11 kados it brings up all the tags/subfields
15:11 kados so you click on marc display
15:11 thd   kados: how would that work exactly?
15:10 thd   kados: I have very limited experience with MARC::Record, which does not go to solving this type of problem.
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: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:07 kados well the thing is I'm not even sure if MARC::Record supports sub-subfields ;-)
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:06 kados it's confusing
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: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:03 thd   kados: Yes, that makes perfect sense.
15:03 kados do you have any ideas?
15:03 kados I don't know if that's the role of the cutter, or $8, or what
15:02 kados am I making sense?
15:02 kados and that there is some way to map all the associated subfield sets
15:02 kados we'd assume that if one of the subfields repeats then all the populated subfields should repeat
15:01 kados so if we're taking our cue from the way that repeatable tags work
15:01 kados specifically, b, c, e, f, g, i, k, m, s, x, and z
15:00 kados there are several repeatable subfields within that 852 tag
15:00 kados so take a single record's 852 field
14:58 thd   which subfields with what?
14:57 kados s/do/to/
14:57 kados so the part I'm still confused about ... is how do associate subfields
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:56 kados so I'm thinking maybe that's a locally defined field internal to Sagebrush
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:54 thd   kados: currency is in 365 $c, if anyone uses the MARC 21 standard for that.
14:54 kados so I take it that's nonstandard then
14:53 kados they could almost be itemtypes
14:52 kados so I'm not sure if those are binding formats
14:52 kados etc.
14:52 kados Book
14:51 kados Pamphlet
14:51 kados Sunday School Curriculum
14:51 kados hmmm ... here are some of the values:
14:50 thd   kados: do you mean they put binding format in the standard 852 linkage $6 subfield?
14:50 kados I don't see Currency listed in 852
14:50 kados Prefix is k (of course)
14:50 kados Fund is in 7
14:49 kados Format is in 6,
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 thd   $b - Sublocation or collection (R)
14:48 kados Vendor is in 8525
14:48 kados ok ... so Location is in 852b
14:47 thd   kados look at the mapping from my koha-devel post
14:46 kados I'm trying to find them now
14:46 kados I think they are stored in 852 somewhere but I'm unsure
14:46 thd   or $9 subfield
14:46 thd   kados: Are you saying that these values may not even be stored in a local use field?
14:45 kados the upper level categories are location, format, currency, etc.
14:44 kados so for Format, the values are Book, etc.
14:44 kados and it allows you to add or deleve values within each of the categories
14:44 kados and it has a 'copies field values'
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 sorry ... I'm just looking at the Sagebrush interface
14:43 thd   kados: Wha doesn't say the MARC fields.  I do not understand that sentence.
14:42 kados thd: it doesn't say the MARC fields
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:41 thd   kados: what field are they in?
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: 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:40 kados location: Archive, Education Lap, Faculty Course materials, main Collection, Periodical Storage, Reference
14:39 kados it has categories: location, format, currency, vendor, fund, prefix
14:39 kados I just found the 'copies field values' in Sagebrush
14:38 kados I noticed that ... just wondering if you had anything more to say about it
14:38 thd   kados: If you read earlier in my koha-devel post, paul had a suggestion, but NPL wisely used 952 instead.
14:36 kados thd: I keep doing that
14:36 kados thd: sorry ;-)
14:36 kados thd: yes
14:36 kados I guess 9 is undefined too but this dataset uses it for 'cost'
14:36 thd   kados: Do you mean 852?
14:36 kados thd: anything to be done with those?
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:34 thd   kados: Or very brief non-exlanations of cutter numbers.
14:33 thd   kados: I mostly come up with information about programs, on OCLC that construct the cutter number for you.
14:31 thd   kados: wel, I just spent a few minutes googling for the cutter tables but need a better query.
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:29 kados thd: are there any good docs explaining it?
14:26 thd   kados: LC cutter tables are rather complex, along with the whole LC classification scheme.
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:22 kados thd: so how does the cutter number work?
14:21 thd   kados: yes, $i is the cutter number.
14:20 thd   $h is the common general part as it should be and does not vary
14:20 kados thd: is that meaningful to you?
14:20 kados maybe that's where 'i' comes in? it's listed in Sagebrush as the Call Number Cutter
14:20 kados because k, i and m are Repeatable but H isn't
14:19 kados hmmm ... and that's problematic too
14:18 thd   kados: actually, they should be treated separately to form a separate call number.
14:17 kados thd: can you think of a real world example of what this would look like?
14:16 kados thd:  but are you sure they should be concatenated?
14:16 kados thd: it's not hard to do I suppose
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: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:13 kados thd: I'm just not sure what to do when I encounter a repeatable subfield within 852 ... is it important?
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:11 thd   kados: You want something to use today, right?
14:11 owen  the 'yet to be developed' part is the sticking point
14:11 thd   Why not one framework with multiple implementations depending on various factors, but that has yet to be developed.
14:10 kados right ... exactly
14:09 owen  Otherwise when you go to edit those records, they would open with the default MARC template
14:09 kados what he said ;-)
14:09 kados thd: I was under the impression that you might want to have a framework for books, another for periodicals
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 and some of those are repeatable ... how can I possible do that?
14:08 kados because if I'm building a new classification number by concatenating k, h, i, m
14:08 thd   kados: What do you mean by 'types of records' for frameworks?
14:08 kados and $k, $m
14:08 kados it becomes problematic in some cases ... like take $i for instance
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:05 kados oops ... I meant 852 subfields
14:05 kados or $e Address
14:05 kados like $c Shelving location
14:05 kados thd: I'm unclear as to why some of the 952 subfields are repeatable
14:04 kados thd: I can't quite parse that sentence ;-)
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:01 owen  It's listed in marc_biblio
14:01 kados thd: for import purposes it would be useful to put types of records 'into' frameworks
14:00 owen  I think the framework information is in the MARC record somewhere
13:56 thd   kados: why would you need the MARC record to specify a framework?
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:50 thd   kados: http://www.loc.gov/marc/holdings/echditem.html
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:46 kados thd: s/amont/among/
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:45 kados owen: is there a way to specify a framework withing the MARC record?
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:43 owen  thd: the NPL template for marc_subfields_structure.pl is buggy
13:41 kados thd: so which is authoritative?
13:41 thd   kados: 876-878 sometimes modify and override location information from 852
13:39 thd   owen: do you mean the cataloguing template or the frameworks subfield addition template?
13:38 owen  We don't use frameworks right now because the NPL template for setting up marc subfields is buggy
13:38 thd   $t is the same for the same copy so where you get it from does not matter
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:37 owen  Frameworks define what fields you see during MARC entry
13:36 kados under what circumstances would I want more than one framwork for MARC?
13:35 kados right I get that
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 owen: do you remember anything about items.itemcallnumber?
13:34 kados and what if data exists in more than one of those fields?
13:34 thd   kados: I have not had the chance to ask paul about ites.itemscallnumber yet.
13:34 kados thd: why is 852 $t before 876 $t
13:33 kados thd: what did you use to determine the order of the mappings
13:33 kados form a unique whole number.)
13:33 kados you have been using $3, you should find some way of combining $t with $3 to
13:33 kados Map 852 $t, 876 $t, 877 $t, and 878 $t to 952 $t for items.copynumber.  (If
13:33 kados thd: I'm not sure I follow that last section
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:31 kados what do you remember?
13:31 kados I didn't even remember that we discussed it ;-)
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:28 kados I had it flagged as important ;-)
13:28 kados found it
13:28 thd   kados: tying again :) MARC Holdings, Koha, and Migration
13:27 thd   kados: Marc Hlings, Koha, and Migraton
13:27 kados I"m looking now
13:26 thd   items.paidfor is for when a borrower pays a replacement fine
13:25 thd   kados: did you see the last section of my latest post to koha-devel?
13:25 kados thd: they were probably good ideas
13:25 kados ahh
13:24 thd   repeatable and not repeatable
13:24 thd   items.stack, items.binding, items.multivolume, items.multivolumepart were for old ideas that were never implemented
13:22 kados thd: on the loc.gov holdings site ... what does the (NR) and (R) stand for?
13:18 kados (hopefully it's done correctly)
13:18 kados and looking at the indicators to see what classification is being used
13:18 kados it seems like I should be paying attention mainly to the 852 tag
13:16 kados all with different ways of doing things
13:16 kados there are three generations of records
13:16 kados well I'm not sure yet ... the biggest problem is getting used to the MARC records
13:13 thd   So: what problems are you having with the import?
13:13 kados thd: hopefully by tonight ;-)
13:13 kados thd: as soon as I'm done with this import ;-)
13:12 thd   kados: have you read Martha Yee's FRBRization paper yet?
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:07 kados remember that Koha's original design predated FRBR by a couple of years
13:07 kados yea ... that'd be nice
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:02 thd   kados: If you do not populate biblioitemsnumber, then you loose non-MARC Koha.
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.
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: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:50 thd   Libraries often only have the hardover, so in practise there is less confusion overall.
12:49 kados and FRBR is even closer
12:49 kados Koha's internal system is a bit more sane than that
12:49 kados yea ... and even that's confusing
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 but there's also a items.binding
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:45 kados but I'm not a MARC expert
12:45 kados so you don't really need to specify a itemtype at the item level (ideally)
12:44 kados so I think that in standard marc practice a different format/itemtype goes in a separate MARC record
12:42 thd   oh yes, I had meant biblioitems.itemtype :)
12:42 kados right
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:41 kados are you suggesting that itemtypes should be determined on the item level rather than on the biblioitem level?
12:41 kados so not sure I completely understand ... are you talking about determing the itemtypes?
12:38 thd   s/same item/same biblio/
12:37 thd   what woud happen to multiple copies of the same item if you reduced MARC Koha to item level only?
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:33 kados for deep linking
12:33 thd   however, for what I imagine you want it do for non-MARC Koha uses biblioitems.mediatype
12:33 kados at least for when we move to zebra
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:31 thd   well it is not doing anything at the moment
12:31 kados it could be so useful
12:31 kados damn
12:31 thd   binding is an orphaned field
12:31 kados thd: really? what did he say?
12:30 thd   kados: I discussed this extensively with chris
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 kados binding, paidfor, location
12:30 kados thd: yep
12:30 kados like stack, itemlost, wthdrawn, issues, renewals reserves
12:29 thd   So, for fiction NPL has author shelving for call number instead of 8XX?
12:29 kados there are some other seemingly useful things in items
12:28 kados :-)
12:28 kados (well, one non-fiction)
12:27 kados you can see call numbers for fiction and non-fiction works side-by-side
12:27 kados http://search.athenscounty.lib.oh.us/cgi-bin/koha/opac-search.pl?op=do_search&type=opac&marclist=&and_or=and&excluding=&operator=contains&value=neal+stephenson
12:27 kados here's a good example:
12:27 kados 942 $k
12:26 kados yea
12:26 kados is organized lastname, firstname, etc.
12:26 thd   Are they linked to the same MARC subfield?
12:26 kados fiction for instance
12:26 kados no ... some classification isn't dewey ... it's our own strange amalgam of a standard
12:26 thd   they are always identical?
12:25 kados it's the dewey
12:25 thd   kados: how does NPL use biblioitems.classification
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:24 kados you mean items.itemcallnumber?
12:24 thd   about items.itemcallnumber
12:24 thd   he told me to ask paul about items.callnumber
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:23 kados thd: those are the relevant fields right?
12:23 kados barcode, itemcallnumber, location
12:23 kados then in items we have
12:22 kados that's in biblioitems
12:22 kados classification, dewey, subclass, lccn
12:22 thd   kados: That is where all the fun is :)
12:22 kados in Koha we have biblioitems
12:22 kados I'm still not really groking this classification/call number stuff
12:21 thd   not a universal scheme
12:21 kados weird
12:21 thd   4 is shelving control number
12:21 kados thd: that's useful ... what's '4'?
12:20 kados talk about a mess!
12:20 thd   kados: 852 indicator 1 specifies classification scheme used.  0 is LC,  1 is DDC, etc. http://www.loc.gov/marc/holdings/echdloca.html#mrch852
12:20 kados long term they want to switch to LOC
12:20 kados some stuff uses the internal and some uses dewey
12:20 kados cause they started out using an internal system ... then switched to dewey
12:20 owen  Why not just use classification for everything?
12:20 owen  I guess I'd try to figure out what dewey gets you.  Is there an advantage to using it?
12:19 kados (another column)
12:19 kados and the internal classification somewhere else?
12:19 kados say have the dewey ones in a different column
12:19 kados would you want to differentiate betweeen them on the OPAC
12:19 kados some are internal
12:19 kados some items are dewey
12:19 kados say you've got three or four classification types in a single collection
12:19 kados yea ... not sure if I do either
12:18 owen  Uh... I don't know what you're asking
12:18 kados owen: so ideally you'd keep the call number/classification separate right?
12:18 owen  Yeah
12:18 kados owen: quick question
12:16 kados with the order of 852$k$h$i$m
12:16 kados most stuff is dewey and some is internal classification
12:16 kados I just spoke with them and they only recently started using LOC
12:15 kados $a
12:15 kados thd: and some LOC in 092
12:15 kados thd: they have some dewey stuff in $h
12:15 kados thd: I think so