- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Thu, 13 Oct 2016 13:12:48 +0300
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
- Message-ID: <CA+u4+a0PELRZVzyGOKUT6AtVy3O_a9nXPnTK9cpwpBE+7PZvFg@mail.gmail.com>
Thank you Peter, I further refined the definitions (see inline)
https://github.com/w3c/data-shapes/commit/15b0db419d2bec2fbb621ec2485c063d036cd52d
On Wed, Oct 12, 2016 at 7:19 PM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:
>
> 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?
>
Yes, as this is my understanding from the discussion we had with the WG
Unless I misinterpreted something
Best,
Dimitris
>
>
> 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
> >
>
>
--
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 Thursday, 13 October 2016 10:14:01 UTC