Re: Recursion in RDF Data Shape Languages

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