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.<br>
<br>-Ian<br><br><div class="gmail_quote">On Thu, Mar 10, 2011 at 9:21 AM, <span dir="ltr"><<a href="mailto:hansbkk@gmail.com">hansbkk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Thu, Mar 10, 2011 at 8:49 PM, Ian Walls<br>
<div class="im"><<a href="mailto:ian.walls@bywatersolutions.com">ian.walls@bywatersolutions.com</a>> wrote:<br>
</div><div class="im">> What we really need here is Arbitrary Biblio Relationships, so we can have<br>
> these distinct biblios broken down by item type (or, rather GMD), but also<br>
> have a 'higher level' biblio that patrons can place holds upon if they don't<br>
> care about the format. I've got this all spec'ed out, I just need some time<br>
> and funding to make it happen.<br>
<br>
</div>Isn't that what the original intention was behind the three<br>
hierarchical levels in the Koha database? If this were the case there<br>
would be no need for ItemType at the item level, only at BiblioItem.<br>
The choice could then be "1:1 Biblio:BiblioItem" (what we have now<br>
with the old style biblio-level itemtypes) or 1:many.<br>
<br>
Biblio = "2009 Proms Gala"<br>
<br>
BiblioItemA "DVD-VDO"<br>
BiblioItemB "DVD-MKV"<br>
BiblioItemC "DVD-AVI"<br>
BiblioItemD "VHS"<br>
<br>
with the Items (holdings) level being identical copies of their parent<br>
BiblioItem.<br>
<br>
My understanding is that Biblio and BiblioItem effectively merged to<br>
become a single table via code-enforced one-to-one relationship around<br>
the time of Koha adopting Marc record frameworks. It seems to me that<br>
must mean that few libraries needed that flexibility, much less the<br>
ability to specify an Abritrary relationship (?). I would advocate<br>
KISS at such a fundamental level, the whole code base seems to have<br>
not yet fully adapted to having the relatively simple choice between<br>
item-level and biblio-level itemtypes.<br>
<div class="im"><br>
> On Thu, Mar 10, 2011 at 8:42 AM, Nicole Engard <<a href="mailto:nengard@gmail.com">nengard@gmail.com</a>> wrote:<br>
</div><div class="im">>> Traditional cataloging rules state that you shouldn't be attaching<br>
>> multiple item types to one bib record, so if you have multiple copies<br>
>> of the book those should be on one bib record and if you have an audio<br>
>> book that should be a different record. Not all libraries follow that<br>
>> rule, but if that rule is followed then yes patrons would just want<br>
>> the next copy of the item returned, not a specific item.<br>
<br>
</div>Well, there must have been compelling reasons for Koha to evolve to<br>
accommodate item-level ItemTypes, and they seem a great fit for my use<br>
case. Note that my scenario is very different from "paper book" vs<br>
"audio book", which are actually different in content and patron<br>
experience, not just the carrier medium. My example is more of a<br>
simple "tech detail" difference, like VHS vs Betamax, or say a set of<br>
biblio records, available in both MARC and XML.<br>
<br>
If we only had biblio-level itemtypes, maintaining a large set of<br>
Biblio records for such resources (that are identical except for<br>
carrier medium) would be a nightmare, not only for staff-level editing<br>
of the biblio information (updating cast lists, genre, subject<br>
headers) but especially when making use of dynamic features like user<br>
tagging and lists - which I fully intend to do!<br>
<br>
IMO the current database architecture at this level strikes a good<br>
balance, just some ongoing tweaking of the support module/scripts is<br>
needed to accommodate that level of flexibility.<br>
</blockquote></div><br><br clear="all"><br>-- <br>Ian Walls<br>Lead Development Specialist<br>ByWater Solutions<br>Phone # (888) 900-8944<br><a href="http://bywatersolutions.com">http://bywatersolutions.com</a><br><a href="mailto:ian.walls@bywatersolutions.com">ian.walls@bywatersolutions.com</a><br>
Twitter: @sekjal<br>