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

Simplifying DirectContainers to SimpleContainers

From: Henry Story <henry.story@bblfish.net>
Date: Sat, 14 Dec 2013 16:14:41 +0100
Message-Id: <6B5905F7-E30A-4AFA-BEB5-E50FB3579EF6@bblfish.net>
To: Linked Data Platform WG <public-ldp-wg@w3.org>
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/
Received on Saturday, 14 December 2013 15:15:17 UTC

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