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

"Wilde, Erik" <Erik.Wilde@emc.com> wrote on 05/29/2013 01:19:27 PM:

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

If it does shouldn't they simply worry about saving more of the 
context/container?

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

This is an interesting point but being able to arbitrarily merge 
containers isn't a requirement that has been expressed as far as I know, 
so I don't think I would take this as a criteria for the quality of the 
standard.

Is that what you meant by interoperable containers at the beginning? I 
have to admit not to quite understand what you meant by that. Is it the 
ability to take any resource from one container and put into another - any 
other -?

Isn't that very application specific though? I don't see how that could 
always make sense. If I have a list of bugs on one hand and a list of 
requirements on the other I don't expect to be able mix the two.

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

I think I agree with that description although I'm not sure about the 
"rewrite entries". I think there is still a disconnect on that level 
because in LDP, as the spec current stands, there is no entries. Member 
resources are directly linked from the container.
I do think that RDF is very different from XML in regard to how much 
flexibility is expected.

> 
> thanks and cheers,
> 
> dret.
> 
> 

Cheers!
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group