- 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