Re: ISSUE-71: second bug tracking example

Hi Henry,

Henry Story <> 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: 

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


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


>  > > The ldp:memberXXX relations would probably best be renamed 
>  > don't necessarily have anything to do with rdf:member. So naming them 
>  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 
>  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. rdf:member is the default value of 
membershipPredicate, which is the property that defines the predicate used 
to link member resources to the container.

Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Received on Wednesday, 29 May 2013 14:56:18 UTC