Re: Remaining issues with impact on the syntax

On 15/11/2016 11:20, Karen Coyle wrote:
>
>
> On 11/13/16 7:41 PM, Holger Knublauch wrote:
>>
>>
>> On 14/11/2016 8:52, Eric Prud'hommeaux wrote:
>>> * Holger Knublauch <holger@topquadrant.com> [2016-11-11 10:46+1000]
>>>> I believe we are supposed to publish another working draft before 
>>>> reaching
>>>> CR status at the end of this year. If we want to give enough room for
>>>> feedback I think we ought to do this soon after the upcoming 
>>>> virtual face to
>>>> face meeting.
>>>>
>>>> Looking at the list of open tickets, many are entirely editorial 
>>>> and others
>>>> could be closed simply because we ran out of time and won't be able 
>>>> to give
>>>> them justice (e.g. ISSUE-179, ISSUE-176). However, there remain 
>>>> some tickets
>>>> with impact on the syntax and implementations:
>>>>
>>>> ISSUE-92: partitions
>>>> https://www.w3.org/2014/data-shapes/track/issues/92
>>>> Eric promised to work on an update to the partition chapter. Without
>>>> progress, I don't think we can include these features. We risk 
>>>> running out
>>>> of time, and I want to be in a position where I understand all 
>>>> implications
>>>> for an implementation (e.g. the potential worst-case complexity).
>>> The implications are all in the abstract syntax document. I 
>>> understood the expression of it in the SHACL doc as being an 
>>> editorial issue. The text in the abstract syntax document is very 
>>> similar to the expression in the current partition text. (There are 
>>> also two implementations that run in a JVM, Iovka's Java 
>>> implementation and Jose's Scala implementation.)
>>
>> I think you should expose this proposal to a wider audience, e.g. of our
>> external reviewers, by adding it into the spec. It is not a proper
>> process to sneak a whole range of new features into the spec a month
>> before we are supposed to reach CR status.
>>
>> We currently have exactly the situation that several people felt nervous
>> about with the introduction of the Abstract Syntax: to have some kind of
>> a shadow spec that differs from the normative spec and evolves
>> independently. This isn't helpful. We are making enormous efforts to get
>> the terminology of the main spec bullet proof and weight every single
>> word. Then the Abstract Syntax comes along and uses different
>> terminology such as "pass" and "fail" or "expression" (probably 
>> ShEx-based).
>
> Having the abstract syntax as a separate document does have 
> disadvantages. I would prefer to see it integrated with SHACL, which 
> would make it easier to keep the two in sync. In fact, it shouldn't be 
> thought of as "two" because the abstract syntax, if not in error, 
> should be an expression of SHACL. Quite frankly I find the abstract 
> syntax adds clarity, and does so efficiently, so it allows a quick 
> understanding of the elements of SHACL. My own experience is that the 
> SHACL document does not provide the reader with an overview of 
> elements and rules because some key elements are somewhat buried in 
> the text. An example of this is this statement in Section 3, which is 
> about validation:

I'd be fine with adding the abstract syntax as an appendix - the 
abstract syntax only and its mapping to the RDF triples. This would also 
resolve the issue about duplicate examples, duplicate explanation of the 
semantics and all other issues that I mentioned before. The current 
situation is a mess.

>
> "SHACL can be used with RDF graphs that are obtained by any means, 
> e.g. from the file system, HTTP requests, or RDF datasets. SHACL makes 
> no assumptions about whether a graph contains triples that are 
> entailed from the graph under any RDF entailment regime."
>
> That doesn't relate to validation at all, but it is a key statement 
> about the nature of SHACL graphs and the role of targets and filters. 
> Without a concise abstract syntax, I don't think that this will be 
> visible to readers.

I don't see that connection. Could you elaborate a bit? How would the 
abstract syntax explain that graphs can be loaded from the web or the 
role of entailment?

Holger


>
> kc
>
>>
>> I also suggested before to use different keywords than sh:or. Currently
>> I have no idea how Choice, Group and PathConstraint map into triple
>> syntax. Your (only) example uses sh:partition combined with sh:or.
>> Shouldn't this become sh:choice, replacing sh:partition? How get
>>
>> PartitionConstraint := |expression|:Sexpr
>> <http://w3c.github.io/data-shapes/shacl-abstract-syntax/#dfn-Sexpr>, 
>> |extra|:Set[IRI]
>> Sexpr := Choice
>> <http://w3c.github.io/data-shapes/shacl-abstract-syntax/#dfn-Choice>|Group 
>>
>> <http://w3c.github.io/data-shapes/shacl-abstract-syntax/#dfn-Group>|PathConstraint 
>>
>> <http://w3c.github.io/data-shapes/shacl-abstract-syntax/#dfn-PathConstraint> 
>>
>> Choice := |exprs|:Set[Sexpr
>> <http://w3c.github.io/data-shapes/shacl-abstract-syntax/#dfn-Sexpr>]
>> Group := |exprs|:Set[Sexpr
>> <http://w3c.github.io/data-shapes/shacl-abstract-syntax/#dfn-Sexpr>]
>>
>> translated into RDF?
>>
>> (also is the sh:and in your example needed at all? The surrounding bnode
>> is already a shape, so the shape should be equivalent to
>>
>>  [
>>         [ sh:property [
>>             sh:predicate foaf:givenName ; sh:minCount 1 ; sh:maxCount 
>> 1 ] ]
>>         [ sh:property [
>>             sh:predicate foaf:familyName ; sh:minCount 1 ; 
>> sh:maxCount 1 ] ]
>>  ]
>>
>> In general I think we could delete sh:and from the language).
>>
>> Holger
>>
>>
>>>
>>>
>>>> ISSUE-180: Path nodes.
>>>> https://www.w3.org/2014/data-shapes/track/issues/180
>>>> The suggestion is to change the path syntax so that IRIs are always 
>>>> named
>>>> predicates while all path expressions (inverses etc) must be bnodes. I
>>>> believe Dimitris and I agree on this change.
>>>>
>>>> ISSUE-186: validation report properties.
>>>> https://www.w3.org/2014/data-shapes/track/issues/186
>>>> The suggestion is a simple vocabulary fix:
>>>> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0040.html 
>>>>
>>>>
>>>> The latter two are hopefully easy to resolve in the next meeting.
>>>>
>>>> A big unknown remains the topic of pre-binding (ISSUE-68 and 
>>>> ISSUE-170). The
>>>> SPARQL EXISTS group seems to be making slow but steady progress, 
>>>> yet we need
>>>> this done before we can move to CR.
>>>>
>>>> BTW what ever happened to the Compact Syntax? It looks like we are 
>>>> running
>>>> out of time and it won't happen. Maybe a differentiator for ShEx?
>>>>
>>>> Holger
>>>>
>>>>
>>
>

Received on Tuesday, 15 November 2016 02:17:26 UTC