On 28/05/2020 20:47, Chris Tomlinson wrote:
Hi,
I have a two questions regarding behavior I’m seeing w/ jena-shacl in 3.14.0.
The data file is P707_nameErrs02.ttl <https://pastebin.com/8wZeMiEU>, the shape graph is at
ShapeName_01.ttl <https://pastebin.com/spJJAsJ3>, and the test code is
ShaclName_validateGraph.java <https://pastebin.com/qvUy2XeB>.
Can we focus on one question please?
This is a complex setup and I'm not sure I have reproduced it correctly.
With the ontology added, it isn't small.
Question 1: regarding the name bds:PersonShape at line 9 of ShapeName_01.ttl
<https://pastebin.com/spJJAsJ3>. With that name the results of running
ShaclName_validateGraph.java <https://pastebin.com/qvUy2XeB> are as expected, see
ShapeName-results-PersonShape.txt <https://pastebin.com/Hbk4dj04>.
There are two errors in P707_nameErrs02.ttl <https://pastebin.com/8wZeMiEU> regarding
bdr:NMC2A097019ABA499F and bdr:NM0895CB6787E8AC6E which are reported in the
ShapeName-results-PersonShape.txt <https://pastebin.com/Hbk4dj04> file.
However, if the name at line 9 of ShapeName_01.ttl <https://pastebin.com/spJJAsJ3> is
changed to: bds:PersonLocalShape or bds:Frogs; then detail for bdr:NM0895CB6787E8AC6E
reports, (see ShapeName-results-PersonLocalShape.txt <https://pastebin.com/f4F9h1E2>):
[ a sh:ValidationReport ;
sh:conforms true ] .
instead of:
[ a sh:ValidationReport ;
sh:conforms false ;
sh:result [ a sh:ValidationResult ;
sh:focusNode bdr:NM0895CB6787E8AC6E ;
sh:resultMessage ":PersonName must have exactly one
rdfs:label"@en ;
sh:resultPath rdfs:label ;
sh:resultSeverity sh:Violation ;
sh:sourceConstraintComponent sh:MinCountConstraintComponent ;
sh:sourceShape
bds:PersonNameShape-personNameLabel
]
] .
which is the result with bds:PersonShape at line 9 of ShapeName_01.ttl
<https://pastebin.com/spJJAsJ3>. In fact changing the name to bds:FrogTarts
also produces the expected results.
Summary: If the shape name at line 9 of ShapeName_01.ttl
<https://pastebin.com/spJJAsJ3> is either bds:PersonShape or bds:FrogTarts then
the results are as expected; while if the shape name is either bds:PersonLocalShape
or bds:Frogs then one of the detail results disappears and is replaced by
sh:conforms true.
Why this dependence on the shape name? The shape name isn’t referred to elsewhere in
ShapeName_01.ttl <https://pastebin.com/spJJAsJ3>.
A way to check is run both Jena Shacl and TQ Shacl and see if they get
the same violations
I ran the shapes and data in both and get 32 violations (with no
ontology added)
and then running with the datafile as P707+ontology. Now 5 results each.
shacl v -s ShapeName_01.ttl -d P707_nameErrs02.ttl > V1.ttl
tb-shacl -shapesfile ShapeName_01.ttl -datafile P707_nameErrs02.ttl
The name of the shape does not seem to make a difference when run like this.
Have you tries with targetNode to select the node to validate? With a
subset of thee shapes? That would make discussing it much easier as
would a self-contained data (the ontology isn't particularly small).
Do you have an example which has one target shape and shows differences?
This:
bds:PersonShape-personName
a sh:PropertyShape ;
sh:class bdo:PersonName ;
sh:message "PersonName is not well-formed, wrong Class or
missing rdfs:label"@en ;
sh:minCount 1 ;
sh:node bds:PersonNameShape ;
sh:nodeKind sh:IRI ;
sh:path bdo:personName ;
.
(and others) could be split up into separate shapes, one per constraint
(this has node kind, node shape, and minCount) which might make the
report clearer
bds:PersonNameShape also has a target - it can get called via two
different routes.
It's quite complicated to track what's going on.
Question 2: With the same files as illustration, I’m wanting to understand how
deep the:
sv.validate(shapes, dataGraph, rez.asNode());
goes? What I mean is that simply calling:
Model topReport = process(shapes, dataGraph, rez);
Since passing 'rez' is like choosing one node out of the target set, it
is possible to write with targetNode - does this behave the same?
at line 74 of ShaclName_validateGraph.java <https://pastebin.com/qvUy2XeB>
produces just the result:
I get three separate reports all in one model, with 0, 1 and 2 violations.
[ a sh:ValidationReport ;
sh:conforms false ;
sh:result [ a sh:ValidationResult ;
sh:focusNode bdr:P707 ;
sh:resultMessage "PersonName is not well-formed,
wrong Class or missing rdfs:label"@en ;
sh:resultPath bdo:personName ;
sh:resultSeverity sh:Violation ;
sh:sourceConstraintComponent sh:NodeConstraintComponent ;
sh:sourceShape bds:PersonShape-personName ;
BTW bds:PersonNameShape is both a target and a sh:node connected shape.
sh:value bdr:NM0895CB6787E8AC6E
] ;
sh:result [ a sh:ValidationResult ;
sh:focusNode bdr:P707 ;
sh:resultMessage "PersonName is not well-formed,
wrong Class or missing rdfs:label"@en ;
sh:resultPath bdo:personName ;
sh:resultSeverity sh:Violation ;
sh:sourceConstraintComponent sh:ClassConstraintComponent ;
sh:sourceShape bds:PersonShape-personName ;
sh:value bdr:NMC2A097019ABA499F
]
] .
without going deeper to produce the more detailed results for each of the
PersonNames in error.
Is this a result of validate node semantics?
As can be seen the detailed results are produced by using validate node on the
sh:value objects in the above two results. Is this the appropriate way of
extracting more useful detail than the generic results reported from the
violations reported by the “top-level” call to validate node?
I hope the questions and files are reasonably clear.
Thanks for help with these two questions,
Chris
