Re: Networth example with ldp:contains

Hi Roger,

On 01/13/2014 12:39 PM, Roger Menday wrote:
>
> hello,
>
> Following up on the long call this afternoon ...
>
> In the following two examples, where/why is it necessary to use client preference for materializing ldp:contains ?
>
> 1. 'DirectContainer' case (such as a Networth in the spec):
>
> <>
>     a o:NetWorth;
>     o:netWorthOf <http://example.org/users/JohnZSmith>;
>     o:asset
>        <assetContainer/a1>,
>        <assetContainer/a2>;
>     o:liability
>        <liabilityContainer/l1>,
>        <liabilityContainer/l2>,
>        <liabilityContainer/l3>.
>
> <assetContainer/>
>     a ldp:DirectContainer;
>     dcterms:title "The assets of JohnZSmith";
>     ldp:containerResource <>;
>     ldp:containsRelation o:asset.
>
> <liabilityContainer/>
>     a ldp:DirectContainer;
>     dcterms:title "The liabilities of JohnZSmith";
>     ldp:containerResource <>;
>     ldp:containsRelation o:liability.
>
> POSTing to  the LDPCs (<assetContainer/>, <liabilityContainer/>) creates new Assets and Liabilities.
> The response has the Location: of these newly created resources.
> If I GET the LDPR, I see domain-specific <asset> and <liabilities> triples.
> If I GET the LDPC, I see ldp:contains triples.

You're right, if the server does not inline the content of the
containers (or does it partially) when dereferencing the
hashless-ContainerResource, then thanks to the LDP Named Graphs
resolution [1] you're not supposed to see the containment triples for
this specific example, because the containment triples and the
membership triples would belong to different Named Graphs.

That being said, there might be other scenarios where this can be
still an issue. I tried to come up with realistic examples for
FOAF/WebId profiles, but I always end up having my containers being
completely dissociated from the hashless-ContainerResource, just being
the ContainerResource is often meant to be part of an LDPR.

So after some thinking, it seems to me that the duplication of triples
is an actual issue only when the following conditions are met:

* the LDPC is a DirectContainer or an IndirectContainer
* the hashless-ContainerResource is itself the Container
* the membership predicate is overriden (no longer ldp:contains)
* there are "too many" members/contained resources

I don't understand why one would want to inline the containment
triples where dereferencing the hashless-ContainerResource. At least
the specification does not ask for that behavior, so I consider that
as an non-issue for now.

That being said, being able to opt-out from the membership triples
(when GETting the hashless-ContainerResource) and/or the containment
triples (when GETting the Container) might be something interesting,
and not difficult to specify.

Alexandre.

[1] http://www.w3.org/2012/ldp/wiki/Issue-90#PROPOSAL_2:_LDP_Named_Graphs

>
>
> 2. 'SimpleContainer' case:
>
> <>
>     a o:Box, ldp:SimpleContainer;
>     o:boxOwner <http://example.org/users/JohnZSmith>;
>     ldp:contains
>        <item/m1>,
>        <item/m2>;
>
> In this case, the LDPR and LDPC are the same thing, and by the ldp:contains triples are found when GETting.
> There isn't a duplication issue.
>
> Roger
>
>
>

Received on Monday, 13 January 2014 19:23:31 UTC