- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 12 Oct 2016 09:19:24 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
The new wording exposes the following problem:
"Expected Type
In a shapes graph, the non-lieral values of a property or a property path
can have an expected type. These nodes are treated as RDFS 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."
"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"
"The objects of triples with sh:not as predicate have sh:Shape as expected
type."
Consider
s:s1 rdf:type sh:Shape ,
sh:property [ sh:predicate ex:p ;
sh:not "shape" ] .
Here "shape" has sh:shape as expected type but doesn't seem to be suitable
to have an expected type at all.
In the example below, I'm assuming that you also don't want 7 to be a shape.
In the example below, you appear to be saying that any non-literal object of a
sh:not triple has expected type sh:Shape, no matter whether that triple has a
subject that is a constraint or not. Is this the case?
Peter F. Patel-Schneider
Nuance Communications
On 10/12/2016 07:52 AM, Dimitris Kontokostas wrote:
>
>
> On Wed, Oct 12, 2016 at 5:15 PM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>
> 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.
>
>
> I will create an issue for the WG to decide on this
>
>
> 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?
>
>
> While you were writing this email I already identified this issue and adjusted
> the definition of "Expected type" to remove literal values
> if you remove "shape" your list is correct
>
>
> 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.
>
>
> in my last reply I marked this as a typo and already replaced it with
> "indicates the expected value type"
> is this still not clear? Do you think another name would be more appropriate?
>
>
> 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>
> <mailto: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>>
> > <mailto: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>
> > <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>
> > <http://aksw.org/DimitrisKontokostas <http://aksw.org/DimitrisKontokostas>>
> > Research Group: AKSW/KILT http://aksw.org/Groups/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
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>
Received on Wednesday, 12 October 2016 16:20:12 UTC