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

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.

> 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.

> 
>   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. 



> 
> 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.

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.

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.

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