ISSUE-75 Non-montonic - was: ISSUE-71: second bug tracking example

On 30 May 2013, at 22:41, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Henry Story <henry.story@bblfish.net> wrote on 05/30/2013 01:09:17 PM:
> 
> > ... 
> > 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! 
> 
> I agree we don't want to break RDF semantics. The fact that we don't want LDP to depend on inferencing doesn't mean we should prevent anyone from using it either. 

Completely agree there.

> 
> This being said, I think there are ways you can address the monotonicity issue and keep membershipPredicate. We could require membershipPredicate to be specified rather than have a default value for one, couldn't we?

Perhaps that could do the trick.... Let's explore.

You'd have to do the same thing for ldp:membershipSubject then too. And as ISSUE-72 points out, 
there are reasons to believe that without an ldp:membershipObject the job would not be finished.

It would mean that even in order to describe a basic container which currently we have
been describing in one triple { <> a ldp:Container . } you would need

  <> a ldp:Container;
       ldp:membershipSubject <> ;
       ldp:membershipProperty rdf:member ;
       ldp:membershipObject <??> .

This seems very heavy, and somewhat bizaare. 

1. It looks like somehow we have something that feels like reification here 
    http://www.w3.org/TR/rdf-schema/#ch_reificationvocab
    since we have xxxSubject, xxxProperty, xxxObject relations ....

2. It feels odd that one has to specify the relation that indicates membership, even
    in the default case. Let me suggest that we help ourselves to ISSUE-79 
    ldp:contains here, which we define as THE relationship of ldp containement.
   So instead of saying that we can switch between different "containement relations" that
   are not in fact anything about containement,  let us think of this rather as saying that we 
   can create rules that allow us to deduce ldp:contains relations from what exists.
  
How come we ended up here?  The above leads me to believe that we have
a modelling problem...

So we want it to be the case that when we read 

  <> ldp:contains <member> .

we don't need any more relations to conclude that <member> was created by the 
LDPC <>  . I suggest you turn things around and instead of thinking of different 
"membership relations" you think of one ldp:contains relationship and different 
rules that allow us to infer that relation. So I would suggest instead

  <> a ldp:Container;
       ldp:creationRule [ subject <source>;  property ex:attachment ] .

The reification make sense if one thinks as it being just a way to
fill in a query such as this one

  CONSTRUCT { <> ldp:contains ?ldpr } 
  WHERE {
     ?subject ?property ?ldpr.
  }

And then one can see how one could easily have more than 
one such rule, where the current spec 
ldp:membershipXXX relations only allow one ( and not even that
since there seems to be an inconsistency in the definition of those
relations that leads us to ISSUE-75 ).


Now here the "default rule" we were looking for is simply the 

 <> a ldp:Container;
       ldp:creationRule [ subject <>;  property ldp:contains ] .

ie the following

  CONSTRUCT { <> ldp:contains ?ldpr } 
  WHERE {
     <> ldp:contains ?ldpr.
  }


And it is clear here why this can be left out, why it need not
be said.

Henry


> 
> 
> > 
> > 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? 
> 
> Let's not jump the gun. I haven't heard anyone say we should ignore the issue. I certainly don't plan to! :-) 
> 
> > 
> > Henry 
> > 
> > Best Regards, John
> > 
> > Voice US 845-435-9470  BluePages 
> > Tivoli OSLC Lead - Show me the Scenario 
> 
> > 
> > Social Web Architect 
> > http://bblfish.net/ 
> 
> 
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 

Social Web Architect
http://bblfish.net/