[dini-ag-kim-identifier] Http-URIs for items

[Jakob Voss]

Christian Hauschke schrieb:

>> Es gibt übrigens noch einen weiteren Exemplar-Identifier und zwar
>> den Barcode. Deshalb werde ich zusätzlich Exemplar-URIs folgender
>> Form einführen:
>>
>> http://uri.gbv.de/document/$DBKEY:bar:$BARCODE
>>
>> Der Barcode ist allerdings nicht in jedem Fall dauerhaft. So werden
>> für Fernleihen von der empfangenden Bibliothek u.A. neue Barcodes
>> vergeben. Trotzdem halte ich den Barcode für eine Gute Wahl, da sie
>> international standardisiert sind. Bei Verwendung von RFID steht am
>> Exemplar neben dem Barcode sogar auch die ISIL. Schau dir mal ISO
>> 28560 an.
>
> Einwand: nicht jedes Exemplar hat einen Barcode. Dies betrifft in
> einigen Bibliotheken zum Beispiel nicht ausleihbare Präsenzexemplare,
> wie das 1. Ex. von
>
> <http://opac.lbs-braunschweig.gbv.de/DB=5/PPN?PPN=626977835>
>
> Hier gibt es eine Signatur (die ich wegen Umsystematisierungen /
> Umsignierungen nicht für geeignet halte): AA B 200 (5)/10. Und es
> gibt eine EPN, die es allerdings nur im PICA-Kontext gibt:
> 1272237109. Einen Barcode gibt es allerdings nicht.

Irgendeine ID wird das Exemplar schon haben, ansonsten erübrigt sich die 
Diskussion. Ich kann nur für den GBV sprechen, wo ich bislang folgende 
Fälle kenne:


A. Exemplare mit oder ohne EPN

A.1. Exemplare, die eine eindeutige EPN haben (die allerdings nur im 
Zusammenhang mit einem konkreten Katalog eindeutig ist)

A.2. Exemplare, die gemeinsam mit anderen Exemplaren eine EPN haben 
(z.B. Bandsätze).

A.3. Exemplare, die keine EPN haben (z.B. Titel die aus der Fernleihe 
kommen und nicht im Katalog stehen)


B. Exemplare mit oder ohne Barcode

B.1. Exemplare, die einen eindeutige Barcode haben (der allerdings nur 
im Zusammenhang mit einem Katalog oder einer ISIL eindeutig ist)

B.2. Exemplare, die keinen Barcode haben

B.3. Exemplare, die einen Barcode, der allerdings nicht im Katalog steht

B.4. Exemplare, die einen anderen Barcode haben als er im Katalog steht


Daraus leite ich folgende URIs ab:

A.1. => http://uri.gbv.de/document/$DBKEY:epn:$EPN

A.2. => http://uri.gbv.de/document/$DBKEY:epn:$EPN-XXX (noch zu 
klärendes Postfix)

B.1. => http://uri.gbv.de/document/$DBKEY:bar:$BARCODE

B.4. => http://uri.gbv.de/document/$DBKEY:bar:$BARCODE


Ggf. hat also ein Exemplar auch keine URIs (A.2 + B.2/3), zwei URIs 
(A.1/2 + B.1) oder sogar eine falsche URI (B.4). Das lässt sich aber 
nicht mit besseren URI-Schemata oder anderen theoretischen Konzepten 
ändern sondern nur indem die Qualität der Katalogdaten verbessert wird. 
Das Problem hat also weniger mit URIs Linked Data, RDF etc. zu tun 
sondern mit Datenqualität und Management.

> Muss es denn zwangsläufig eine ID sein, die aus vorhandenen Daten
> erzeugt wird? Wäre nicht beispielsweise auch eine UUID möglich, die
> dem bibliothekarischen Alltag trotzt und an der Umsystematisierungen
> und Buchbindearbeiten spurenlos vorbei gehen?

Abgesehen von Hellseherei gibt es nur zwei Optionen:

1. Die ID wird aus vorhandenen Daten erzeugt
2. Es wird eine neue ID erzeugt und in eine Tabelle eingetragen,
    die die neue ID mit vorhandenen Daten verknüpft.

Eine dritte Möglichkeit gibt es nicht. Im Zweiten Fall muss jemand die 
Tabelle warten, die eine weitere mögliche Fehlerquelle darstellt.

Jakob

-- 
Jakob Voß <jakob.voss at gbv.de>, skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
+49 (0)551 39-10242, http://www.gbv.de