Re: ISSUE-71: second bug tracking example

On 30 May 2013, at 21:08, John Arwe <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

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

Social Web Architect
http://bblfish.net/