govdataofficial / dcat-ap.de-shacl-validation

SHACL-Shapes für DCAT-AP.de

DCAT-AP.de SHACL-Validation

⚠️ Hinweis zur aktuellen Entwicklung ⚠️
Die DCAT-AP.de SHACL-Validation wurde mit Blick auf die DCAT-AP.de 2.0 Spezifikation neu erstellt. Wenn Sie Fehler entdecken, dann freuen wir uns über Ihr Feedback!

DCAT-AP.de 2.0 - Spezifikation

Die SEMIC stellt ihren eigenen DCAT-AP-Validator zur Verfügung, der zuverlässig funktioniert.

Der deutsche Validator verwendet die verpflichtenden Regeln der SEMIC und reichert sie mit deutschen Fehlernachrichten an. Dazu werden folgende Dateien verwendet:

• https://github.com/init-dcat-ap-de/DCAT-AP/blob/2.1.1-draft/releases/2.1.1/dcat-ap_2.1.1_shacl_shapes.ttl
• https://github.com/GovDataOfficial/DCAT-AP.de-SHACL-Validation/blob/master/validator/resources/v2.0/shapes/dcat-ap-spec-german-messages.ttl

Die folgende Datei fügt zu den DCAT-AP-SHACL-Shapes deutsche Regeln hinzu, so dass DCAT-AP.de 2.0 geprüft wird. Dafür werden zum Teil auch widersprüchliche DCAT-AP-SHACL-Shapes deaktiviert:

• https://github.com/GovDataOfficial/DCAT-AP.de-SHACL-Validation/blob/master/validator/resources/v2.0/shapes/dcat-ap-spec-german-additions.ttl

Weitere externe Quellen, wie Ontologien, deren Kontext relevant sind oder kontrollierte Vokabulare, werden durch diese Datei importiert:

• https://github.com/GovDataOfficial/DCAT-AP.de-SHACL-Validation/blob/master/validator/resources/v2.0/shapes/dcat-ap-de-imports.ttl

Prüfungen

• Verwendung aller Pflichteigenschaften
• Min- und Max-Kardinalitäten
• Verwendung (getypter) Literals, wenn zutreffend
• Verwendung von URIs, wenn als Ziel eine Klasse erwartet wird
• Verwendung von URIs, wenn als Ziel eine beliebige Webadresse erwartet wird
• Verwendung der korrekten kontrollierten Vokabulare
• Warnung bei der Verwendung von deprecated-Eigenschaften

Ob das Objekt einer Eigenschaft die von DCAT-AP(.de) vorgegebene Klasse hat, wird geprüft, wenn der Aufbau des Objekts für den Anwendungsfall "Anlieferung an ein Metadatenportal" entscheidend ist. Dies betrifft die DCAT-AP-Kernklassen und Eigenschaften dcat:catalog, dcat:dataset, dcat:service, dcat:record und dcat:distribution sowie die Eigenschaften, die auf z.B. foaf:Agent, dct:PeriodOfTime oder dct:Location verweisen.

Für die Eigenschaften adms:sample, dct:source, dct:hasVersion, dct:isVersionOf, dct:hasPart und dct:isPartOf wird davon ausgegangen, dass deren Objekte nicht im Kern der Validierung stehen. Daher wird lediglich gewarnt, wenn sie nicht die korrekte Klasse haben.

Keine Prüfungen

• Kategorie (da kontrolliertes Vokabular genutzt werden muss)
• Kategorienschema (da kontrolliertes Vokabular genutzt werden muss)
• Lizenzdokument (da kontrolliertes Vokabular genutzt werden muss)

---

DCAT-AP.de 2.0 - Spezifikation & Konventionen

Dieses Profil prüft alles, was DCAT-AP.de SHACL-Validation prüft. Zusätzlich:

Prüfung von Konventionen

• K01: dcat:contactPoint: Kontaktinformationen MÜSSEN mindestens Angaben zur Email (vcard:hasEmail) oder einen Link zum Kontaktformular oder Chatbot (vcard:hasURL) enthalten.
• K12&13: dcat:Dataset: dcatde:contributorID MUSS verwendet werden und DARF nur genau einmal eine IRI aus http://dcat-ap.de/def/contributors/ verwenden.
• K36: dcat:Dataset: dct:publisher MUSS verwendet werden.
• K30: dcat:Dataset: dcat:theme: Zur Steigerung der Metadatenqualität wird die Angabe von Kategorien empfohlen.
• K31: dcat:Distribution: dct:license MUSS eine IRI aus http://dcat-ap.de/def/licenses/ verwenden.
• K32: dcat:Distribution: dct:format MUSS eine IRI aus dem EU Vokabular 'File Type' verwenden.

Prüfung besonders empfohlener Eigenschaften

• dcat:Dataset: dcat:distribution: Es wird empfohlen, dass jedes Dataset über eine Distribution verfügt.
• dcat:Dataset: dcat:keyword: Zur Steigerung der Metadatenqualität wird die Angabe von Schlagworten empfohlen.
• dcat:Dataset: dcat:landingPage: Zur Steigerung der Metadatenqualität wird die Angabe der ursprünglichen Webseite empfohlen.
• dcat:Dataset: dct:issued: Zur Steigerung der Metadatenqualität wird die Angabe des Veröffentlichungsdatums empfohlen.
• dcat:Distribution: dct:title: Es wird empfohlen, dass jede Distribution über einen dct:title verfügt.

Prüfung im Rahmen der Dublettenprüfung

• dcat:Dataset: Ggf. MUSS dct:identifier zur Dublettenprüfung verwendet werden.
• dcat:Dataset: Ggf. MUSS dct:modified zur Dublettenprüfung verwendet werden.

Prüfung auf (ausgewählte) sinnvolle Ranges

Die Auswahl erfolgte mit Blick auf die Verarbeitung im GovData-Frontend.

• dcat:Dataset: IRIorLiteral: dct:conformsTo, dct:accessRights, dct:provenance
• dcat:Dataset: IRI: prov:wasGeneratedBy, dcat:landingPage, foaf:page
• dcat:Catalog: IRIorLiteral: dct:rights
• dcat:Catalog: IRI: foaf:homepage
• dcat:DataService: IRIorLiteral: dct:accessRights
• dcat:Distribution: IRIorLiteral: dct:conformsTo, dct:rights
• dcat:Distribution: IRI: foaf:page, odrl:hasPolicy
• dcat:CatalogRecord: IRIorLiteral: dct:conformsTo

---

GovData MQA/Dashboard

Diese Profile prüfen Eigenschaften, die auch im GovData-Dashboard zur Metadatenqualität angezeigt werden.

---

Weitere Informationen

Feedback gerne als GitHub Issue oder per E-Mail an [email protected].

Bisherige Inhalte wurden in die Datei README_v1X.md verschoben.

© CC BY 4.0 ']init[ AG für GovData'

dcat-ap.de-shacl-validation's Issues

Formulierungen vereinheitlichen

Derzeit gibt es:

• Empfohlen: Es wird empfohlen, mittels ...
• Empfohlen: Sie sollten mittels ...
  Und
• Optional: Mittels dcatde:maintainer können sie ...
• Optional: Sie könnten die zeitliche Granularität mittels ...

In der Ausgabe sollte einheitlich und aktiv formuliert werden:

• Empfohlen: Sie sollten mittels ...
• Optional: Sie können mittels ...

Tippfehler sie/Sie

Optional: Mittels dcatde:legalbasis könnten sie die Rechtsgrundlage für den Zugang zu den Informationen als Freitext angeben.

CHANGELOG wäre hilfreich

Wenn man dieses Repo besucht und sich über die Änderungen informieren will, muss man die einzelnen Commits ansehen. Das ist zeitaufwändig und nicht immer besonders aussagekräftig.

Ein high-level CHANGELOG.md wäre sehr hilfreich. Beispiel: https://github.com/ckan/ckan/blob/master/CHANGELOG.rst

When validating with URI, please trim input!

When validating with URI, e.g. https://offenedaten.frankfurt.de/catalog.rdf?fq=name%3Ahauskoordinaten-franfurt
with a space at the end (that may happen when URI is copy&pasted), the validator breaks and gives an error:

Bei der Validierung ist ein Fehler aufgetreten [Illegal character in query at index 79: 
https://offenedaten.frankfurt.de/catalog.rdf?fq=name%3Ahauskoordinaten-franfurt ].

Please strip off any whitespaces of the input before processing.

German addition dcat-ap-spec-german-additions.ttl is does not comply to SHACL

Dear Govdata!

At first a lots of thanks to GovData and ]init[ to provide us with a set of SHACL rules to make DCAT-things better.

We in BBG are currently including these SHACLE rules to come up with a replacement for our homebrew DCAT validator.

Our OpenData Portal the "Datenadler" utilizes Python. Python is quite common in OpenData since CKAN is also Python based.

There is just one SHACL Library in Python: pySHACL, which all the CKAN people may be using if CKAN will utilize SHACL.

Our code supplied with (All files from this GH repository):

• The OWL import file: dcat-ap-de-imports.ttl
• The shape file of the EU: dcat-ap_2.1.1_shacl_shapes.ttl

validates our DCAT data quite well. The validation points out violations and such in the given DCAT-RDF data. Normal behavior.

But when we include additionally the german shape files dcat-ap-spec-german-additions.ttl and dcat-ap-spec-german-messages.ttl then pySHACL informs us with an exception:

"Shacl File does not validate against the Shacl Shapes Shacl file" with a stacktrace a kilometer long.

This exception arouses since pySHACL checks the SHACL shapes before using them.

In this it was not clear for me where the cause of the problem is:

• Our code
• PySHACL
• the shape files

Having filed already one bugreport to pySHACLE today the first blame was to PySHACL.

But at the end of the day I was not wiser. Desperately I just put the shape files into the European shape validator:

https://www.itb.ec.europa.eu/shacl/shacl/upload

and it produces a comparable number and detail problems with the shape files as pySHACL delivers.

The message file is OK, but dcat-ap-spec-german-additions.ttl produces 21 errors.

Now I think that the German shapes are not in shape.

The only code that I have found concerning DCAT and SHACL is JAVA based.
@]init[ You are using JAVA, I bet? Have you ever tried an other programming language with your shapes? I can try and and run the shapes on our RDF4J DB to get more platforms into play.

Let us work together to supply the BRD with a SHACL validation anyone can use.

Cheers Volker

spdx:algorithm - Meldung "Does not have value spdx:checksumAlgorithm_sha1"

Der Validator mit Profil "DCAT-AP.de 1.1 Spezifikation & DCAT-AP 2.1 Mandatory & Recommended" gibt folgende Fehlermeldung:

"Does not have value spdx:checksumAlgorithm_sha1"

Als Wert für spdx:algorithm ist "https://www.dcat-ap.de/def/hashAlgorithms/md/5" laut DCAT-AP.de- Spezifikation gesetzt.

Das passiert sogar mit den Beispieldateien von https://www.dcat-ap.de/def/dcatde/1.1/examples.zip

Ist das ein Fehler im Validator oder muss der Wert anders gesetzt werden?

Syntax: JSON-LD

Bei Validierung mit Syntax JSON-LD, ist das Validierungsergebnis immer positiv.

Konventions-Validation für mittelbare Metadatenbereitsteller

Als Verantwortlicher für ein kommunales Open Data Portal würde ich gern den Validator zur Überprüfung der veröffentlichten Datensätze und Kataloge nutzen.
Unter Berücksichtigung der Konventionen erhalte ich jedoch stets ein negatives Resultat, da die ContributorID nicht gesetzt ist. Als mittelbarer Metadatenbereitsteller gegenüber GovData (über Landes-Portal) ist meine Kommune aber auch nicht in der Contributor-Liste geführt.

Ist hier die Erwartungshaltung, dass wir als Kommune bereits die ContributorID des Landesportals setzen? Oder könnte ein Validations-Profil eingeführt werden, welches eine nicht gesetzte ContributorID akzeptiert?

Named Property Shape With `sh:path` Only Within `sh:or`

w3c/data-shapes#147

How to invoke validator from application?

We use CKAN with the dcat-ap-de extension.

We'd like to support a dataset editor directly to perform DCAT-AP.de validation.

Therefore we need to invoke the validator using a single button inside CKAN which shows validator output for the dataset being edited in eith a new browser tab or in an embedded iframe.

Is it possible to invoke the validator with a GET request?

Which parameters are required to call the validation process directly?

URIs verlinken

Es wäre hilfreich, URIs in der Ausgabe zu verlinken.
Beispiel: [http://dcat-ap.de/def/dcatde/politicalGeocodingURI]

Fehlermeldung zu locn:geometry

Es gibt eine Fehlermeldung dct:Location: locn:geometry MUSS ein Literal sein. Es DARF maximal einmal vorhanden sein. Die scheint mir falsch zu sein. Im Beispiel des Konventionenhandbuch werden drei Angaben gemacht.

Fill calling parameters in form

When invoking the validator, we have to fill all form fields.

When submitting the form multiple times (e.g. to try multiple validation rules or to revalidate a dataset) why not fill in the parameters in the form fields again?

Can we expect this on the roadmap?

Validierung Teil G - dcat-ap_2.1.0_shacl_shapes_recommended.ttl

Bei der Validierung nach Teil G - dcat-ap_2.1.0_shacl_shapes_recommended.ttl erhalte ich mehrere Warnungen mit folgendem Text:

Property needs to have at least 1 values, but found 0 Ort:[Ergebnispfad] - [http://purl.org/dc/terms/type]

Gibt es eine Möglichkeit nähere Infos zu erhalten was genau von der Warnung betroffen ist?

Unter bekannte Probleme steht folgendes:

es werden bereits Klassen geprüft, die in DCAT-AP.de 1.1 nicht enthalten sind (führt nicht zu Fehlern)

Werden hier also Klassen wie dcat:DataService validiert und wenn diese nicht vorhanden sind kommt es zu der oben genannten Warnung?

Error: "Die RDF-Sprache konnte nicht für den bereitgestellten Inhalt bestimmt werden."

The validator guesses the filetype using the file extension. This works when submitting URLs like

https://opendata-portal/catalog.rdf

But this does not work using urls with parameters:

https://opendata-portal/catalog.rdf?fq=name:dcat-ap-de-example-dataset

The error message displayed is Die RDF-Sprache konnte nicht für den bereitgestellten Inhalt bestimmt werden.

Is this a bug?

json-ld validation: An error occurred during the validation [Error writing RDF model]

Bei der Validierung eines der Kölner Datensätze tritt der beschriebene Fehler auf. Könnten Sie prüfen, ob es an der hochgeladenen Datei oder dem Validator liegt, und den Validator ggf. fixen? siehe json unten) cc: @eGovCologne

vornamen.json.txt

Inline validation Fehler

Die Ausführung von https://www.itb.ec.europa.eu/shacl/dcat-ap.de/uploadm
als POST request bringt den Fehler:

Content-Security-Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).

Der HTML-Code dazu ist:

<form method="POST" enctype="multipart/form-data" 
        action="https://www.itb.ec.europa.eu/shacl/dcat-ap.de/uploadm" 
        target="output">
    <input style="display:none" type="text" name="uri" value="url-to-ckan-dataset">
    <input type="hidden" name="validationType" value="v20_de_spec_implr">
    <button type="submit">Prüfung starten ...</button>
</form>
<iframe name="output" style="width:100%; height:400px;" src='about:blank'></iframe>

Die Lösung dafür wäre, entsprechende Header-Informationen in das Ergebnis einzubauen, z.B.:

<meta http-equiv="Content-Security-Policy" content="...">

Show results only

The validator is a single page application.

To better embed the validator inside an application it would be helpful to only show the results and to hide the form fields.

This could be implemented e.g. by a (hidden) form parameter hide_form.

Can we expect this on the roadmap?