- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 20 May 2015 18:44:07 -0700
- To: Arthur Ryman <arthur.ryman@gmail.com>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 certainly not a fixed-up version of the Z-based semantics in the Shape Expressions member submission. The approach builds up a minimal set of labellings, which is different from Iovka's approach and from Jose's approach. In the approach it is not possible to require that some neighbour has a constraint, only that all of them do. 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. 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. 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. This document provides a particularly bad support for recursive definitions because the running example can be easily handled without recourse to recursive definitions, via 1/ there is a node that has type foaf:Person and exactly one foaf:name 2/ all the foaf:knows edges from the contact terminate at nodes - that have type foaf:Person, and - have only one incoming foaf:knows link. The exposition of the running example permits graphs where the contact is the associate. The document uses "unique name" where it could be misread to mean that name is a key. 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. peter On 05/20/2015 05:35 AM, Arthur Ryman wrote: > I just posted an article that formalizes the kind of recursion that > Resource Shape 2.0 supports. [1] It therefore also covers a subset of the > kind of recursion that SHACL(Holger) and SHACL(ShEx) supports. I believe > this kind of recursion could be added to SHACL-SPARQL(Peter). > > The article is language-neutral in the sense that it does restrict how > constraints are specified. It uses Z Notation, but I've attempted to keep > it as simple as possible, and I've illustrated every definition with a > running example. > > In the interest of having a stable version, I've posted it on arXiv. I'd > appreciate feedback and will include corrections or improvements in the > next version. Thanks. > > [1] http://arxiv.org/abs/1505.04972 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVXThnAAoJECjN6+QThfjzFYcIAMnryB6YvPWejQu5Kg2KPbIt RnUh/j62xJBVJ3Gp9d1E2XBPAJhw4ebh3L/W5KCIl8RLMH4Eew6Er8apyGOSXSHy q8ewJTp11eOMiO7Uucm95Il5EQJpHQes3n4OeGtG5zqON9lt00SwPtS5RDZTHAp6 qybj3BIH9TjFGA7f+TWfKDo7rGeXVOhKvhW98X/P76nYSoTD74bjKYzIUlA+kATy KLtx7LYWAO2irrS83ZldHw75M6rI07hXB/EdL6RLLyiwZjU7V0br+/hL3ckcgoR/ vWC/qEJNP+KRfMsWlm+LLBTf12GALB8yt1atd+vj7ljg75M9Kvmwt3MgzITjVGQ= =hLPn -----END PGP SIGNATURE-----
Received on Thursday, 21 May 2015 01:44:43 UTC