Re: preliminary analysis of shape expressions proposal

Dear Peter, all,

Thank you for your comments, here are my answers.

Le 01/05/2015 15:13, Peter F. Patel-Schneider a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> I spent some time yesterday and today looking over the Core SHACL Semantics
> document http://w3c.github.io/data-shapes/semantics/
>
> This is a new formal basis for a shapes/constraint language.
>
> The language (in Section 2) is quite limited.  It includes closed shape
> expressions and open shape expressions.  It has disjunction and a construct
> called grouping.  It has cardinality ranges.  It has values and node kinds
> and datatyping and facets.  It has inverse properties (which are not handled
> in the semantics).  That's it.

Indeed, that's it ! Because these few constructs allow to express 
complex constraints on the neighbourhood of a node, we didn't consider 
it necessary to add anything else for now. By the way, the unique 
difficulty in integrating inverse constraints is that it makes the 
definitions more verbose, handling two distinct cases each time. We 
added explanations how it works, to be found in the actual version of 
the document.

> In particular there is no conjunction of
> shape expressions, and adding this conjunction would break a property of the
> semantics.

Adding conjunction would not break anything in the semantics. We already 
have conjunction of types in triple constraints. It is actually very 
easy to add general conjunction as construct of shape expressions. If a 
user case justifies the need of conjunction (i.e. cannot be handled with 
what is already in the language), then conjunction is a an evolution to 
be considered.


>
> The basic technical idea of the semantics is that nodes in a graph are
> assigned zero or more shape labels and then the elements of these
> assignments have to be backed up with local derivations that cover all the
> outgoing edges from a node and are consonant with the shape labels assigned
> to neighbouring nodes.  This gets around problems with ill-foundedness of
> recursive shapes.

There is no problem with recursion. Peter, as you already realized 
earlier, there was a problem with recursion in the initial Eric's shape 
expressions, because of the 'exclusive or' (so hidden negation) combined 
with recursion. On the other hand, I think I convinced you earlier that 
there is no problem with recursion and the 'normal' disjunction that we 
currently have in the language. Because a choice of only one among 
several (kind of 'exclusive or') is useful in the use cases, we added 
the 'one-of' operator, for which we impose a syntactic restriction that 
limits the use of recursion, while guaranteeing a sound semantics.


>
>
> There are some minor problems with the proposal.
>
> The language (Section 2) is very ambiguous.  The productions for
> disjunction and grouping need to be modified to require them to be
> disjunctions or groupings, respectively.

I do not understand this remark. Does this relate to the abstract syntax ?


>
> The abstract syntax used in Section 5 is different from that in Section 2.
>
>
> There are some broken parts of the proposal.
>
> There is a claim that disjunctive shape expressions are similar to logical
> disjunction.  However disjunctive shape expressions here end up being quite
> different from logical disjunction.  See below for more on this.
>
>
> There are some serious problems with the proposal
>
> There is no connection between how shapes are associated with data (Section
> 4) and the main part of the semantics (Section 5).

Fixed: 2 lines in the end of the document.


>
> The semantics in Section 5 does not cover the full language from Section 2.
> It is missing inverse triple constraints.  Adding inverse triple constraints
> to the semantics appears to be problematic.
>
> The semantics depends on witness mappings.  The definition of witness
> mappings talks about triples appearing in the conclusion of applications of
> the rule for the empty shape expression.  However, applications of this rule
> do not include any triples at all.  I think that there is a simple
> fix---using the rule for triple constraints instead---but that remains to be
> verified.

I do not think there is a problem with the empty shape. Actually, I am 
not sure I understand your remark. In any case, a non-empty set of 
triples does not satisfy the empty rule.


>
>
>
> Disjunctive shape expressions
>
> Disjunctive shape expressions work differently from what one might expect.

Unfortunately, users' expectations are subjective, and differ depending 
on the user's experience. Our proposal is closer to the intuition of 
users of structural schemas (like XMLSchema, DTD, ...). By giving 
precise semantics of a language, one allows to users to agree on a 
shared meaning, rather than relying on their personal expectations. 
Let's focus more on the capability of the language to meet the use 
cases, and less on the (necessary subjective) expectations.

Follows a more technical explanation trying to give a better intuition 
of our disjunction. Stating that disjunction is similar to logical 
disjunction probably gives a wrong intuition. It would have been more 
correct to say that disjunction is similar to disjunction in regular 
languages, or to choice in XMLSchema which is a restriction of the 
former. The difference with the choice in XMLSchema is that, for 
defining the semantics, we do not require something like the Unique 
Particle Attribution (UPA) of XMLSchema (which makes that our 
disjunction is not an exclusive choice, but real disjunction like in 
regular languages). Restrictions like UPA are useful for efficient 
validation, but not for defining a proper semantics.


>
> For example, there is no valid typing for the shape expression schema
>  S open { p , q } p E [1;1] | q E [1;1]
>  E open { } empty
> on the graph
>  a p b .
>  a q c .
> that includes S in the shapes of a.
>
>
> Open shape expressions
>
> Open shape expressions work differently from what one might expect.
>
> For example, there is a valid typing for the shape expression schema
>  S open { p } p { b } [1;1]
> on the graph
>  a p b .
>  a p c .
> that includes S in the shapes for a.  However, there is no such valid typing
> for either the shape expression schema
>  S open { p } p { b , c } [1;1]
> or the shape expression schema
>  S open { p } p E [1;1]
>  E open { } empty
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVQ3vvAAoJECjN6+QThfjzOiYIAM+LjmGgimUKwucHkHjjKTfS
> qw1gw9kVBiv1Gcdnyk1G7RY6JbQ5eHEJn8XyNIsTFhW68SSAZ5BggqwgoXgdaD/y
> 6VuS6yh1gWL2lQgliBDOaqUIhRU96Au+RBaLMnz+NNkGtW788qx0j8RhC+QktVmk
> sAKV3g72l+8iNmxZrm6I4kcBSwfKuiVegSWztYS7AS6zkY8YjdqOf4MUNSd/9yFo
> mNjwWSmLnIsv8r82A20HQZaHY/fFeNqlptTXlAgZCEcKns9oVaUyUMUncgk8ih24
> GwmuNQL6OCYjeHAFE24hVwFl4JUctKTC66yVAvq/vQ6Nvf/GzOzeKfzZOKoBBWA=
> =o8K5
> -----END PGP SIGNATURE-----
>


-- 
Iovka Boneva
Associate professor (MdC) Université de Lille
http://www.cristal.univ-lille.fr/~boneva/
+33 6 95 75 70 25

Received on Tuesday, 5 May 2015 22:46:37 UTC