Re: Early feedback on SHACL Spec appreciated

I agree with some of Peter's remarks.

>From my point of view there are some missing sections on the spec and some
sections that should probably moved out of the spec and be part of some
different deliverable.

- I miss a section describing the core vocabulary used to define the
shapes. That section should be one of the first sections. Now, there is
section 6 but it contains a mixture of things.

- That core vocabulary for shape definitions should not need any reference
to SPARQL. I suggest to remove the examples using SPARQL in section 4 and
to use examples based on that core vocabulary.

- The definitions in section 6.2.1, 6.2.2, 6.2.3, etc. are in natural
language and in SPARQL. I propose to use a semantic formalism which does
not depend on SPARQL and to have SPARQL mappings in a different section
(probably section 15).

- Section 2 contains the axiomatic semantics that can be used to define the
semantics of the language constructs that appear in section 6.2.1, .... We
could maintain this section here although I would accept to have other
semantic formalisms instead, like the model-based semantics proposed by
Peter.

- I would add a subsection about how to map from the core vocabulary terms
defined in RDf to the abstract syntax used to define the semantics.

- Section 7 (Union/or constraints) should be part of the core vocabulary.

- Section 8 (Shape selection) probably needs more work, but I agree with
maintaining it.

- Sections 9 (templates) and 10 (functions) should probably be removed
until we have more consensus on what extensibility mechanism we are going
to use. In the requirements we employed the name "Macros" instead of
templates.

- I would remove sections 11 (Graph management), 12 (Contexts) and 13
(Profiles) because some of them are almost empty and others contain
features on which there is no consensus yet.

- I am not sure if we should include Section 14 (supported operations) but
I would not oppose to maintain it.

- I think section 15 (SPARQL based execution) could be an independent
document, but I would not oppose to maintain it there.

Best regards, Jose Labra

On Fri, Feb 27, 2015 at 7:39 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> 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/49f996151a920ebf6c24ea5dddea63
> 9ce9144986
>
> Thanks
> Holger
>
>
>


-- 
-- Jose Labra