Re: recursive shapes in shape expressions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 02/24/2015 04:32 AM, Iovka Boneva wrote:
> Le mar. 24 févr. 2015 02:02:02 CET, Peter F. Patel-Schneider a écrit :
>> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Just a preliminary response to get at a particular part of one
>> example.
>> 
>> On 02/23/2015 07:25 AM, Iovka Boneva wrote:
>> 
>>> 
>>> 
>>> Le sam. 21 févr. 2015 23:27:52 CET, Peter F. Patel-Schneider a écrit
>>> :
[...]
>>>> 
>>>> There are ever trickier situations involving recursive shapes. For 
>>>> example, consider the two mutually recursive shapes <S> { ( ex:p
>>>> @<S> | ex:p @<T> ) } <T> { ( ex:p @<T> | ex:p @<S> ) } (something
>>>> is in <S> if it has an ex:p fillers and either all its ex:p fillers
>>>> are in <S> or its ex:p fillers are in <T> but not both, and
>>>> similarly for <T>). It is unclear as to which nodes should have
>>>> shape <S> or <T> in the graph ex:a ex:p ex:b . ex:b ex:p ex:a .
>>>> 
>>> 
>>> 
>>> With our semantics and considering /closed/ shapes, the shape
>>> 
>>> <S> { ( ex:p @<S> | ex:p @<T> ) }
>>> 
>>> intuitively says that a <S> typed node should have exactly one
>>> outgoing ex:p, that leads either to <S> or to <T> node. This however
>>> does not forbid the target node to have both <S> and <T>; we exclude
>>> any form of negative constraints.
>>> 
>>> There are 9 valid typings, associating with ex:a and ex:b, in this
>>> order, the sets of shapes: {<S>} {<S>} {<S>} {<T>} {<S>} {<S>,<T>}
>>> {<T>} {<S>} {<T>} {<T>} etc. actually all combinations in the
>>> Cartesian product { {<S>}, {<T>}, {<S>,<T>} } X { {<S>}, {<T>},
>>> {<S>,<T>} } The unique maximal typing is <S>,<T> for both ex:a and
>>> ex:b.
>> 
>> 
>> Huh?
>> 
>> If ex:b is of type {<S>,<T>} then <ex:a> should not be <S> or in <T>
>> because both arms of the exclusive or disjunct are true. The literature
>> that I have read on shape expressions is very clear that exclusive or
>> is the meaning of the | construct - see 
>> http://www.w3.org/Submission/2014/SUBM-shex-primer-20140602/ for
>> example.
>> 
> Indeed, there is a difference between our semantics and the one on the
> page you site. The reason for that is basically that we started our work
> on a previous version of shapes, in which the Or was not exclusive. e.g.
> http://www.w3.org/2013/ShEx/Primer.html
> 
> If the user cases require Xor, then we can think of extending the
> semantics. I would however not advise to introduce the possibility to
> check whether a node *does not satisfy* a given shape. Some form of
> exclusiveness can be expressed with closed shapes, or even with a
> 'controlled' version of open shapes. Indeed, with closed shapes, a node
> would match
> 
> <S> { ( ex:p @<S> | ex:p @<T> ) }
> 
> if it has exactly one ex:p outgoing property. The 'controlled' version of
> /open/ shape would enforce that the shapes are 'open' only on the labels
> not mentioned in the shape. So, the latter shape would be satisfied by
> nodes that have exactly one outgoing ex:p, and any other outgoing edges
> which label is different from ex:p.

I don't remember having seen any open or controlled open treatment in this
semantics.  It appears to me that there would have to be a complete rewrite
of the semantics for this.

> I believe that such controlled open semantics allows to talk about what
> is expected to be in the graph, including cardinality constraints for
> all properties that were mentioned, and in the same time allows to have
> in the graph all other triples which predicates are outside of the
> 'domain' of interest. Additionally, it has a well defined declarative
> semantics.

Where?

[...]

> Iovka

peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU7JKJAAoJECjN6+QThfjzojAH/iaKyCgeFwozCacP5LPAYnmz
sGSETSl+6OnjzQA7nshwFV7ZgOLIe5QVI+HKTrwTwL3I4wMaDrNLJ0Dhaodyrf9p
QdJcEbIl3cw5je6vYEILHnI8eOJ5BBlwFB0sq9GAX+qw0RHn83giKNny9PWNcWxr
j8SCn7R7DKtAnBMNEKgs7gAVL12lDvAJG40NE1as0i4mFNvgPof5u9KuRvrmgq8K
klzO1sgvcHAUiT9vcsOclPGU8IQiHAGA3nI7dpfSsBJi+Z8bxgxGO2m2FQUr52Iw
En4uvco5XxTQOoX7p+m+0Kzrqb+GzTUSRDQKCvQLHEXkR0WafBm061fU2M3RT9A=
=p3MK
-----END PGP SIGNATURE-----

Received on Tuesday, 24 February 2015 15:03:05 UTC