Jakoblog — Das Weblog von Jakob Voß

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

$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" .
  ] .

7 Comments »

RSS feed for comments on this post. TrackBack URI

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

   Comment 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/

   Comment 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.

   Comment 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.

   Comment 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).

   Comment 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…

   Comment 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.

   Comment by David Maus — 29. Juli 2013 #

Sorry, the comment form is closed at this time.