Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
volkerjaenisch opened this issue Nov 17, 2022 · 7 comments

Comments

@volkerjaenisch
Copy link

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

@volkerjaenisch
Copy link
Author

I tracked part of the problem down.

With some help of the pySHACL community. RDFLib/pySHACL#168 (comment)

:Dataset_dcat_theme_v_List
    sh:description "Todo: Wenn zutreffend, so umbauen, dass lediglich wenigstens einmal das Vokabular genutzt wurde. Dann wird auch :Dataset_dcat_theme_v_IRI zusätzlich benötigt." ;
    sh:path dcat:theme ;
    sh:node [
        sh:path skos:inScheme ;
        sh:hasValue <http://publications.europa.eu/resource/authority/data-theme> ;
    ] ;
    sh:severity sh:Violation ;
    sh:message "dcat:Dataset: dcat:theme MUSS eine IRI aus diesem Vokabular verwenden: https://www.dcat-ap.de/def/dcatde/2.0/spec/#kv-data-theme"@de ;
.

Problem is the node shape

    sh:node [
        sh:path skos:inScheme ;
        sh:hasValue <http://publications.europa.eu/resource/authority/data-theme> ;
    ] ;

According to W3C https://www.w3.org/TR/shacl/#NodeConstraintComponent

sh:node | The node shape that all value nodes need to conform to. The values of sh:node in a shape must be well-formed node shapes.
And for node-shapes it is stated that:

SHACL instances of sh:NodeShape cannot have a value for the property sh:path.

So
sh:path skos:inScheme ;
in a sh:node is a violation of the SHACL syntax.

Cheers
Volker

@init-dcat-ap-de
Copy link
Collaborator

Hello,

thank you for this analysis! I've come to a similar conclusion, even though I hadn't found the reason for the problem:
grafik

There might be a second problem with or (...) shapes, but I have to look into this.

Unfortunately I can't give a timeframe until when the shapes are fixed, but it has a high priority.

Cheers
Ludger

@volkerjaenisch
Copy link
Author

@init-dcat-ap-de
Thanks for digging into this.
I would like to support you. If you update the repository frequently I will check for further problems.
Cheers,
Volker

@init-dcat-ap-de
Copy link
Collaborator

I pushed updates to improve the conformity. Unfortunately I couldn't find a solution for the sh:or problem. I created an issue here: w3c/data-shapes#147

@volkerjaenisch
Copy link
Author

Any news on the original problem of this issue?

@init-dcat-ap-de
Copy link
Collaborator

Should be fixed.

@volkerjaenisch
Copy link
Author

Then I advice to open a new issue for the "OR problem". When you then there elaborate a bit on the OR problem I am probably able to support you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants