Re: Remaining issues with impact on the syntax

On 14/11/2016 8:52, Eric Prud'hommeaux wrote:
> * Holger Knublauch <> [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
>> 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).

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 
Sexpr :=Choice 
Choice :=|exprs|:Set[Sexpr 
Group :=|exprs|:Set[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).


>> ISSUE-180: Path nodes.
>> 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.
>> The suggestion is a simple vocabulary fix:
>> 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 Monday, 14 November 2016 03:42:32 UTC