- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Fri, 22 May 2015 13:15:26 -0700
- To: Arthur Ryman <arthur.ryman@gmail.com>
- CC: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/22/2015 11:16 AM, Arthur Ryman wrote: > Peter, > > On Thu, May 21, 2015 at 6:12 PM, Peter F. Patel-Schneider > <pfpschneider@gmail.com> wrote: >>>> This document provides a particularly bad support for recursive >>>> definitions because the running example can be easily handled >>>> without recourse to recursive definitions, > By "support" I assume you mean supporting > evidence/justification/motivation. I agree. I crafted the running example > to be small and to illustrate the definitions. I refer to the example as > "highly simplified". > > Your comments are valid. I think the article would be improved if it > included a real-world example too. To be convincing, the example should > make use of recursion in a non-trivial way in the sense that it could not > be expressed by your SHACL-SPARQL proposal. At this point I conjecture > that such an example exists. It would be very instructive to have an > example that can be expressed in something as simple as Resource Shape > 2.0, but that is not expressible as a single SPARQL query. If you already > have such an example, please share it. Otherwise I'll try to construct > one. I don't know if there is a real example of something that cannot be handled by the SPARQL solutions. Even when I try to concoct examples that cannot be handled by the SPARQL solutions I end up failing. For example, it is possible to iterate over all non-literal nodes in an RDF graph via { ?this ?p ?that . } UNION { ?that ?p ?this .} FILTER ( !isLiteral(?this) ) >> The running example can easily be handled using SPIN, for example, >> without any definitions, shapes, or constraints that reference back to >> themselves. > I am not a SPIN expert. I thought SPIN constraints were associated with > the rdf:type of a node which I assume would be problematic since both > "contacts" and "associates" are foaf:People. Do you have the SPIN > implementation at hand? Remember that in SPIN you can use raw SPARQL. Just turn what I provided as a non-recursive recasting of the problem into SPARQL queries. The hard part is handling the existential condition, but that can be done via a global constraint that constructs a violation if a global condition is met, something like CONSTRUCT { _:b0 rdf:type spin:ConstraintViolation . } WHERE { VALUES ?this { ex:error } FILTER NOT EXISTS { ?that rdf:type foaf:Person . ... . } [...] > -- Arthur peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVX45eAAoJECjN6+QThfjzEdoIAMDcnOvOxMiFdrr7XHjFz9KJ ujA+5qn6d8BXk15/lnUTe3cgXvaQy1zpOXTk6+ldOT2ex5g0bb2L37H0Ql23RR/d 7Pj47DH5PYYuiFdxefmN14LqRGIHbft9tatUfISvB6tV4YYEu2sJWNivPJlCQjee JegWYwDN2OsX/EIVDW0lnetMJKPPVkvX8zMVvfEKPQyXLFhTux4R6CLG3/EkguB3 58CNyd51C3VGGUB9To8DEBi+QE3QvHtra/0SF7M5IRPNsN2fWvpjcx8LvljzbmJO tUouzkJ+dtkzNCdSV+5zv9vYl896gAQdmK5BQvrCZxF7FopClVj1pRV/RmPqcLg= =aaSS -----END PGP SIGNATURE-----
Received on Friday, 22 May 2015 20:15:57 UTC