Re: Remaining issues with impact on the syntax

On 11/15/16 2:08 PM, Holger Knublauch wrote:
>
>
> On 16/11/2016 5:13, Karen Coyle wrote:
>>
>>
>> On 11/14/16 6:16 PM, Holger Knublauch wrote:
>>>
>>>
>>> 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.
>>
>> An appendix would be ok; better would be integration with the text
>> itself.
>
> If the AS contains explanatory prose that should be in the spec, then
> let's copy it over. If the AS contains helpful examples that should be
> in the spec, then let's copy them over.

I'm not thinking of prose, I'm thinking of the concise, formal 
definitions. The other option would be to make the information clearer 
in the spec.

>
>>
>>>
>>>>
>>>> "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?
>>
>> No, you are right, I see that it does not - however, I think it
>> should, so I'll be back. It's a matter of showing that targets and
>> filters are optional, but I honestly don't know the rules that would
>> be applied:
>>
>> - Does a filter require a target?
>
> No, filter shapes are always validated, even if a potential focus node
> is determined by some other means.

And if it isn't determined by some other means? What happens then? Say 
if there is no previously defined node, then what? It seems that a 
filter must have something to filter on, and 1) we don't seem to have a 
word for that, since we've clarified "focus node" 2) the spec should say 
this.

>
>> - Does a shape require constraints?
>
> No, but a shape without constraints doesn't have any effect and is
> always valid.

That would be a helpful thing to say in the spec.
kc

>
> HTH
> Holger
>
>
>>
>>
>> kc
>>
>>>
>>> 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
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>

-- 
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 23:26:22 UTC