-
Notifications
You must be signed in to change notification settings - Fork 6
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
SHACL shapes do not pass SHACL-SHACL validation #139
Comments
Apologies, I should have included this in the initial post: |
The shape-component transcribed from DASH was transcribed incorrectly. The RDF List was constructed incorrectly, needing both a `rdf:first` and `rdf:rest` predicate. Also, from DASH-prescribed usage with `sh:or`, the RDF List members must be `sh:Shape`s, each housing a `sh:datatype` constraint predicate. To avoid other transcription or reformatting errors, this patch copies the original shape from DASH, adding an `rdfs:isDefinedBy` to cite the source. Because DASH does not provide a `owl:versionIRI`, an extra comment noting the copy date and destination file is also added. This patch addresses 37 of the 70 reported SHACL-SHACL validation errors noted in Issue 139. References: * https://datashapes.org/dash.html#StringOrLangString * DOI-DO#139 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
I've drafted some changes to address SHACL-SHACL validation errors, and will be happy to send some more PRs akin to #162 after this week's holiday. However, I also tried running the shapes against the examples in this repository, and saw there are several validation issues raised. A shell transcript is at the end of this post. I'd made a remark in my initial post on adding a Continuous Integration process. That seems like it might be a bigger discussion that will expand into whether the examples should conform to all, or just some, of the SHACL shapes. Would that be better handled in a separate Issue? (I'm not sure how amenable your workflow is to receiving new Issues at the moment.) Shell transcript, using
Footnotes
|
Alex, Thank you so much for your detailed feedback. Your ticket is currently under review and we will come back to you as soon as possible with remediation for the issue you raised. Thanks for your patience. |
Would like to discuss further as I don't have background/understanding on this |
An updated SHACL shapefile has been commited in the repository that fixes the issues. Also updated the activity,ttl to get the required fields to pass validation. A more complete example has been added in the Git repository that pass the validation: https://github.com/DOI-DO/dcat-us/blob/main/docs/examples/example1-dcat-us-3.0.ttl |
Hi @fellahst , Thank you for the updates! I've checked the DCAT-US 3 SHACL graph as I did before, and it now appears to be conformant with SHACL syntactic requirements. I noticed not all of the examples under ls docs/examples/*ttl | while read x; do echo $x; pyshacl --shacl shacl/dcat-us_3.0_shacl_shapes.ttl ${x} ; done 2>&1 | egrep '^Conforms' | sort | uniq -c I got these results:
I appreciate making all of the examples conformant might be distracting from each example's purpose. But on the other hand, examples might be copied with the hope of starting an application from a "known passing" state. Could a README be added to Also, with Footnotes
|
@fellahst-- what is the response to Alex Nelson's question above about adding a README? |
Thank you for your insightful feedback and the excellent suggestion regarding the addition of a README to clarify the purpose and conformity status of examples in the docs/examples directory. We will make more examples SHACL conformant by adding the missing required fields and add a README.txt if we can not make them all compliant without significant work. Incorporating a Continuous Integration (CI) process, particularly for the automated validation of new examples, is indeed a wise move forward. I am eager to delve into and discuss the CI practices you have suggested when we will enter the implementation phase. Such practices promise to significantly enhance our project by maintaining consistent compliance and streamlining updates. |
+1 |
I went the extra-mile to make sure that every single file of the 123 examples are validating against the SHACL file.
|
Name: Alex Nelson
Affiliation: I am an employee of the National Institute of Standards and Technology. I am also a community member of the Cyber Domain Ontology in some leadership roles.
Type of issue: Schema (specifically, SHACL shapes)
Issue: A review of the file
dcat-us_3.0_shacl_shapes.ttl
in today's state raises several SHACL-SHACL validation errors -- that is, errors specific to SHACL syntax. Unfortunately, these errors cause the shapes graph to fail to load in a SHACL-executing engine. An example shape that has errors isdcat-us-shp:Document_Shape-creator
(link is to today's version of that file).sh:path
, while SHACL syntactically requires only one object.dcterms:creator
is a sub-property ofdc:creator
, there are different effects for either being the object ofsh:path
.sh:minCount
,sh:nodeKind
.In total, this pySHACL (version 0.24.0) command1, which runs SHACL-SHACL validation of the shapes graph before attempting to validate the data graph, reports 70 errors across the graph:
# (current working directory: top source directory of repository) pyshacl \ --metashacl \ --shacl shacl/dcat-us_3.0_shacl_shapes.ttl \ docs/examples/activity.ttl
Recommended change(s):
docs/examples
.Footnotes
Disclaimer: Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose. ↩
The text was updated successfully, but these errors were encountered: