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

Re: Simplifying DirectContainers to SimpleContainers

From: Henry Story <henry.story@bblfish.net>
Date: Sun, 15 Dec 2013 12:17:28 +0100
Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
Message-Id: <B19BF60D-24E3-4FBF-BF5F-334CAECB85E3@bblfish.net>
To: Roger Menday <roger.menday@uk.fujitsu.com>

On 15 Dec 2013, at 09:04, Roger Menday <roger.menday@uk.fujitsu.com> wrote:

> 
> ... but, I don't want to introduce new concepts ('assetDocCollection', 'bugcollection') to my domain model.
> 
> 

So I suppose this is the case where you would have modelled your relations with the bt:hasBugReport 
from a product to a BugReport, as I show in example [1.2.2] below. 

In that case it seems you have to live with duplication of triples. 
Your </products/swfwo> resource which defines the "/products/swfwo#v2" URI (see the URI
RFC section 3.5 http://tools.ietf.org/html/rfc3986#section-3.5 ) is the default resource to go
to if anyone wants to know what </products/swfwo#v2> is. That would have the relations from 
product to bug report I suppose. Then if you are using the inferencing rule form 
"membership triples" to ldp:contains relation you are placing the same relations 
in the </products/swfwo/bugs/> as shown in [1.2.1]. 

Otherwise say if you did not want to place those 
 { <#v1> bt:hasBugReport ?report } 
relations in the </products/swfwo> document,
you would need the client to do an extra HTTP request to get the data in the LDPC. 
But then you have to describe to the client why he should look "over there" to get data
that relates <#v1> to bug reports. After all, there are a lot of links to all kinds of
resources, and the client cannot know a priori where those resources could possibly be.
But is this not the bt:bugCollection relation you don't want to introduce?


> Put it another way, do you want all to re-factor all existing documents which
> use your https://code.google.com/p/baetle/ vocabulary in order to support RESTful writing ? 

My point was to show that you can publish the same information as you do using the 
ldp:DirectContainer using just the ldp:SimpleContainer. If that is correct then it 
is worth noting. 

Now any RDF publication mechanism existing currently that did not have a protocol
to create information resources, to edit them via HTTP PATCH, etc... This
is what LDP is adding.

You are then saying: there is information allready published in RDF that clients
are using, and that you want to make available with minimal change to LDP enable it.
What then needs to be worked out is which information resources in that space 
stand in the ldp:contains relation. 

( NOTE: the ldp:contains relation MAKES IT SO EASY TO explain what the problem to be
solved is! )

from there your tools for minimal change is to consider the ldp:container* relations
as rules that allow you to deduce from existing relations the ldp:contains relations. 
( Where you may have to add ldp:contains relations explicity when this can't be made
to fit cleanly ).


> 
> Roger
> 
> 
> 
> On 14 Dec 2013, at 15:14, Henry Story wrote:
> 
>> I just want to consider the possibility that all DirectContainers
>> can be reduced without information loss to ldp:SimpleContainers.
>> A few examples will help.
>> 
>> There are three secitons to this
>> 
>> 1. reduction of bug reports
>> 2. reduction of liabilities
>> 3. issues.
>> 
>> 
>> 1. bug reports on a product
>> ===========================
>> 
>> 1.1 collection of bug reports
>> -----------------------------
>> 
>> Consider the well known case of bug reports on a product.
>> Using ldp:DirectContainer one could model it like this
>> using inferencing from "membership triples" to ldp:contains
>> relation.
>> 
>> [[1.1.1] GET /products/swfwo/bugs/
>> 
>> <> a bt:BugReportCollection, ldp:DirectContainer;
>>  ldp:containerResource <>;
>>  ldp:containsRelation bt:containsBugReport;
>>  bt:containsBugReport <1>;
>>      ....; 
>>  bt:containsBugReport <300000> .
>> ]]
>> 
>> This requires the relation from the product
>> to the bug report collection:
>> 
>> [[1.1.2] GET /products/swfwo
>> <#v2> a Book;
>>  dc:title "Semantic Web For the Working Ontologist";
>>  bt:bugCollection <swfo/bugs/>;
>>  c:price "37"^^c:dollars ;
>> ]]
>> 
>> It has the advantage of requiring 1 relation, and the 
>> bugs are left in the container, without needing
>> to duplicate them.
>> 
>> 
>> 1.2 direct relation from product to bug reports
>> -----------------------------------------------
>> 
>> A DirectContainer would also make it possible to materialise
>> relations between the product and the bug reports 
>> directly in the following way
>> 
>> [[1.2.1] GET /products/swfwo/bugs/
>> <> a bt:BugReportCollection, ldp:DirectContainer;   
>>   ldp:containerResource <../swfwo#v2>;
>>   ldp:containsRelation bt:hasBugReport .
>> 
>> <../swfo#v2>
>>     bt:hasBugReport <1>;
>>      ....; 
>>     bt:hasBugReport <300000> .
>> ]]
>> 
>> But then the </products/swfwo> resource needs to
>> either specify all the relations to each bug report,
>> or to point to the bug report collection so that
>> a client can know how to add resources. So we have
>> 
>> [[1.2.2] GET /products/swfwo
>> <#v2> a Book;
>>  dc:title "Semantic Web For the Working Ontologist";
>>  bt:hasBugReport <swfo/bugs/1>, ... ,<swfo/bugs/30000>;  #a lot!! 
>>  c:price "37"^^c:dollars.
>> 
>> <swfo/bugs/> ldp:containerResource <#v2> .
>> ]]
>> 
>> So here we end up with two resources duplicating all
>> the bugs, and we also need the extra relation such
>> as 
>> { <swfo/bugs/> ldp:containerResource <#v2> . } 
>> so that a client can know where to post new bugs.
>> ( the client allready has all the bugs ).
>> 
>> 
>> 1.3 Simplification
>> ------------------
>> 
>> The answer in [1.1] has an advantage of relating the product to the
>> collection in a manner similar to how it is done in programming
>> languages where one has a relation from an object to a collection
>> of some sort. [1.2] creates a direct relation between the product and the
>> reports, but it comes at a cost of duplication. It is no longer so clear 
>> where triples have to live either.
>> 
>> It turns out that we can simplify the example in [1.1] to a SimpleContainer
>> like this:
>> 
>> [[1.3.1] GET /products/swfwo/bugs/
>> 
>> <> a bt:BugReportCollection, ldp:SimpleContainer;
>>  ldp:contains <1>;
>>      ....; 
>>  ldp:contains <300000> .
>> ]]
>> 
>> This requires the relation from the product to the bug report collection 
>> as in [1.1.2]
>> 
>> [[1.3.2] GET /products/swfwo
>> <#v2> a Book;
>>  dc:title "Semantic Web For the Working Ontologist";
>>  bt:bugCollection <swfo/bugs/>;
>>  c:price "37"^^c:dollars.
>> ]]
>> 
>> It turns out there is no need for the predicate 
>> bt:containsBugReport between the collection and its
>> members, just as there is no need for a different collection
>> type in any programming languages.
>> 
>> 2. network example
>> ==================
>> 
>> The networth example from the spec is not much more complicated. 
>> It is a bit like the example in [1.2] with relations directly 
>> from the NetWorth to the assets or the liabilities. 
>> 
>> Since the Network example mixes up documents and things let me
>> adapt it a little bit:
>> 
>> [[2.1]
>> @prefix ldp: <http://www.w3.org/ns/ldp#>.
>> @prefix o: <http://example.org/ontology/>.
>> <>
>>  a o:NetWorthDocument;
>>  o:netWorthOf <http://example.org/users/JohnZSmith>;
>>  o:assetdoc 
>>     <assetContainer/a1>,
>>     <assetContainer/a2>;
>>  o:liabilitydoc 
>>     <liabilityContainer/l1>,
>>     <liabilityContainer/l2>,
>>     <liabilityContainer/l3>.
>> ]]
>> 
>> 
>> so instead of this one could just simplify this as above
>> to 
>> 
>> [[2.2]
>> @prefix ldp: <http://www.w3.org/ns/ldp#>.
>> @prefix o: <http://example.org/ontology/>.
>> <>
>>  a o:NetWorthDocument;
>>  o:netWorthOf <http://example.org/users/JohnZSmith>;
>>  o:assetDocCollection <assetContainer/>;
>>  o:liabilityDocCollection <liabilityContainer/> .
>> ]]
>> 
>> Now of course the <assetContainer/> and <liabilityContainer/> can
>> be written out simply as ldp:SimpleContainer-s. The advantage
>> is that the information is not duplicated between the networthdocument
>> and the liabilityDocument, and it is clear where the information needs
>> to be placed.
>> 
>> 
>> 3. Problems
>> ===========
>> 
>> It seems clear that one can reduce ldp:DirectContainer s to ldp:SimpleContainers like
>> this. But it does mean that the objects of the relations are always documents, or LDPGs.
>> If one wanted to move out of the document space then one would need the ldp:IndirectContainers,
>> and these cannot be so reduced.
>> 
>> 
>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
> 

Social Web Architect
http://bblfish.net/
Received on Sunday, 15 December 2013 11:18:34 UTC

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