On Thu, Mar 10, 2011 at 8:49 PM, Ian Walls <ian.walls@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@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.