[Koha] biblionumber and biblioitemnumber

[Library Guy]

Thanks, Jesse.  BTW - it looks like merging them is planned for Koha
3.2 according to the developer wiki.

On Wed, Jul 15, 2009 at 4:22 PM, Jesse<pianohacker at gmail.com> wrote:
>
>
> 2009/7/15 Library Guy <library.guy.zero at gmail.com>
>>
>> Thanks Jesse.  Any guess what the original thinking was for this
>> 3-tiered structure?  I can't think of any advantage to it.
>>
>> James
>>
>> On Wed, Jul 15, 2009 at 3:52 PM, Jesse<pianohacker at gmail.com> wrote:
>> >
>> >
>> > 2009/7/15 Library Guy <library.guy.zero at gmail.com>
>> >>
>> >> What is the reasoning/advantage for assigning both a biblionumber and
>> >> a biblioitemnumber?  In my test database they are always identical.
>> >> Would there ever be an example where they would differ, and if not,
>> >> why the duplication?
>> >>
>> >> James
>> >> _______________________________________________
>> >> Koha mailing list
>> >> Koha at lists.katipo.co.nz
>> >> http://lists.katipo.co.nz/mailman/listinfo/koha
>> >
>> > In the past, it was actually a three-level hierarchy; each biblio had
>> > multiple biblioitems, which in turn had multiple items. Nowadays, biblio
>> > and
>> > biblioitems perform much the same function, but the split remains.
>> > (There
>> > was a proposal to merge the two tables, but I'm not sure what's
>> > happening
>> > with that.)
>> >
>> > Note that biblionumber and biblioitemnumber are _usually_ equal, but
>> > it's
>> > not safe for the code to assume so. There are situations where they get
>> > out
>> > of sync.
>> >
>> > --
>> > Jesse Weaver
>> >
>
> It actually allowed some fairly interesting features. For instance, if a
> biblio had copies both in audiobook form and print form (separate
> biblioitems), it allowed patrons to place a hold either on any form of that
> book, any copy of just one form (say, any of the copies of the audio book),
> or just one particular copy of the book. The original sponsors of Koha and
> this feature, the Horowhenua Library Trust, have called it a proto-FRBR.
>
> That said, that particular code has aged so much that bringing back such
> features would be a massive undertaking (that we might have to do anyway, if
> FRBR ever becomes practical).
>
> See http://www.frbr.org/ for more info on FRBR.
>
> --
> Jesse Weaver
>