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

Make version SHACL shapes less restrictive #167

Open
holycrab13 opened this issue Feb 8, 2024 · 3 comments
Open

Make version SHACL shapes less restrictive #167

holycrab13 opened this issue Feb 8, 2024 · 3 comments

Comments

@holycrab13
Copy link
Contributor

holycrab13 commented Feb 8, 2024

SHACL shapes are currently very restrictive, rejecting inputs with fields that could be auto-completed.
Currently SHACL validation is executed after auto-completion, so this is currently not a problem by itself.

However, SHACL validation should be the first thing to execute since it can also reliably detect malformed RDF.
Additionally, this could be more user-friendly since users can validate their non-autocompleted inputs against the SHACL resources at /res/shacl.

Task is to make anything auto-completeable optional in the SHACL shapes

@JJ-Author
Copy link
Collaborator

JJ-Author commented Feb 8, 2024

yeah we have to be a bit careful here. i think its best have a shacl library with all the tests and then one master shape with some optional values as you describe applied before autocompletion and one master shape after autocompletion where values are required (to verify that this does not mess up sth).

@JJ-Author
Copy link
Collaborator

another (probably easier) idea by me discussed in todays meeting was the following

  • add special triple to propertyshape e.g. sth like databus:ApiAutocompletionStrategy "explain how it is autocompleted"
  • generate an automatically rewritten version of the shacl test that can be applied prior any processing in javasript by rewriting by overwriting the sh:mincount with value 0 for all that shapes having this autocompletion property

this way we can solve 2 issues for one: we can do easier documentation and can display it easily in the docu for every property how it will be autocompleted.

@JJ-Author
Copy link
Collaborator

JJ-Author commented Feb 16, 2024

an example to the proposal from my first message.
it is more effort but it is possible to define more fine-grained and helpful error messages as shown in the toy example below. Note the error message describe error causes that explain violation causes and not the test logic. We shoud consider that for all test messages.
the general idea is for properties hat are autocompleted we remove the mincount but add another shape in a dedicated file
where we include all the min:counts for autocompleted values that we use for the backend.

:OptionalPartByteSizeShape
    a sh:PropertyShape ;
sh:targetClass databus:Part ;
    sh:path dcat:byteSize ;
    sh:maxCount 1 ;
    sh:datatype xsd:integer;
    sh:message "A databus:Part dcat:byteSize is not of type xsd:integer or has MORE than one value"@en .

:AfterAutocompletionPartShape
    a sh:NodeShape ;
    sh:targetClass databus:Part ;
    sh:property [                         # with sh:and instead we can enumerate all autcompleted properties for databsu:Part here
        sh:path dcat:byteSize ;
        sh:minCount 1 ;  # Making it mandatory
        sh:message "A databus:Part is missing the dcat:byteSize value"@en ;
    ] .

Note the maxCount is not checked correctly in shaclplayground (but here it works https://rdfplayground.dcc.uchile.cl/)

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