limiting ill-formed nodes in SHACL

It appears that SHACL defines ill-formed nodes too broadly.

Currently the graph

ex:s1 rdf:type sh:NodeShape ;
 sh:targetClass ex:C1 ;
 sh:class ex:C2 .

ex:s2 sh:class 5 .

appears to contain an ill-formed node because an object of a triple with
property sh:class is not an IRI.  Validation results when using this graph
thus appear to be undefined.

It would be better to limit these requirements to situations where the
subject of the triple is a shape.


Currently the graph

ex:s1 rdf:type sh:NodeShape ;
 sh:targetClass ex:C1 ;
 sh:pattern "(" .

contains an ill-formed node because the value of ex:s1 for sh:pattern is not
a valid pattern argument for the SPARQL REGEX function.  Validation results
when using this graph are thus undefined.

It would be better to just require that the values of shapes for sh:pattern
be strings and handle the possible errors produced like SPARQL errors are
handled elsewhere in SHACL.


Currently the graph

ex:s1 rdf:type sh:NodeShape ;
 sh:targetClass ex:C1 ;
 sh:class ex:C2 .

ex:s2 sh:node ex:s3 .

ex:s3 sh:path ex:p1 .

contains an ill-formed node because ex:s3 is a node shape and it has a value
for sh:path.  Validation results when using this graph are thus undefined.

It would be better if objects of triples with properties like sh:node only
made their objects shapes if the subject of the triple was already a shape.
A suitable inductive definition of shapes that does the right thing is easy
to produce.


Limiting ill-formed nodes expands the number of graphs that have defined
behaviour in SHACL without appreciably increasing the complexity of the
language.


Peter F. Patel-Schneider
Nuance Communications

Received on Sunday, 26 February 2017 20:41:41 UTC