[Dini-ag-kim-bestandsdaten] Holdings, Units, Items and URIs

[Klee, Carsten]

Hi everybody!



I like to have your input on my thoughts on how to model holding data.



But first I want to let you know, that I was busy and extended our Google spreadsheet with information from the Z39.71 [1] standard as also from the MARC Holdings [2] description. You'll find all links under [3].



I also updated the wiki page "Scope of Holdings" [4] with the proposed holding entities. But then I ran into some trouble defining the core properties of holdings.



The question is: What is the relation between a Holding, a Unit, an Item etc.?



Let me explain this, so maybe you can figure out what I'm talking about.



Lukas Koster wrote an article in January 2012 about this [5]. He said that there is a Holding-level, which links all Items or access information on electronic documents to a Manifestation.

[cid:image004.jpg at 01CE691D.07A33E70]

In this case every Item and every Holding has an own URI.



Jakob Voß on the other hand wrote a little bit later [6], that there is no Holding-level but only Items.

[cid:image005.jpg at 01CE691D.07A33E70]



This view corresponds with the little diagram I created earlier:

[cid:image006.jpg at 01CE691D.07A33E70]



In this case there is a "Holding". But it is only the description for the Item. And there is only one URI!



Now I come a little bit closer to the core of the problem:

In all of the formats and standards like MARC, Z39.71, ZETA etc. there is always the possibility to subsume multiple Units/Items within one Holding.



For instance the MARC Holding field 852 (Location) is repeatable. And in our union catalogue it is common that multiple Units with different locations, callnumbers and access restrictions are described in one holding record.



This means if someone wants to follow Jakobs and my model, she has to split her data into Units/Items to generate multiple Holding descriptions with an URI for each Unit/Item. And this means she has to invent an URI for each Unit/Item and cannot use the holding record identifier, right?



Do we really think that someone wants to do this? So what is the alternative?



Describing multiple Units/Items through one Holding - there could only be one URI for the whole Holding. Descriptions of multiple Units/Items are then blank nodes and nobody can state: This Item is available.



Can anybody help me with this? Is there a way out?



Have a nice weekend,



Carsten





[1] <https://docs.google.com/spreadsheet/ccc?key=0Aq_5gFc8QhODdHU0R3IzQlFlcEV6TkI1U0lmYnpONWc#gid=2>

[2] <https://docs.google.com/spreadsheet/ccc?key=0Aq_5gFc8QhODdHU0R3IzQlFlcEV6TkI1U0lmYnpONWc#gid=3>

[3] <https://wiki.dnb.de/display/DINIAGKIM/Collection+of+Holdings+Ontologies%2C+Vocabularies%2C+Standards>

[4] <https://wiki.dnb.de/display/DINIAGKIM/Scope+of+Holdings>

[5] <http://commonplace.net/2012/01/local-library-data-in-the-new-global-framework/>

[6] <http://jakoblog.de/2012/01/10/linked-local-library-data-simplified/>







_______________________________________________

Carsten Klee

Abt. Überregionale Bibliographische Dienste IIE

Staatsbibliothek zu Berlin - Preußischer Kulturbesitz

Potsdamer Straße 33

10785 Berlin



Fon:  +49 30 266-43 44 02

Fax:   +49 30 266-33 40 01

carsten.klee at sbb.spk-berlin.de

www.zeitschriftendatenbank.de


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.d-nb.de/pipermail/dini-ag-kim-bestandsdaten/attachments/20130614/18197361/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 34767 bytes
Desc: image006.jpg
Url : http://lists.d-nb.de/pipermail/dini-ag-kim-bestandsdaten/attachments/20130614/18197361/image006-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 17161 bytes
Desc: image005.jpg
Url : http://lists.d-nb.de/pipermail/dini-ag-kim-bestandsdaten/attachments/20130614/18197361/image005-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 39325 bytes
Desc: image004.jpg
Url : http://lists.d-nb.de/pipermail/dini-ag-kim-bestandsdaten/attachments/20130614/18197361/image004-0001.jpg