Re: ISSUE-71: second bug tracking example

On 29 May 2013, at 16:55, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi Henry, 
> 
> Henry Story <henry.story@bblfish.net> wrote on 05/29/2013 07:18:39 AM:
> 
> > ... 
> > There are two things: 
> >   1. members of an LDPC are added via the rdf:member relation 
> >   2. other relations that get added when you POST content to an LDPC: membershipXXX 
> > 
> 
> I believe what you're suggesting is similar to the way we considered resolving ISSUE-59 (option B) [1] and the WG decided against it [2]. 
> 
That issue was 

ISSUE-59: Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior

In any case I don't think I ever saw an argument made in that discussion which revolved around membershipXXX properties.
How do you make the relation?

> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0123.html 
> [2] http://www.w3.org/2013/meeting/ldp/2013-04-29#resolution_5 
> 
> As the minutes show I personally preferred that way too but the WG decided against it and I'm not convinced you've made the case for reversing that decision. 
>     
> >  It's up to you to specify what the point of adding those relations is. There is nothing in the UC&R for it, so I can't 
> >  really tell, and their addition was not discussed in this WG. 
> 
> I think it's fair to say that the UC&R may not cover every use case and requirements the Member Submission addressed and which we have inherited. This has been acknowledged. But Steve has sent an email [3] explaining the motivation for membershipPredicate/Subject to fill in that gap so I don't think it helps to keep repeating there is no use case for it. 

That is a proposed use case, not an existing one. I see that Alexandre Bertails has been
critical of it. I need to read it in detail. I don't think you can assume that the proposed
use case will address this issue. Or is the idea to keep tweaking the use case until it makes
the required point? That would seem to be the opposite of what use cases are designed for.
I'll look at that proposal in detail next.

> 
> [3] http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0250.html 
> 
> >  > > The ldp:memberXXX relations would probably best be renamed 
> >  > don't necessarily have anything to do with rdf:member. So naming them that 
> >   
> >  That's cognitively interesting.  I see you stop reading after member.  I stop after 4 additional letters (-shipXXX).  See the world in a grain of sand. 
> >   
> >   
> >   
> >  ldp:relationshipPredicate, ... would also be fine. As Arnaud has pointed out a few times on this list an ldp:relationshipPredicate 
> >  object need not be a subProperty of rdf:member. 
> 
> I have said that indeed. This doesn't mean membershipPredicate has nothing to do with rdf:member.

I wrote: 

[[
As Arnaud has pointed out a few times the relations one can create with these [ie: rdf:membershipProperty ]
don't necessarily have anything to do with rdf:member. So naming them that way is very confusing.
]]

I said "does not necessarily have anything to do with".


> rdf:member is the default value of membershipPredicate, which is the property that defines the predicate used to link member resources to the container. 

Yes it is true that everything is related to everything by some relation. But it is misleading
to make the name of the property be so closely tied to the default, as to make one conclude
that it is much more tightly related than it is in fact.

> 
> Regards.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 29 May 2013 15:53:22 UTC