- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Wed, 12 Oct 2016 17:52:52 +0300
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
- Message-ID: <CA+u4+a2EQKeBpOdRHeLon6JVP+B+s+h9bG2zY4QQ43gdwpZgYA@mail.gmail.com>
On Wed, Oct 12, 2016 at 5:15 PM, Peter F. Patel-Schneider <
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>> 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>
> >
>
>
--
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 14:53:50 UTC