Re: unannounced changes to http://w3c.github.io/data-shapes/semantics/

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

Your list of changes appears to form a major change to the language.  The
changes to the semantics appear to also be a major change, particularly the
handling of negation.

peter


On 05/18/2015 11:53 AM, Iovka Boneva wrote:
> Dear Peter, dear all,
> 
> The ShEx proposal is being continuously improved, taking into account
> what is pointed out to be missing.
> 
> The version from May 8 indeed looks very different. This is however due
> more to a refactoring than to significant change to the semantics. A new
> version will be available later today, with only small changes w.r.t. the
> version from May 8.
> 
> In what follows, I explain the differences between the new version to
> come in few hours, and the one from before May 8.
> 
> I apologise for the short time left for inspection.
> 
> Summary of changes (details below).
> 
> ** Added features
> 
> 1. Negation on shapes 2. Negation on triple constraints 3. Exclusive
> choice 4. Multiplicity on full expressions
> 
> ** Modification in the semantics
> 
> The new features 1., 2. and 3. require taking negation into account.
> There are two main modifications.
> 
> a) there is a syntactic restriction, called well-defined shapes, that
> forbids negation to appear mixed with recursion. This guarantees that the
> semantics is well defined
> 
> b) a typing is now defined as a map that associates with the nodes of
> the graph either shape names (e.g. T), or negated shape names (e.g. !T)
> 
> Moreover, we have c) a slight extension of openness
> 
> ** Refactoring
> 
> We previously introduced first a simple version, and then added inverse 
> constraints in a separate section, and also complex types in a separate 
> version. Now everything is defined at once. This makes the definitions
> longer.
> 
> Also, the definition [Triple matches constraint] changed a bit, this is
> in order to take c) into account.
> 
> Hope these explanations help.
> 
> Iovka
> 
> ************************* **** More detailed explanations In the
> examples, all missing cardinalities are [1;1]
> 
> 1. Negation on shapes ex:p !@T    # property ex:p leads to a node that
> does not satisfy shape T ex:p !(@T1 or @T2 or @T3)    # property ex:p
> leads to a node that satisfies none of T1, T2, T3 ex:p !(@T1 and @T2 and
> @T3)   # similar to previous, with conjunction
> 
> 2. Negation on triple constraints ! ex:p @T     # there is no property
> ex:p that leads to node satisfying shape T.
> 
> Note that this is "semantic sugar", it was already possible with the
> previous semantics written ex:p @T [0;0] (i.e. asking for 0 cardinality)
> 
> 3. Exclusive choice We now have two choice operators - some-of : non
> exclusive choice (previously called disjunction) - one-of : exclusive
> choice
> 
> 4. Multiplicity on full expressions (ex:p @T | ex:q @S)[2;4]    # there
> are between 2 and 4 out-going edges, each of which is either ex:p to T,
> or ex:q to S
> 
> Regarding b) Note that negated shape names appear only for so called
> negated shapes, these are the shapes for which it is necessary to test
> whether a node does not satisfy that shape. In theory we require that
> every node in the graph has either type T or type !T, for all negated
> shape T. This however can be weakened and required only for the
> appropriate nodes, we kept it like this in order not to complicate
> further the semantics.
> 
> Regarding c) By default, open shapes allow all properties not mentioned
> in the shape definition to occur freely (w/o any restriction). We also
> added so called included properties (for openness), which are properties
> that occur in the shape definition, but we also allow to occur outside,
> as soon as the target node does not satisfy the constraint from the
> shape. This is useful for instance with rdf:type. For example S -> open
> {rdf:type} rdf:type ex:Animal says that one rdf:type property is
> required, going to ex:Animal, and any other rdf:type properties are
> required.
> 
> In the previous version, the included properties were only handled for 
> properties involved in value constraint (as in the example above,
> ex:Animal is a fixed value for the rdf:type property). With the new
> version, we can also include open properties associated with shapes in
> the type definition. For example: S -> open {ex:p} ex:p @T meaning that
> one ex:p to T is required, and other ex:p are allowed if they lead to a
> node that does not satisfy T (this uses negation).
> 
> 
> 
> 
> Le lun. 18 mai 2015 16:07:04 CEST, Peter F. Patel-Schneider a écrit :
>> 
> On 8 May, there were what appear to be significant changes made to Core 
> SHACL Semantics http://w3c.github.io/data-shapes/semantics/
> 
> I find it very unfortunate that these changes were not announced to the 
> working group. It is going to be difficult to have informed discussion
> of this proposal tomorrow.
> 
> peter
>> 
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVWjYgAAoJECjN6+QThfjzhiAH/2qA/hMjTdHnEhZPzqNC3Ju/
oyCrEX175PKoWwA4QZ7TH2zLZT8EPraI+lwC/7HkpZW7qJbdyp4O6+KWyfAlpiFK
5qvycYIG3kea7/6hxaYIlZEKQqKBamR2tQkJ74Yh/EAXe/jl/36tuZenasbLVNXU
26dmI636Hfzupx+PRpuRge1h59zFRffk1u8dbsrIIabBvgFcqFPYtbnTQ01A85C6
2ICJpNqHDdvy8u4m6hsSL04A5o5p9GWdmd8nyzKnfbQRy+ZJh1u4TBLVrhEuV8dm
36z3k088uACNDtabQCCqLlkW8urFK6ETaPSEhZLPm5ewDLvW0J2GjGtioEQkGTA=
=UN5L
-----END PGP SIGNATURE-----

Received on Monday, 18 May 2015 18:58:16 UTC