Re: Issue-71: the first bug tracking example

On 22 May 2013, at 17:25, Roger Menday <roger.menday@uk.fujitsu.com> wrote:

>>>> 
>>>> I have no idea what you mean "define containers without forcing 
>>>> people to change their vocabulary". 
>>>> The question is what is the UC&R for this functionality? Where does 
>>>> it come from? What is the 
>>>> need? (I mean for the protocol) 
>>> 
>>> This is about allowing people to expose existing data in which they have been using something like Nandana's bt:hasBugReport predicate or something similar without forcing them to change the representation of their data to use rdf:member. 
>> 
>> I don't see how we are forcing people to change their data given that the LDP spec
>> is not finished and this is in flux. 
>> 
>>> I don't know that we have this requirement captured in our UC&R. If we don't we should fix this. 
>> 
>> The easiest way to fix this may be to be clearer about what these relations are doing
>> first. 
>> 
>>> 
>>>> 
>>>> The LDP spec is about GET, PUT, POST, DELETE. One whole section of 
>>>> the spec is about how those 
>>>> words are used in resources we call LDPCs . Fine. So it is quite 
>>>> reasonable to ask what the point of 
>>>> ldp:membershipPredicate is. 
>>> 
>>> Yes, it is. But the reason is much simpler than what you seem to think and it has nothing
>>> to do with validation. 
>> 
>> That's a pitty, because that's a good reason. I don't see why the LDP spec
>> needs to otherwise add vocabulary for things that have nothing to do with 
>> adding resources to a container. People can add other relations to a container
>> but what business is it of ours to specify it? 
>> 
>> It is clear from Roger Menday's "membershipObject" thread that these 
>> membershipXXX relations are completely orthogonal to the rdf:member-ship 
>> of a container. To use these relations in a way that would allow us to
>> model things correctly one would end up with something like this:
>> 
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> <> a ldp:Container;
>>   ldp:membershipSubject <#i>;
>>   ldp:membershipOject ??? ;
>>   ldp:membershipPredicate pets:has_pet .
>> 
>> <#i> pets:has_pet <zaza#it>, <zara#it> .
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> so clearly here pets:has_pet has nothing to do with rdf:member anymore. It is
>> doing something completely different. Not something that one needs be against,
>> it is just orthogonal to rdf:member-ship of an LDPC.
>> 
>> Let's then seperate concerns.
> 
> Henry, 
> 
> I would just like to say that one potential solution [1] to issue-72 does NOT to introduce a new membershipObject predicate. 

Indeed, and in that case the whole membershipXXX relations fall by the way too,
since they otherwise push people to bad modelling practices. 

This exercise is proving something I can prove just as well with membershipSubject,
namely that these relations are orthogonal to the rdf:member relations on an LDPC.

The other thing I was trying to proove in my thread on ISSUE-71 is that you can do everything
you want in LDP without these relations. The problem is that people have gotten attached to
this mechanism, without justification. It was never argued to be put into the spec on this list.
We just let it go in in September so that we could move on.

> 
> Roger
> 
> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0195.html
> 

Social Web Architect
http://bblfish.net/