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

[Ian Walls]

Item type does not necessary need to mean material type; You could have 3
different "Book" types if for some reason these materials circulated
differently (like one was a regular material, the other reference, and the
third an archival copy).  In this case, you'd want a single biblio, because
they're all essentially the same material, just different copies that have
different circulation rules attached.

-Ian

On Thu, Mar 10, 2011 at 9:21 AM, <hansbkk at gmail.com> wrote:

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



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20110310/2de543c8/attachment.htm