Re: on property paths in SHACL

"A SHACL property path p is represented by an IRI or a blank node that is
mapped to a SPARQL property path when it satisfies the antecedent of one of
the following rules:"

The meaning of this sentence is very hard to decipher.  My guess is that it
means something like:
1/ A SHACL property path *is* a node in an RDF graph that matches the
antecedent of one of the following rules, except for nodes that are somehow
recursive.
2/ The mapping from SHACL property paths to SPARQL property paths is defined
by the following rules.
The sentence needs to be revised to better state this meaning.

"A node p is not a SHACL property path if p is a blank node and any nested
path constructs of p directly or transitively reference p."  There is no
definition of 'nested path constructs' here.  A better way to say this is needed.

The definition of members of a SHACL list needs to say that an empty list has
no members.  The definition should also not use must not (even in lower case).
 Instead use "cannot".

The following is a valid SHACL property list

[ rdf:first ex:p1 ;
  rdf:rest [ rdf:first ex:p2 ;
             rdf:rest rdf:nil ] ;
  rdfs:comment "ex:p1 followed by ex:p2" ] .

The following is a valid SHACL property list

[ rdf:first ex:p1 ;
  rdf:rest [ rdf:first ex:p2 ;
             rdf:rest rdf: nil ] ;
  sh:inversePath ex:p3 ] .

The following is a valid SHACL property list

[ sh:inversePath [] ] .

The following is not a valid SHACL property lis

[ sh:alternativePath ( ex:p1 ex:p2 ) ;
  rdfs:comment "Either p1 or p2" ]

Are these all as intended?  If not, changes need to be made to the rules.

The mapping does not apply within property paths, so the mapping of
( ex:p1 ( ex:p2 ex:p3 ) )
is
SequencePath ex:p1 <blank node for the interior list>

The section uses SPARQL property path expression names in some places and
property path syntax in others.  This is only going to cause confusion.  Use
only one of these throughout the document.


The [] sh:path in the example just confuse matters.

The section has multiple ways to describe the relationship between SHACL
property paths and SPARQL property paths.  It should use only one.


Embedding syntax within RDF graphs is a very tricky matter, but one that needs
to be done perfectly and clearly in specifications.  Otherwise there will be
many unpleasant surprises.



peter


On 11/28/2016 06:12 AM, Dimitris Kontokostas wrote:
> Thank you again for your feedback Peter,
> 
> Could you please check again if you find any other issues on the definition of
> property paths?
> 
> Best,
> Dimitris
> 
> On Mon, Nov 21, 2016 at 6:50 PM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> 
>     There are still several problems:
> 
>     1/ Although the intent of "in the given order" is somewhat clear, it doesn't
>     really say what is needed, which is something along the lines that the first
>     applicable rule wins.  It would be better to use "otherwise" for each rule.
>     (Except that many or all otherwises are not allowed, but this is only
>     forbidden in a cryptic note.)   It would be much better to say all this
>     explicitly at each rule, like "If p is a blank node that is the subject of
>     exactly one triple with predicate rdf:first and one triple with predicate
>     rdf:rest and no other triples, then ..." and "If p is a blank node that is the
>     subject of exactly one triple with predicate sh:inversePath and no other
>     triples, then ...".)
> 
>     2/ The definition of RDF list is inadequate as it allows for circular lists.
>     As well, the order of the members of a list is not defined.
> 
>     3/ The rules allow for something that has multiple values for rdf:first and
>     one value for sh:alternativePath.  It would be better to make this case
>     illegal.  Similarly for other places that say "exactly one value for".
>     (Except that this is illegal from the cryptic note.  See above.)
> 
>     The ,, needs to be remove from the first "Note" sentence.  The second "Note"
>     sentence should not be a note as it is part of the core of path processing.
>     The first clause should be rolled into the definition of a SHACL property
>     path, like "A *SHACL property path" p is an IRI or blank node that satisfies
>     the antecedent of one of the following rules:"  The second clause should be
>     made more explicit.  The third clause should be distributed over the various
>     rules.
> 
> 
>     peter
> 
> 
> 
> 
>     On 11/21/2016 02:08 AM, Dimitris Kontokostas wrote:
>     > Dear Peter,
>     >
>     > Thank you for your feedback on property paths.
>     > Can you please check if you have further comments on this section?
>     > We tried to also cover other comments you had on the equivalency of property paths
>     >
>     > http://w3c.github.io/data-shapes/shacl/#path-syntax
>     <http://w3c.github.io/data-shapes/shacl/#path-syntax>
>     >
>     > Best regards,
>     > Dimitris
>     >
>     > On Fri, Sep 23, 2016 at 5:25 PM, Peter F. Patel-Schneider
>     > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>
>     <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>> wrote:
>     >
>     >     Following up one of the recent responses to my comments on Shapes
>     Constraint
>     >     Language (SHACL) lead me to look at how property paths work in Shapes
>     >     Constraint
>     >     Language (SHACL), W3C Editor's Draft 22 September 2016.
>     >
>     >
>     >     The definition of property paths includes:
>     >     "A valid SHACL property path p is represented by an IRI or a blank
>     node that
>     >     can be correctly traversed recursively using the following rules."
>     >
>     >     The use of "recursively" is incorrect here.  There is no need to use a
>     >     recursive process here at all.  The use of "traversed" is incorrect
>     here.
>     >     There is no need to traverse anything here at all.
>     >
>     >     A much better wording is
>     >     "A valid SHACL property path p is represented by an IRI or a blank
>     node that
>     >     satisfies the following conditions."
>     >
>     >     It is possible for a node to both be a valid property path and an
>     invalid
>     >     property path, which does not seem to make any sense.
>     >
>     >     It is possible for a non-invalid property path to satisfy both rule
>     4 and
>     >     one of the other rules. What happens then?
>     >
>     >     The definition of property paths contains a use-mention error.  A
>     property
>     >     path is represented by a node but then the path itself is treated as
>     if it
>     >     were a node in an RDF graph.
>     >
>     >     As a not-invalid property path cannot have multiple outgoing edges it is
>     >     hard to add extra information to property paths.
>     >
>     >     The SPARQL path resulting from rule 2 is not defined.  As well,
>     "value of
>     >     path" is not defined.   It appears that the intent is that p itself
>     is an
>     >     RDF list, but that would make p be an invalid SHACL property path.
>     >
>     >     The entire section needs to be completely rewritten.
>     >
>     >
>     >
>     >     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
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>

Received on Monday, 28 November 2016 14:57:52 UTC