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

Proposal to use IRI nodes for properties in SHACL shapes instead of blank nodes #48

Open
EmidioStani opened this issue Oct 24, 2018 · 7 comments
Labels
release:3.0.0 https://semiceu.github.io/DCAT-AP/releases/3.0.0 status:fixed This issue has been fixed in a draft.

Comments

@EmidioStani
Copy link
Member

With the purpose to reuse the SHACL shapes, it would nice the properties restrictions are written as IRI instead of blank nodes, so then reusers might disable certain shapes in case they don't fit in their application profile.

E.g.
dcat:Distribution
rdf:type sh:NodeShape ;
sh:property dcat:accessURLShape ;

dcat:accessURLShape
rdf:type sh:PropertyShape ;
sh:path dcat:accessURL ;
sh:class rdfs:Resource ;
sh:minCount 1 ;
sh:severity sh:Violation .

such shape requires that the access url should be explicitly indicated a rdfs:Resource whereas most of the time just a URL would be enough.

Using it as IRI could deactivate the shape for their need:

dcat:accessURLShape
sh:deactivated true .

@addragan
Copy link
Contributor

addragan commented Nov 8, 2018

Thank you for the suggestion. Proposal to discuss this in the next major release cycle.

@addragan
Copy link
Contributor

Proposed resolution: Replace properties restriction written as blank nodes with IRI.

@bertvannuffelen bertvannuffelen added the future-work this topic will be dealt in the future label Nov 15, 2019
@bertvannuffelen
Copy link
Contributor

resolution: will be for the future to see what is the best organisation of the SHACL file. To be considered in the chosen approach is the creation of local variants reusing part of the SHACL templates. Currently reuse at the level of class is possible. And the usage of controlled vocabularies is in a separated file.

@init-dcat-ap-de
Copy link

I created a pull request which does the requested change for the shacl_shapes.ttl file:
#224 (comment)

@init-dcat-ap-de
Copy link

Current validation message:
grafik

Validation message with named property shape:
grafik
This message already helps more, because the user can identify shape that is throwing the error. The shape name includes the type of class that was the target for the shape.

In this example I added

:Agent_Property_foaf_name
    sh:message "Ein foaf:Agent MUSS über einen foaf:name verfügen!" @de .

in an additional file:
grafik

@init-dcat-ap-de
Copy link

An additional wish we have would be to split the shapes further into atomar tests, so

:Agent_Property_foaf_name
    sh:minCount 1 ;
    sh:nodeKind sh:Literal ;
    sh:path foaf:name ;
    sh:severity sh:Violation .

becomes:

:Agent_Property_exists_foaf_name
    sh:minCount 1 ;
    sh:path foaf:name ;
    sh:severity sh:Violation .

:Agent_Property_literal_foaf_name
    sh:nodeKind sh:Literal ;
    sh:path foaf:name ;
    sh:severity sh:Violation .

This would allow us to give more specific error messages an reuse the shapes even moren.

@bertvannuffelen bertvannuffelen added release:3.0.0 https://semiceu.github.io/DCAT-AP/releases/3.0.0 status:fixed This issue has been fixed in a draft. and removed future-work this topic will be dealt in the future component:shacl labels Feb 5, 2024
@bertvannuffelen
Copy link
Contributor

Add a reference to a complete list of generated shacl rules: https://semiceu.github.io/uri.semic.eu-generated/DCAT-AP/releases/3.0.0/#validation-of-dcat-ap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release:3.0.0 https://semiceu.github.io/DCAT-AP/releases/3.0.0 status:fixed This issue has been fixed in a draft.
Projects
No open projects
dcat-ap release 2.0
releaseTagged
Development

No branches or pull requests

5 participants