Re: Remaining issues with impact on the syntax

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:

"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.

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
>>>
>>>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 15 November 2016 01:21:05 UTC