Page tree
Skip to end of metadata
Go to start of metadata

Das dcat-Vokabular

Da wir bei der ersten experimentellen Modellierung der Beschreibungen freier bibliographischer Rohdatensammlungen stark auf das in der Entwicklung befindliche dcat-Vokabular zurückgreifen, sei dieses hier etwas erläutert.

Hintergrund

dcat ist ein RDF vocabulary for interoperability of data catalogues (vgl. diese Folien von Richard Cyganiak. In erster Linie wird mit dcat ein Standardvokabular in RDF für Kataloge zur Verzeichnung von Open Government Data entwickelt. Diese Kataloge gibt es von Nationalstaaten (z.B. UK und USA), von Bundesstaaten (z.B. Maine), von Kommunen und Städten (z.B. London oder San Francisco). Das Problem ist, dass sie in verschiedenen Formaten und mit verschiedenen Metadaten daherkommen, die eine Interoperabiblität erschweren, zumal die Katalogisierung häufig inkonsistent und die benutzen Metadatenelemente nicht dokumentiert sind.

Mit dcat wird nun ein Standardvokabular in RDF-Schema für Open-Data-Kataloge entwickelt, um deren Interoperabilität zu ermöglichen. Die Entwicklung des dcat-Vokabulars wurde 2010 von Richard Cyganiak angestoßen, der eine erste Fassung auf den Seiten des Digital Enterprise Research Institute (DERI) veröffentlichte.

Mittlerweile wird dcat vom Data Catalog Vocabulary project am W3C weiterentwickelt. Der Prozess ist noch nicht abgeschlossen, die Arbeitsgruppe hat noch keine Version des dcat veröffentlicht. Unsere Überlegungen und Probleme mit dem Vokabular sollen als Feedback an diese Gruppe gehen.

Terminologie

Die grundlegenden Begriffe des dcat Vokabulars sind dataset, catalog record und catalog:

A dataset is a collection of information in a machine-readable format. It is published by an agency, usually some sort of official government organisation, and thought to be useful to the public.

A catalog record consists of metadata for a dataset. It thus describes the dataset. The actual dataset is not considered part of the catalog record, but the catalog record usually contains a download link or web page link from where the actual dataset can be obtained.

A catalog is a collection of catalog records. It is operated by a catalog operator, which could be a government agency, citizen initiative, ...

Erwähnenswert ist auch noch das Konzept einer "Distribution", wodurch berücksichtigt wird, dass dieselben Daten in verschiedenen Formaten vorliegen oder über verschiedene Rechercheschnittstellen abgefragt werden können.

[Distribution] Represents a specific available form of a dataset. Each dataset might be available in different forms, these forms might represent different formats of the dataset, different endpoints,... Examples of Distribution include a downloadable CSV file, an XLS file representing the dataset, an RSS feed...

Experimentelle Beschreibungen

Beschreibung des COBiD (Catalogue of Open Bibliographic Data)

Diese Beschreibung bezieht sich auf den Katalog freier Daten (COBiD) selbst, der wiederum einzelne Datensätze vereinigt, die Datenpakete beschreiben.

@prefix dcat:    <http://vocab.deri.ie/dcat#> .
@prefix dcterms:      <http://purl.org/dc/terms/> .
@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix foaf:	 <http://xmlns.com/foaf/0.1/>

<http://lobid.org/cobid>
    rdf:type dcat:Catalogue ;
    dcterms:title 	"Catalog of Open Bibliographic Data"@en ;
    dcterms:description "COBiD stands for 'Catalog of Open Bibliographic Data'. It's a registry of bibliographic datasets which are published under a license compatible with the Open Definition (see http://opendefinition.org)."@en ;
    dc:created 		"2010-04-28T14:30:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
    dcterms:publisher 	<http://lobid.org/organisation/DE-38> ;
    foaf:homepage 	<http://lobid.org/cobid>
    dcterms:spatial 	"international" ;
    dcterms:license  	<http://creativecommons.org/publicdomain/zero/1.0/> ;
    dcat:record  	<http://lobid.org/cobid/hbz_DE-38.ttl> ,
 		 	<http://lobid.org/cobid/DE-Kn41.ttl> ,
		 	<http://lobid.org/cobid/DE-38.ttl> .
    dcat:dataset  .

Der COBiD-Eintrag für die Beschreibung der hbz-Daten der USB-Köln

Dies ist ein beispielhafter Datensatz im COBiD-Katalog, der den USB-Export aus dem hbz-Verbundkatalog beschreiben soll. dcat unterscheidet dcat:dataset und dcat:distribution.

  • dcat:dataset beschreibt eine Datenbank als Abstraktum, unabhängig von der konkreten Erscheinung in bestimmten Formaten oder zu bestimmten Zeitpunkten.
  • dcat:distribution kann somit zur Beschreibung von Datenexporten in verschiedenen Formaten und zu verschiedenen Zeiten benutzt werden. Problem hier: dcat:issued und dcat:modified werden dem dataset zugewiesen.
@prefix dcat:    <http://vocab.deri.ie/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf:    <http://xmlns.com/foaf/0.1/> .

<http://lobid.org/cobid/hbz_DE-38.ttl>
    rdf:type dcat:CatalogRecord ;
    foaf:primaryTopic 	<http://lobid.org/collection/20100312-hbz_DE-38> ;
    dcterms:issued 	"2010-04-29"^^<http://www.w3.org/2001/XMLSchema#date> ;
    dcterms:modified 	"2010-06-14"^^<http://www.w3.org/2001/XMLSchema#date> .

<http://lobid.org/collection/20100312-hbz_DE-38>
    rdf:type 		dcat:Dataset ;
    dcterms:publisher 	<http://lobid.org/organisation/DE-605> ;
    dcterms:description	"Records with holdings from the USB extracted from the hbz union catalog. These aren't identical with the data stemming directly from the USB's catalog, see http://ckan.net/package/usbkoeln-library-data."@en
    rdfs:comment 	"In dieser Exportversion sind keine Normdaten-Nummern enthalten, diese sind beim Export aufgelöst worden. Zukünftige Exporte werden diese Nummern enthalten."@de ;
    dcterms:license	<http://creativecommons.org/publicdomain/zero/1.0/> ;
    dcterms:title 	"Titeldaten des Bestandes der USB aus dem hbz-Verbundkatalog"@de ;
    dcat:distribution 	<http://opendata.hbz-nrw.de/export/20100312-DE-38.tar.gz> ;
    dcterms:references 	"PND" ;
    dcterms:references 	"SWD" ;
    dcterms:issued 	"2010-03-15"^^<http://www.w3.org/2001/XMLSchema#date> ;
    dcterms:modified 	"2010-03-12"^^<http://www.w3.org/2001/XMLSchema#date> ;
    dcterms:identifier	"http://lobid.org/collection/20100312-hbz_DE-38" ;
    dcat:dataDictionary	<http://opendata.hbz-nrw.de/projects/data-publishing/wiki/Format-Dokumentation-de> ;
    dcat:keyword	"Raw Library Catalog Data" .


<http://opendata.hbz-nrw.de/export/20100312-DE-38.tar.gz>
    rdf:type 		dcat:Distribution ;
    dcat:downloadURL 	<http://opendata.hbz-nrw.de/export/20100312-DE-38.tar.gz> ;
    dcterms:format 	<http://www.iana.org/assignments/media-types/application/tg> ;
    dcat:size 		"758MB" .

Der COBiD-Eintrag für die Beschreibung des lokalen Exports der ZB Sport

siehe http://opendata.zbsport.de/

@prefix dcat:    <http://vocab.deri.ie/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf:    <http://xmlns.com/foaf/0.1/> .

<http://lobid.org/cobid/DE-Kn41.ttl>
    rdf:type dcat:CatalogRecord ;
    foaf:primaryTopic 	<http://lobid.org/collection/DE-Kn41> ;
    dcterms:issued 	"2010-06-14"^^<http://www.w3.org/2001/XMLSchema#date> ;
    dcterms:modified 	"2010-06-14"^^<http://www.w3.org/2001/XMLSchema#date> .

<http://lobid.org/collection/DE-Kn41>
    rdf:type 		dcat:Dataset ;
    dcterms:publisher 	<http://lobid.org/organisation/DE-Kn41> ;
    dcterms:description	"Catalog export of the Central Library of Sports Science of the German Sports University Cologne."@en ;
    rdfs:comment 	"Die Daten werden in zwei Formaten zur Verfügung gestellt und wöchentlich aktualisiert."@de ;
    dcterms:license	<http://creativecommons.org/publicdomain/zero/1.0/> ;
    dcterms:title 	"Raw bibliographic data of the Central Library of Sports Science of the German Sports University Cologne"@de ;
    dcat:distribution 	<http://www.zbsport.de/docs/zbsport-aleph.gz> ;
    dcat:distribution 	<http://www.zbsport.de/docs/zbsport.xml.gz> ;
    dcterms:references 	"PND" ;
    dcterms:references 	"SWD" ;
    dcterms:issued 	"2010-04-12"^^<http://www.w3.org/2001/XMLSchema#date> ;
    dcterms:modified 	"2010-06-14"^^<http://www.w3.org/2001/XMLSchema#date> ;
    dcterms:accrualPeriodicity  "weekly"@en ;
    dcterms:identifier	"http://lobid.org/collection/DE-Kn41" ;
    dcat:keyword	"Raw Library Catalog Data" .


<http://www.zbsport.de/docs/zbsport-aleph.gz>
    rdf:type 		dcat:Distribution ;
    dcat:downloadURL 	<http://opendata.hbz-nrw.de/export/20100312-DE-38.tar.gz> ;
    dcterms:format 	<http://www.iana.org/assignments/media-types/application/tgz> ;
    dcat:size 		"66MB" .

<http://www.zbsport.de/docs/zbsport.xml.gz>
    rdf:type 		dcat:Distribution ;
    dcat:downloadURL 	http://www.zbsport.de/docs/zbsport.xml.gz> ;
    dcterms:format 	<http://www.iana.org/assignments/media-types/application/tgz> ;
    dcat:size 		"16MB" .

Lessons Learned & Fragen

Siehe hierzu auch die Beschreibung der Rohdaten im hbz-Opendata-Wiki.

Allgemein

  • Sollten die Records als konkrete RDF-Serialisierung identifiziert werden wie im obigen Beispiel? Oder sollte es eine abstrakte Record-URI geben, die per Content-Negotiation die jeweils gewünschte Serialisierung ausliefert?
  • Wir brauchen URIs für Bibliotheken und Verbundzentralen. --> Siehe hierzu und zum nächsten Punkt das Projekt RDF-basierter Index bibliothekarischer Organisationen.
  • URIs für Kataloge/Datenbanken, Thesauri und Klassifikationen wären auch sinnvoll: hbz01, hbz02, ..., PND, SWD, GKD, GND,...
  • URIs für Sammlungen: Es wäre sinnvoll, die Datensammlungen mit den Mediensammlungen, die durch jene beschrieben werden, in Beziehung zu setzen. Bisher gibt es keine URIs für Sammlungen, sondern - mit dem ISIL-Verzeichnis in RDF - nur für übergeordnete Institutionen. Z.B. gibt es einen URI für die USB Köln, die deutlich über 30 Sammlungen innerhalb der USB haben aber keine URI.
  • URI-Schema für Datensammlungsbeschreibungen: Eine Möglichkeit wäre es, URIs der Form http://lobid.org/collection/{} zu verwenden und mit diesem Schema nicht nur Sammlungen elektronischer Daten zu identifizieren, sondern auch Sammlungen phyischer Medien, wie etwa die "Sammlung Gertrud von Le Fort" (s.o.).

dcat-spezifisch

  • Es wäre sinnvoll, auch einen Link auf den jeweiligen OPAC anzugeben, um eine Verknüpfung von Export und traditioneller Nutzerschnittstelle herzustellen. Beides - sowohl der OPAC wie auch ein Export - sind ohne Frage Exemplifikationen der Datensammlung. Das Problem ist, dass sie unter unterschiedlichen Lizenzen publiziert sein können. Da aber die Lizenzinformation einem dcat:Dataset zugewiesen wird, erlaubt dcat es momentan nicht, zwei unterschiedlich lizenzierte Distributionen an ein Dataset zu hängen.
  • Wir brauchen ein Prädikat für die Prüfsumme einer Archivdatei.
  • Ein Prädikat für die Anzahl der Datensätze in einem dcat:dataset ist auch sinnvoll.
  • Die Unterscheidung "Format der Archivdatei" vs. "Format der darin enthaltenen Daten" kann mit dcat nicht abgebildet werden, ist aber sinnvoll. Evtl. könnte man auch überlegen, bei dcterms:format in bezug auf Distributionen das Format der gezippten Daten anzugeben. Eine andere Lösung wäre dcterms:format auch auf dcat:Dataset anzuwenden.
  • Zur Problematik, neben der Klasse "dcat:Distribution" noch die Klasse "dcat:Download" zu definieren (wir haben die zweite hier nicht verwendet) siehe Ed Summers' Kommentar und Verbesserungsvorschlag unter http://www.w3.org/egov/IG/track/issues/38. Wir unterstützen diesen Vorschlag.
  • Auch bezweifelt Ed Summers, dass die Klasse "dcat:Distribution" und ihre Subklassen überhaupt notwendig sind: http://www.w3.org/egov/IG/track/issues/39. Wir sind uns in diesem Punkt auch nicht so sicher.
  • dcat verwendet das DC-Terms-Prädikat "dcterms:accrualPeriodicity" (http://purl.org/dc/terms/accrualPeriodicity). Dies hat als vorgegebene Range dcterms:Frequency, was wiederum eine Klasse ist. Allerdings sind nirgendwo deren Instanzen spezifiziert. Wir verwenden deshalb vorerst als Objekt von dcterms:accrualPeriodicity einen Literal.
  • Allgemeine Idee: Warum nicht dcat:Dataset als abstrakte Ressource? Das hieße, die Angaben zu "Release Date" und "Modification date" an die dcat:Distribution zu hängen. Gerade in unserem Fall unterscheidet sich etwa das Veröffentlichungsdatum des OPACs von dem des Exports.
  • No labels