[Koha] Idea: Basing Cart off Items instead of Biblios

[hansbkk at gmail.com]

On Thu, Mar 10, 2011 at 8:49 PM, Ian Walls
<ian.walls at bywatersolutions.com> wrote:
> What we really need here is Arbitrary Biblio Relationships, so we can have
> these distinct biblios broken down by item type (or, rather GMD), but also
> have a 'higher level' biblio that patrons can place holds upon if they don't
> care about the format.  I've got this all spec'ed out, I just need some time
> and funding to make it happen.

Isn't that what the original intention was behind the three
hierarchical levels in the Koha database? If this were the case there
would be no need for ItemType at the item level, only at BiblioItem.
The choice could then be "1:1 Biblio:BiblioItem" (what we have now
with the old style biblio-level itemtypes) or 1:many.

Biblio = "2009 Proms Gala"

BiblioItemA "DVD-VDO"
BiblioItemB "DVD-MKV"
BiblioItemC "DVD-AVI"
BiblioItemD "VHS"

with the Items (holdings) level being identical copies of their parent
BiblioItem.

My understanding is that Biblio and BiblioItem effectively merged to
become a single table via code-enforced one-to-one relationship around
the time of Koha adopting Marc record frameworks. It seems to me that
must mean that few libraries needed that flexibility, much less the
ability to specify an Abritrary relationship (?). I would advocate
KISS at such a fundamental level, the whole code base seems to have
not yet fully adapted to having the relatively simple choice between
item-level and biblio-level itemtypes.

> On Thu, Mar 10, 2011 at 8:42 AM, Nicole Engard <nengard at gmail.com> wrote:
>> Traditional cataloging rules state that you shouldn't be attaching
>> multiple item types to one bib record, so if you have multiple copies
>> of the book those should be on one bib record and if you have an audio
>> book that should be a different record. Not all libraries follow that
>> rule, but if that rule is followed then yes patrons would just want
>> the next copy of the item returned, not a specific item.

Well, there must have been compelling reasons for Koha to evolve to
accommodate item-level ItemTypes, and they seem a great fit for my use
case. Note that my scenario is very different from "paper book" vs
"audio book", which are actually different in content and patron
experience, not just the carrier medium. My example is more of a
simple "tech detail" difference, like VHS vs Betamax, or say a set of
biblio records, available in both MARC and XML.

If we only had biblio-level itemtypes, maintaining a large set of
Biblio records for such resources (that are identical except for
carrier medium) would be a nightmare, not only for staff-level editing
of the biblio information (updating cast lists, genre, subject
headers) but especially when making use of dynamic features like user
tagging and lists - which I fully intend to do!

IMO the current database architecture at this level strikes a good
balance, just some ongoing tweaking of the support module/scripts is
needed to accommodate that level of flexibility.