Best Practices
| Regel | Beispiel | Weiterführende Information |
|---|---|---|
| Nutze HTTP-URIs zur Identifikation von Dingen. | http://d-nb.info/1031251227 identifiziert Goethes "Die Leiden des jungen Werther" in der 2012 vom Reclam-Verlag herausgegebenen Ausgabe mit der ISBN 978-3-15-000067-0 | http://linkeddatabook.com/editions/1.0/#htoc10 |
| Nutze einfache, klar strukturierte URIs. | Die URI http://d-nb.info/1031251227 ist zusammengesetzt aus dem Namensraum http://d-nb.info/ und dem DNB-internen Identifier 1031251227. | "Patterned URIs" in "Linked Data Patterns". |
| Vergebe unterschiedliche URIs für ein Ding und seine Beschreibung. | Während http://d-nb.info/1031251227 die Ausgabe eines Buches bezeichnet identifiziert http://d-nb.info/1031251227/about die Beschreibung dieser Ressource (den "Record" oder Titeldatensatz). | http://www.w3.org/TR/cooluris/#distinguishing |
| Nutze bestehende überregionale, regionale oder lokale Identifier zur Generierung der URIs. | "Shared Keys" in "Linked Data Patterns" | |
| Wünschenswert ist das Angebot unterschiedlicher Formate über Content Negotiation. | Die durch http://lobid.org/resources/HT002189125 identifizierte Beschreibung lässt sich durch Modifikation des HTTP Access Headers in verschiedenen Formaten abrufen, z. B. Accept: text/turtle für Turtle, Accept: application/rdf+xml für RDF/XML, Accept: text/plain für N-Triples oder Accept: text/html für HTML. | |
| Wünschenswert sind auch unterschiedliche URIs für Repräsentationen einer Beschreibung in unterschiedlichen Formaten (JSON, RDF/XML, Turtle, HTML etc.). | Idealerweise lassen sich die unterschiedlichen Formate nicht nur über die Anpassung des HTTP-Accept-Headers abrufen, sondern auch durch Abfrage einer dedizierten URL. Bsp.: http://d-nb.info/982315627/about/rdf liefert die bibliographische Beschreibung in RDF/XML und http://d-nb.info/982315627/about/html liefert dieselbe Beschreibung in HTML. |
Anwendungsbeispiele für URI-Design
Hier ein paar Beispiele für URI-Design im Bibliotheksbereich aus dem deutschsprachigen Raum.
| Service | Medien-URI | Beschreibungs-URI | Beschreibung in spezifiziertem Format |
|---|---|---|---|
| B3Kat | http://lod.b3kat.de/title/<ID>; | http://lod.b3kat.de/page/title/<ID> | |
| Deutsche Nationalbibliothek | http://d-nb.info/<ID> | http://d-nb.info/<ID>/about Bsp.: http://d-nb.info/982315627/about
| http://d-nb.info/<ID>/about/<format> |
| lobid (hbz) | http://lobid.org/resources/<ID>#! | http://lobid.org/resources/<ID> | |
| HeBIS | http://lod.hebis.de/resource/<ID> | http://lod.hebis.de/page/<ID> | |
| ZDB | http://ld.zdb-services.de/resource/<ID> | http://ld.zdb-services.de/data/<ID> | http://ld.zdb-services.de/data/<ID>.<format> |
Erläuterung
<ID> steht für den bisher intern verwendeten Identifier für den Datensatz.
<format> steht für ein Kürzel zur Spezifizierung eines Dokumentformats.
2 Kommentare
Klee, Carsten sagt:
Es scheint mir schwierig da eine 'Empfehlung' herauszulesen.
Pohl, Adrian sagt:
Bin gestern nicht fertig geworden. Werde heute versuchen, dem Ganzen mehr einen "Empfehlungscharakter" zu geben.
Zur Differenz zwischen "Information Ressource", "Non-Information Ressource" und "Dokument", die du ergänzt hast:
Ich persönlich mag die Unterscheidung zwischen "Information Ressource" und "Non-Information Ressource" nicht. Gerade in unserem Bereich der bibliographischen Ressourcen ergibt das m. E. keinen Sinn, weil sich ohne Weiteres beides als "Information Ressource" klassifizieren ließe. Meines Erachtens ist es sinnvoller zwischen "Ding/Ressource" und "Beschreibung eines Dings" zu unterscheiden. Das Beschreibungsdokument wiederum kann in verschiedenen Serialisierungen/Formaten kommen. Da würde ich weniger von "Dokument" sprechen (das könnte sich im Prinzip auf alles drei beziehen), sondern von so etwas wie "Dokument in spezifiziertem Format". (Das gefällt mir jetzt auch nicht so gut. Vielleicht hat ja jemand eine bessere Idee.)