Re: [ANN] Shape Expressions 2.1 release candidate

Dear Peter,

Thank you again for the time you spent reviewing the ShEx specifications.
<https://lists.w3.org/Archives/Public/public-shex/2019Mar/0006>

The CG sees the ShapeMap specification orthogonal to ShEx and these two are
considered independent in terms of publication. We hope to publish the ShEx
specification in the next couple weeks so we can proceed with our work on
`EXTENDS` (we have tests and implementations and would like to publish the
semantics shortly).

About the ShEx 2.1 candidate recommendation comments

> On Wed, 20 Mar 2019 09:22:32 -0700, pfps wrote:
>
> The discussion of triple patterns mentions "a known token to identify
> the focus node".  I don't see any discussion of how this is done.  The
> phrase "known token" does not appear anywhere else in the document.

See <https://shexspec.github.io/shape-map/#shapemap-structure>

``` shape: ShEx shapeExprLabel or the string "START" for the start shape
expression. ```


> There is no definition of "match", needed to turn a query ShapeMap
> into a fixed ShapeMap.  (Of course, this is almost certainly taken
> from SPARQL, but there needs to be an explicit statement to this
> effect.  I'm going to go out on a limb and make the assumption that
> "match" is taken appropriately from SPARQL.)

In addressing your feedback on the ShapeMap specification (that is not yet
published) we switched from using SPARQL matches to a definition in the
document (see Merge Request: <https://github.com/shexSpec/shape-map/pull/17>).
We hope to create the first release of the ShapeMaps specification in the
following months but any early feedback you may have would be of course
greatly appreciated.


> It should be stated somewhere that ShapeMaps can contain actual RDF
> nodes, which can be blank nodes (and not blank node IDs).  What is the
> syntax for this?  It doesn't show up in the ShapeMap grammar.

<https://shexspec.github.io/shape-map/#prod-subjectTerm> now says
```
[4 ]    subjectTerm    ::=    iri | BLANK_NODE_LABEL
```


> It is still the case that the map from query ShapeMaps to fixed
> ShapeMaps might fail.  This problem needs to be addressed.

The CG considered this and didn't see an improvement over the current
set-based semantics. Please see the first resolution in <
https://github.com/shexSpec/shex/blob/master/meetings/2019/20190424-minutes.md
>:
```RESOLVED: the note in ShapeMap usage <
https://shexspec.github.io/shape-map/#usage> addresses pfps's issue "It is
still the case that the map from query ShapeMaps to fixed ShapeMaps might
fail.">.```


> With all the problems above there doesn't seem to be any reason for me
> to even look at the longer document.

Note that the CG considers the Shape Expressions specification as a
stand-alone specification. ShEx semantics simply rely on a fixed ShapeMap
which is a set of node/shape pairs and thus, we consider that any possible
remaining issues on the ShapeMaps specification are non-blocking for the
ShEx 2.1 publication.

The CG would like to proceed with the ShEx 2.1 publication in the next two
weeks. We will welcome any other feedback you may have on the spec prior to
publication. Of course, the CG will consider a short extension if you would
request more time.

Best regards,
Dimitris, on behalf of the CG

On Wed, Mar 20, 2019 at 6:23 PM Peter Patel-Schneider <
pfpschneider@gmail.com> wrote:

> As far as I can tell these documents have had no review within the group.
> If so, there is something seriously wrong.  Revisions to group
> documents should be receiving expert review within the group before
> they are sent out for external or general review.  I do not consider
> these documents ready for release until they have received expert
> review from within the group.  Nonetheless, I started a review and
> here are some comments.
>
>
> This is a review of https://shexspec.github.io/shape-map/ dated 30
> January 2019 which I take to be the current draft of the definition of
> ShapeMaps.
>
> The discussion of triple patterns mentions "a known token to identify
> the focus node".  I don't see any discussion of how this is done.  The
> phrase "known token" does not appear anywhere else in the document.
>
> There is no definition of "match", needed to turn a query ShapeMap
> into a fixed ShapeMap.  (Of course, this is almost certainly taken
> from SPARQL, but there needs to be an explicit statement to this
> effect.  I'm going to go out on a limb and make the assumption that
> "match" is taken appropriately from SPARQL.)
>
> It should be stated somewhere that ShapeMaps can contain actual RDF
> nodes, which can be blank nodes (and not blank node IDs).  What is the
> syntax for this?  It doesn't show up in the ShapeMap grammar.
>
> It is still the case that the map from query ShapeMaps to fixed
> ShapeMaps might fail.  This problem needs to be addressed.
>
> With all the problems above there doesn't seem to be any reason for me
> to even look at the longer document.
>
>
>
>
> I pullled out an exchange about ShapeMaps from previous email:
>
> > Iovka
> > > pfps
> >
> > > 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.
>
> It appears that you are not even bothering to read the documents of
> the group.  The second part of Example 1 has a ShapeMap with two
> identical shape associations that is clearly stated as invalid.  So
> it is definitely the case that adding the same (node, label) multiple
> times does indeed end with an invalid ShapeMap.
>
> Peter F. Patel-Schneider
>


-- 
Kontokostas Dimitris