Fragen

  • Welche Möglichkeiten zur Verlinkung gleicher und ähnlicher Ressourcen bzw. deren Beschreibungen gibt es?
  • Konkrete Fragen:
    1. Wie verlinke ich eine Ressource mit dem entsprechenden Eintrag in WorldCat?
    2. Wie gebe ich die LCCN oder OCLC-Nummer an, die den Eintrag der jeweiligen Ressourcenbeschreibung bei der LoC bzw. im WorldCat identifiziert?

Vorschlag mit Begründung

Vorschlag

  • Verlinkung zu WorldCat oder ähnlichen/ als gleich vermuteten Ressourcen in anderen Linked-Data-fähigen Diensten mit: umbel:isLike
  • Angabe von bekannten Identifiern wie der OCLC-Nummer oder der LCCN unter Nutzung der Bibliographic Ontology
    • OCLC-Nummer: bibo:oclcnum
    • LCCN: bibo:lccn
  • Für lokale und regionale Identifier gelte: Jeder der IDs prägt, sollte auch eine passende Property bereitstellen.

Begründung

Wir schlagen hiermit eine pragmatische Lösung vor, die durch folgende Eigenschaften charakterisiert ist:

  1. Die Unterscheidung zwischen Identifikatoren von Titeldatensätzen und Identifikatoren von bibliographischen Entitäten sollte in den Empfehlungen ignoriert werden.Dafür gibt es drei Gründe:
    1. Der gängigen Praxis wird Rechnung getragen, dass Titelsatz-IDs auch "metaphorisch" als IDs der beschriebenen bibliographischen Ressoure verwendet werden.
    2. Wir gehen davon aus, dass dieser Gebrauch sich durchgesetzt hat und nicht mehr verhindert werden kann.
    3. Bereits existierende Properties (bibo:oclcnum und bibo:lccn)können somit genutzt werden.
  2. Statt owl:sameAs sollte für den Verweis auf äquivalente/gleiche Ressourcen die Property umbel:isLike empfohlen werden. Die Nutzung von owl:sameAs sollte nicht empfohlen werden, um falsche Identitätsaussagen und inkorrekte Inferenzen zu vermeiden.
  3. Es sollte empfohlen werden, dass für lokale, regionale und fachspezifische Identifier diejenige Institution eine entsprechende Property bereitstellt, die auch die Identifier kreiert.Gründe:
    1. Die Verknüpfung von bibliographischen Ressourcen mit lokalen/regionalen/fachspezifischen durch spezielle Properties scheint uns der eleganteste und sinnvollste Ansatz zu sein, weil er schlank ist, keine Blank Nodes benötigt und einfache SPARQL-Abfragen ermöglicht.
    2. Eine dezentrale Prägung der Properties scheint uns sinnvoll zu sein, weil zum einen die Pflege an die Institution abgegeben wird, die auch die jeweiligen Identifier kreiert und zum anderen davon auszugehen ist, dass so alle Nutzer des jeweiligen Identifiers von der Existenz der jeweiligen Property erfahren.

      Beispiel hbz-Verbund-ID:

      @prefix lv:   <http://lobid.org/vocab/lobid#> .
      @prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
      @prefix dct:  <http://purl.org/dc/terms/> .
      @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
      
      lv:hbzID
         rdf:type rdf:Property ;
         rdfs:label "hbz-ID" ;
         rdfs:comment "HT-Nummer. Der Identifier, der einer bibliographischen Ressource im hbz-Verbundkatalog zugewiesen wurde."@de ;
         rdfs:comment "The identifier that is assigned to a bibliographic resource in the hbz union catalogue."@en ;
         rdfs:subPropertyOf dct:identifier ;
         rdfs:domain dct:BibliographicResource ;
         rdfs:range rdfs:Literal .
      

Hintergrund

Grundannahmen

Ansätze und Materialien

Möglichkeiten zur Angabe von Identifikatoren bzw. zur Verlinkung

Angabe eines Identifiers

Eine scheinbar einfache Lösung ist es, den Identifier der jeweiligen <Ressource> unter Nutzung einer Property wie dcterms:identifier anzugeben. Dies ist im strengen Sinn nicht korrekt für alle Identifier, die für bibliographische Ressourcen selbst stehen. Andere Identifier identifizieren allerdings eher eine Beschreibung der Ressource, z.B. einen Katalogdatensatz in einer bestimmten Datenbank:

(Warnung) Die Verwendung der vorläufigen Property library:oclcnum in worldcat.org spricht dafür, dass OCLC selbst die OCLC-Nummer (auch) als Identifikator für die <Ressource> und nicht allein für die <Beschreibung> ansieht. Vielleicht haben wir es mit einer stattfindenden "metaphorischen Verschiebung" zu tun, in deren Verlauf identifikatoren, die im Kontext von Datenbanken für Datensätze standen, in einem weiteren Kontext nun auf die beschriebenen Dinge selbst angewendet werden.

Das Problem lässt sich also u.U. vernachlässigen oder man kann es auch unter Verwendung von Blank Nodes lösen:

@prefix dcterms:   <http://purl.org/dc/terms/> .
@prefix bibo:  <http://purl.org/ontology/bibo/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/>.

<Ressource>
  a dcterms:BibliographicResource ;
  bibo:isbn "0915145529"
  foaf:isPrimaryTopicOf [
  dcterms:identifier "BV001240011" ;
  dcterms:identifier "HT002948556" ;
  bibo:oclcnum "991052625"
  ] .

Das ist allerdings keine besonders zufriedenstellende Lösung des Problems.

Verlinkung zu WorldCat-Ressourcen

Eine Möglichkeit, die im vorherigen Abschnitt beschriebene Problematik zu umgehen, wäre auf die Nutzung von OCLC-Nummern zu verzichten. worldcat.org stellt für jede bibliographische Ressource einen HTTP-URI zur Verfügung, der auf Basis der OCLC-Nummer gebildet wird. Zum Beispiel steht http://www.worldcat.org/oclc/8762580 für jene Ressource, deren Datensatz die OCLC-Nummer "8762580" hat.

Welche Properties kommen für eine Verlinkung einer lokalen Ressource mit einer Ressource in worldcat.org in Frage? owl:sameAs schließen wird aufgrund der unklaren Datenlage ausgeschlossen. Zum einen ist ein exaktes automatisches Matching nicht möglich und zum anderen basieren verschiedene Kataloge auf verschiedenen Katalogisierungs- und damit Identifikationspraktiken (siehe)

umbel:isLike

Domain: owl:Thing
Range: owl:Thing

Beschreibung:

The property umbel:isLike is used to assert an associative link between similar individuals who may or may not be identical, but are believed to be so. This property is not intended as a general expression of similarity, but rather the likely but uncertain same identity of the two resources being related.

This property can and should be changed if the certainty of the sameness of identity is subsequently determined.

In general, we may not be able to assert that two individuals are the same based solely on current information on hand. However, there may be quite reasonable bases or methods that the two individuals are likely the same without being one hundred percent sure.

umbel:isLike has the semantics of likely identity, but where there is some uncertainty that the two resources indeed refer to the exact same individual with the same identity. Such uncertainty can arise when, for example, common names may be used for different individuals (e.g., John Smith).

It is appropriate to use this property when there is strong belief the two resources refer to the same individual with the same identity, but that association can not be asserted at the present time with certitude.

Die Beschreibung der Property passt nicht unbedingt auf unseren Anwendungsfall, könnte aber in speziellen Fällen passen.

ex:worldcat

Eine möglicherweise sinnvolle Variante wäre das Prägen einer Property, die einen Link zu einer äquivalenten WorldCat-Ressource herstellt.

@prefix dcterms:   <http://purl.org/dc/terms/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:worldcat
    a owl:ObjectProperty ;
    rdfs:label "Equivalent WorldCat Resource"@en ;
    rdfs:comment "Relates a bibliographic ressource to an equivalent resource described in worldcat.org."@en ;
    rdfs:domain dcterms:BibliographicResource ;
    rdfs:range dcterms:BibliographicResource .

Sonstiges

  • culturegraph: cg:eki --> Entweder CG-Vokabular prägen oder stabile HTTP-URIs auf Basis der EKI schaffen
  • Keine Stichwörter

4 Kommentare

  1. Unbekannter Benutzer (kahla) sagt:

    Hallo Adrian,

    danke für Deine Ausführungen zur Verlinkung - ich bin echt beeindruckt, wie tief Du Dich da eingearbeitet hast. Ich finde den Ansatz von schema.org auch sehr überzeugend: Er arbeitet ausschliesslich mit RDF-Mitteln und verbiegt sie dabei nicht. Ausserdem erlaubt er, die Identifier-Ausgebende-Institution anzugeben und beliebige weitere Metadaten zum Link anzugeben (Matching-Algorithmus, Sicherheits-Score etc.). Schließlich ist schema.org eine gewisse Garantie für Verbreitung, einfach weil da viel Macht dahintersteht ("Wer mich nutzt kommt bei den großen Suchmaschinen besser raus").
    Was mich noch nicht so überzeugt ist die Verwendbarkeit des Ganzen:
    Es gibt für RDF-Implementierer noch nicht das Netscape, dass es für Http/Html-EndUser gab. D.h. der Entwickler muß das RDF zur Zeit selbst durchschauen. Das Parsen nimmt ihm eine Bibliothek ab, aber um die SPARQL-Query dafür zu schreiben, muß er selbst ran und sich die Verknüpfungen ansehen & verstehen. Leider unterscheidet sich dieser Schritt noch nicht wirklich von einer relationalen DB & SQL. Automatisches Schliessen und Verfolgen der Links funktioniert nur bei einfachen Dingen wie owl:sameAs. Und auch größere Anwendungen, die Reasoner wirklich einsetzen kenne ich nicht (d.h. RDF ist zwar für Maschinen; ein falscher owl:sameAs-Link würde in der heutigen Praxis jedoch viel wahrscheinlicher einen Menschen irreführen als eine Maschine).
    Vor diesem Hintergrund halte ich nur den Kritikpunkt, dass Links schlicht falsch sein könnten, für gravierend. Ob die Ressource andernorts nach völlig anderen, mglw. widersprüchlichen Regeln beschrieben ist, muß der Entwickler selbst beurteilen, und ggf. sameAs-Links, die ihm nicht helfen, ignorieren.
    Ausserdem gibt es nicht für jeden Link RDF-Beschreibungen; Wir verzeichnen auch einfache Weblinks. Dafür bräuchten wir auch ein Prädikat wie wdrs:describedBy bzw. das zuletzt kritisierte foaf:homepage. Wenn wir uns hier ausschliesslich auf RDF-Links konzentrieren wollen; können wir diesen Punkt weglassen.
    Fazit: Ich bin nicht gegen die schema.org-Lösung, aber vielleicht ist sie zu kompliziert und nimmt zuviel Zukunftsmusik vorweg. Vielleicht müssen wir erstmal mit einfachen Mitteln arbeiten und uns zu gegebener Zeit wieder anpassen. (z.B. wenn viele Reasoner wg. owl:sameAs auf die Nase fallen, dann stellen wir auf was besseres um wenn es wirklich gebraucht wird - und sind uns dann auch sicherer was genau gebraucht wird)

    Viele Grüße

    Andreas

  2. Pohl, Adrian sagt:

    Hallo Andreas,

    heißt das, dass du dich für eine Nutzung von owl:sameAs aussprichst, selbst wenn die Links nicht der engen Bedeutung von owl:sameAs entsprechen und bei einem Reasoning Probleme machen könnten?

    Adrian

  3. Unbekannter Benutzer (kahla) sagt:

    Hallo Adrian,

    das heisst, dass mich frage ob übergangsweise eine nicht perfekte Verwendung von owl:sameAs die Einstiegshürde zur Verwendung der Daten durch Dritte senken würde.

    Wenn Du meinst, dass das zu gravierende Nachteile hat, oder aus anderen Gründen nicht so gut ist, schliesse ich mich Deinem Vorschlag an, die schema.org-Lösung zu verwenden.

    Soweit mir bekannt ist, befinden wir uns gerade noch in der etwas verbesserungsfähigen Situation, kein nennenswertes Feedback v. Anwendern zu haben - das wäre in dieser Frage eigentlich entscheidend. Deshalb können wir uns natürlich auch von technischen Idealen leiten lassen - und da halte ich wie gesagt den schema.org-Ansatz für den besten, den ich gesehen habe.

    Beste Grüße

    Andreas

    1. Pohl, Adrian sagt:

      Ich halte den schema.org-Ansatz auch nicht für eine gute Lösung, aus zwei Gründen:

      1. Er ist nicht simpel genug.
      2. Es handelt sich um einen Entwurf, der erst in einigen Monaten nutzbar sein wird, wenn er überhaupt vorgeschlagen und angenommen wird. Da ist einfach noch zu viel im Fluss...

      owl:sameAs mag vielleicht für sowas wie Links zu WorldCat eine Lösung sein und somit Frage 1. beantworten. Frage 2,, d.h. wie ich die entsprechende OCLC-Nummer oder die LCCN als String angebe, ist damit allerdings noch nicht beantwortet. (traurig)

      Ich finde das Thema schwierig. Eine ideale Lösung für mich wäre, wenn jede Institution, die Identifier für bibliographische Ressourcen(beschreibungen) kreiert, eine entsprechende rdfs:Property prägt, mit der sich der entsprechende Identifier einer bibliographischen Ressource angeben lässt.