Identifier in RDF considered harmful

18. Juni 2013 um 11:31 7 Kommentare

Ich bin gerade dabei die RDF-Daten des Linked Data Service der ZDB zu analysieren, um sie direkt im RDF-Bibliotheksverzeichnis des GBV nutzen zu können. Dabei sind mir einige Unterschiede bei der Behandlung von Identifiern aufgefallen. Hier ein Beispiel aus den Daten der
Stabi Berlin (das RDF-Subjekt habe ich zum Kürzen durch $BIB ersetzt):

GBV-RDF

$BIB
  dc11:identifier "DE-1a" ;
  foaf:phone <tel:+49-30-2-66-333501> , <tel:+49-30-2-66-433888> .

ZDB-RDF

$BIB
  dc11:identifier "(ISIL)DE-1a" ;
  vcard:tel [
     a vcard:Pref, vcard:Voice ;
     rdf:value "+49 30 2 66-433888 (Auskunft)"
  ], [
     a vcard:Fax, vcard:Pref ;
     rdf:value "+49 30 2 66-333501" .
  ] .

Solche unterschiedlichen Kodierungen sind besonders dann problematisch wenn RDF-Daten aus mehreren Quellen zusammengeführt werden sollen. Plötzlich hat dann in diesem Beispiel die Stabi Berlin zweil Identifier und vier Telefonnummern. Telefonnummern lassen sich übrigens nach RDF 3966 auch als URI kodieren, für ISILs gilt dies leider nicht, weil die internationale ISIL-Agentur versäumt hat, sich darum zu kümmern. Grundsätzlich bestärkt mich dieses Beispiel in der Überzeugung, dass Identifier in RDF-Daten Müll sind, solange sie nicht in Form von URIs kodiert werden – und zwar in vielen Fällen besser nicht als HTTP-URIs in mehrfacher Ausführung, wie im Rahmen von Linked Data gängige Praxis!

7 Kommentare »

RSS Feed für Kommentare zu diesem Artikel. TrackBack URI

  1. In welchen Fällen wäre ein Nicht-HTTP-URI denn besser? Hast Du ein konkretes Beispiel?

    Kommentar by CH — 18. Juni 2013 #

  2. ISIL werden wir zukünftig per URI identifzieren können: http://ld.zdb-services.de/resource/organisations/DE-1a. Ansonsten ist es das übliche Problem, dass es x Standards/Ontologien/Vokabularien gibt, um denselben Sachverhalt zu beschreiben… https://xkcd.com/927/

    Kommentar by jorol — 18. Juni 2013 #

  3. Prinzipiell gibt es in RDF drei Varianten, Identifier zu kodieren: als Literal, als HTTP-URI oder in einem eigenen URI-Namensraum. Beispiele für sinnvolle Nicht-HTTP-URIs, die auch definierte URI-Namensräume haben, sind Telefonnummern (siehe oben) und ISBN. Ein grundsätzliches Problem mit HTTP-URIs ist, dass praktisch jeder seine eigene Basis-URL verwendet – das geht mit Nicht-HTTP-URIs weniger, weil diese nicht zum automatischen Resolving gedacht sind.

    Ein Problem mit der ISIL als HTTP-URI ist, dass die ZDB nur HTTP-URIs für DE-ISILs vergeben kann. Sobald wir ISIL aus mehreren Ländern haben, gibt es kein gemeinsames URI-Prefix mehr.

    Kommentar by jakob — 18. Juni 2013 #

  4. Ein grundsätzliches Problem mit HTTP-URIs ist, dass praktisch jeder seine eigene Basis-URL verwendet – das geht mit Nicht-HTTP-URIs weniger, weil diese nicht zum automatischen Resolving gedacht sind.

    Es handelt sich also um ein soziales Problem. Man könnte ja durchaus die Identifier der anderen verwenden. Zumindest in vielen Fällen.

    Sorry, wenn ich hier etwas naiv daherkomme, aber die Identifier-Frage treibt mich immer wieder umher, besonders was Personen-IDs angeht. Und mir erschien das Shared-Patterns-Kapitel eigentlich recht sinnvoll. Und das ist doch nichts anderes als die von Dir kritisierte Verwendung von Nicht-HTTP-URIs mit unterschiedlichen Basis-URLs.

    Kommentar by CH — 18. Juni 2013 #

  5. Die foaf:phone-Lösung mit der Angabe einer Telefonnummer als URI ist in der Tat um einiges eleganter als das, was ZDB und lobid.org anbieten. Zwar gehen Informationen verloren, aber immerhin ermöglicht das eine klar definierte einheitliche Praxis. Ich werde mal anregen, das in lobid.org auch so zu machen. Der neue Public Working Draft der vCard-Ontologie setzt auch auf tel-URIs, allerdings ist vcard:telephone als Datatype Property angelegt (und nicht wie foaf:phone als object property), so dass Telefonnummern als typed literal (xsd:anyURI) abgelegt würden…

    Bei den ISILs ist das natürlich was anderes. Da es – wie du richtig schreibst – dafür keine URI-Kodierung gibt, müsste man das anders vereinheitlichen.

    Der einfachste Weg zur einheitlichen Angabe einer ISIL in RDF wäre die Nutzung einer entsprechenden Property. Ich habe mal eine solche angelegt: http://purl.org/lobid/lv#isil Was mir dabei wieder aufgefallen ist: Man kann nur noch mit sehr viel Wohlwollen behaupten, dass ISILs nur an Organisationen (foaf:Organization) vergeben werden. Mittlerweile gibt es ja einige Lizenzpakete (“Pakete elektronischer Ressourcen”) im deutschen Sigelverzeichnis, die ich nur mit viel Phantasie als Organisation klassifizieren würde. (In lobid.org sind genau 725 und seit dem letzten Update sind in der ZDB schon wieder ein paar neue dazugekommen, vgl.: curl -H "Accept: text/plain" --data-urlencode 'query=SELECT DISTINCT (COUNT(?s) as ?lizenzpakete) where { ?s }' http://lobid.org/sparql/)

    @CH Guter Hinweis auf die “Patterned URIs” mit “Natural Keys”. So machen wir es ja eigentlich alle, indem wir unsere HTTP-URIs nach einem bestimmten Muster auf Basis der ISIL prägen. Allerdings denke ich, dass die Aussage “x hat die ISIL y” dennoch klar im RDF ausgedrückt werden sollte (und nicht mit dc:identifier).

    Kommentar by Adrian — 19. Juni 2013 #

  6. Telefonnummern als URIs schön und gut. Aber es es geht wieder Information verloren (Auskunft, Fax etc.).

    Die Identifier-Lösung mit (ISIL) davor finde ich auch schrecklich. Ich fürchte das ist so ein Katalogisierungsdinosaurier. Ich frag mich ob beim ISIL nicht eher ein Datentyp als eine Property geeignet wäre…

    Kommentar by collidoscope — 29. Juni 2013 #

  7. Ein grundsätzliches Problem mit HTTP-URIs ist, dass praktisch jeder seine eigene Basis-URL verwendet

    Caching – Werden die RDF-Datensätze produktiv in den eigenen Systemen verwendet, dann dürfen die eigenen Funktionen nicht von der Erreichbarkeit der fremden Webseite abhängig sein.

    Datenintegration – Anreicherung der Fremddaten mit eigenen Informationen.

    Normalisierung – Überführen der Fremddaten in domain-weite kanonische Form.

    Filterung – Reduktion der Fremddaten auf die benötigten Informationen, ggf. Filterung problematischer Inhalte.

    das geht mit Nicht-HTTP-URIs weniger, weil diese nicht zum automatischen Resolving gedacht sind.

    Doch doch, mit Ausnahme von URNs sind sie das und das ist gerade der Witz an der tel:-URI. Resolving (Auswahl eines adäquaten Zugriffsmechanismus) und Dereferenzierung (Zugriff auf die Ressource) einer tel:-URI kann in der Anwahl der kodierten Telefonnummer resultieren.

    Kommentar by David Maus — 29. Juli 2013 #

Entschuldige, das Kommentarformular ist zurzeit geschlossen.

Powered by WordPress with Theme based on Pool theme and Silk Icons.
Entries and comments feeds. Valid XHTML and CSS. ^Top^