Re: Quick "last call" before CR for Data Shapes' SHACL

Hi Olivier,

thanks for your feedback.

On 10/03/2017 2:48, Olivier Corby wrote:
> Hi,
>
> Some remarks on the the document.
>
> Olivier
>
>
>
>
> 1.4 SHACL Example
>
>
> sh:sourceShape ... blank node on ex:ssn above ... ;
> (twice)
>
> -- These statements are ambiguous. Use a bnode ID instead, e.g. _:b1

I don't see these are ambiguous because there is only one blank node 
using ex:ssn. Anyway, I have added a bnode ID as you suggested, to 
double-proof this.

>
>
>
> 1.6 Relationship between SHACL and SPARQL
>
>
> SPARQL variables using the $ marker represent external bindings that 
> are pre-bound or, in the case of $PATH, substituted in the SPARQL 
> query before execution
>
> -- The meaning of "substituted" is not defined.

Ok, hyperlink to the details has been added, making sure that the term 
"substituted" is only used in that context. In general, I believe our 
use of "substitute" is sufficiently close to the normal use of the 
English word.

>
>
>
> 2.1.1 Constraints, Parameters and Constraint Components
>
> Shapes can declare constraints using the parameters of constraint 
> components.
> A constraint component is an IRI.
>
> -- This is ambiguous because we may understand that the URI is part of 
> the shapes graph whereas the IRI is used to identify constraint 
> components in the document.

Could you suggest alternative wording? These IRIs typically only show up 
in shapes graphs when someone defines new constraint components 
(SHACL-SPARQL), otherwise only in result graphs.

>
>
>
>
> 2.1.3.4 Subjects-of targets (sh:targetSubjectsOf)
> 2.1.3.5 Objects-of targets (sh:targetObjectsOf)
>
> -- in addition to IRI, the values of these properties could also be a 
> path

We decided not to do that because it would complicate using the 
language. Currently all four targetXY properties are simply enough to 
query, e.g. to populate forms or find relevant shapes for an instance. 
If we were to open this up to arbitrary paths, then there is significant 
downstream cost, eventually leading to further fragmentation on the tool 
front "does UI generation tool X support target paths or not".

Note that the SHACL-SPARQL advanced features document (not yet 
published) includes sh:target as a general means to express scenarios 
like the above. I believe this is the best balance.

>
>
>
> SELECT DISTINCT ?this    # ?this is the focus node
> WHERE {
>     ?this $targetSubjectsOf ?any .    # $targetSubjectsOf is 
> **pre-boundto** ex:knows
> }
>
> -- a space is missing in *pre-boundto*

Thanks, fixed.

>
>
>
> 3.6 Validation Report
>
> Is it correct to provide additional properties  to ValidationResult 
> and ValidationReport ?

Yes, this is absolutely possible and even encouraged, see 3.6.1:

The RDF graph/may/contain additional information such as provenance 
metadata.

I guess it could also contain the identifier of the engine that produced 
the result, information about which graphs were used, the time stamp, 
flags (e.g. cutting off info messages). I assume such things will lead 
to best practices and de-facto standards in due course.

>
>
>
> 4.1.2 sh:datatype
>
> Note that **the** using rdf:langString as value of sh:datatype can be 
> used to test if value nodes have a language tag.
>
> -- Note that  using rdf:langString as value of sh:datatype can be used 
> to test if value nodes have a language tag.

Thanks, fixed.

>
>
>
> 4.5.1 sh:equals
> 4.5.2 sh:disjoint
> 4.5.3 sh:lessThan
> 4.5.4 sh:lessThanOrEquals
>
> -- The value of these 4 properties  could be generalized to path

I had cautiously suggested that a year ago but it didn't lead anywhere. 
At this stage, I am afraid this would open up various design decisions 
and would require a generalization of $PATH for the extension mechanism too.

Again, such scenarios can be covered by SHACL-SPARQL, so there is no 
lack of expressivity ATM. The general trade-off is that the more 
patterns we allow in the Core language, the more complex it becomes for 
downstream tools to make sense of the constructs. Validation engines are 
not the only consumers of SHACL.

>
>
>
> 4.8.1 sh:closed, sh:ignoredProperties
>
> The following example illustrates the use of sh:closed in a shape to 
> specify the condition that certain focus nodes only have values for 
> ex:exampleProperty1 and ex:exampleProperty2.
>
> -- The  properties in the example are ex:firstName and ex:lastName

Good catch, fixed.

https://github.com/w3c/data-shapes/commit/e38c5688fd7b396e3465c0a63e07682f91319b43

Holger