- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 12 Oct 2016 07:15:36 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
The alternative approach you describe appears to be that sh:hasShape would
produce an error if the node that it is given cannot be otherwise determined
to be a shape. This seems to me to be a much better solution than the
current one. Although there may be a small implementation burden, this
approach has the twin decided benefits of permitting implementations that
transform shapes before verification time and also detecting what would
otherwise be very difficult-to-detect mistakes in shapes graphs. Even if
the implementation burden were quite large these benefits would outweigh it.
However, there still remains the problem of just what a shape is. With this
approach the wording on shapes would say something like:
"2. Shapes
A shape is a node in a shapes graph that is a SHACL instance of sh:Shape or has
an expected type of sh:Shape."
As far as I can tell this means that there are the following ways to be a shape:
1/ Be a SHACL instance of sh:Shape.
2/ Be the object of a triple with predicate sh:not or sh:shape or
sh:qualifiedValueShape.
3/ Be a member of a list that is the object of a triple with predicate
sh:and or sh:or.
Consider the following shapes graph:
sh:s1 rdf:type sh:Shape ;
sh:property [ sh:predicate ex:p ;
sh:shape sh:s3 ;
sh:or ( sh:s4 _:b 7 "shape" ) ] ;
sh:s2 rdf:type [ rdfs:subClassOf sh:Shape ] .
_:x sh:shape sh:s5 ;
sh:or ( sh:s6 sh:s7 ) .
sh:s11
sh:property [ rdf:type sh:PropertyConstraint ;
sh:predicate ex:q ;
sh:shape sh:s8 ;
sh:or ( sh:s9 sh:s10 ) ] .
As far as I can tell, the shapes in this shapes graph under this alternative
approach *and* under the current editors' draft of 12 October 2016 would be
sh:s1, sh:s2, sh:s3, sh:s4, _:b, 7, "shape", sh:s5, sh:s6, and sh:s7, sh:8,
sh:9, and sh:10.
Is this what is intended?
I do recollect that there has been considerable antagonism in the working
group to using RDFS reasoning for anything related to SHACL even though
SHACL was doing quite a bit that is close to RDFS reasoning and is now doing
even more that it is very close to RDFS reasoning.
So the difference between "value type" and "expected type" is described here:
"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
restrictions."
I certainly read this as saying that value type implies expected type. It
is also quite obscure that this implication is only in constraints.
Peter F. Patel-Schneider
Nuance Communications
On 10/12/2016 06:02 AM, Dimitris Kontokostas wrote:
> Thank you again for your feedback Peter, see inline for some comments
>
> On Tue, Oct 11, 2016 at 7:37 PM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>
> 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.
>
>
> An alternative, which I would be in favor for, would be to require the input
> to sh:hasShape to be a shape.
> This would make SHACL Full behave the same as SHACL Core however, this will
> require many additional checks in every sh:hasShape invocation and is not
> implementation friendly.
>
>
> 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.
>
>
> This is correct from my understanding as well, even if the argument is gone
> now, access to the shapes graph is required for sh:hasShape to work as defined
>
>
> 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
> questions.
>
>
> "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?
>
>
> If I remember correctly this was discussed in a telco where you were also
> present and we decided to come up with a related wording for the values of
> sh:property.
> Since this is a recurring pattern we defined this new term.
> Regarding rdfs:range, indeed this is almost the same behavior but the WG very
> early decided to not use RDFS reasoning in SHACL so it is redefined
>
>
> 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
> constraint."
>
> This appears to be redundant - see the comment on the wording for
> sh:hasShape.
>
> "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
> restrictions."
>
> Is there any difference between "Value Type" and "expected type"? If not,
> why not just use expected type? If so, what is the difference?
>
>
> This was a typo, should be expected value type.
> There is indeed some repetition here but if I am not mistaken, value type talk
> about the expected value types of some properties when these are used as
> parameters of constraint components
> while expected types are global (in the shapes graph)
> Value types also server as user guides while expected type for SHACL Processors
> We will discuss if we should define value type in the terminology section as well
>
>
> "The objects of triples with sh:not as predicate have sh:Shape as expected
> type.
> Constraint Component IRI: sh:NotConstraintComponent
> Parameters:
> 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.
>
>
> I believe the intent here is different since SPARQL functions are more strict
> on the type of the arguments they accept.
>
> Best regards,
> Dimitris
>
>
>
>
> 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>
> <mailto: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
> <http://aksw.org/DimitrisKontokostas>
> > Research Group: AKSW/KILT http://aksw.org/Groups/KILT
> >
>
>
>
>
> --
> 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
> <http://aksw.org/DimitrisKontokostas>
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
> <http://aksw.org/Groups/KILT>
>
Received on Wednesday, 12 October 2016 14:16:12 UTC