[Koha] Biblio and Biblioitem

Fri Dec 4 03:42:55 NZDT 2009

Yes, the biblio/biblioitem distinction was part of Koha 1.x, before it had MARC support.  It was designed by folks trained in database normalization and other computer science-y traditions, and just makes good sense from that perspective.  When Koha got MARC support in version 2.0, these tables were linked with a one-to-one correspondence, since MARC doesn't make the distinction between the two levels.  Biblionumber and biblioitemnumber should always be the same for any Koha 2.0+ installation.

There has been talk of merging the two tables together, since they are functionally one table already, but with the coming of RDA, and FRBR, and all that create new cataloging stuff, it may make sense to reevaluate the biblio/biblioitems distinction.

Anyone with more direct or personal experience with the development of this, please feel free to correct me if I've mis-stated anything; this is just my understanding of the situation.

Cheers,

-Ian

-----Original Message-----
From: koha-bounces at lists.katipo.co.nz [mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of Elaine Bradtke
Sent: Thursday, December 03, 2009 9:09 AM
To: Kyle Hall
Cc: Koha list
Subject: Re: [Koha] Biblio and Biblioitem

That would explain why there's no biblio.isbn but there's a
biblioitems.isbn.  If you're working with a 'concept' level regardless
of format, ISBN wouldn't be appropriate.
I think I get the picture. Thanks!

On Thu, Dec 3, 2009 at 1:38 PM, Kyle Hall <kyle.m.hall at gmail.com> wrote:
> The idea was to allow all items to share a common biblio even if they
> were different formats. So the biblio for Harry Potter & The
> Sorcerer's Stone may have biblioitems for Book, Large Print Book, DVD,
> VHS, Soundtrack etc. I believe this is how Koha worked in the
> beginning, but at this point I don't think there is a distinction
> between the two. You can think of them as a single table, as the
> relationship is one-to-one at this point. I think someone was working
> on bringing back that feature, but I've not heard much about it. I
> imagine Chris Cormack would be the best person to answer these
> questions.
>
> Kyle
>
> http://www.kylehall.info
> Information Technology
> Crawford County Federated Library System ( http://www.ccfls.org )
>
>
>
>
> On Thu, Dec 3, 2009 at 8:09 AM, Nicole Engard <nengard at gmail.com> wrote:
>> These terms are the names of MySQL tables - and now that I'm looking
>> at them, I'm not sure why there are two tables - maybe someone else
>> can explain the why - but if you understand MySQL then maybe the table
>> structure below will help you out.
>>
>> This from : http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob_plain;f=installer/data/mysql/kohastructure.sql;hb=HEAD
>>
>> --
>> -- Table structure for table `biblio`
>> --
>>
>> DROP TABLE IF EXISTS `biblio`;
>> CREATE TABLE `biblio` (
>>  `biblionumber` int(11) NOT NULL auto_increment,
>>  `frameworkcode` varchar(4) NOT NULL default '',
>>  `author` mediumtext,
>>  `title` mediumtext,
>>  `unititle` mediumtext,
>>  `notes` mediumtext,
>>  `serial` tinyint(1) default NULL,
>>  `seriestitle` mediumtext,
>>  `copyrightdate` smallint(6) default NULL,
>>  `timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP on update
>> CURRENT_TIMESTAMP,
>>  `datecreated` DATE NOT NULL,
>>  `abstract` mediumtext,
>>  PRIMARY KEY  (`biblionumber`),
>>  KEY `blbnoidx` (`biblionumber`)
>> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
>>
>> --
>> -- Table structure for table `biblioitems`
>> --
>>
>> DROP TABLE IF EXISTS `biblioitems`;
>> CREATE TABLE `biblioitems` (
>>  `biblioitemnumber` int(11) NOT NULL auto_increment,
>>  `biblionumber` int(11) NOT NULL default 0,
>>  `volume` mediumtext,
>>  `number` mediumtext,
>>  `itemtype` varchar(10) default NULL,
>>  `isbn` varchar(30) default NULL,
>>  `issn` varchar(9) default NULL,
>>  `publicationyear` text,
>>  `publishercode` varchar(255) default NULL,
>>  `volumedate` date default NULL,
>>  `volumedesc` text,
>>  `collectiontitle` mediumtext default NULL,
>>  `collectionissn` text default NULL,
>>  `collectionvolume` mediumtext default NULL,
>>  `editionstatement` text default NULL,
>>  `editionresponsibility` text default NULL,
>>  `timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP on update
>> CURRENT_TIMESTAMP,
>>  `illus` varchar(255) default NULL,
>>  `pages` varchar(255) default NULL,
>>  `notes` mediumtext,
>>  `size` varchar(255) default NULL,
>>  `place` varchar(255) default NULL,
>>  `lccn` varchar(25) default NULL,
>>  `marc` longblob,
>>  `url` varchar(255) default NULL,
>>  `cn_source` varchar(10) default NULL,
>>  `cn_class` varchar(30) default NULL,
>>  `cn_item` varchar(10) default NULL,
>>  `cn_suffix` varchar(10) default NULL,
>>  `cn_sort` varchar(30) default NULL,
>>  `totalissues` int(10),
>>  `marcxml` longtext NOT NULL,
>>  PRIMARY KEY  (`biblioitemnumber`),
>>  KEY `bibinoidx` (`biblioitemnumber`),
>>  KEY `bibnoidx` (`biblionumber`),
>>  KEY `isbn` (`isbn`),
>>  KEY `publishercode` (`publishercode`),
>>  CONSTRAINT `biblioitems_ibfk_1` FOREIGN KEY (`biblionumber`)
>> REFERENCES `biblio` (`biblionumber`) ON DELETE CASCADE ON UPDATE
>> CASCADE
>> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
>>
>>
>> On Thu, Dec 3, 2009 at 6:43 AM, Elaine Bradtke <bradtke.e at googlemail.com> wrote:
>>> Could someone please explain the terms Biblio and Biblioitem?  I tried
>>> looking through the manual and the FAQ's but the terms appear so
>>> frequently that I get too many hits. And the Glossary wasn't any help
>>> either.
>>>
>>> I'm editing the subfields in the MARC framework and under Advanced
>>> constraints there's a Koha link.  I was trying to link at what I
>>> thought was the appropriate level - the biblio.isbn  but there only
>>> appears to be a biblioitems.isbn
>>>
>>> Not understanding the difference between biblio and biblioitems makes
>>> me wonder if this will work.  I'm trying to link analyticals together
>>> using their common ISBN in the 773 Host Item Entry field.
>>>
>>> Quoting from the 3.0 manual:
>>> # link : If you enter a field/subfield here (200b), a little glass
>>> appears after the subfield. If the user click on the glass, a search
>>> is done on the DB for the field/subfield with the same value. Can be
>>> used for 2 main topic :
>>>
>>>    * on a field like author (200f in UNIMARC), put 200f here, you
>>> will be able to see all biblios with the same author
>>>    * on a field that is a link (4xx) to reach another biblio. For
>>> example, put 011a in 464$x, will find the serial that was previously
>>> with this issn. With the 4xx pligin, you get a powerful tool to manage
>>> biblios connected to biblios
>>>
>>> # Koha link : Koha is multi-MARC compliant. So, it does not know what
>>> the 245$a means, neither what 200$f (those 2 fields being both the
>>> title in MARC21 and UNIMARC !). So, in this list you can "map" a MARC
>>> subfield to it's meaning. Koha constantly maintains consistency
>>> between a subfield and it's meaning. When the user want to search on
>>> "title", this link is used to find what is searched (245 if you're
>>> MARC21, 200 if you're UNIMARC).
>>> --
>>> Elaine
>>> _______________________________________________
>>> Koha mailing list
>>> Koha at lists.katipo.co.nz
>>> http://lists.katipo.co.nz/mailman/listinfo/koha
>>>
>> _______________________________________________
>> Koha mailing list
>> Koha at lists.katipo.co.nz
>> http://lists.katipo.co.nz/mailman/listinfo/koha
>>
>

-- 
Elaine
_______________________________________________
Koha mailing list
Koha at lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

------------------------------------------------------------
This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is proprietary, confidential, and exempt from disclosure under applicable law. Any unauthorized review, use, disclosure, or distribution is prohibited. If you have received this email in error please notify the sender by return email and delete the original message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email.
=================================