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 <johnarwe@us.ibm.com 
> <mailto:johnarwe@us.ibm.com>> 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
> https://www.w3.org/2012/ldp/track/issues/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

+1

Kingsley
>
>>
>> Best Regards, John
>>
>> Voice US 845-435-9470 BluePages 
>> <http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe> 
>>
>> Tivoli OSLC Lead - Show me the Scenario
>>
>
> Social Web Architect
> http://bblfish.net/
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen