| 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 |
