Re: preliminary analysis of shape expressions proposal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


> Le 06/05/2015 07:34, Peter F. Patel-Schneider a écrit :
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>>> Dear Peter, all,
>>> 
>>> Thank you for your comments, here are my answers.
>>> 
>>> Le 01/05/2015 15:13, Peter F. Patel-Schneider a écrit :
>>>> I spent some time yesterday and today looking over the Core SHACL 
>>>> Semantics documenthttp://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.
>> A few more things have been added since my initial analysis, including 
>> inverse triple constraints and a partial treatment of the association
>> of data with shapes, but there is still no negation, no conjunction,
>> no keys, no transitive traversal, and no extensibility.  That's quite a
>> bit of stuff that is not handled.
> 
> We did define how extensions are to be handled in the semantics, see end
> of Sect. 2 for the syntax and item 7. in Definition [Typing, Valid
> typing].

We appear to be using different notions of extensibility.  You were
thinking of a mechanism that can be used to support mechanisms that
provide extra features, I was thinking of mechanisms that actually do
support extra features.  (And the third notion in play here is
mechanisms that can be used to extend the "high-level" language.)

Eric appears to be putting together a document that is an attempt to
provide the second notion
(http://w3c.github.io/data-shapes/semantics/SPARQL#glue) and maybe the
third (the rest of http://w3c.github.io/data-shapes/semantics/SPARQL).

So taking both documents into consideration there is an extension
proposal there.

> As I said previously, conjunction can be added if required. I however
> think that we can meet most of the use cases w/o conjunction, thanks to
> the grouping operator.

I disagree, based on my idea of the motivations and uses of SHACL.  I
don't believe that grouping can be used to replace conjunction in this
view of SHACL.

> Some sort of negation can be modelled with maximum cardinality of 0. For
> now it is not clear whether more involved negation would be useful
> (negation of types).

In my view of SHACL negation is a very important construct.  For
example, it is implicit in checking for disjointness of types.

>>>> 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.
>> Adding a normal conjunction would break the property that each triple
>> in Neigh is introduced exactly once in a proof tree.
> 
> Indeed. This however is not an issue: if a triple is used several times
> in the proof tree (against several triple constraints), then all the
> shapes of all these triple constraints will be required for the object
> node of the triple.

If this is not an issue, then why was the property introduced and
proven?  If the property is not needed, then just remove it.

[...]

>> What I find most disturbing about | here is how it interacts with open 
>> shapes.  I find the results very unintuitive.  I find the interaction 
>> between open shapes and triple matching similarly unintuitive.

> I see. This will be improved by giving more explanations about the design
> choices around open shapes.

Perhaps.  I am skeptical that the behaviour of open shapes here can be
given any reasonable intuitions, but perhaps this is because of my
beliefs about of what SHACL is supposed to be doing.

> Iovka Boneva

peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVS5KEAAoJECjN6+QThfjzWnQIAJxoNNhUPmV+9xH0LLpl7OfE
/w2D4OiAcaoNZ+QJXhpMftRMbAk9xs+/BOqBYTcWSGaMEhk5gXAKjgCOLKTjOJHc
tdc7sa1IODLD6Q4MedCWULt8jqkSI+H2CVuBhe2R9EQ7ZTLPo1PaJiFTZaRWCHpv
kQZG5A6C0+ThoS/LNN0uRqIJTvvbmdoca8H7//HMllqP0pSBwGivA/aJEyGcyTLx
TA4LiNicO3H7g/1qvryIqiIeumHl6YDXMrFQkvUfOoiuPMnsg7XvQNJ2aj+2adnN
3OMzPWEAWLcr13tWHxfA/8JdF4xC9kIfzEakpPljCLZ9a2ukkAi3v79Wn/t2auo=
=xhxB
-----END PGP SIGNATURE-----

Received on Thursday, 7 May 2015 16:28:19 UTC