- From: Arthur Ryman <arthur.ryman@gmail.com>
- Date: Thu, 21 May 2015 16:38:36 -0400
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>

Peter, Thanks for the careful review. I'll incorporate your suggestions into the next version. On Wed, May 20, 2015 at 9:44 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote: > This is an entirely new approach. It builds on none of the proposals in the > working group and does not appear to be compatible with any of them. It is a precision definition of recursion as allowed in Resource Shape 2.0, and therefore covers a subset of the proposals insofar as they are a superset of Resource Shape 2.0. Therefore whatever semantics are defined for SHACL, it should reduce to this on the intersection with Resource Shape 2.0. > The interface to the approach starts with a node and a shape for that node > and determines whether that node can belong to the shape. There are no > options to start with multiple nodes and shapes, or any of the other options > in the various approaches, such as scoped shapes. Correct. In Resource Shape 2.0 there is always a start node and a start shape. However, allowing multiple start nodes is a matter of forming the conjunction (intersection) of the constraints defined by each node. Similarly, if the meaning of multiple shapes is conjunction, then the constraint is the conjunction. > The approach has a very large number of moving parts, with neighbour > functions, constraints, shapes, data graphs, neighbour graphs, labelled > graphs, and constrained graphs. This seems to me to be too much machinery > for the task at hand. Agreed, there are a lot of definitions. I can reduce the number of definitions (effectively doing a macro expansion), but then logical formulae get larger and harder to understand. > I do not understand why the PIM application "enforces" a particular > constrained graph. Surely that is what is supposed to be determined by the > approach, not what is input to the approach. The requirements for the PIM application are given. The article shows how they translate into a shape. > This document provides a particularly bad support for recursive definitions > because the running example can be easily handled without recourse to > recursive definitions, Agreed. The recursion is only apparent. The shape appears to have circular references, but the actually meaning is obtained by labelling nodes with the names of the node constraints they must satisfy. > The exposition of the running example permits graphs where the contact is > the associate. I don't think so. The contact is not known by any person so it violates the associate constraint. > The document uses "unique name" where it could be misread to mean that name > is a key. Agreed, wrong wording. I meant that the names are distinct. > SPARQL 1.1 path expressions are much more general than path expressions, > which appear to be just properties and inverses. A different name should be > chosen. Agreed. I was going to call them "simple path expressions". I should do that to avoid confusion with abritray SPARQL 1.1 path expression. -- Arthur

Received on Thursday, 21 May 2015 20:39:03 UTC