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

On 5/31/13 7:56 AM, Henry Story wrote:
>
> On 30 May 2013, at 22:41, Arnaud Le Hors <lehors@us.ibm.com 
> <mailto:lehors@us.ibm.com>> wrote:
>
>> Henry Story <henry.story@bblfish.net 
>> <mailto: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

+1

Kingsley
>
>
>>
>>
>> >
>> > 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/
>


-- 

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