Re: Recursion in RDF Data Shape Languages

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.

> 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?

>
>>> 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.
>
> Not if the contact knows itself.
Good catch! Resource Shape 2.0 is incapable of ruling that out. It is
worth mentioning that in the article. It illustrates the limited
expressive power of any fixed set of high-level constraints. The PIM
application has to enforce that kind of constraint with custom
application code or use SHACL, etc.

>>> 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.
>
> Huh?  The constraint indicates different, saying that there is one name per
> x, not that the name is distinct in any way.
D'oh! I didn't read the whole text.
Reading more carefully this time, I assume you are referring to p.10 ,
definition of "has_one_name". The sentence is "Both contact and
associate nodes must have unique names."
The intention here is simply that they each have exactly one name. I
will change the text to read: "Every contact or associate must have
exactly one name."

-- Arthur

Received on Friday, 22 May 2015 18:16:27 UTC