-
Notifications
You must be signed in to change notification settings - Fork 64
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
Trouble with qualified value shape #213
Comments
@ajnelson-nist Thanks for reporting this. This is one of the areas where the SHACL W3C Test Suite (SHT) and the Datashape Tests suite (DASH) both are lacking comprehensive and exhaustive test cases. |
Ok, I've found the source of the problem. It is due to a potentially overzealous optimisation added when the feature to detect and prevent shape-recursion was implemented in Sept 2022. pySHACL/pyshacl/constraints/core/shape_based_constraints.py Lines 323 to 328 in 52e239c
Basically, the second So I suppose an easy solution would be to skip this shortcut check if |
I think this would be correct.
Yes, I believe the complete absence of value nodes equally effects unqualified property shapes and qualified property shapes. Looking over the qualified shapes part of the spec, the phrasing does not seem to have a "qualified matches among matches found" logical flex. Instead, sentence one looks pretty definitive: " |
Yes, I agree with your assessment, and that's the same conclusion I came to. |
Spectacular to hear! Many thanks! |
Okay, @ajnelson-nist you don't need to wait until the weekend. The new version is out already. |
A local-to-CASE-Corpora shape requires `InvestigativeAction`s to have `ProvenanceRecord`s as outputs. (See `/shapes/local.ttl`, `sh-case-corpora-local:InvestigativeAction-shape`.) That shape used a SHACL mechanism that was not active in this repository's testing until pySHACL Issue 213 was closed. This patch adds a `ProvenanceRecord` as output to the last non-subaction that had the phone as input. Review of the results of this SPARQL query indicate the device is not used in further actions, so this `ProvenanceRecord` has no further impact on the graph today. ```sparql SELECT ?nAction ?lDescription WHERE { ?nAction uco-action:object kb:device-ea732801-7d0e-46ac-a028-69b782c97a46 ; . OPTIONAL { ?nAction uco-core:description ?lDescription ; . } } ORDER BY ?nAction ``` There is some open question on how to tie the subactions' outputs to the parent action's `ProvenanceRecord`; that thread is on CASE Issue 136. A follow-on patch will regenerate Make-managed files. References: * RDFLib/pySHACL#213 * casework/CASE#136 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
The `case_validate` version is bumped to acknowledge behavior changes from pySHACL 0.24.0. References: * RDFLib/pySHACL#213 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
This patch re-introduces `DownloadableFile`, as well as some related classes, to describe a concept IRI that behaves as a file-yielding URL. This patch removes a qualified SHACL constraint that had been written on a conflated-classes guess that instigated UCO Issue 534. After discussion on Issue 534, this shape should have been removed, but it wasn't until pySHACL Issue 213 was addressed that the shape started triggering and raising awareness it was still around. Hand-maintained data, as well as the Digital Corpora rendering script, have been updated to accommodate the new shapes around `DownloadableObject` and `DownloadableRelation`. A later patch will need to add the `DownloadableRelation`s to the chain of custody. A follow-on patch will regenerate Make-managed files. References: * RDFLib/pySHACL#213 * ucoProject/UCO#534 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
This patch also updates a test result expectation to account for an effect of pySHACL 0.24.0. A follow-on patch will regenerate Make-managed files. References: * RDFLib/pySHACL#213 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
References: * RDFLib/pySHACL#213 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
This new shape stemmed from discussion on CASE Issue 136. As a matter of preserving backwards compatibility, this patch introduces the shape requiring `ProvenanceRecord`s with a `sh:Warning`-level severity. In CASE 2.0.0, this requirement will be strengthened into a `sh:Violation`. A separate proposal will be filed with UCO to test the minimum qualified cardinality OWL structure. A draft of that syntax review system was used to test this patch. This patch adds a version floor for pySHACL to ensure an update in qualified value shape handling is included, which is necessary for the new property shape to function when using pySHACL. Disclaimer: References: * RDFLib/pySHACL#213 * #136 * #146 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
Hello,
I'm having a difficult time making a qualified value shape work.
I've tried the graph
ex:Hand
example in SHACL Section 4.7.3, and have gotten it to trigger as the spec has me think it should, with this data:The results of running
pyshacl --shacl HAND_SH.ttl HAND_DATA.ttl
are:(This worked with and without
sh: qualifiedValueShapesDisjoint
included)But, I'm having a hard time getting a reduced example to trigger.
The shapes graph I'm trying is:
The data graph I'm feeding in is:
And this is the only result I'm getting from running
pyshacl --metashacl --shacl POST_SH.ttl POST_DATA.ttl
:(
--metashacl
didn't raise any complaints.)I was expecting a second
sh:Violation
to occur based on the qualified value shape. The first violation shows the unqualified minimum count is working. Are there any thoughts on why the qualified minimum count isn't working?The text was updated successfully, but these errors were encountered: