Re: [ANN] Shape Expressions 2.1 release candidate

Thank you for your feedback Peter,

We will take all the points you raised and try to address them in the
following CG meetings

Best,
Dimitris

On Tue, Nov 27, 2018 at 3:48 PM Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> [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.
>
> 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.
>
> 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". 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. 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.
>
> 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?
>
> 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?
>
> 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
>
>

-- 
Kontokostas Dimitris