IRC log for #koha, 2007-10-08

All times shown according to UTC.

Time S Nick Message
00:30 thd kados: why is biblioitems.ccode at the biblioitems level instead of at the items level?
00:31 thd kados: different collections then cannot share the same basic bibliographic record
00:42 kados thd: I'm here
00:42 kados good point
00:42 kados it should be at both levels
00:43 thd kados: why have it at the biblioitems level at all?
00:46 thd kados: also, why would you store cn_edition in the SQL tables unless what you actually meant was classification source: DDC, LCC, etc.?
00:48 thd kados: edition by itself should not be relevant for sorting, it is significant for knowing the meaning in case of changes between editions.
00:50 kados thd: i'm here
00:50 thd did you see the 2 additional questions?
00:51 kados yes
00:51 kados I'm thinking :-)
00:51 thd kados: also what I said about ccode applies equally to classification
00:52 thd kados: different library consortia members, branches or collections might have different classification for the same material
00:53 thd kados: you could specify that a different bib record should be used if the classification is different for an item but is that what you really want?
00:53 kados hmmm
00:54 kados I need a few minutes
00:54 kados having a chat with ryan
00:57 thd or you could have actually repeatable classification in 942 with an additional entry if multiple classification is used between different items
01:40 kados thd: OK, I agree about ccode (Collection Code)
01:40 kados thd: it belongs at the items level
01:41 kados and not at the biblioitems level
01:41 kados cn_edition, that is from the spec
01:41 kados thd: it's for dewey only
01:42 kados thd: http://www.loc.gov/marc/biblio[…]clas.html#mrcb082
01:43 kados thd: I forgot about classification source
01:43 kados thd: that does belong at both bib and item level
01:43 kados cn_source
01:44 kados items.cn_source
01:44 kados biblioitems.cn_source
01:44 kados classification IS at the bib and item level
01:59 thd kados: why would you store cn_edition in the SQL tables?  I certainly understand the advantage of storing it in the record but why in SQL?.
02:01 kados hmmm
02:01 kados well for one it will be easier to display that way
02:06 thd ok but if we add cn_edition as separate and distinct from cn_source in which it would be included in MARC then after also adding cn_sort and ccode to items mappings we have to loose something
02:07 thd for storing in the record in 952 or for mapping
02:08 kados good point
02:08 kados ahh, wait
02:08 kados remember, we're not doing it item-leve in the sql
02:08 kados just biblioitem level
02:08 kados remember, I got shot down on that proposal :-)
02:08 thd unless call number prefix is the equivalent of collection which does not seen necessarily true
02:10 kados my feeling is that call number prefix could be any field they want it to be
02:10 thd Oh, I was reading your statement "classification IS at the bib and item level" and assuming that you had now been shot up
02:10 kados well, it's there, just not in the SQL
02:10 kados you already mapped it to the 952
02:12 thd kados: Wat do you do about different library consortia members, branches or collections might have different classification for the same material?
02:14 thd kados: if they share the same biblio with different classification systems then cn_sort needs to be at the item level does it not?
02:14 kados yes, I"ve added it to the item level
02:15 kados biblioitems.cn_source (needs auth value)
02:15 kados biblioitems.cn_class
02:15 kados biblioitems.cn_item
02:15 kados biblioitems.cn_edition
02:15 kados biblioitems.cn_suffix
02:15 kados biblioitems.cn_sort
02:15 kados items.itemcallnumber
02:15 kados items.cn_source
02:15 kados items.cn_sort
02:15 kados items.ccode
02:16 kados make the cn_class a plugin
02:16 kados that plugin will fill values for all of the others
02:16 kados also make itemcallnumber a plugin
02:17 kados and make ccode a authorized value with CCODE
02:17 thd kados: ok so we loose 952 $6 and $8 to add cn_sort and ccode
02:17 kados ok
02:17 thd cn_source already has a place at 952 $2
02:18 thd kados: why two plugins when one would do at the items level?
02:19 kados we need one at the bib level
02:19 kados to decide what belongs in 942 in the first place
02:19 kados there may be nlm, ddc, and lcc call numbers
02:19 kados in the record
02:20 kados but what belongs in the 'official' call number for koha
02:20 kados that's whaty we need the plugin
02:20 thd kados: is that not double effort of even tabbing through the 942 field for the cataloguer?
02:20 kados yes, but I also have to release 3.0 soon :-)
02:20 thd kados: so you are only going to sort on one?
02:20 kados this will do the job
02:21 thd kados: as long as the LCC and DDC libraries in your consortia are happy :)
02:22 kados exactly :-)
02:22 thd they should be happy just using 3.0 of course
02:23 kados :-)
02:23 kados ok, I'll send you these revisions
02:26 kados thd: sent
02:30 thd kados: cn_edition should also have a value list
02:31 thd kados: in MARC 21 source and edition are unfortunately often combined for fields like 055 and 852
02:31 kados sure, give it a auth value for CN_EDITION
02:31 kados since it's a DCC-specific one that's easy
02:32 kados ahh, well hang on
02:32 kados the same subfield is used for source
02:32 kados we can't do that this time around
02:32 kados that'll have to wait for 3.2
02:33 thd kados: if it was always filled with a plugin you could easily distinguish source from edition inside the plugin
02:34 kados make sure that the sort fields are hidden from everything
02:34 thd kados: that is an easy plugin :)
02:34 kados they are strictly internal
02:34 kados thd: you underestimate how much time I have :-)
02:34 kados overestimat I mean :-)
02:35 thd kados: no I don't.  I presume that you only have negative time borrowed against the future :)
02:35 kados hehe, yea, that's abotu right
02:52 thd thinking about using items.issues, etc. for popularity.  Popular books with many copies will be under represented.  Popularity should accumulate at the by branch or library wide and be represented at the biblio level for sorting by popularity.
02:52 kados I agree
02:52 kados in fact, I have already done something like that
02:52 kados it requires a batch process though
02:53 kados biblios can't be updated with every circ
02:53 kados it's too proc intensive
02:54 thd kados: so I question the utility of mapping items.issues, items.renewals, and items.reserves because you are only measuring barcodes
02:54 kados at least map issues
02:54 kados renewals and reserves you can skip
02:55 kados thd: one thing to keep in mind
02:55 kados if something is not mapped to items, and it's in the items marc data, it's wiped out on update
02:56 kados so any extranous marc holdings fields will just be deleted anyway
02:56 kados that's how 3.0 works
02:56 kados if it's not in the items table, it doesn't exist :-)
02:56 kados we need to do it that way to ensure that there is an authoritative spot for items data
02:57 kados as opposed to the 2.2 method, where depending on context, items table or marc data was authoritative
02:57 thd kados: the authoritative spot being SQL?
02:57 kados yes, for items data
02:57 kados (for bib data, the authority for everything but the biblionumber is the marc record)
02:57 kados that's not something we can change this late in the game either
02:58 kados thd: so no sense in putting up a fight for those missing bits of data :-)
02:58 kados it does indicate that we probably still need cn_editions
02:59 thd kados: so if anyone would use the new URI 952 $u equivalent to the new 852 $u for a URL for item location then we need items.uri
03:00 kados good point
03:03 thd I favour using the items.renewals and items.requests places in 952 for items.cn_sort and items.ccode
03:03 kados sounds good to me
03:05 thd kados: that would allow the crazy people trying to sync with standard MARC to use 952 $6 with items.link and 952 $8 with items.sequence
03:05 kados we dont' have link or sequence
03:06 thd kados; and you should have biblioitems.totalissues for periodically adding items.issues collectively
03:07 kados yep
03:07 kados thd: add that to 942 :-)
03:07 thd kados: if you had link and sequence it would be technically possible highly motivated cataloguers do record standard holdings in sync with 952
03:08 kados thd: we have another plan for that already
03:08 kados thd: but that won't make it into 3.0
03:09 thd kados:, I know but libraries could adopt 3.0 while  waiting if they could maintain things in manner close to standard
03:09 kados thd: 3.2 will be released shortly after 3.0 :-)
03:09 thd items.link and items.sequence would make that possible
03:10 kados they don't belong at the items level
03:10 kados or the record level
03:10 kados and I don't have time to discuss it right now :-)
03:17 thd kados: we also need to record all the classification parts in items merely to preserve them from loss
03:18 kados thd: can't do that for 3.0
03:18 kados sorry
03:18 kados it'll have to be in itemcallnumber
03:18 kados as a concatenated string
03:18 thd kados: just to store them
03:19 thd kados: I understand that the code may not support sorting them but the code should be able to preserve the parts in SQL instead of losing them on update
03:21 kados actually, the framework shouldn't support those fields, they give the false impression that Koha will save them :-)
03:21 thd kados: Koha could easily save them just to save them
03:32 kados thd: biblioitems.lccn needs to be mapped to the LC Call Number
03:32 kados thd: if it's not already
03:32 kados ahh, it is already
03:33 thd you mean LCCN 010 $a
03:33 kados yes
03:33 thd always was
04:29 thd kados: what in the items table is preserving materials specified 952 $3 for the text string for a bound volume of a serial or other particular of a biblio which has its own separate bar code?  items.material
04:29 thd ?
04:29 thd or items.materials ?
04:40 thd kados: is cn_class for the classification part only?  Does marc21_callnumber.pl fill all the cn_.* values?
04:42 thd kados: call number prefix in 942 should still have a value list so the cataloguer is not typing JVU when JUV was intended and working too fast to notice
05:06 thd kados: is both a value list and a plugin allowed?
05:07 thd kados: we have that now for CN_SOURCE and marc21_classcodes.pl
05:09 thd kados: can a plugin read values from CN_SOURCE to use for populating the plugin values?
05:10 kados hi thd
05:10 thd hello
05:10 kados at the moment, value lists and plugins are mutually exclusive
05:10 kados but a plugin can read values from an authorized value
05:11 kados and you wouldn't need to put the authorized value in the framework for that to happen
05:11 kados a plugin can basically do anything you need it to do
05:11 kados except provide a drop-down :-)
05:12 thd I assumed that but just to be certain there was no strange isolation
05:12 thd a popup is almost as good as a drop down
05:12 kados yep
05:37 kados thd: received
05:37 kados thd: thanks!
05:37 thd sent with a note suggesting preserving $t because it is universally used by libraries I have seen
05:45 kados *nod*
05:48 thd I left out biblioitems.totalissues
05:48 thd preparing to send again now
05:54 thd kados: sent with correction
05:58 kados thanks
06:42 thd kados: I missed a field for items
06:43 thd kados: there is nothing preserving 952 $f coded location qualifier
06:50 thd and I mislabelled a plugin
08:10 chris hi paul and hdl
08:10 paul hi crhis
08:10 paul chris even ;-)
08:10 chris going to be a north vs south final it seems
08:11 paul yep
08:11 chris maybe france vs argentina .. the revenge :)
08:11 paul france saf I bet
08:11 hdl GB SAF
08:11 chris yes i think so too, altho ... fiji troubled SAF more than i thought
08:12 chris so maybe argentina can beat them
08:12 hdl But maybe SAF were too much confident.
08:12 chris yeah
08:12 hdl And they will be more cautious next time
08:13 chris i think so
08:13 hdl (This may explain why NZ lost the game :D )
08:13 chris i think they just hadnt played together enough
08:14 chris too much of this rotation policy
08:14 hdl (NZ players affected to disregard French team )
08:16 chris yeah, i think a little bit of that, but i think also not enough hard games leading up
08:18 chris have you seen this ? http://www.icikm-2008.com.np/index.php?p=tutorial
08:19 chris if you want to do a paper http://www.icikm-2008.com.np/i[…]x.php?p=forpapers
08:20 chris im a reviewer :) http://www.icikm-2008.com.np/i[…]x.php?p=reviewers
08:31 hdl Are YOU doing a paper ?
08:35 chris i dont think i can if im reviewing :)
08:35 chris im doing a 3 day tutorial on using Koha though
08:35 chris using, submitting patches, adminstering etc
08:39 chris i hope to teach people not only how to use koha, but how to fix bugs :-) with the new sending patches in, its quite easy for someone to do if they want too
08:52 hdl chris : but then, ppl would still need an IT guy.
08:58 chris yep, i think a few of the people coming to the conference will be IT guys
08:58 chris so ill try to teach them things about how to backup koha, mysql configuration tweaks etc
08:59 chris and try to teach the librarian type ppl about how to use Koha

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