W3C home > Mailing lists > Public > public-ldp-wg@w3.org > December 2013

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

From: Arnaud Le Hors <lehors@us.ibm.com>
Date: Fri, 13 Dec 2013 08:41:29 -0800
To: Linked Data Platform WG <public-ldp-wg@w3.org>
Message-ID: <OF2AB1CA9F.E3F02F09-ON88257C40.005A7524-88257C40.005BB137@us.ibm.com>
Thanks Roger for expressing yourself.

I have to say that I'm surprised by Henry's take on this. First, the 
example being discussed isn't new at all. We've been talking about this 
from the very beginning. Again, it is very disruptive to start questioning 
these so late in the game. Second, I don't think there is much future in 
arguing that other people's use cases aren't valid on the basis that their 
data isn't structured properly or any other reasons. People have different 
needs and the only way forward is to accept that and try to address them 
equally rather than disqualify them.

For these reasons I don't see any value in entertaining such a discussion.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group




From:   Roger Menday <roger.menday@uk.fujitsu.com>
To:     Henry Story <henry.story@bblfish.net>, 
Cc:     Steve K Speicher <sspeiche@gmail.com>, Arnaud Le 
Hors/Cupertino/IBM@IBMUS, Linked Data Platform WG <public-ldp-wg@w3.org>
Date:   12/13/2013 07:59 AM
Subject:        Re: Issue-89, proposal 3: Duplication of triples & 
inferencing




Henry, 

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. 

thanks, 
Roger 



On 12 Dec 2013, at 22:28, Henry Story wrote:

On 12 Dec 2013, at 21:26, Steve Speicher <sspeiche@gmail.com> wrote:

Hi Henry,

Let me try to reiterate the use case we've discussed.

On Thu, Dec 12, 2013 at 2:01 PM, Henry Story <henry.story@bblfish.net> 
wrote:
>
>
> On 12 Dec 2013, at 19:20, Arnaud Le Hors <lehors@us.ibm.com> wrote:
>
> > While true, it's been pointed out before, several times, that this 
would fall short of addressing the use case at hand: allowing one to 
define a container over existing data by leveraging a domain specific 
vocabulary.
>
> I am not sure I understand. The use case is I suppose that one should
> be able to publish existing data using LDP. It can't be a requirement
> to publish the data in an LDPC in particular.
>
> It seems obvious that one can publish any data in an LDPR ( that is not
> an LDPC of course ). So the use case is satisfied anyway.
>
> Can anyone explain in particular why the data MUST be placed in an
> LDPC?

Because that how my model structured being part of a container-like 
structure, prior to LDP spec, and I want to apply LDP to it.  I shouldn't 
need to setup a LDPC to the side of my model but apply to it.  Take 
example 6 from the primer[1], it is an example of this. 

Example 6 from the primer is very badly modelled. It is confusing the 
LDPContainer with a product. 
Unless the product is the container itself, in which case it is a very odd 
container that has so many bugs.
(I would not use a container that has so many bugs).

Presumably the  product should be something other than the container. It 
would then need 
another LDPG that can describe that product, in order to make it easy for 
a client to edit 
( using PATCH ) without getting confused about relations that are managed 
by the container 
- such as ldp:xyz, a.k.a. ldp:contains relations - and those that are 
relations about the product 
( such as its size, its date of creation, its owner, its price, etc, and 
that may be managed by human
managers ).

So  we could have the following resources

</app/product1>           <-   the document about the product
</app/product1#v1>     <-   the real product
</app/product1/bugs/> <-   the bugs about the product

You don't even need anything more than a ldp:SimpleContainer as
I can show below:

The product description can be found with the following

[[
GET /app/product1

<#v1> a 
    dc:title "Semantic Web For the Working Ontologist";
    shop:price "38"^^currency:dollars;
    bt:bugReportCollection <bugs/> . 
]]

The bugs collection linked from the product can also be found by following
your nose from above:

[[
GET /app/product1/bugs/

<../product1> bt:bugReportCollection <> .
<> a ldp:SimpleCollection;
     ldp:contains <bugReport1>, <bugReport2>, <bugReport3> .
]]


• Looking at that  </app/product1/bugs/> collection one can find what 
product is the subject of the collection.
• POSTing to /app/product1/bugs creates new bug reports 
• DELETEing a bug report is the understood way to remove it from the LDPC
• There is no duplication of triples here anywhere


Additional context is that there are a number of data sources that expose 
similar models (servers emitting Linked Data resources).  So basically it 
has membership predicate bt:hasBug, you can infer ldp:xyz from it.  Using 
the approach Henry outlined below it opposite what I need.  I already know 
the membership triples. 

If I map this to programming languages this seems like what you are saying 
is that a List or a Set is not enough 
to represent a collection, that you need the relations in each list to be 
a different type of relation.

But usually in programming languages one models such things by creating an 
object with an attribute to a collection
of things. Eg:

{ 
  name: "Semantic Web For the Working Ontologist";
  bugs: [ bug1, bug2, bug3 ];
}

where the collection [ bug1, bug2, bug3 ] here is a list, where the 
relation from one member of the list
to the next is always the same relation ( e.g.: rdf:first, rdf:next ). 

Here for some reason you seem to be requiring that each collection have a 
different 
type of relation, but that the subject of the collection be an LDPC and 
the object be an LDPR.
There are so many other ways of modelling this that seem to be better, and 
that would 
make the specification simpler, and the work of clients easier.


We've already cover this use case quite a bit.  I believe for 
DirectContainers, the ldp:xyz could be inferred for those clients that 
need it.  Instead of requiring that burden on all servers to explicitly 
produce these (c, ldp:xyz, mr) triples that are very simple for those 
clients that need it to produce it.

I think I show above that you get what you want without the need for 
DirectContainers, without the need for duplicationg relations,
and without needing clients to do odd inferencing. 


[1] - https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html





 - Steve Speicher

>
>
> > It's this new relationship that should be inferred.
> > --
> > Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> >
> >
> > Henry Story <henry.story@bblfish.net> wrote on 12/12/2013 09:27:28 AM:
> >
> > > From: Henry Story <henry.story@bblfish.net>
> > > To: Linked Data Platform WG <public-ldp-wg@w3.org>,
> > > Date: 12/12/2013 09:31 AM
> > > Subject: Issue-89, proposal 3: Duplication of triples & inferencing
> > >
> > > Part 3 of Issue-89 creates a relation ldp:propertiesOnlyResource
> > > to allow an LDPC to point in its header to the "membership 
properties".
> > > The reason for this is to avoid so called duplication of triples.
> > >
> > > The duplication of triples is an issue mostly for the
> > > ldp:DirectContainer as is visible for a container such
> > > as the following
> > >
> > > <> a ldp:DirectContainer;
> > >         ldp:containerResource <>;
> > >         ldp:containsRelation m:manages;
> > >     ldp:xyz <doc1>, <doc2>, <doc3> ;
> > >     m:manages <doc1>, <doc2>, <doc3> .
> > >
> > > ( I am using ldp:xyz for what alexander in ISSUE-89 calls
> > >   ldp:contains. You can replace it without loss here and
> > >   throughout this e-mail. )
> > >
> > > But according to the rule such as the one used in the Membership 
wiki [1]
> > > it would be very easy to determine the "membership triples" using 
only
> > > the ldp:xyz relations
> > >
> > > PREFIX ldp: <http://www.w3.org/ns/ldp#>
> > >
> > > CONSTRUCT { ?subject ?predicate ?object }
> > > WHERE {
> > >    ?ldpc a ldp:DirectContainer;
> > >         ldp:containerResource ?subject;
> > >         ldp:containsRelation ?predicate;
> > >
> > >    ?ldpc ldp:xyz ?document .
> > >    BIND (?document AS ?object)                             # the
> > > POSTed resource is the member
> > >  } UNION {
> > >    ?ldpc a ldp:DirectContainer;
> > >         ldp:containerResource ?object;
> > >         ldp:containedByRelation ?predicate.                   #
> > > ldp:containedByRelation is used
> > >
> > >    ?ldpc ldp:xyz ?document .
> > >    BIND (?document AS ?object)
> > >  }
> > > }
> > >
> > > In that case duplication is not a problem at all,
> > > since a client could just infer the "membership triples"
> > > from the ldp:xyz ones using that query.
> > >
> > > On the other hand if such a rule is not true, and cannot
> > > be written out, then there is no duplication, since the
> > > "membership triples" are in fact different triples, and
> > > have no necessary relation to the ldp:xyz ones.
> > >
> > > But then this does give one a good reason for having them in a
> > > different possibly server managed resource.
> > >
> > >
> > >
> > >
> > > [1]in the Membership wiki "Determining the membership  triples to be
> > > added when a new member
> > > is created"  http://www.w3.org/2012/ldp/wiki/

> > > 
Membership#Determining_the_membership_triples_to_be_added_when_a_new_member_is_created
> > >
> > >
> > > Social Web Architect
> > > http://bblfish.net/

> > >
> > >
>
> Social Web Architect
> http://bblfish.net/

>
>

Social Web Architect
http://bblfish.net/




Received on Friday, 13 December 2013 16:42:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:54 UTC