Re: SHACL draft ready for review

Many thanks, Olivier. Responses inline.

Resulting edits have been committed to the current editor's draft:

     http://w3c.github.io/data-shapes/shacl/

If you have any specific follow-up comments that may lead to longer 
discussions, please feel free to move them into separate response emails 
with a different subject line.

Thanks,
Holger


On 7/02/2017 18:30, Olivier Corby wrote:
> Hi,
>
> Some comments abouthttp://w3c.github.io/data-shapes/shacl/
>
> Regards,
>
> Olivier
>
>
>
>
> 1.1 Terminology
>
> if there is no rule to make *a* some situation true

Fixed.

>
>
>
> SHACL supports a subset of the property path *syntax* from SPARQL 1.1
>
> -- not  syntax but language (or expressions)

I have taken that whole sentence out - it was redundant as a similar 
sentence exists in 2.3.1

>
>
>
> SHACL List
>
> and the list does not have itself as a value of the property path 
> rdf:rest+ in G.
>
> -- and rdf:first ?

I don't see why rdf:first would be relevant here (in the definition of 
non-recursive lists). rdf:first is just a member of the list. Could you 
clarify if I am missing something?

>
>
>
> SHACL type
>
> -- is it a set ?

Yes (all <a>values</a> of a property form sets). I have inserted that 
term "set" into the definition for extra clarity.

>
>
> SHACL Class
> Nodes in an RDF graph that are subclasses, superclasses, or types of 
> nodes in the graph are *often* referred to as SHACL class.

I have removed "often".

>
>
> SHACL Core
> SHACL-SPARQL
>
> I would use SHACL SPARQL without "-"

To me, SHACL SPARQL is too disconnected, and sounds more like a 
variation of SPARQL than a SHACL dialect. Are there other names that 
make this clearer? E.g. SHACL+SPARQL or SHACL/SPARQL. Note that there 
may be SHACL-JS in the future, so whatever pattern we apply here may 
multiply.

>
>
>
> In the introduction I would add :
>
> The syntax of SHACL is RDF,  Turtle syntax is used in this document.
> Other RDF syntax can be used as well: RDF/XML, JSON-LD.

Since Turtle was already references in the Document Outline, I have 
extended that to read

   The syntax of SHACL is RDF.
   The examples in this document use Turtle [[!turtle]] and (in one 
instance) [[json-ld]].
   Other RDF serializations such as RDF/XML may be used in practice.


>
>
>
> Validation report :
> results are blank nodes, are  URI  possible ?

Yes, URIs can be used in the results graph. Is this stated differently 
anywhere?

>
> What when result value is a bnode ?

The SHACL spec only speaks about RDF terms. The same blank node (term) 
may appear as node in multiple graphs. This linkage may of course get 
lost of such nodes are serialized (e.g. Turtle would remove the fact 
that the two nodes were the same term).

In practice this means that the if the results graph contains bnodes 
(e.g. as value of sh:value or sh:focusNode) then a consumer should not 
go through a serialization step before processing the results.

>
>
>
>
>
> 2. Shapes and Constraints
>
> A sentence would be welcome to talk about SHACL and OWL:

The WG had long discussions about the role of inferencing, as summarized 
in section 1.5.
SHACL only depends on RDF but is orthogonal to OWL. It is also 
orthogonal to RIF or other W3C standards.

In practice, if someone wants to operate on a graph with OWL inferences 
on, she is welcome to do that. The SHACL processor would simply see 
additional triples, but doesn't have any special treatment of OWL IRIs 
apart from a minor role of owl:imports which we chose to keep in because 
it's well established to declare linkage between graphs.

>
> sh:targetClass : rdfs:Class
> What about owl:Class and OWL entailment ?
>
> what about cardinality constraints in presence of owl:sameAs and OWL 
> entailment
> what about owl:equivalentClass, owl:equivalentProperty ?
>
> sh:targetObjectsOf : rdf:Property
> What about owl:ObjectProperty, owl:DatatypeProperty

owl:Class is a subclass of rdfs:Class, so assuming that these "system 
triples" are present, then members of owl:Class are SHACL instances of 
rdfs:Class and are valid values of sh:targetClass property

Similarly, for owl:ObjectProperty, owl:DatatypeProperty.

OWL entailment is not required for this.

For other OWL axioms, OWL entailment may be necessary.



>
>
>
> 2.1.1 Constraints, Parameters and Constraint Components
>
> Why not just Constraint  and not both Constraints and Constraint 
> Components
>
> The distinction between Shape, Constraint and Constraint Component is 
> not simple

Yes, there is a certain complexity in SHACL. The WG found this 
complexity was necessary to have a clean and extensible language design. 
Constraint Components are building blocks that are used to declare 
specific constraints. Much like with OWL, there is, for example, 
owl:minCardinality axiom that has defined semantics and is expected to 
be used with an integer value and then, there is a use of it in a 
specific restriction where it is given a value.

>
>
> A shape in a shapes graph declares a constraint of *type* c
>
> -- is it rdf:type ?

No, the word *type* here is used in a general sense of the word. If you 
have specific suggestions on how to make it clearer, please let us know.

>
>
>
> I would add a sentence to state that the validation process starts 
> with shapes with targets.

Other reviewers requested explicitly to downplay these procedural 
notions in the spec, leaving it up to the implementers of how to select 
focus nodes for a given shape. Note for example that ShEx does not have 
the concept of target nodes, and some design decisions of the SHACL WG 
should be regarded as attempts to bring together different viewpoints.

>
>
>
>
> 2.1.3.1 Node targets (sh:targetNode)
>
> Each value of sh:targetNode is either an IRI or a literal.
>
> -- contradicts sh:targetNode any (in 2. Shapes and Constraints)

Thanks, diagram updated to clarify this.

>
>
>
>
> 2.1.3.2 Class-based Targets (sh:targetClass)
>
>
> sh:targetClass may tolerate bnode for future use with OWL ?
> sh:targetClass [ owl:intersectionOf ex:A ex:B ]

The sh:targetClass triples are stored in the *shapes graph*. In order to 
find matching instances, the exact same blank node would have to be used 
in the *data graph*, via rdf:type. So the scenarios you describe would 
require that shapes graph == data graph. In my personal opinion, 
allowing bnodes here would be promoting a bad practice, because the OWL 
ontology developer can just as well turn the owl:intersectionOf into a 
IRI class.

If, following my clarification, you still believe that this should be 
changed, please let me know and we will discuss it within the WG.

>
>
>
>
> 2.1.3.3 Implicit Class Targets
>
> unclear with  sh:PropertyShape
> give an example and an explanation

Implicit Class Targets were a topic of very intense discussions. In the 
end, they were "barely" left in because several people strongly 
objected, but the compromise was that the document should downplay its 
importance and not promote them. That's also why we never use them in 
examples except in this section. I want to honor this previous agreement 
(regardless of my personal opinion).

In the case of PropertyShapes, it works just like with NodeShapes: 
targets select focus nodes. The focus nodes are combined with the 
sh:path which produces the set of value nodes. I see no inconsistency.

>
>
>
>
> Any IRI can be used as a severity.
> -- including user defined URI in the shacl sh: namespace ?

Yes, any user-defined IRI is allowed too. Using the sh: namespace would 
be very unusual but is not illegal.

>
>
> sh:sourceShape ... blank node above ... ;
>
> use an explicit bnode ID instead (e.g. _:b1)

Good idea, done in the two examples that use this format.

>
>
>
> 2.2 Node Shapes
>
>
> sh:NodeShape is the class of node shapes and should be declared as a 
> type for shapes that are IRIs.
> -- What about bnodes ?
>
> However, the presence of any rdf:type triple does not determine 
> whether a node is treated as a node shape or not.
> -- This is weird
>

These two sentences will be clarified or removed, see ISSUE-223 and 
ISSUE-224

>
>
> 2.3 Property Shapes
>
>
> Informally, property shapes specify constraints that need to be met 
> with respect to nodes that can be reached from the focus node either 
> by directly following a given property (specified as an IRI*)* or any 
> other SHACL property path*,* specified using sh:path.

Thanks, editorial change made.

>
>
>
> sh:PropertyShape is the class of property shapes and should be 
> declared as a type for shapes that are IRIs. However, the presence of 
> any rdf:type triple does not determine whether a node is treated as a 
> property shape or not.
> -- This is weird

See above, ISSUE-223 and 224

>
>
> 2.3.1.2 Sequence Paths
>
> If p is a sequence path in G with list members v1, v2, ..., vn then 
> path(p,G) is a SPARQL SequencePath of path(v1,G) as elt1, and the 
> results of the path mapping of the list node of *v2 ..vn* as elt2.

I don't think the current definition is incorrect. Note that we are 
talking about "the list of v2", i.e. the subject of ?subject rdf:first 
?v2. The sequence path definition is thus recursively calling itself. 
This was needed because the SPARQL SequencePath element is binary, not 
n-ary.

>
>
>
> 3.2 Data Graph
>
>
> SHACL makes no assumptions about whether a graph contains triples that 
> are entailed from the graph under any RDF entailment regime.
>
> -- What about OWL entailment ?

See above, no special status. OWL is one language among others. There 
can be any number of other entailment regimes too.

>
>
>
> 3.6 Validation Report
>
> Note that *although* this specification only covers the case in which 
> the validation report must include all validation results.

Thanks, "although" removed.

>
>
>
> When source shape is a bnode, what value for sh:sourceShape is in the 
> report   ?

The same RDF term.

> Same for sh:resultPath

This is different: we state that the property path must be equivalent to 
the one in the shapes graph. This means that an implementation will 
typically create some "deep copy" (although details of this have been 
left out).

>
>
> a validation report has *one or several value(s)* for the property 
> sh:result.

Please re-read that whole sentence: it starts with "For every..." then 
"... has a value" - which looks correct to me.

>
> Can result have URI instead of bnode ?

Yes, do we state otherwise?

>
>
>
> 3.6.2.2 Path (sh:resultPath)
>
>
> Validation results may have a value for the property sh:resultPath 
> pointing at a well-formed property path starting with the given 
> sh:focusNode.
>
> -- "starting with the given sh:focusNode" is not clear

I have removed this sub-sentence. It was not adding value and indeed 
just added confusion.

>
>
>
> For results produced by a property shape, this path is equivalent to 
> the value of sh:path of the shape.
>
> -- do we need to duplicate the whole path or just put the bnode of the 
> path ?

Duplicate, see above.

>
>
> 4. Core Constraint Components
>
> All constraint components can be used both in property shapes and node 
> shapes.
> -- This is weird, why are there two classes of shapes ?

We will be discussing this again in the WG, see

https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Feb/0011.html

>
>
>
> 4.1.1 sh:class
>
> -- if there are several values for sh:class, it is a conjunction

Yes, this is worth highlighting for newcomers so I have added an 
informal paragraph

     Note that multiple values for <code>sh:class</code> are interpreted 
as a conjunction,
     i.e. the values need to be SHACL instances of all of them.


>
>
>
> 4.2 Cardinality Constraint Components
>
> What if owl:sameAs with OWL entailment regime ?

See above.

>
>
> sh:disjoint specifies the condition that the set of value nodes is 
> disjoint with *the the*

Thanks, duplicate removed.

>
>
>
>
>
> 4.6.3 sh:or
>
> ex:OrConstraintExampleShape
> a sh:NodeShape ;
> sh:targetNode ex:Bob ;
> sh:or (
>     [
>         sh:path ex:firstName ;
>         sh:minCount 1 ;
>     ]
>     [
>         sh:path ex:givenName ;
>         sh:minCount 1 ;
>     ]
> ) .
>
> -- as in xor example, syntax should be :
>
> ex:OrConstraintExampleShape
> a sh:NodeShape ;
> sh:targetNode ex:Bob ;
> sh:or (
>     [sh:property [
>         sh:path ex:firstName ;
>         sh:minCount 1 ;
>     ]]
>     [sh:property [
>         sh:path ex:givenName ;
>         sh:minCount 1 ;
>     ]]
> ) .

Both cases are valid syntax and have the same effect. However, I wanted 
to illustrate both patterns. In the case of sh:xor, the other form made 
more sense because I needed to say "first name and last name at once" - 
the surrounding node shape acts as a conjunction.

>
>
>
> Can sh:qualifiedValueShape be used with boolean connector and or not 
> xor ?
> e.g. :
>
> ex:QualifiedValueShapeExampleShape
> a sh:NodeShape ;
> sh:targetNode ex:QualifiedValueShapeExampleValidResource ;
> sh:property [
>     sh:path ex:parent ;
>     sh:minCount 2 ;
>     sh:maxCount 2 ;
>     sh:qualifiedValueShape [
>         sh:path ex:pp ;
>         sh:or ([sh:hasValue ex:xx] [sh:class ex:cc])
>     ] ;
>                     sh:qualifiedMinCount 1 ;
> ] .
>
>
> There is no systematic definition of the places where we can use 
> boolean connectors: and or not xor.

Yes they can be used everywhere. Their definitions are quite general, 
and apply on any set of value nodes. Property shapes and node shapes 
have different policies on how to produce those value nodes, but they 
always apply.

>
>
> There is no systematic definition of sh:qualifiedValueShapesDisjoint

This is just a "flag" that IMHO doesn't require further definitions 
beside the relationship with sh:qualifiedValueShape. There are syntax 
rules however.

>
>
>
>
>
> 4.8 Other Constraint Components
>
>
> This section enumerates Core constraint components that *did* not fit 
> into the other categories.
>
> -> do not fit

Ok, done.

>
>
>
> 4.8.1 sh:closed, sh:ignoredProperties
>
> If $closed is true then a validation result must be produced for each 
> triple that has a value node as its subject and a predicate that is 
> not explicitly enumerated as a sh:path in any of the property shapes 
> declared via sh:property at the current shape.
>
> -- With property paths, e.g.:
> sh:path (ex:p1 ex:p2)
> sh:path [ sh:alternativePath (ex:p1 ex:p2) ]
> do the properties (i.e. ex:p1 and ex:p2)  participate to the 
> definition of sh:closed ?

No, only direct properties. I have added clarification "not enumerated 
as a <a>value</a> of <code>sh:path</code>" to hopefully make this clearer.

>
>
>
> D. Summary of SHACL Core Validators
>
>
> sh:qualifiedValueShapesDisjoint is missing

This is not a constraint component but can only be used in conjunction 
with the two QCR types.

Received on Wednesday, 8 February 2017 03:01:32 UTC