Re: SHACL-C [was: misleading parse exception message in Shacl.]

[Andy Seaborne]

On 19/07/2020 23:21, Holger Knublauch wrote:

On 19/07/2020 19:53, Andy Seaborne wrote:


Hi Chris,

Oddly, sh:group/sh:order aren't in SHACLC - they look like they got 
overlooked as they fit is quite naturally into the grammar. Maybe the 
WG focus was validation and these aren't "validation".


All terms from the sh: namespace are supported at property shapes and 
node shapes, see


https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue


"concatenating the sh namespace with the string value of /propertyParam/"

("string value" taken to mean the string that is the token)

Today, 2020-07-20, the words aren't in the propertyParam grammar rule.

Andy

Re: SHACL-C [was: misleading parse exception message in Shacl.]

[Holger Knublauch]

On 19/07/2020 19:53, Andy Seaborne wrote:


Hi Chris,

Oddly, sh:group/sh:order aren't in SHACLC - they look like they got 
overlooked as they fit is quite naturally into the grammar. Maybe the 
WG focus was validation and these aren't "validation".


All terms from the sh: namespace are supported at property shapes and 
node shapes, see


https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue

e.g.

    ex:property xsd:string [0..1] order=0 .

should work. Theoretically this could be extended to allow other 
prefixes such as dash: there too. This would then also cover 
rdfs:subClassOf, e.g.


shapeClass ex:Company rdfs:subClassOf ex:Organization {
    ...
}

As the Compact Syntax is a living spec we could easily add this if there 
is sufficient consensus.


The larger question of course becomes at what stage the syntax is no 
longer compact. If we add more features, people could just as well use 
TTL, which has the advantage of being more regular. I have no strong 
opinion. (Likely better continued on the SHACL CG list)


Holger




dash:editor, and your own annotations:

There was a brief discussion on the SHACL CG list about allowing RDF 
in SHACL-C. I didn't see a conclusion.


It can be done, in rather ungraceful way, with IMPORTS but you have 
ask "why bother" if its splitting the shapes into compact and RDF parts.


Similarly, if there is an RDF block in a SHACL-C file: at least 
everything is in one file but having to wire two sections of the file 
by using the shape URIs is again, to me, kind of contrary to the 
compact, ease of use, aspect of SHACL-C.


It looks like it would nearly work with inline Turtle inside the 
compact shape with some parser contortions; property + the compact 
class/datatype constraint would be ambiguous, but otherwise I think it 
could be done because most things are using keywords. Another way 
would be syntax to say "here be Turtle, same subject as the 
node/property a this point".


All options that allow RDF are assuming the shape writer understands 
the compact syntax as a specialised way to write some RDF and also 
what the RDF structure looks like if they are going to add RDF into 
it. So it all may be a step too far.


What I'd like in a SHACL-C file is being able to have RDFS 
subclass/subproperty declarations.


    Andy

On 17/07/2020 17:27, Chris Tomlinson wrote:

Hi Andy,

I haven’t looked into SHACLC. We do use features such as sh:group, 
sh:order, dash:editor and so on; as well as a few annotations of our 
own that are relevant to editing and some validation controls. 
Off-hand it isn’t clear how to use SHACLC and weave these other 
features in.


The notation is nicely compact and if there’s an integration approach 
for additional features I’ll look deeper.


Thanks,
Chris

SHACL-C [was: misleading parse exception message in Shacl.]

[Andy Seaborne]

Hi Chris,

Oddly, sh:group/sh:order aren't in SHACLC - they look like they got 
overlooked as they fit is quite naturally into the grammar. Maybe the WG 
focus was validation and these aren't "validation".


dash:editor, and your own annotations:

There was a brief discussion on the SHACL CG list about allowing RDF in 
SHACL-C. I didn't see a conclusion.


It can be done, in rather ungraceful way, with IMPORTS but you have ask 
"why bother" if its splitting the shapes into compact and RDF parts.


Similarly, if there is an RDF block in a SHACL-C file: at least 
everything is in one file but having to wire two sections of the file by 
using the shape URIs is again, to me, kind of contrary to the compact, 
ease of use, aspect of SHACL-C.


It looks like it would nearly work with inline Turtle inside the compact 
shape with some parser contortions; property + the compact 
class/datatype constraint would be ambiguous, but otherwise I think it 
could be done because most things are using keywords. Another way would 
be syntax to say "here be Turtle, same subject as the node/property a 
this point".


All options that allow RDF are assuming the shape writer understands the 
compact syntax as a specialised way to write some RDF and also what the 
RDF structure looks like if they are going to add RDF into it. So it all 
may be a step too far.


What I'd like in a SHACL-C file is being able to have RDFS 
subclass/subproperty declarations.


Andy

On 17/07/2020 17:27, Chris Tomlinson wrote:

Hi Andy,

I haven’t looked into SHACLC. We do use features such as sh:group, sh:order, 
dash:editor and so on; as well as a few annotations of our own that are 
relevant to editing and some validation controls. Off-hand it isn’t clear how 
to use SHACLC and weave these other features in.

The notation is nicely compact and if there’s an integration approach for 
additional features I’ll look deeper.

Thanks,
Chris

Re: misleading parse exception message in Shacl.

[Chris Tomlinson]

Hi Andy,

I haven’t looked into SHACLC. We do use features such as sh:group, sh:order, 
dash:editor and so on; as well as a few annotations of our own that are 
relevant to editing and some validation controls. Off-hand it isn’t clear how 
to use SHACLC and weave these other features in.

The notation is nicely compact and if there’s an integration approach for 
additional features I’ll look deeper.

Thanks,
Chris


> On Jul 17, 2020, at 5:37 AM, Andy Seaborne  wrote:
> 
> Be interested to hear experiences using SHACL Compact Syntax.
> 
> It's Lang.SHACLC
> 
> SHACL-CS doesn't cover all SHACL but what it does cover is easier to read and 
> write.
> 
> 1/ What is missing from SHACL-CS from your perspective?
> 2/ Is it, in fact, actually helpful for managing SHACL at scale or not?
> 
>Andy
> 
> https://w3c.github.io/shacl/shacl-compact-syntax/
> 
> 
> On 16/07/2020 22:31, Chris Tomlinson wrote:
>> Andy,
>> That's great news! Updating to 3.16.0 is on the ToDo list. I'm moving it to 
>> the top.
>> Thanks very much,
>> Chris
>>> On Jul 16, 2020, at 16:20, Andy Seaborne  wrote:
>>> 
>>> Fixed in 3.16.0:
>>> 
>>> "shacl parse" gives:
>>> 
>>> No sh:path on a property shape: 
>>> node= sh:property 
>>> 
>>> 
>>> when there exists at least one triple with
>>> bds:ContentLocationShape-contentLocationStatement as subject
>>> 
>>> and
>>> 
>>> Missing property shape: node= 
>>> sh:property 
>>> 
>>> 
>>> if there are none:
>>> 
>>> 
>>> (and no stacktraces)
>>> 
>>> but what you show if 3.15.0.
>>> 
>>> Test RDF::
>>> 
>>> PREFIX rdf: 
>>> PREFIX rdfs:
>>> PREFIX sh:  
>>> PREFIX xsd: 
>>> 
>>> PREFIX bds: 
>>> PREFIX bdo: 
>>> 
>>> bds:ContentLocationShape
>>>  a sh:NodeShape ;
>>>  sh:property bds:ContentLocationShape-contentLocationStatement ;
>>>  sh:targetClass bdo:ContentLocation .
>>> 
>>> #bds:ContentLocationShape-contentLocationStatement rdf:type 
>>> sh:PropertyShape .
>>> 
>>> 
 On 16/07/2020 21:44, Chris Tomlinson wrote:
 Hi,
 I’ve gotten a parse exception:
 org.apache.jena.shacl.parser.ShaclParseException: No sh:path on a property 
 shape: 
at 
 org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:285)
at 
 org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:214)
at 
 org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:196)
at 
 org.apache.jena.shacl.parser.ShapesParser.parseRootShape(ShapesParser.java:140)
at 
 org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:84)
at org.apache.jena.shacl.Shapes.parse(Shapes.java:55)
 performing:
 Shapes shapes = Shapes.parse(testGraph);
 on the graph:
 bds:ContentLocationShape
   a sh:NodeShape ;
   sh:property bds:ContentLocationShape-contentLocationStatement ;
   sh:targetClass bdo:ContentLocation .
 In the above graph there are no triples with
 bds:ContentLocationShape-contentLocationStatement
 as subject so the Shapes.parse raises an exception which seems reasonable; 
 however, the message should refer to the missing definition of a putative 
 PropertyShape reference rather than to the NodeShape that contains the 
 reference.
 In the simple case above it’s trivial by a casual inspection what the 
 problem is, but when there are a large number of PropertyShape refs and 
 all that the message says is that the NodeShape doesn’t have an sh:path, 
 its pretty opaque as to what the problem is.
 Maybe there’s a way to improve the exception message?
 Thanks,
 Chris

Re: misleading parse exception message in Shacl.

[Andy Seaborne]

Be interested to hear experiences using SHACL Compact Syntax.

It's Lang.SHACLC

SHACL-CS doesn't cover all SHACL but what it does cover is easier to 
read and write.


1/ What is missing from SHACL-CS from your perspective?
2/ Is it, in fact, actually helpful for managing SHACL at scale or not?

Andy

https://w3c.github.io/shacl/shacl-compact-syntax/


On 16/07/2020 22:31, Chris Tomlinson wrote:

Andy,

That's great news! Updating to 3.16.0 is on the ToDo list. I'm moving it to the 
top.

Thanks very much,
Chris


On Jul 16, 2020, at 16:20, Andy Seaborne  wrote:

Fixed in 3.16.0:

"shacl parse" gives:

No sh:path on a property shape: node= 
sh:property 

when there exists at least one triple with
bds:ContentLocationShape-contentLocationStatement as subject

and

Missing property shape: node= sh:property 


if there are none:


(and no stacktraces)

but what you show if 3.15.0.

Test RDF::

PREFIX rdf: 
PREFIX rdfs:
PREFIX sh:  
PREFIX xsd: 

PREFIX bds: 
PREFIX bdo: 

bds:ContentLocationShape
  a sh:NodeShape ;
  sh:property bds:ContentLocationShape-contentLocationStatement ;
  sh:targetClass bdo:ContentLocation .

#bds:ContentLocationShape-contentLocationStatement rdf:type sh:PropertyShape .



On 16/07/2020 21:44, Chris Tomlinson wrote:
Hi,
I’ve gotten a parse exception:
org.apache.jena.shacl.parser.ShaclParseException: No sh:path on a property shape: 

at 
org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:285)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:214)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:196)
at 
org.apache.jena.shacl.parser.ShapesParser.parseRootShape(ShapesParser.java:140)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:84)
at org.apache.jena.shacl.Shapes.parse(Shapes.java:55)
performing:
Shapes shapes = Shapes.parse(testGraph);
on the graph:
bds:ContentLocationShape
   a sh:NodeShape ;
   sh:property bds:ContentLocationShape-contentLocationStatement ;
   sh:targetClass bdo:ContentLocation .
In the above graph there are no triples with
bds:ContentLocationShape-contentLocationStatement
as subject so the Shapes.parse raises an exception which seems reasonable; 
however, the message should refer to the missing definition of a putative 
PropertyShape reference rather than to the NodeShape that contains the 
reference.
In the simple case above it’s trivial by a casual inspection what the problem 
is, but when there are a large number of PropertyShape refs and all that the 
message says is that the NodeShape doesn’t have an sh:path, its pretty opaque 
as to what the problem is.
Maybe there’s a way to improve the exception message?
Thanks,
Chris

Re: misleading parse exception message in Shacl.

[Chris Tomlinson]

Andy,

That's great news! Updating to 3.16.0 is on the ToDo list. I'm moving it to the 
top.

Thanks very much,
Chris

> On Jul 16, 2020, at 16:20, Andy Seaborne  wrote:
> 
> Fixed in 3.16.0:
> 
> "shacl parse" gives:
> 
> No sh:path on a property shape: node= 
> sh:property 
> 
> when there exists at least one triple with
> bds:ContentLocationShape-contentLocationStatement as subject
> 
> and
> 
> Missing property shape: node= 
> sh:property 
> 
> if there are none:
> 
> 
> (and no stacktraces)
> 
> but what you show if 3.15.0.
> 
> Test RDF::
> 
> PREFIX rdf: 
> PREFIX rdfs:
> PREFIX sh:  
> PREFIX xsd: 
> 
> PREFIX bds: 
> PREFIX bdo: 
> 
> bds:ContentLocationShape
>  a sh:NodeShape ;
>  sh:property bds:ContentLocationShape-contentLocationStatement ;
>  sh:targetClass bdo:ContentLocation .
> 
> #bds:ContentLocationShape-contentLocationStatement rdf:type sh:PropertyShape .
> 
> 
>> On 16/07/2020 21:44, Chris Tomlinson wrote:
>> Hi,
>> I’ve gotten a parse exception:
>> org.apache.jena.shacl.parser.ShaclParseException: No sh:path on a property 
>> shape: 
>>at 
>> org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:285)
>>at 
>> org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:214)
>>at 
>> org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:196)
>>at 
>> org.apache.jena.shacl.parser.ShapesParser.parseRootShape(ShapesParser.java:140)
>>at 
>> org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:84)
>>at org.apache.jena.shacl.Shapes.parse(Shapes.java:55)
>> performing:
>> Shapes shapes = Shapes.parse(testGraph);
>> on the graph:
>> bds:ContentLocationShape
>>   a sh:NodeShape ;
>>   sh:property bds:ContentLocationShape-contentLocationStatement ;
>>   sh:targetClass bdo:ContentLocation .
>> In the above graph there are no triples with
>> bds:ContentLocationShape-contentLocationStatement
>> as subject so the Shapes.parse raises an exception which seems reasonable; 
>> however, the message should refer to the missing definition of a putative 
>> PropertyShape reference rather than to the NodeShape that contains the 
>> reference.
>> In the simple case above it’s trivial by a casual inspection what the 
>> problem is, but when there are a large number of PropertyShape refs and all 
>> that the message says is that the NodeShape doesn’t have an sh:path, its 
>> pretty opaque as to what the problem is.
>> Maybe there’s a way to improve the exception message?
>> Thanks,
>> Chris

Re: misleading parse exception message in Shacl.

[Andy Seaborne]

Fixed in 3.16.0:

"shacl parse" gives:

No sh:path on a property shape: 
node= sh:property 



when there exists at least one triple with
bds:ContentLocationShape-contentLocationStatement as subject

and

Missing property shape: node= 
sh:property 



if there are none:


(and no stacktraces)

but what you show if 3.15.0.

Test RDF::

PREFIX rdf: 
PREFIX rdfs:
PREFIX sh:  
PREFIX xsd: 

PREFIX bds: 
PREFIX bdo: 

bds:ContentLocationShape
  a sh:NodeShape ;
  sh:property bds:ContentLocationShape-contentLocationStatement ;
  sh:targetClass bdo:ContentLocation .

#bds:ContentLocationShape-contentLocationStatement rdf:type 
sh:PropertyShape .



On 16/07/2020 21:44, Chris Tomlinson wrote:

Hi,

I’ve gotten a parse exception:

org.apache.jena.shacl.parser.ShaclParseException: No sh:path on a property shape: 

at 
org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:285)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:214)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:196)
at 
org.apache.jena.shacl.parser.ShapesParser.parseRootShape(ShapesParser.java:140)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:84)
at org.apache.jena.shacl.Shapes.parse(Shapes.java:55)
performing:

Shapes shapes = Shapes.parse(testGraph);

on the graph:

bds:ContentLocationShape
   a sh:NodeShape ;
   sh:property bds:ContentLocationShape-contentLocationStatement ;
   sh:targetClass bdo:ContentLocation .
In the above graph there are no triples with

bds:ContentLocationShape-contentLocationStatement

as subject so the Shapes.parse raises an exception which seems reasonable; 
however, the message should refer to the missing definition of a putative 
PropertyShape reference rather than to the NodeShape that contains the 
reference.

In the simple case above it’s trivial by a casual inspection what the problem 
is, but when there are a large number of PropertyShape refs and all that the 
message says is that the NodeShape doesn’t have an sh:path, its pretty opaque 
as to what the problem is.

Maybe there’s a way to improve the exception message?

Thanks,
Chris

misleading parse exception message in Shacl.

[Chris Tomlinson]

Hi,

I’ve gotten a parse exception:

org.apache.jena.shacl.parser.ShaclParseException: No sh:path on a property 
shape: 
at 
org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:285)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:214)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:196)
at 
org.apache.jena.shacl.parser.ShapesParser.parseRootShape(ShapesParser.java:140)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:84)
at org.apache.jena.shacl.Shapes.parse(Shapes.java:55)
performing:

Shapes shapes = Shapes.parse(testGraph);

on the graph:

bds:ContentLocationShape
  a sh:NodeShape ;
  sh:property bds:ContentLocationShape-contentLocationStatement ;
  sh:targetClass bdo:ContentLocation .
In the above graph there are no triples with  

bds:ContentLocationShape-contentLocationStatement 

as subject so the Shapes.parse raises an exception which seems reasonable; 
however, the message should refer to the missing definition of a putative 
PropertyShape reference rather than to the NodeShape that contains the 
reference.

In the simple case above it’s trivial by a casual inspection what the problem 
is, but when there are a large number of PropertyShape refs and all that the 
message says is that the NodeShape doesn’t have an sh:path, its pretty opaque 
as to what the problem is.

Maybe there’s a way to improve the exception message?

Thanks,
Chris