- From: Arnaud Le Hors <lehors@us.ibm.com>
- Date: Fri, 13 Dec 2013 13:02:00 -0800
- To: Henry Story <henry.story@bblfish.net>
- Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
- Message-ID: <OF3B100C39.48453A51-ON88257C40.0071111A-88257C40.00738B0C@us.ibm.com>
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
Received on Friday, 13 December 2013 21:02:34 UTC