Hi Andy,
Thank you for the reply. Focussing on just the first question. I have prepared
small self-contained tests of jena-shacl from 3.14.0 (JS) and TopQuadrant Shacl
1.3.2 (TQ).
The apps differ only according to differences imposed by the JS and TQ APIs:
ShaclName_validateGraphJS.java <https://pastebin.com/5382xZeL>
ShaclName_validateGraphTQ.java <https://pastebin.com/3BxmyhqA>
The DATA_P707.ttl <https://pastebin.com/ugCZfABj> contains the three needed
triples from the ontology and the bare minimum from the example P707 with two
different errors in two of the PersonName instances.
The ShapeName_01.ttl <https://pastebin.com/jDqzvPTe> contains the shape
definitions and all tests are performed only by changing the name on line 9.
The ShaclName_validateGraphJS-results-PersonShape.txt
<https://pastebin.com/seEfWKNa> shows the results when the JS app is run with
the name bds:PersonShape and gives the expected results.
The ShaclName_validateGraphJS-results-PersonLocalShape…
<https://pastebin.com/q1SWMC4H> shows the results when the JS app is run with
the name bds:PersonLocalShape and gives unexpected results. Namely, the
expected violation regarding the PersonName which uses skos:prefLabel instead
of rdfs:label is erroneously reported as conforming.
The ShaclName_validateGraphJS-results-varying.txt
<https://pastebin.com/CNwnE5kg> shows results for names ranging from “P”, “Pe”,
“Per” thru “PersonLocal”, “PersonShape” upto “PersonLocalShape”,
“PersonLocalShaper”, and finally “PersonLocalShapers” for the JS app. In the
table a “0” means the unexpected result and a “1” means the expected result - 7
names produce unexpected results and 20 names produce expected results.
The ShaclName_validateGraphTQ-results.txt <https://pastebin.com/BQnStjVq> shows
the results when the TQ app is run for any spelling of the name on line 9 of
ShapeName_01.ttl <https://pastebin.com/jDqzvPTe>. The results are the expected
results as with some spellings of the name in the JS case. TQ shows no
variation owing to the name on line 9 as is expected.
(Note: The TQ engine needed to be re-initialized for each use otherwise it
accumulated results. This is why there is an init of the ShaclSimpleValidator
at each use in the JS app even though it is not needed. I just wanted to
produce as much as possible an apples-to-apples comparison of JS and TQ.)
(Note: The TQ report does not include sh:conforms true ; in the results, just:
[ a sh:ValidationReport ] . I don’t know if this conforms to the SHACL
spec but that’s another matter.)
The results from the command line tests show the same as the above.
Running with line 9 of ShapeName_01.ttl <https://pastebin.com/jDqzvPTe> set
to bds:PersonLocalShape:
shacl v -s ShapeName_01.ttl -d DATA_P707.ttl >
PersonLocalShape_JS_Results.ttl <https://pastebin.com/M9s859Kc>
produces the unexpected results, namely there is no detail regarding the
missing rdfs:label on bdr:NM0895CB6787E8AC6E.
However, running with line 9 of ShapeName_01.ttl
<https://pastebin.com/jDqzvPTe> set to bds:PersonShape:
shacl v -s ShapeName_01.ttl -d DATA_P707.ttl > PersonShape_JS_Results.ttl
<https://pastebin.com/DhBNucpX>
produces the expected results, in that the detail regarding the missing
rdfs:label on bdr:NM0895CB6787E8AC6E is present among the results.
I did not set up the TQ command line but I think the above TQ results make this
testing unnecessary.
I think these tests show that there is an unexpected dependence on a shape name
in the JS library and not in the TQ library. I think this is an error and I can
open a JIRA issue if appropriate.
A consideration I have is that we want to be able to use the fuseki shacl
endpoint for some processing and hence need to understand the expected behavior
of the JS library which is integrated.
Thank you again for your help
Chris
> On May 29, 2020, at 6:26 AM, Andy Seaborne <a...@apache.org> wrote:
>
>> 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.
