Re: ISSUE-71: second bug tracking example

On 5/30/13 4:09 PM, Henry Story wrote:
> On 30 May 2013, at 21:08, John Arwe < 
> <>> wrote:
>> > I am saying there is no restriction the Range of the
>> > ldp:membershipSubject Property. So it can be any resource, right?
>> *that* I can agree with.
>> > 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
>> >
>> > 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.
>> rdfS:member, and yes *if we assume* in-flight proposals to redefine 
>> the spec are resolved as you wish.
>> In the submission and in the current spec, those relations replace 
>> the subject/predicate of the membership triples.
>> Saying there's nothing in UC&R is irrelevant, UC&R is about ... lemme 
>> see... Use Cases and Requirements.  It's function is not to specify 
>> syntax.
>> Saying their addition was not discussed with the WG is pretending the 
>> world is other than it is.
>> We've had the questions, discussions in the WG more than once, (and 
>> there are examples in the spec+submission to motivate them).  You 
>> might not find them sufficiently convincing for your personal tastes, 
>> but that's a different matter.
> Look, it is not my personal taste. Please look at the note of issue-75
> "non-monotonic ldp:membershipXXX "
> which shows that you have serious logical flaws in the system
> currently: you break RDF semantics!
> So I am sure you can do what you want to do without breaking
> RDF semantics. It would be pretty bizzaare that you had found
> a way of doing things that expressed something that could
> not be expressed in something more powerful than first order
> logic.
> Now it would have helped if people had looked at that before
> and pointed it out. But well I only just recently got to look
> carefully at this issue. And though I have had a suspicion
> about it for a long time, I can't deal with every issue
> simultaneously. As I started digging we found more and more
> issues with this. Initially I just gave you the initiators the
> benefit of the doubt. After all you did a very good job
> with the spec.
> But not every problem is just a simple matter of taste decision.
> This one is a core issue. Now the question is: is there enough
> time to solve the problems, or should we perhaps defer this till
> a next verion? Or do you want to have the whole spec rejected
> in final call because you break major core founding spec of the
> W3C?
> Henry


>> Best Regards, John
>> Voice US 845-435-9470 BluePages 
>> <> 
>> Tivoli OSLC Lead - Show me the Scenario
> Social Web Architect



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:

Received on Thursday, 30 May 2013 20:28:33 UTC