Re: [ANN] Shape Expressions 2.1 release candidate

Dear Peter, all,

We have added some minor fixes (explained in the sequel) in order to 
answer your issue.

The changes can be seen in the editor drafts
https://shexspec.github.io/spec/
https://shexspec.github.io/shape-map/


Le 27/11/2018 à 15:48, Peter F. Patel-Schneider a écrit :
> [This is a slight modification of a comment in Issue 84 on
> https://github.com/shexSpec/shex/.]
> 
> 
> The semantics in Shape Expressions Language 2.1
> http://shex.io/shex-semantics-20181122/ very different from the previous
> semantics for ShEx that suffered from being ill-founded.
> 
> It is not easy to tease out all the aspects of the new semantics, as
> information about semantics is spread throughout the document. The following
> is my interpretation of what is going on, but I have been unable to get my
> head around the semantics in its entirety. My view is that it would have
> been better to have a separate section on semantics with an introductory bit
> saying how the semantics unfolds.
> 
> The first mention of isValid is in Section 2.5 where it is stated that the
> function takes a shapes schema, an RDF graph, and a fixed ShapeMap and
> returns a result ShapeMap.
> 
> Section 3 of ShapeMap Structure and Language Draft Community Group Report 13
> July 2017 at http://shex.io/shape-map/#dfn-fixed-shapemap defines ShapeMaps.
> Here the status is one of two strings "conformant" and "nonconformant".
> However, in Section 2.5 of Shape Expressions Language 2.1 Draft Community
> Group Report 17 November 2018 at http://shex.io/shex-semantics/#process the
> result ShapeMap does not have a status but instead a result with values pass
> and fail. This disconnect needs to be fixed.
> 

The explanation that "pass" corresponds to "conformant" status and 
"fail" corresponds to "nonconformant" status was already given in Sect. 
2.5. Now it has been made more explicit.


> ShapeMaps cannot have two shape associations with the same nodeSelector and
> shapeLabel. But the notion of identity for shape associations is not
> explicitly defined. However, the second half of Example 1 indicates that
> shape associations have an identity independent of their membership. This
> means that the process of converting a query ShapeMap to a fixed ShapeMap
> defined in Section 4 of ShapeMap Structure and Language Draft Community
> Group Report 13 July 2017 at http://shex.io/shape-map/#dfn-fixed-shapemap
> might not produce a valid ShapeMap. This needs to be fixed.

The requirement that no two shape associations in a ShapeMap may have 
the same combination of node and shape simply ensures that a fixed 
ShapeMap is a non-redundant representation of a set of pairs of the form 
(node, label). The identity of shape association is very naturally the 
pair (node, label) that it represents.

As for the process of converting a query ShapeMap to a fixed ShapeMap, I 
do not see how it might produce an invalid ShapeMap: the query ShapeMap 
does not specify a status, so even though the same (node, label) is 
added multiple times during the conversion, it will be represented only 
once.


> Moving on, the definition of isValid is in Section 5.2. There are several
> problems in the definition. First, here the third argument is an "input
> shape map". Is this different from "fixed ShapeMap". 

Changed to "fixed ShapeMap"

Second, although
> strongly connected is a notion generally known in graphy theory circles
> there should be a definition of it in this document, or at least a pointer
> to a definition.

Pointer added to Wikipedia, where anybody could find such standard 
definitions.

  Third, there is the unsupported claim that different
> stratifications lead to the same unique complete typing. This is a
> fundamental part of the semantics here and needs to be demonstrated.
> 

Giving a demonstration in the specification document does not seem 
appropriate. Moreover, for those who the demonstration could be 
interesting, this result should not be surprising: the proof is very 
similar to the one used for defining the semantics of Datalog with 
stratified negation (see e.g. Theorem 15.2.10 in Chapter 15 of 
"Foundations of Databases" by S. Abiteboul, R. Hull and  V. Vianu, 
Addison Wesley, 1994.)

If you in particular need to be convinced, please see the sketch of 
proof attached to this mail and feel free to ask me for clarifications.



> The second note in Section 5.2 is puzzling. isValid takes a input ShapeMap.
> So then why is there a note that the semantics of ShEx are indpendent of the
> construction of the input ShapeMap?


This sentence should be read "the semantics of SheEx is independent of 
the way the input ShapeMap is constructed". We removed this misleading 
sentence.


> There is no requirement that I can see that ShapeMaps be finite. What
> happens to stratification in a ShapeMap with an infinite number of strata?

The ShapeMap spec now contains a requirement that a ShapeMap is finite.

It is the schema and not the ShapeMap that is stratified, and a schema 
is always finite.


> 
> Without clarification or correction of these points I cannot say for certain
> whether this ShEx semantics is well-founded.
> 
> Peter F. Patel-Schneider
> Nuance Communications
> 

-- 
Iovka Boneva
Maître de conférences (assistant professor)
Université de Lille
https://pro.univ-lille.fr/iovka-boneva/