Re: [shex] semantics of recursive shapes ill-founded (#84)

This is a very different semantics from the previous semantics for ShEx.  It
is not easy to tease out all the aspects of the 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 associations with the same nodeSelector and
shapeLabel.  This does not rule out a ShapeMap that would associate a node
in an RDF graph with two different shapeLabels.  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 give a certain
answer as to whether the ShEx semantics is no longer ill-founded.


-- 
GitHub Notification of comment by pfps
Please view or discuss this issue at https://github.com/shexSpec/shex/issues/84#issuecomment-441281489 using your GitHub account

Received on Friday, 23 November 2018 16:31:18 UTC