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

hello arnaud.

thanks for your response!

On 2013-05-29 14:12 , "Arnaud Le Hors" <lehors@us.ibm.com> wrote:
>"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?

yes, but then interactions are not really that stateless anymore. let's
say i am implementing a migration client, and i am reorganizing while i am
doing this. so i am going through containers, GET their contents, and then
POST them to others. now if i tell applications that have been working
with these resources so far that they should have actually kept around
state about the resources, instead of just relying on being able to GET
them whenever they need them, then this may couple them unnecessarily to
the context of the resources.

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

you're absolutely right that this is not a scenario we have captured. i
would think that it would be very useful to be able to do that, but i see
that this pretty much contradicts the goals of the membership predicate.
the goal of the membership predicate is that people don't have to change
their existing data. on the other hand, if you're not willing to bring
your data into standardized form, you cannot expect to be able to simply
mix things.

i guess in the end it's about balancing these issues. personally, i think
i would rather have some upfront work and bring data into standardized
form and then be able to freely mix things, but that's definitely just a
preference.

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

yup, pretty much. that's where a huge share of atom's value comes from:
providing a platform for how people can handle data in a unified way.

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

why not, when you're trying to archive the list of things that you
captured when you were working on a project? or if you have two bug
trackers and want to join them, but they are using different bug models, i
would still expect to be able to create just one bug container. of course
clients would need to expect to different kinds of bugs in there, but i
think it might be useful if you could merge the two bug containers and
then start working from the assumption that to make sense of all of the
bugs, you need to know those two bug models.

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

yup, you're right that the analogy is only half-baked. but it's partly
accurate when you think of (sorry for more XMLish things) the difference
between the XPath /feed/entry or /feed/*[matches(local-name(),
../@entry-element)], and those naive clients that will simply code
/feed/whatevermakesyouhappy and then break when the mapping changes...

cheers,

dret.

Received on Wednesday, 29 May 2013 22:58:20 UTC