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

El 30/05/13 01:26, Ashok Malhotra escribió:
> I think merging containers is a good usecase.
> The data formats should be general enough to support such usage.
> All the best, Ashok


I totally agree with the need for such use case.

One important feature of RDF is that it provides a straightforward way 
to aggregate data from different sources.

Kind regards,

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


Dr. Raúl García Castro

Ontology Engineering Group
Departamento de Inteligencia Artificial
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19

Received on Thursday, 30 May 2013 06:46:28 UTC