W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > September 2016

on classes from the SHACL vocabulary

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Thu, 29 Sep 2016 18:24:45 -0700
To: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
Message-ID: <eba56d7a-de1c-5639-8bda-c9578a34a2c3@gmail.com>
The SHACL document mentions several classes that are in the SHACL
vocabulary.  These classes appear to have quite a few surprising aspects,
including the ability to recognize nodes that don't have any outgoing
rdf:type links.

There are several different ways of describing the classes that indicate that
there are significant differences in their relationship to their instances.
This is surprising.


Relevant quotes from the SHACL document:

"A shape is a node in a shapes graph that is typically a SHACL instance of
sh:Shape."

OK, so far, but a bit weird.  What happens if a shape is not a SHACL
instance of sh:Shape?

"When, in the shapes graph, a shape is a SHACL instance of both sh:Shape and
rdfs:Class then the shape is a class target of itself."

Does this happen here?
  ex:s1 rdf:type sh:Shape ;
    sh:shape ex:s2 .
  ex:s2 rdf:type rdfs:Class ;
    sh:nodeKind sh:IRI .

"[...] sh:Constraint is the SHACL superclass of all constraint types."

What does this mean?  Every constraint type?  Just SHACL constraint types?
Just the SHACL constraint types mentioned in this document?

This is different than is the case for shapes.  Is there a reason for the
difference?

"sh:PropertyConstraint is the class of property constraints.  A SHACL
processor treats all values of sh:property as property constraints. Thus,
the values of sh:property do not require the rdf:type sh:PropertyConstraint
triple."

Hmm, this is a special relationship then, neither SHACL type, nor RDF type,
nor RDFS type (although this one might be close).

"The class sh:Shape is defined as rdfs:subClassOf sh:Constraint."

What happens for shapes that are not SHACL instances of sh:Shape?  Are they
SHACL instances of sh:Constraint?

"Validation results must be SHACL instances of the class
sh:ValidationResult. Its SHACL superclass, sh:AbstractResult, defines the
properties described in the following sub-sections. SHACL implementations
may produce SHACL instances of other SHACL subclasses of sh:AbstractResult,
for example to report successfully completed constraint checks or
accumulated results."

Is sh:AbstractResult doing anything useful?

"In particular, for sh:PropertyConstraints, the variable PATH is
substituted with a path expression based on the values of either
sh:predicate or sh:path in the constraint."

What does "sh:PropertyConstraints" mean here?  Suggest use "property
constraints" instead.

"Constraint Component: sh:ClassConstraintComponent
Parameters:
Property 	Value Type 	Summary
sh:class 	rdfs:Resource 	Type of all value nodes"

Also for other constraint components.

No problems concerning constraint components so far.

"The values of sh:nodeKind must be one of the following six instances of the
class sh:NodeKind: sh:BlankNode, sh:IRI and sh:Literal as well as the
following values that represent combinations of the former three,
i.e. either-or: sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral and
sh:IRIOrLiteral."

No problems here.

"Constraint Component: sh:AndConstraintComponent
Parameters:
Property 	Value Type 	Summary
sh:and 	rdf:List (members: sh:Shape) 	List of shapes to validate the value
nodes against"

What effect does this have on members of the parameter values?  Do they
"become" instances of sh:Shape?  SHACL instances of sh:Shape?  RDFS instances?

A few other constraint components also use sh:Shape, and have the same issue.

"Property constraints may link to an SHACL instance of the class
sh:PropertyGroup using the property sh:group to indicate that the constraint
belongs to a group of related property constraints."

No problem here.

"sh:SPARQLConstraint is an rdfs:subClassOf sh:Constraint and is the class of
all SPARQL-based constraints."

What kind of relationship is being used here?  How can sh:SPARQLConstraint
be the class of *all* SPARQL-based constraints?  The following example
indicates that there might not be any path from a SPARQL constraint to
sh:SPARQLConstraint but there is no wording like for sh:PropertyConstraint.

"sh:ConstraintComponent is the SHACL class of all constraint components.
Each constraint component must define:
    one or more parameters (e.g. sh:class, sh:stem)
    at least one validator"

So even the constraint components in the core of SHACL belong to this class
(somehow) and have to have a validator?

"shimpl:hasPattern
	a sh:SPARQLAskValidator ;"

"Each parameter must be a SHACL instance of sh:Parameter, but the rdf:type
triples can be omitted."

If there are no rdf:types how can the parameter be a SHACL instance of
anything?

"Each sh:Parameter must" -> "Each parameter must"
"Every sh:ConstraintComponent must" -> "Every constraint component"

"The class sh:Parameter is defined as a SHACL subclass of
sh:PropertyConstraint, and all properties that are applicable to property
constraints may also be used for parameters."

Looks OK.

"Validators that have the rdf:type sh:SPARQLSelectValidator"

Can they also have an rdf:type value that is a SHACL (?) subclass of
sh:SPARQLSelectValidator?

"Furthermore, a sh:SPARQLSelectValidator" -> "Furthermore, a SPARQL select
validator"

"Validators that have the rdf:type sh:SPARQLAskValidator"

As above.

"Template for sh:Shape context:"
"Template for sh:PropertyConstraint context:"

Contexts are not really defined in the document.

"SPARQL-based targets must be SHACL instances of sh:SPARQLTarget, which is a
SHACL subclass of sh:Target."

OK, I guess.

"The class sh:TargetType can be used to define high-level vocabularies for
targets."

OK, I guess.

"The class sh:SPARQLTargetType is an rdfs:subClassOf sh:TargetType for
target types that define a SPARQL SELECT query via the property sh:select."

OK, I guess, but could be worded better.

"The values of sh:derivedValues must be SHACL instances of a SHACL subclass
of sh:ValuesDeriver. sh:SPARQLValuesDeriver is the only SHACL subclass of
sh:ValuesDeriver defined by SHACL Full."

So the only useful one here is sh:ValuesDeriver.  Get rid of
sh:ValuesDeriver.

"Each sh:SPARQLValuesDeriver" -> "Each SHACL instance of ..."

"Functions that encapsulate a SPARQL query must be SHACL instances of
sh:SPARQLFunction, which is a SHACL subclass of the more general class
sh:Function."

So sh:Function doesn't add any utility.  Get rid of it.

"The parameters of a function are linked to its sh:Function via the property
sh:parameter." -> ""The parameters of a function are linked from(?) its
function via the property sh:parameter."

"Each parameter must be a SHACL instance of sh:Parameter, but their rdf:type
triple can be omitted."

Are these parameters different from the ones from previous sections?

"Each sh:Parameter" -> "Each parameter"

"There must not be any other declared sh:Parameter" -> "There must not be
any other parameter"

"Each sh:Parameter" -> "Each parameter"

"SHACL instances of sh:SPARQLFunction must have exactly one value for either
sh:ask or sh:select"

OK




Peter F. Patel-Schneider
Nuance Communications
Received on Friday, 30 September 2016 01:25:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:44 UTC