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

[Linda Culberson]

Once, again to build off Han's model. How would you handle the 300 
(physical description) field  (which is repeatable) for videocassettes 
or beta that have been digitized or converted to another format  but are 
exactly the same information? Having multiple bibliographic records, 
such as Nicole describes doesn't work. There are also collections that 
contain multiple formats - 2 reels, 8 cassettes, 4 c.f. boxes.


On 1:59 PM, Ian Walls wrote:
> 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
> <mailto:hansbkk at gmail.com>> wrote:
>
>     On Thu, Mar 10, 2011 at 8:49 PM, Ian Walls
>     <ian.walls at bywatersolutions.com
>     <mailto: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
>     <mailto: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 <mailto:ian.walls at bywatersolutions.com>
> Twitter: @sekjal

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824