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

I think merging containers is a good usecase.
The data formats should be general enough to support such usage.
All the best, Ashok
On 5/29/2013 6:57 PM, Wilde, Erik wrote:
> hello arnaud.
> thanks for your response!
> On 2013-05-29 14:12 , "Arnaud Le Hors" <> wrote:
>> "Wilde, Erik" <> 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 23:26:54 UTC