- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Mon, 18 May 2015 11:57:36 -0700
- To: Iovka Boneva <iovka.boneva@univ-lille1.fr>
- CC: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>

-----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