- From: Holger Knublauch <holger@topquadrant.com>
- Date: Mon, 14 Nov 2016 13:41:59 +1000
- To: public-data-shapes-wg@w3.org
- Message-ID: <1c7b3e5f-d7e1-944a-975f-e30f77964bf8@topquadrant.com>
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). 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 Monday, 14 November 2016 03:42:32 UTC