Re: Early feedback on SHACL Spec appreciated

Thanks for your feedback, Peter. It's good to have specific things to 
work against.

On 2/27/2015 16:03, Peter F. Patel-Schneider wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Right now the specification is quite incoherent.
>
> There is Section 2, which appears to define a language.  However, this
> definition does not appear to be used anywhere else in the document.  As far
> as I can tell the SPARQL definitions later in the document do not conform to
> the definitions in this section.

Yes, I had marked section 2 with a big red Issue box for that reason. 
Eric stated today that his goal was to include this section because he 
wanted to expose these semantics to feedback. He also stated he wanted 
other alternative semantics to be included too. In the call today we 
have decided to delay the final decision about this until the next call. 
My proposal is to move section 2 into another document (Jose already has 
a URL) and add pointers to that document into the Introduction. This 
should allow readers to find the necessary information and provide feedback.

>
> The introduction talks about constraints being attached to shapes.  What
> does this mean?  The introduction talks about restricting the predicates of
> triples.  What does this mean?  The introduction talks about SPARQL a lot.
> In general I found the introduction to be more confusing than descriptive.

Yep, it needs consolidation - different authors with different focus. I 
have added a corresponding comment.

>
> There are many aspects of the described SHAQL that are not supported by
> resolutions of the working group, such as:
> - - the division of constraints into native and template constraints
> - - the use of a native executable
> - - the use of SPARQL as the native executable
> - - template shapes
> - - private shapes
> - - specialization of shapes
> - - abstract shapes
> - - final shapes
> - - matching of literals instead of their values
> - - contexts

Here I have a general process question: does the WG need to formally 
resolve on every single feature and design decision of the language? For 
example, if I want to add certain triples to the system vocabulary, does 
each triple have to be covered by a resolution? Where to draw the line? 
Most features above have proven to be useful in existing languages like 
SPIN. Many are indirectly referenced in accepted requirements (e.g. the 
Complex constraints can be implemented by SPARQL). For some (such as 
specialization of shapes) it feels pretty obvious that it will 
eventually get agreed upon. But in the end, someone (in this case me) 
has to make concrete proposals, based on some form of judgement, 
experience, etc.

>
> The idea of having three properties that do the same thing (sh:constraint,
> sh:property, and sh:inverseProperty) is not useful.

Resource Shapes 2.0 introduced this concept, and I think it is a useful 
design to make the code more readable. Of course, you are welcome to 
have a different opinion, and this matter may boil down to a matter of 
personal preferences.

One nice side effect of having sh:property in addition to sh:constraint 
is that with sh:property the rdf:type triple of the constraint is 
optional - this creates better readable code with less to edit.

>    The grouping of
> constraints related to the same property is not something that needs to be
> recommended.

Why not? It feels like a good practice in general. Better than

ex:Shape
     sh:property [
         sh:predicate ex:property ;
         sh:minCount 1 ;
     ] ;
     sh:property [
         sh:predicate ex:property ;
         sh:valueType xsd:string ;
     ] ;

but again this is a matter of taste. I can take out this 
"recommendation" if people agree this recommendation is harmful. I have 
marked this sentence as "at risk".

>    Overloading rdfs:label and rdfs:comment is not useful.

We have open Requirements for those, and I have responded to your 
concerns there:

https://www.w3.org/2014/data-shapes/wiki/Requirements#Property_Labels_at_Shape

We should follow up on that topic over there.

>
> The language only allows conjunctions of primitive constraints, i.e., no
> disjunction.

It will eventually support disjunction, there is a placeholder chapter:

https://w3c.github.io/data-shapes/data-shapes-core/#union-or-constraints

> The supported operations don't make sense.  How can a single constraint be
> checked without some notion of what graph or dataset is involved, and what
> scope is involved for constraints that need a scope?

The dataset and its default graph are implicit arguments to all these 
operations. I have clarified this with a red TODO paragraph. Overall 
this topic interacts with the general topic of graph management. I have 
created a placeholder chapter for that topic, which is currently empty 
because we have not agreed on any relevant requirements yet.

What do you mean with "scope"? The focus node?

I have committed my updates here:

https://github.com/w3c/data-shapes/commit/49f996151a920ebf6c24ea5dddea639ce9144986

Thanks
Holger

Received on Friday, 27 February 2015 06:40:56 UTC