Re: Issue-89, proposal 3: Duplication of triples & inferencing

On 13 Dec 2013, at 22:02, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Henry Story <henry.story@bblfish.net> wrote on 12/13/2013 12:24:13 PM:
> 
> ...
> >   The complexity in this group has clearly arisen through the 
> > introduction of the 
> > ldp:memberXXX relations, which I am still trying to get to the bottom of. 
> 
> As you know this was part of the initial specification so speaking of its "introduction" doesn't quite make sense. The difficulty didn't arise from its "introduction", it has arisen from people having other needs than what this provided for. As I've said repeatedly, if anything, the one thing that has made things much more complicated is the introduction of MembershipObject. It's with the introduction of this additional parameter that we lost the one to one mapping member - resource. 

I see the introduction of the ldp:MembershipObject as just a consequence of the initial introduction of the other
relations. But in any case we were here speaking of the ldp:DirectContainer, which has no MembershipObject.

> 
> > Sometimes it happens that ideas that seem good at first are not as 
> > good as they seemed
> > after using them.  What I am doing here is to try to get to the 
> > underlying need
> > for them. 
> 
> Unfortunately, you don't seem to understand it, despite having this need been repeated many times
> through the last year and a half. 

The need is under discussion here.

> 
> > 
> >   After looking at Rogers example I showed that it could be reduced elegantly
> > to an ldp:SimpleContainer, ( which doesn not need the ldp:memberXXX relation)
> > without the need for reasoning, and without loss of information. I brought 
> > this up because you have often worried about simplicity of this type.
> 
> But Roger said it earlier. Your solution comes at the cost of changing the data model which has disadvantages: 
> 
> > > > > Whilst the path between a product and a bug is probably 
> > something like:   
> > > > > 
> > > > >    product --hasbug--> bug 
> > > > > 
> > > > > ... you are saying: 
> > > > > 
> > > > >    product  --bugreportcollection-->  bugcollection  --
> > ldpcontains-->  bug 
> > > > > 
> > > > > I have a number of problems with this. 
> > > > > For a start, this becomes more difficult to query. 

Ah sorry I missed this mail as I got back home this evening. 
Your mail cought my attention first. 

Anyway how is that difficult to query?

SELECT ?member
WHERE {
  <../product1#v1> :bugReportCollection [ ldp:contains ?member ] .
}

It has the advantage of not requiring reasoning on the client, and does not
need reasoning of the following type in order to work out how to interact with
LDP.

PREFIX ldp: <http://www.w3.org/ns/ldp#>

CONSTRUCT { ?subject ldp:contains ?object }
WHERE
{
 {
   ?subject a ldp:SimpleContainer;
          ldp:contains ?object .
 } UNION {
   ?ldpc a ldp:DirectContainer;
        ldp:containerResource ?subject;
        ldp:containsRelation ?predicate.    
     ?a ?predicate ?c. 
   BIND (?c AS ?object)                            
 } UNION {
   ?ldpc a ldp:DirectContainer;
        ldp:containerResource ?object;
        ldp:containedByRelation ?predicate.         
     ?a ?predicate ?subject. 
   BIND (?a AS ?object)                            
 } UNION {
   ?ldpc a ldp:IndirecContainer.
   ?subject ldp:contains ?object .
 } 
}



> 
> > 
> > It seems that some people need to  
> > 
> >    "define a container by leveraging their existing 
> >     data structure".
> > 
> > but I have no idea what this means. Could someone explain
> > this to me? 
> 
> As Roger pointed out the idea is that you already have a resource linked to a bunch of other resources - in this example a product linked to a bunch of bugs via a set of "product hasbug bug" triples - and you want to define a container that captures this set. Your proposal is to insert a container in between the product and the bugs, while the desired result is to define a container on top of the existing structure, without changing it. 

Yes, that point would be interesting if the example from the section 2.1 in the primer
were an example of good modelling. But as I argued it needs the product uri to at least be
different from the container. Once that is the case then you need to use the 
rule from the ldp:DirectContainer using the ldp:containsResource relation, giving you the
above rather complex SPARQL rule.

Furthermore I am not the one installing a ldp:Container between the product and the bug. 
It is the use case that does this. It relates a product and a bug and not a container 
and a bug. The Container is inserted by LDP as it is what we need for the interaction 
model.

> In the case of Example 3 in the spec (netWorth), imagine you already have netWorth the way it is. Now you want to define an asset container and a liability container on top of that. 

Ok. Let me look at that example in more detail tomorrow. It's a bit too late here
for me to do that case justice. Perhaps you are right on this one. I'll see.

> 
> We've gone through this many times, I really don't know what it is that you don't understand. 
> 
> > 
> > Is it that the use case tied to 2.1 of the primer requires the data 
> > to be written 
> > out in the exact way it is written out in primer? Clearly that 
> > cannot be, since the 
> > example in the primer is out of sync with the spec. What is the use 
> > case data base 
> > that needs to be leveraged? Why does it require data to be written 
> > out in exactly 
> > the way explained in the Primer, when in fact there is a simpler wayto do that
> > using the ldp:SimpleContainer as I showed?
> > 
> > I understand that you wish to make the group progress to the final call, but
> > I don't see how cutting short on discussions like this is going to 
> > make things 
> > better. If we found out that ldp:SimpleContainer was all that is needed then
> > one would have a simpler spec, and it would be easier to go to last call.
> > 
> > Mind you I did not start out arguing for just ldp:SimpleContainer. It is just
> > that in the course of this conversation it seemed that in example 2.1 of the
> > spec nothing more is needed. Perhaps all other examples can be reduced this
> > way? If not it would be good to know exactly why not.
> 
> Sure, but it's been stated several times and the fact that you think ldp:SimpleContainer addresses the use case just shows that you don't understand, not that it is sufficient. 

How do you know that it is I who does not understand and not you? :-)
Come on, let's be open to reality teaching us something here.

> 
> > 
> >  I hope this helps put the previous discussion into perspective, as one
> > that is in line with your aims. 
> 
> I appreciate the intent but it will take more than that to achieve that goal I'm afraid. 
> 
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Social Web Architect
http://bblfish.net/

Received on Friday, 13 December 2013 21:46:48 UTC