[Koha] Biblio records as book set "container" records - hierarchical groupings, et seq.

Steven F. Baljkas baljkas at mb.sympatico.ca
Fri Jul 9 16:15:01 NZST 2004


Thursday, July 8, 2004     22:40 CDT

Hi, Hans,

Since your follow-up invited "feedback on how I'm totally off-base regarding
normal library practices <g>, along with suggestions on how to accomplish
what I'm trying to do", I thought I might give this a go. Shan't be as long
or as detailed as you deserve, given the effort you put in, but after 3
reads, my head is still swimming slightly ;-) ...

I understand the hierarchical nature of the sets. Excellent diagramming BTW.
:-)

I think what you proposed is very imaginative and thorough but I think it
might prove overwhelming for you or others to code and daunting even to look
at on the OPAC.

What I would propose as a 'counter-offer' is using a series tag 440 (or
490 - 830 if necessary), based on the understanding that these sets of books
really are parts of series that are meant to be used in the way that you are
doing.

If you created/imported a simpler MARC record for each title, you could make
the links with their hierarchical series by creating a useful local 440
(series tracing). Granted, this may not be a perfectly kosher use of the
440 -- what you choose might not be recognised anywhere else as a series --,
but what you are proposing otherwise really would require detailed Analytics
(library jargon) that would give any cataloguer a headache.

In any case, what I am proposing would allow OPAC users the ability to find
each individual title without necessarily making each individual record
overwhelming (20-30 title- and/or author-title added entries plus the
problem of deciding a legitimate 245 entry). Each record would have the 440
showing what group it belongs to as well as the call number which would show
where it is collocated/located on the shelves.

Again, on the creative and imaginative, I think your classification schema
is quite neat, but if these are stable sets (i.e. there isn't anything
significant that is going to be going in/coming out of them), it might be
simpler to make a Dewey like number, something like this (and please forgive
me if I don't get the details all correct in this first go at it):

001
Kip
r1 <and so on for readers, playscripts, etc.>
a1 <and so on for added title cutters (if desired to lock down
 -       title order:  if you desire that level of alphabetic
z9    arrangement on the shelves, be careful here if more
        books are expected in the sets/series>
c.1 <i.e. copy 1, and so on>

---- for what you diagrammed as ----

Oxford====>Reading Tree===>Stage 1==>Kipper=>Readers:

The '001' part would represent all of  the "Oxford====>Reading Tree===>Stage
1" element.
"Kip" would represent the 'subseries' "Kipper", the "r1" (or simply 'r') the
"Readers" group of format, and the "a1 - z9" (and so on), the titles of the
individual readers, if that is something desirable for keeping the
collection in predictable order. Copy numbers would be added last as is
usual.

This kind of system, of course, would depend on whether I understood what
you meant by --

> Our shelving/numbering system (at least for this Item type) is to put
> all the books in order of reading difficulty level. I've created an
> alphanumeric local call number, which is the first part of the
> barcode that shows the level, then the set, then the titles, and then
> the copies. So Q010A04 means "the fourth copy of title A in set 010
> in reading difficulty level Q". I've collected all my MARC records
> into text files by set. The file name for this set would be Q010.mrc,
> which would contain the MARC records for titles A, B, C, etc.

-- that is, specifically, whether you meant that, within each grouping, the
Kipper, Biff etc. are providing the collocation of reading difficulty. If
there are multiple levels within each of those, it could still be salvaged
by adding digits to the series, provided that this would preserve the
shelving arrangement that your staff desired.

> I plan to import these one set file at a time, and if any MARC fields
> could be added to the records before importing to facilitate what I'm
> trying to do that would be relatively easy. I've done some initial
> reading of the MARC documentation and found some fields that seem
> designed to handle such relationships between separate titles (e.g.
> 440), but I only want to invest time in figuring out how to add them
> to my records if it will be useful within Koha after importing the
> MARC records.

This is the point where you lost me, Hans. Do you mean that somebody already
went to the trouble of creating the complex in-analytics that would track
each individual title within a 'master' record that lists everything in one
of these sets?!? Would it be possible for you to send a copy of this?
(offlist might work better, unless others are curious, too).

> Some of the MARC records list multiple ISBNs reflecting some of this
> information, but they aren't complete, nor even consistent within a
> series! It is critical for people to see what related resources are
> available when they are browsing a given Reader in the OPAC, but some
> people want to just use the readers and ignore the rest, so I don't
> want to artificially create monolithic sets forcing people to borrow
> more than they need.

That's why I suggested what I did above.

Another way to handle it, with analytics, would be to have brief but
complete records for all the 'elements' of the set, and a 'master' record
that listed (say in a 505 and with 700s) all the elements that make up the
set.

> As a separate but related issue, people placing orders to replenish
> our inventory should know which ISBNs to use for ordering - via set
> ISBNs rather than individually. Some ISBNs might be for six copies of
> one title within the series, others might be for one copy of each
> book in the series, another might be for six copies of each Reader
> plus one of each Big Book and take-home card plus one Teacher's Guide
> covering everything. And so on, with many permutations for each
> publisher. If necessary this information can be stored outside the
> system, but if it's possible for Koha to show these relationships
> that would be ideal. Even better would be for the budgeting and
> acquisitions modules to take advantage of such data.

That's why I would favour each element being linked as part of a series,
even if that isn't strictly speaking, a true series.

> [major snip]

I can't tackle your questions on s the Biblio:Biblioitems relationship,
because, quite frankly, I've never got this straight in my own head.
Hopefully someone else will tackle that one for you.

> Phew! I really hope I'm making things more complicated than
> necessary, and there's a usual library management practice to handle
> this reflected in Koha and/or MARC information.

That's okay. We're all in different places in these regards and you've only
asked for help. The worst that can happen is that no one will have the
right/good-enough answers. ;-) As many of us learn in library tech and
professional library studies, in librarianship, 'it depends' is usually the
right answer and you will find a fairly wide range of acceptable practices.

> I appreciate your even reading this far, much less actually attempting an
answer <g>

Hope you still feel that way ;-) and that this answer may help in part. Give
us a shout back and let the games begin.

Cheers,
Steven F. Baljkas
library tech at large
Koha neophyte
Winnipeg, MB, Canada


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.707 / Virus Database: 463 - Release Date: 15/06/2004




More information about the Koha mailing list