some more thoughts on marc linkage of call number...
Hi, I am thinking of the "093" field we use here. It has the following structure (as far as I understand): a LC classification number c Cutter number y Year of publication - can be null (if a+c already uniquely identifies a book) - if not null, can be followed by a letter (a, b, c, etc.) if a+c+year cannot uniquely identify a book v Volume number (V.1, V.2, etc.) or other things like INDEXES, MANUAL, etc. What if there is a feature where we can map more than one subfield (e.g., c+y+v here) to one Koha field (e.g., biblioitems.subclass)? Would this make any sense? -- Ambrose Li Chinese Cultural Centre of Greater Toronto | http://www.cccgt.org/
Ambrose Li [CCCGT] a écrit:
Hi,
I am thinking of the "093" field we use here. It has the following structure (as far as I understand):
a LC classification number c Cutter number y Year of publication - can be null (if a+c already uniquely identifies a book) - if not null, can be followed by a letter (a, b, c, etc.) if a+c+year cannot uniquely identify a book v Volume number (V.1, V.2, etc.) or other things like INDEXES, MANUAL, etc.
What if there is a feature where we can map more than one subfield (e.g., c+y+v here) to one Koha field (e.g., biblioitems.subclass)? Would this make any sense?
it makes sense if you plan to use marc and non marc db back-end. if you plan to use only marc, i think you can avoid a link. if you really want to link, maybe *classification* is what you're looking for, but katipans should know better. Anyway, subclass is only char(3), so, a little bit too short. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIBGB libre http://fr.koha.org)
participants (2)
-
Ambrose Li [CCCGT] -
paul POULAIN