Re: ISSUE-58: the simple solution to inlined membership

On 20 May 2013, at 01:42, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Henry Story <henry.story@bblfish.net> wrote on 05/19/2013 12:49:06 PM:
> > ... 
> > 
> > The point is that inlining other resources is merging information 
> > from different graphs. That requires either 
> > 
> >  1. the server to know that the graphs that are members are all consistent 
> >  2. the client to know that when it POSTs something it is POSTing 
> > something that is compatible with the content 
> >    of all the members 
> >  3. the inlined content to be carefully quoted 
> > 
> > Neither of 1 or 2 those is something that can be done easily without
> > creating problems. Mechanically it can be 
> > done easily but you'll very quickly end up with inconsistent graphs.
> > It is not easy for either the server to do 
> > it correctly or the  client to do it correctly. Especially as the 
> > client will have difficulty having a full overview 
> > of the all the members. 
> 
> As it has been pointed out before inlining is optional and servers that don't know how to do it just shouldn't. 
> I can see how this might be challenging in a vanilla implementation where the server merely stores triples blindly to regurgitate later but in the case of an application specific server it is not. 

You can mechanically do that easily Arnaud, as I have said on this thread numerous times. The problem
is not with the mechanism, it is rather that you will very likely end up with something that is not at
all what you intended to say, and even often turn a truth into a falsehood.

I showed that in the part 2 my response to Ashok Malhotra, which I think provides the best summary
of my position:

http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0143.html


> Take for instance the case of a bug tracker in which I have a container listing all the bugs related to a given project. Inlining can be done without problems. If it can't then the server has a serious bug somewhere.


Say  you have  two simple bugs <bug1> and <bug2>

<bug1> log:semantics {
 <bug1> foaf:primaryTopic <bug1#it> .
                                            <bug1#it> causedBy <bug2#it> .
}

<bug2> log:semantics { 
  <bug2> foaf:primaryTopic <bug2#it> .
                                            <bug2#it> causedBy <bug1#it> .
}

That is there seems to be a bit of a disagreement about which bug caused
which, something I doubt would be uncommon in a bug system.

Now if we inline the members the LPDC would say

<> rdf:member <bug1>, <bug2> ;
     ldp:memberInlined <bug1>, <bug2> .

 <bug1> foaf:primaryTopic <bug1#it> .
                                            <bug1#it> causedBy <bug2#it> .

  <bug2> foaf:primaryTopic <bug2#it> .
                                            <bug2#it> causedBy <bug1#it> .
 

Whereas before hand one had two documents that contradicted
each other, which is fine - people can disagree - we now have one
document that contains a contradiction, and furthermore one does not
know where that came from by looking at the graph.

To make that last claim clearer assume 

  :causedBy owl:inverseOf :causes .

then you can see that the above graph is equivalent to 

<> rdf:member <bug1>, <bug2> ;
     ldp:memberInlined <bug1>, <bug2> .

 <bug1> foaf:primaryTopic <bug1#it> .
                                            <bug1#it> causes <bug2#it> .

  <bug2> foaf:primaryTopic <bug2#it> .
                                            <bug2#it> causes <bug1#it> .


But if you just follow that graph structure from <bug1> via the primaryTopic to <bug1#it>
and then via causes to <bug2#it> then you are not in fact using a relation that was
contained in the <bug1> resource, but one that was declared in the <bug2> resource.

I think I could come with an infinite number of example of the same type.

	Henry

Social Web Architect
http://bblfish.net/