Re: About the ldp:xyz relationship

A few remarks (I quote the text from the wiki page):

> There is no harm for a client to infer this relationship.

The SPARQL queries does make it look easy, but this is ignoring the
Named Graphs in which the triples are expected to be found, as
ldp:containerResource is expected to introduce an indirection for
where to find the membership triples. The query could be fixed to
reflect that, but that wouldn't look as easy anymore, and URIs should
be hashless.

> if one were to require this triple, the number of triples would simply double in number in some cases.

This is true under the current conditions. My proposal at [1] proposes
another solution to that problem.


> It is tempting to think that ldp:xyz should simply be ldp:member but that would lead to a contradiction  [...]

I agree.

> Binary/non-RDF resources

Everything is made more complex by the fact that Binary today is not
an LDPR, so you'd have special cases again. My proposals at [2, 3]
try to offer a unified view.



On 12/04/2013 04:51 PM, Arnaud Le Hors wrote:
> In relation to ISSUE-89, I said on Monday's call that I would write down
> how the "managed resources" can be found and the so called ldp:xyz
> relationship can be inferred.
> I revised the wiki page on Membership to accommodate for the three types
> of containers we now have and added a section on the ldp:xyz relationship.
> Please, have a look:
> Note: because wiki pages are by nature mutable, we should be careful not
> to use the link to the latest version as reference, unless that is what is
> indeed desired. Instead we ought to use version specific links as
> references. Otherwise our archives will end up with a bunch of
> broken/useless references.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Received on Thursday, 5 December 2013 20:07:21 UTC