Closed GKStGovData closed 2 years ago
Ergänzend noch die Darstellung der Klasse dcat:DataService in PlantUML-Notation:
class "dcat:DataService" <
<<mandatory>> dcat:endpointURL ~> rdfs:Resource [1..*]
<<mandatory>> dct:title ~> rdfs:Literal [1..*]
<<recommended>> dcat:endpointDescription ~> rdfs:Resource [*]
<<optional>> dct:description ~> rdfs:Literal [*]
<<optional>> dct:license ~> dct:LicenseDocument [*]
<<optional>> dct:accessRights ~> dct:RightsStatement [*]
}
"dcat:DataService" --> "" "dcat:Dataset" : <
Bei der Diskussion um DCAT-AP wurde bereits im November 2019 auf den Spielraum aufmerksam gemacht: https://github.com/SEMICeu/DCAT-AP/issues/100 Leider gab es bislang auf der Ebene von DCAT-AP keine hinreichende Konkretisierung, wie folgendes Issue zeigt: https://github.com/SEMICeu/DCAT-AP/issues/144
Siehe auch: https://github.com/w3c/dxwg/issues/1126
Mit dem Release von DCAT-AP.de 2.0 umgesetzt.
DCAT2 und DCAT-AP 2.0 führen die Klasse dcat:DataService ein: https://www.w3.org/TR/vocab-dcat-2/#Class:Data_Service
Neue Klasse dcat:DataService
Neue Eigenschaft für dcat:Catalog
Neue Eigenschaft für dcat:Distribution
DCAT2 und DCAT-AP 2.0 lassen viel Spielraum, wie ein DataService mit dcat:Catalog, dcat:Dataset und dcat:Distribution in Verbindung stehen.
Für das Konventionenhandbuch sollte festgelegt werden, wie diese Angaben erwartetet werden, damit sie vom GovData-Datenportal (sowie auch weiteren Portalen) korrekt dargestellt werden können.
Eine Idee wäre, den dcat:DataService als Option anzusehen, wie die Daten einer Distribution abgerufen werden können. Die Kette wäre demnach:
Weitere Konventionen wären: