Re: Missing use case for supporting ldp:membershipPredicate/Subject

hello arnaud.

thanks a lot for your response. it seems like now i can challenge you even
more ;-)

On 2013-05-29 11:21 , "Arnaud Le Hors" <lehors@us.ibm.com> wrote:
>I agree that the container in which you find each resource provides a
>context but I don't see how using membershipPredicate makes a difference
>in this regard.

because the relationship between containers and members is part of the LDP
data model, and may or may not introduce some side-effects if you do not
have a standardized (i.e., non-indirect) way to represent it. more below...

>If all you do is archive the resource rather than the container you find
>it in you lose whatever context comes from the container. This is true
>for the membership predicate used as well as any other information the
>container may have about the resource.

that's true, but most information is either not standardized (in which
case you cannot reasonably expect that it is interoperable between
containers), or should be standardized, so that containers are
interoperable.

>> 
>>If you GET any of the resources a1, a2, l1, l2, and l3 and add them to
>>your own container you would have the exact same result as if the above
>>was structured to use rdf:member only.

true, to some extent. but you lose the membership predicate, right?
wouldn't you expect that maybe this predicate matters to clients? or asked
differently: if clients wouldn't care about losing this information, then
why introduce the indirection model and its complications in the first
place. maybe another scenario can make this more clear:

let's assume i have three LDPC using different membership predicates. how
do i merge them? that's a slight variation of the question i asked before,
but maybe better illustrates the problem. if the membership predicate
matters, i would assume you cannot merge them without losing information.

one of the signs that a standard is nicely interoperable is to look at
these examples of how to compose things in ways that i would expect to
work in scenarios where i am using standards, and want to start combining
things that are based on those standards. when there are certain things i
cannot do (even though everything is following the standards), i think
that's at least something that deserves a very close look.

[[ TLDR: given my XML background, to me this looks as if atom had said
<entry> is not an actual element, but instead in each feed you find
something like <feed entry-element="whatevermakesyouhappy">, and then you
have to process <whatevermakesyouhappy> elements in that particular feed
(and you have to rewrite entries when you are trying to ever take entries
out of their original context). sorry for the feed reference! but: i guess
a design like this would not make it very far as a proposed standard in an
XML environment. i am still trying to understand whether this is just
something that feels pretty awkward in XML, or whether the RDF variant of
this pattern in LDP actually is the same. my concern is that if this is
the same pattern, and atom had been designed this way, i am pretty sure it
would have failed. is the LDP pattern different? if not, is there anything
in RDF that makes us confident that while this probably looks like a bad
idea in XML to most people, in RDF it actually is not a problem? ]]

thanks and cheers,

dret.

Received on Wednesday, 29 May 2013 20:20:09 UTC