subject:"two jena\-shacl questions"

Re: one jena-shacl question - was Re: two jena-shacl questions

2020-06-03 Thread Chris Tomlinson

Hi Andy,

Thank you so much for your patience and help. I think I’ve got a handle on 
things now and will forge ahead. 

I appreciate you raising JENA-1905 
, JENA-1906 
, and JENA-1907 
. I’ll comment on the issues 
as appropriate.

Thank you again,
Chris


> On Jun 1, 2020, at 4:44 PM, Andy Seaborne  wrote:
> 
> 
> 
> On 01/06/2020 21:08, Chris Tomlinson wrote:
>> Hi Andy,
>> Not trying to be pedantic below but I’m trying to understand how to think in 
>> shacl and establish some expectations of the validation process.
> 
> If it help, the general pattern is
> 
> Target ->
>  (Node shape -> property shape->)*
>  Constraint*
> 
>>> On May 31, 2020, at 9:40 AM, Andy Seaborne  wrote:
>>> 
>>> Do we agree that this is a test case?
>>> (one file, data and shapes combined)
>>> Only command line tools needed.
>> I agree that the combined data and shapes file exhibits differences in 
>> report results, when interchanging bds:PersonShape and bds:PersonLocalShape.
>>> 
>>> @prefix rdf:    .
>>> @prefix rdfs:   .
>>> @prefix sh: .
>>> @prefix bdo:    .
>>> @prefix bdr:    .
>>> @prefix bds:    .
>>> 
>>> ## Data:
>>> 
>>> bdr:NM0895CB6787E8AC6E
>>> a   bdo:PersonName ;
>>> .
>>> 
>>> bdr:P707  a  bdo:Person ;
>>>bdo:personName   bdr:NM0895CB6787E8AC6E ;
>>> .
>>> 
>>> ## Shapes:
>>> 
>>> #bds:PersonShape   # 2
>>> bds:PersonLocalShape  # 1
>>>sh:property bds:PersonShape-personName ;
>>>sh:targetClass  bdo:Person ;
>>> .
>>> 
>>> bds:PersonShape-personName
>>>sh:message  "PersonName is not well-formed, wrong Class or missing 
>>> rdfs:label"@en ;
>>>sh:node bds:PersonNameShape ;
>>>sh:path bdo:personName ;
>>> .
>>> 
>>> bds:PersonNameShape  a  sh:NodeShape ;
>>>sh:property bds:PersonNameShape-personNameLabel ;
>>>sh:targetClass  bdo:PersonName ;
>>> .
>>> 
>>> bds:PersonNameShape-personNameLabel
>>>sh:message  ":PersonName must have exactly one rdfs:label"@en ;
>>>sh:minCount 1 ;
>>>sh:path rdfs:label ;
>>> .
>>> 
>>> 
>>> The differences seems to be that the hash order is different and it affects 
>>> finding targets, combined with the fact that targets are nested:
>> I see JENA-1907  raises the 
>> issue; I understand:
>>> If A is processed first as a target then the parser shapes now includes B 
>>> so processing B is skipped.
>>> Note - the effect is only in the number of times constriants are executed , 
>>> once or twice, not whether they are omitted.
>> to say that, in the current test case w/ the hash order issue, when nesting 
>> occurs owing to sh:node, then when a violation is found by (A) 
>> bds:PersonShape-personName, then the validation does not "go deeper" to 
>> consider (B) bds:PersonNameShape, by itself. W/o sh:node, in 
>> bds:PersonShape-personName, then both  bds:PersonShape-personName and 
>> bds:PersonNameShape are parsed as independent targets and  executed 
>> independently.
>>> bds:PersonLocalShape (target)
>>> -> bds:PersonLocalShape
>>>   -> bds:PersonNameShape (target)
>>> -> bds:PersonNameShape-personNameLabel
>> I think the second line above is supposed to be
>> -> bds:PersonShape-personName
>>> Both targets match bdr:P707, one by class, one by property.
>> I understand the NodeShape, bds:PersonLocalShape, matching bdr:P707, 
>> meaning, to me, that the constraints expressed in that shape need to be 
>> evaluated w/ P707 being the subject (== focus node). I take this to be “by 
>> class”.
>> I do not understand how NodeShape, bds:PersonNameShape, matches bdr:P707. I 
>> think bds:PersonNameShape matches bdr:NM0895CB6787E8AC6E because of 
>> sh:targetClass bdo:PersonName.
> 
> 1/
> bds:PersonShape
>  sh:targetClass  bdo:Person
>  -> bdr:P707
> 
> and is has
>  sh:property bds:PersonShape-personName ;
> ->
> sh:node bds:PersonNameShape ;
> ->
> sh:property bds:PersonNameShape-personNameLabel ;
> 
> 2/
> bds:PersonNameShape  a  sh:NodeShape ;
>sh:property bds:PersonNameShape-personNameLabel ;
>sh:targetClass  bdo:PersonName ; <-- which is part of bdr:P707
> ->  bdr:NM0895CB6787E8AC6E ;
> 
> so two ways to get to bds:PersonNameShape-personNameLabel from target 
> declarations.
> 
> (try "shacl validate -v")
> 
> In case1: you can see the paths:
> 2 targets.
> each with one focus node
> leading to the same property shape /PersonNameShape-personNameLabel
> which has a constraint.
> 
> (I checked the spec and it is onlt says to execute once if the same

Re: one jena-shacl question - was Re: two jena-shacl questions

2020-06-01 Thread Andy Seaborne





On 01/06/2020 21:08, Chris Tomlinson wrote:

Hi Andy,

Not trying to be pedantic below but I’m trying to understand how to think in 
shacl and establish some expectations of the validation process.


If it help, the general pattern is

Target ->
  (Node shape -> property shape->)*
  Constraint*


On May 31, 2020, at 9:40 AM, Andy Seaborne  wrote:

Do we agree that this is a test case?
(one file, data and shapes combined)
Only command line tools needed.


I agree that the combined data and shapes file exhibits differences in report 
results, when interchanging bds:PersonShape and bds:PersonLocalShape.




@prefix rdf:    .
@prefix rdfs:   .
@prefix sh: .
@prefix bdo:    .
@prefix bdr:    .
@prefix bds:    .

## Data:

bdr:NM0895CB6787E8AC6E
 a   bdo:PersonName ;
.

bdr:P707  a  bdo:Person ;
bdo:personName   bdr:NM0895CB6787E8AC6E ;
.

## Shapes:

#bds:PersonShape   # 2
bds:PersonLocalShape  # 1
sh:property bds:PersonShape-personName ;
sh:targetClass  bdo:Person ;
.

bds:PersonShape-personName
sh:message  "PersonName is not well-formed, wrong Class or missing 
rdfs:label"@en ;
sh:node bds:PersonNameShape ;
sh:path bdo:personName ;
.

bds:PersonNameShape  a  sh:NodeShape ;
sh:property bds:PersonNameShape-personNameLabel ;
sh:targetClass  bdo:PersonName ;
.

bds:PersonNameShape-personNameLabel
sh:message  ":PersonName must have exactly one rdfs:label"@en ;
sh:minCount 1 ;
sh:path rdfs:label ;
.


The differences seems to be that the hash order is different and it affects 
finding targets, combined with the fact that targets are nested:


I see JENA-1907  raises the 
issue; I understand:


If A is processed first as a target then the parser shapes now includes B so 
processing B is skipped.
Note - the effect is only in the number of times constriants are executed , 
once or twice, not whether they are omitted.



to say that, in the current test case w/ the hash order issue, when nesting occurs owing 
to sh:node, then when a violation is found by (A) bds:PersonShape-personName, then the 
validation does not "go deeper" to consider (B) bds:PersonNameShape, by itself. 
W/o sh:node, in bds:PersonShape-personName, then both  bds:PersonShape-personName and 
bds:PersonNameShape are parsed as independent targets and  executed independently.



bds:PersonLocalShape (target)
-> bds:PersonLocalShape
   -> bds:PersonNameShape (target)
 -> bds:PersonNameShape-personNameLabel


I think the second line above is supposed to be

 -> bds:PersonShape-personName



Both targets match bdr:P707, one by class, one by property.


I understand the NodeShape, bds:PersonLocalShape, matching bdr:P707, meaning, 
to me, that the constraints expressed in that shape need to be evaluated w/ 
P707 being the subject (== focus node). I take this to be “by class”.

I do not understand how NodeShape, bds:PersonNameShape, matches bdr:P707. I 
think bds:PersonNameShape matches bdr:NM0895CB6787E8AC6E because of 
sh:targetClass bdo:PersonName.


1/
bds:PersonShape
  sh:targetClass  bdo:Person
  -> bdr:P707

and is has
  sh:property bds:PersonShape-personName ;
->
 sh:node bds:PersonNameShape ;
->
 sh:property bds:PersonNameShape-personNameLabel ;

2/
bds:PersonNameShape  a  sh:NodeShape ;
sh:property bds:PersonNameShape-personNameLabel ;
sh:targetClass  bdo:PersonName ; <-- which is part of bdr:P707
->  bdr:NM0895CB6787E8AC6E ;

so two ways to get to bds:PersonNameShape-personNameLabel from target 
declarations.


(try "shacl validate -v")

In case1: you can see the paths:
2 targets.
each with one focus node
leading to the same property shape /PersonNameShape-personNameLabel
which has a constraint.

(I checked the spec and it is onlt says to execute once if the same 
focus node comes up multiple times for the same target shape but here 
there are two different target shapes. TQ shacl agrees.)


F: Focus node
S: Node Shape
P: Property Shape.
C: Constraint

NodeShape[http://purl.bdrc.io/ontology/shapes/core/PersonLocalShape]
N: FocusNodes(1): [http://purl.bdrc.io/resource/P707]
  F: http://purl.bdrc.io/resource/P707
  S: NodeShape[http://purl.bdrc.io/ontology/shapes/core/PersonLocalShape]
  P: 
PropertyShape[http://purl.bdrc.io/ontology/shapes/core/PersonShape-personName 
-> ]

  C: http://purl.bdrc.io/resource/P707 :: Node
  S: NodeShape[http://purl.bdrc.io/ontology/shapes/core/PersonNameShape]
  P: 
PropertyShape[http://purl.bdrc.io/ontology/shapes/core/PersonNameShape-personNameLabel 
->

Re: one jena-shacl question - was Re: two jena-shacl questions

2020-06-01 Thread Chris Tomlinson

Hi Andy,

Not trying to be pedantic below but I’m trying to understand how to think in 
shacl and establish some expectations of the validation process.

> On May 31, 2020, at 9:40 AM, Andy Seaborne  wrote:
> 
> Do we agree that this is a test case?
> (one file, data and shapes combined)
> Only command line tools needed.

I agree that the combined data and shapes file exhibits differences in report 
results, when interchanging bds:PersonShape and bds:PersonLocalShape.

> 
> @prefix rdf:    .
> @prefix rdfs:   .
> @prefix sh: .
> @prefix bdo:    .
> @prefix bdr:    .
> @prefix bds:    .
> 
> ## Data:
> 
> bdr:NM0895CB6787E8AC6E
> a   bdo:PersonName ;
> .
> 
> bdr:P707  a  bdo:Person ;
>bdo:personName   bdr:NM0895CB6787E8AC6E ;
> .
> 
> ## Shapes:
> 
> #bds:PersonShape   # 2
> bds:PersonLocalShape  # 1
>sh:property bds:PersonShape-personName ;
>sh:targetClass  bdo:Person ;
> .
> 
> bds:PersonShape-personName
>sh:message  "PersonName is not well-formed, wrong Class or missing 
> rdfs:label"@en ;
>sh:node bds:PersonNameShape ;
>sh:path bdo:personName ;
> .
> 
> bds:PersonNameShape  a  sh:NodeShape ;
>sh:property bds:PersonNameShape-personNameLabel ;
>sh:targetClass  bdo:PersonName ;
> .
> 
> bds:PersonNameShape-personNameLabel
>sh:message  ":PersonName must have exactly one rdfs:label"@en ;
>sh:minCount 1 ;
>sh:path rdfs:label ;
> .
> 
> 
> The differences seems to be that the hash order is different and it affects 
> finding targets, combined with the fact that targets are nested:

I see JENA-1907  raises the 
issue; I understand:

> If A is processed first as a target then the parser shapes now includes B so 
> processing B is skipped.
> Note - the effect is only in the number of times constriants are executed , 
> once or twice, not whether they are omitted.

to say that, in the current test case w/ the hash order issue, when nesting 
occurs owing to sh:node, then when a violation is found by (A) 
bds:PersonShape-personName, then the validation does not "go deeper" to 
consider (B) bds:PersonNameShape, by itself. W/o sh:node, in 
bds:PersonShape-personName, then both  bds:PersonShape-personName and 
bds:PersonNameShape are parsed as independent targets and  executed 
independently.

> bds:PersonLocalShape (target)
> -> bds:PersonLocalShape
>   -> bds:PersonNameShape (target)
> -> bds:PersonNameShape-personNameLabel

I think the second line above is supposed to be 

-> bds:PersonShape-personName

> Both targets match bdr:P707, one by class, one by property.

I understand the NodeShape, bds:PersonLocalShape, matching bdr:P707, meaning, 
to me, that the constraints expressed in that shape need to be evaluated w/ 
P707 being the subject (== focus node). I take this to be “by class”.

I do not understand how NodeShape, bds:PersonNameShape, matches bdr:P707. I 
think bds:PersonNameShape matches bdr:NM0895CB6787E8AC6E because of 
sh:targetClass bdo:PersonName.

> It should execute twice -

I’m not following the referent “it” (but see below, I think I may).

My understanding of (target) bds:PersonLocalShape is that for resources of 
targetClass, bdo:Person, check that the constraints expressed in 
bds:PersonShape-personName conform for all objects of bdo:personName where the 
subject of that property path is bdr:P707 (in this case); and

(target) bds:PersonNameShape says that for resources of targetClass, 
bdo:PersonName, check that the constraints in PersonShape-personNameLabel 
conform where the resource is a bdo:PersonName, in this case 
bdr:NM0895CB6787E8AC6E.

I don’t see what’s supposed to execute twice.

> but did you mean to do this in the first place? Note while it is a minCount 
> failure, because of going through the sh;node, the message is the "wrong 
> Class" one because executing via bds:PersonShape-personName makes that the 
> message.

I meant to express that for a bdo:Person there must be at least 1 
bdo:personName - via bds:PersonShape-personName (the test case omits 
sh:minCount 1 in bds:PersonShape-personName);

and that a conforming bdoPersonName must have exactly 1 rdfs:label (the test 
case omits sh:maxCount 1 in bds:PersonShape-personNameLabel).

I used "sh:node bds:PersonNameShape" in the declaration for 
bds:PersonShape-personName to identify the particular NodeShape that is 
intended to validate objects of the "sh:path bdo:personName” in this situation.

Perhaps I see what is "supposed to execute twice”. 

With the "sh:node bds:PersonNameShape” in bds:PersonShape-personName, then 
bds:PersonNameShape validation must be

Re: one jena-shacl question - was Re: two jena-shacl questions

2020-05-31 Thread Andy Seaborne

Do we agree that this is a test case?
(one file, data and shapes combined)
Only command line tools needed.

@prefix rdf: .
@prefix rdfs: .
@prefix sh: .
@prefix bdo: .
@prefix bdr: .
@prefix bds: .

## Data:

bdr:NM0895CB6787E8AC6E
a bdo:PersonName ;
.

bdr:P707 a bdo:Person ;
bdo:personName bdr:NM0895CB6787E8AC6E ;
.

## Shapes:

#bds:PersonShape # 2
bds:PersonLocalShape # 1
sh:property bds:PersonShape-personName ;
sh:targetClass bdo:Person ;
.

bds:PersonShape-personName
sh:message "PersonName is not well-formed, wrong Class or
missing rdfs:label"@en ;

sh:node bds:PersonNameShape ;
sh:path bdo:personName ;
.

bds:PersonNameShape a sh:NodeShape ;
sh:property bds:PersonNameShape-personNameLabel ;
sh:targetClass bdo:PersonName ;
.

bds:PersonNameShape-personNameLabel
sh:message ":PersonName must have exactly one rdfs:label"@en ;
sh:minCount 1 ;
sh:path rdfs:label ;
.

The differences seems to be that the hash order is different and it
affects finding targets, combined with the fact that targets are nested:

bds:PersonLocalShape (target)
-> bds:PersonLocalShape
-> bds:PersonNameShape (target)
-> bds:PersonNameShape-personNameLabel

Both targets match bdr:P707, one by class, one by property.

It should execute twice -

but did you mean to do this in the first place? Note while it is a
minCount failure, because of going through the sh;node, the message is
the "wrong Class" one because executing via bds:PersonShape-personName
makes that the message.

You can see the differences with "shacl print".

Andy

On 29/05/2020 20:39, Chris Tomlinson wrote:

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

ShaclName_validateGraphTQ.java

The DATA_P707.ttl 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 contains the shape
definitions and all tests are performed only by changing the name on line 9.

The ShaclName_validateGraphJS-results-PersonShape.txt
shows the results when the JS app is run with
the name bds:PersonShape and gives the expected results.

The ShaclName_validateGraphJS-results-PersonLocalShape…
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
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 shows the
results when the TQ app is run for any spelling of the name on line 9 of ShapeName_01.ttl
. 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 set
to bds:PersonLocalShape:

shacl v -s ShapeName_01.ttl -d DATA_P707.ttl > PersonLocalShape_JS_Results.ttl

produces the unexpected results, namely there is no detail regarding the

one jena-shacl question - was Re: two jena-shacl questions

2020-05-29 Thread Chris Tomlinson

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 

ShaclName_validateGraphTQ.java 

The DATA_P707.ttl  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  contains the shape 
definitions and all tests are performed only by changing the name on line 9.

The ShaclName_validateGraphJS-results-PersonShape.txt 
 shows the results when the JS app is run with 
the name bds:PersonShape and gives the expected results.

The ShaclName_validateGraphJS-results-PersonLocalShape… 
 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 
 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  shows 
the results when the TQ app is run for any spelling of the name on line 9 of 
ShapeName_01.ttl . 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  set 
to bds:PersonLocalShape:

shacl v -s ShapeName_01.ttl -d DATA_P707.ttl > 
PersonLocalShape_JS_Results.ttl 

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 
 set to bds:PersonShape:

shacl v -s ShapeName_01.ttl -d DATA_P707.ttl > PersonShape_JS_Results.ttl 

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  wrote:
> 
>> Question 1: regarding the name  bds:PersonShape at line 9 of 
>> ShapeName_01.ttl . With that name the results 
>> of running ShaclName_validateGraph.java  are 
>> as expected, see ShapeName-results-PersonShape.txt 
>> .
>> There are two errors in P707_nameErrs02.ttl  
>> regarding bdr:NMC2A097019ABA499F and bdr:NM0895CB6787E8AC6E which are 
>> reported in the ShapeName-results-PersonShape.txt 
>>  file.
>> However, if the name at line 9 of ShapeName_01.ttl 
>>  is changed to: bds:PersonLocalShape or 
>> bds:Frogs; then detail for bdr:NM0895CB6787E8AC6E reports, (see 
>> ShapeName-results-PersonLocalShape.txt ):
>> [ a sh:ValidationReport ;
>>   sh:conforms true ] .
>> instead of:
>> [ ash:ValidationReport ;
>>   sh:conforms  false ;
>>   sh:result[ a

Re: two jena-shacl questions

2020-05-29 Thread Andy Seaborne





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 , the shape graph is at 
ShapeName_01.ttl , and the test code is 
ShaclName_validateGraph.java .



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 
. With that name the results of running 
ShaclName_validateGraph.java  are as expected, see 
ShapeName-results-PersonShape.txt .

There are two errors in P707_nameErrs02.ttl  regarding 
bdr:NMC2A097019ABA499F and bdr:NM0895CB6787E8AC6E which are reported in the 
ShapeName-results-PersonShape.txt  file.

However, if the name at line 9 of ShapeName_01.ttl  is 
changed to: bds:PersonLocalShape or bds:Frogs; then detail for bdr:NM0895CB6787E8AC6E 
reports, (see ShapeName-results-PersonLocalShape.txt ):

 [ a sh:ValidationReport ;
   sh:conforms true ] .

instead of:

[ ash: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 
. 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 
 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 .



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:classbdo: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  
produces just the result:



I get three separate reports all in one model, with 0, 1 and 2 violations.


[ ash: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 ;

two jena-shacl questions

2020-05-28 Thread Chris Tomlinson

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 , the shape 
graph is at ShapeName_01.ttl , and the test code 
is ShaclName_validateGraph.java .


Question 1: regarding the name  bds:PersonShape at line 9 of ShapeName_01.ttl 
. With that name the results of running 
ShaclName_validateGraph.java  are as expected, 
see ShapeName-results-PersonShape.txt . 

There are two errors in P707_nameErrs02.ttl  
regarding bdr:NMC2A097019ABA499F and bdr:NM0895CB6787E8AC6E which are reported 
in the ShapeName-results-PersonShape.txt  file.

However, if the name at line 9 of ShapeName_01.ttl 
 is changed to: bds:PersonLocalShape or 
bds:Frogs; then detail for bdr:NM0895CB6787E8AC6E reports, (see 
ShapeName-results-PersonLocalShape.txt ):

[ a sh:ValidationReport ; 
  sh:conforms true ] .

instead of:

[ ash: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 
. 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 
 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 .



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);

at line 74 of ShaclName_validateGraph.java  
produces just the result:

[ ash: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:sourceShapebds:PersonShape-personName ;
 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:sourceShapebds: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

Re: one jena-shacl question - was Re: two jena-shacl questions

Re: one jena-shacl question - was Re: two jena-shacl questions

Re: one jena-shacl question - was Re: two jena-shacl questions

Re: one jena-shacl question - was Re: two jena-shacl questions

one jena-shacl question - was Re: two jena-shacl questions

Re: two jena-shacl questions

two jena-shacl questions

7 matches

Site Navigation

Mail list logo

Footer information