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

Jörg Prante prante at hbz-nrw.de
Fri Jun 14 23:59:21 CEST 2013


Hi Carsten,

thanks for your work moving forward on the road!

I also have adopted Z39.71 in my ontology at
http://bibitems.org/2013/05/item# so here are my comments to your
questions.

The structure of "bibliographic units" is both logical and physical,
from what I understand.

- there is a "basic bibliographic unit", which is prominently
described. It can have single, multipart, or convoluted ("lose",
"ungezählt", "lückenhaft") physical structure. Such units carry
designations (chronologically, and/or enumerative).

- and there are supplemental units, for example, registers or indexes
(like "Registerbände" of serials in ZDB). They have no designations and
co-exist with a basic unit.

- there can be secondary bibliographic units, like reproductions on
microform, or digitizations (in ZDB, microforms are quite well hidden in
ZDB-Titel, in the paper version record). Secondary units are parallel to
primary units.

And there is the item. An item is comprised of a basic unit with all
connected units. For example, all the issues of a serial from within a
year, after being processed by book binding, are shelved as a single
item. But there may be two volumes, for example if the book binder
decides that one volume is too heavy, a second volume is added. In the
volumes, there is physical structure, and in the units, there is logical
structure, in form of chronological or enumerative desginations.

In general, an item is the smallest thing the librarian can hand over
to a patron for reference, or for circulation. An item gets a single
shelfmark, and a single barcode (or a number, for inventory). It can
have multiple locations in a library, depending on the current  service
("Ausleihbereich", "Magazin").

A holding is a complete description for an item, together with
information about the library, and services for the item (for example,
if inter library loan is allowed or not, or if the item can be accessed
online).

Don't worry too much about URIs. In RDF models, there are many classes
(each are identified by URIs and should carry an rdf:type), and there
are properties (the attributes), also defined by URIs. So there should
be many, many URIs for units, items, services (access information),
holdings, and their relationships.

Best regards,

Jörg


>>> "Klee, Carsten" <Carsten.Klee at sbb.spk-berlin.de> schrieb am
14.06.2013 um 16.36
Uhr in Nachricht
<F92C45C191C9FB4281F352EB52DFA7AD0857EEB0 at PMXMDB02.pk.de>:
> 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_5gFc8QhODdHU0R3IzQlFlcEV6TkI
> 1U0lmYnpONWc#gid=2>
> 
> [2] 
>
<https://docs.google.com/spreadsheet/ccc?key=0Aq_5gFc8QhODdHU0R3IzQlFlcEV6TkI
> 1U0lmYnpONWc#gid=3>
> 
> [3] 
>
<https://wiki.dnb.de/display/DINIAGKIM/Collection+of+Holdings+Ontologies%2C+V
> ocabularies%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




-- 
Jörg Prante
hbz, Gruppe Portale
- Digitale Bibliothek und Online-Fernleihe -
Postfach 270451, 50510 Köln, Deutschland
Telefon +49-221-40075-156, Fax +49-221-40075-190
prante at hbz-nrw.de
http://www.hbz-nrw.de




More information about the Dini-ag-kim-bestandsdaten mailing list