- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Wed, 12 Oct 2016 16:02:11 +0300
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
- Message-ID: <CA+u4+a0_P3M6zX+sv3JAWkZKdNuZ_WVDwT3C9Ox+-zphmBNozg@mail.gmail.com>
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> 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>> 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
> >
>
>
--
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 13:03:09 UTC