Versionen im Vergleich

Alte Version 25

changes.mady.by.user Pohl, Adrian

Gespeichert am

verglichen mit

Neue Version Aktuell

changes.mady.by.user Pohl, Adrian

Gespeichert am

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.
Kommentar: Migrated to Confluence 5.3

...

  • 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. (To Do: Für hbz-Identifier exemplarisch in lobid vocab machen.)

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:

      Codeblock
      @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 .

...