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

Re: on what is a shape

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Tue, 11 Oct 2016 09:37:14 -0700
To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Cc: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
Message-ID: <f77a6bf6-bdf7-af4b-32d4-f4bd77e24a4d@gmail.com>
So in SHACL Full there is no way of determining the shapes in a shapes graph
without actually running SPARQL code.  This appears to eliminate the
possibility of somehow compiling shapes in SHACL Full before validation
time.  I am rather disappointed that this kind of implementation appears to
be precluded.  It also appears to require access to the entire shapes graph
at validation time in SHACL Full, which appears to go counter to making
access to the shapes graph optional.

Expected type would be a new significant aspect of SHACL - comprising
a decided change to the SHACL language.  This leads to a number of new

"Expected Type
In a shapes graph, the values of a property or a property path can have an
expected type. These nodes are treated as instances of specific classes,
even when these nodes are not SHACL instances of these classes. For example,
the objects of triples with sh:shape as predicate have sh:Shape as expected
type and there does not need to be a triple with the object node as the
subject, rdf:type as predicate and sh:Shape as object in the shapes graph."

This appears to be just like rdfs:range.  Why then not use RDFS reasoning to
get the effect that appears to be desired?

Instance is undefined here.

"2. Shapes
A shape is a node in a shapes graph that is a SHACL instance of sh:Shape or
the expected type of the node is sh:Shape, or is provided as input in the
second argument of the sh:hasShape function through the evaluation of a

This appears to be redundant - see the comment on the wording for

"Note that the parameter tables in each of the following sections have a
column called Value Type which indicates the expected type of the parameter
values for documentation purposes, without enforcing any formal

Is there any difference between "Value Type" and "expected type"?  If not,
why not just use expected type?  If so, what is the difference?

"The objects of triples with sh:not as predicate have sh:Shape as expected type.
Constraint Component IRI: sh:NotConstraintComponent
Property 	Value Type 	Summary
sh:not	 	sh:Shape 	The shape to negate"

Why bother giving both expected type and Value Type?  Similarly for sh:and,
sh:or, sh:shape, and sh:qualifiedValueShape.

"A. The Function sh:hasShape
Issue 131: sh:hasShape
The following definition is under discussion.

SHACL Full processors must implement the function sh:hasShape, which takes
the following parameters:
Parameter 	Node Kind 	Summary
focusNode 	Any 	The focus node to validate.
shape 	IRI or blank node 	The shape to validate the focus node against."

Why not use value type or expected type here?
Why the new requirement that the first argument cannot be a literal.  Up to
now there was no such requirement.

Peter F. Patel-Schneider
Nuance Communications

On 10/11/2016 08:01 AM, Dimitris Kontokostas wrote:
> Dear Peter, thank you for your comments
> note that this is an unofficial response that is not necessarily endorsed by
> the WG
> We updated the definition of a shape can you check if this looks good to you now?
> based on your question, you are right, there is no way to determine if a node
> is a shape when the sh:hasShape SPARQL function is used.
> This is evaluated during runtime and unless one uses a customised SPARQL
> engine there is no way to get this information back from a SHACL Processor.
> Best,
> Dimitris
> On Tue, Oct 4, 2016 at 8:25 PM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>     Just what are shapes?
>     The terminology section says:
>     "Shape
>     A shape is a node in a shapes graph that is typically a SHACL instance of
>     sh:Shape. A shape provides a collection of targets, filters, constraints and
>     parameters of constraint components that specify how a data graph is
>     validated against the shape. Shapes can also provide non-validating
>     information, such as labels and comments."
>     Section 2 says:
>     "Shapes define constraints that a set of focus nodes can be validated
>     against."
>     This doesn't, however, provide guidance in determining what the shapes in a
>     shapes graph are.
>     Consider the following shapes graph:
>     [prefix stuff as needed]
>     s:s1 a sh:Shape ;
>       sh:targetClass ex:c1 ;
>       sh:nodeKind sh:IRI ;
>       ex:p ex:q .
>     s:s2 a sh:Shape ;
>       sh:targetClass ex:c1 ;
>       ex:p ex:q .
>     s:s3 a sh:Shape ;
>       sh:nodeKind sh:IRI ;
>       ex:p ex:q .
>     s:s4 a sh:Shape ;
>       ex:p ex:q .
>     s:s5 sh:targetClass ex:c1 ;
>       sh:nodeKind sh:IRI ;
>       ex:p ex:q .
>     s:s6 sh:targetClass ex:c1 ;
>       ex:p ex:q .
>     s:s7 sh:nodeKind sh:IRI ;
>       ex:p ex:q .
>     s:s8 ex:q ex:p .
>     s:s9 a sh:Shape ;
>       sh:targetClass ex:c1 ;
>       sh:sparql [
>         sh:select
>           ""SELECT $this WHERE {
>            GRAPH $shapesGraph { $currentShape ex:p ?shape }
>            BIND (sh:hasShape($this, ?shape) AS ?hasShape)
>            BIND (!bound(?hasShape) AS ?failure) .
>            FILTER (?failure || ?hasShape) . }""" ] ;
>       ex:p ex:q .
>     s:s10 rdf:type sh:Shape ;
>       sh:targetClass ex:foo ;
>       sh:sparql [
>         sh:select
>           """SELECT $this WHERE {
>             $this s:shape ?shape ;
>             BIND (sh:hasShape($this,?shape,$shapesGraph) AS ?hasShape)
>             BIND (!bound(?hasShape) AS ?failure )
>             FILTER (?failure || !?hasShape) }""" ] .
>     Which of the ex:si are shapes and which are not shapes?  Are there any nodes
>     in the graph besides the ex:si that are shapes?
>     Peter F. Patel-Schneider
>     Nuance Communications
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Tuesday, 11 October 2016 16:38:17 UTC

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