Re: Simplifying DirectContainers to SimpleContainers

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

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 ? 

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