- From: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
- Date: Thu, 23 May 2013 07:52:23 +0200
- To: Henry Story <henry.story@bblfish.net>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CAAOEr1=_b1t2Khsm7RQRv=sgrL8g6RWwkSCK+qmEKeaL=-9Eeg@mail.gmail.com>
It might be useful to analyze the model 2 example too as this was the
example that illustrated the use case of the 'ldp:membershipSubject' as
mentioned in the specification. The use case as I see it is to "use two
containers as creation factories to create two different types of (child)
resources that belongs to a resource", for example assets and liabilities
of NetWorth example or projects and bugs in the Bug Tracker example.
Here I took an attempt to address the separation of information resource
and the real thing in the model 2 example (concern #3). As Roger
mentioned, the information resource and the thing could be the same as the
BugTracker resource in this example.
----------------------- Model 2 -------------------------------------
</BugTracker> a bt:BugTracker;
tracksProduct
</BugTracker/productsContainer/ProductA#p> ,
</BugTracker/productsContainer/ProductB#p> ;
hasBug </BugTracker/bugsContainer/bug1#b> .
</BugTracker> rdfs:member </BugTracker/productsContainer/ProductA> ;
rdfs:member </BugTracker/productsContainer/ProductB> ;
rdfs:member </BugTracker/bugsContainer/bug1> .
------
</BugTracker/productsContainer/> a ldp:Container;
ldp:membershipSubject </BugTracker>;
ldp:membershipPredicate bt:tracksProduct .
------
</BugTracker/bugsContainer/> a ldp:Container;
ldp:membershipSubject </BugTracker>;
ldp:membershipPredicate bt:hasBug .
------
</BugTracker/productsContainer/ProductA> a bt:ProductDescription;;
foaf:primaryTopic <#p>;
dcterms:title "The Product A Page";
------
</BugTracker/bugsContainer/bug1> a bt:BugReport;
foaf:primaryTopic <#b> ;
dcterms:title "Product A crashes when shutting down.";
dcterms:creator </users/johndoe#me>;
dcterms:created "2013-05-05T10:00"^^xsd:dateTime .
<#b> a bt:Bug;
bt:relatedProduct </app/BugTracker/ProductA#p>;
bt:isInState "New" .
------------------------------------------------------------------------
Best Regards,
Nandana
On Wed, May 22, 2013 at 12:41 AM, Henry Story <henry.story@bblfish.net>wrote:
>
> On 21 May 2013, at 18:30, Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
> wrote:
>
> > ----------------------- Model 2 -------------------------------------
> >
> > <http://example.org/app/BugTracker> a bt:BugTracker;
> > tracksProduct
> > <http://example.org/app/BugTracker/products/ProductA> ,
> > <http://example.org/app/BugTracker/products/ProductB> ;
> > hasBug <http://example.org/app/BugTracker/bugs/1> .
> > ------
> > <http://example.org/app/BugTracker/products/> a ldp:Container;
> > ldp:membershipSubject <http://example.org/app/BugTracker>;
> > ldp:membershipPredicate bt:tracksProduct .
> > ------
> > <http://example.org/app/BugTracker/bugs/> a ldp:Container;
> > ldp:membershipSubject <http://example.org/app/BugTracker>;
> > ldp:membershipPredicate bt:hasBug .
> > ------
> > <http://example.org/app/BugTracker/products/ProductA> a bt:Product .
> > ------
> > <http://example.org/app/BugTracker/ProductA/Bug1> a bt:Bug;
> > dcterms:title "Product A and B doesn't interoperate ";
> > dcterms:created "2013-05-05T10:00"^^xsd:dateTime;
> > dcterms:creator <http://example.org/users/johndoe>;
> > bt:relatedProduct <
> http://example.org/app/BugTracker/products/ProductA>;
> > bt:relatedProduct <
> http://example.org/app/BugTracker/products/ProductB>;
> > bt:isInState "New" .
> > ------------------------------------------------------------------------
>
> Ok, so what you want is:
>
> 1. a way to create new products
> 2. a way to create new bugs on existing products
> 3. a list that ties the bugs and the products together
>
> So you could create new products simply by Posting to
> the collection:
>
> ~~~~~ /app/BugTracker/products/ ~~~~~~~~~~~~~>
>
> <> a ldp:Container, bt:ProductDescriptionCollection;
> bt:member <Ace>, <Base> .
>
> <Ace> a bt:ProductDescription;
> dct:title "The Ace Product Page";
> dct:created "2013-05-00T17:05Z"^^xsd:dateTime;
> dct:creator </staff/Eliza#i> .
>
> <Base> a bt:ProductDescription;
> dct:title "The Base Product Page";
> dct:created "2013-05-02T19:19Z"^^xsd:dateTime;
> dct:creator </staff/Eliza#i> .
> ~~~~~~~~~~~~~~~~~~
>
> So the good thing is that we then know from the collection who
> owns the documents about the object in them and what the type
> of the documents in them is.
>
> Again we distinguish between the Product an the description
> of the product. For example here:
>
> ~~~~~~~~~~<Ace>~~~~~~~~~~~~
> <> a bt:ProductDesciption;
> dct:title "The Ace Product Page";
> dct:created "2013-05-00T17:05Z"^^xsd:dateTime;
> dct:creator </staff/Eliza#i> ;
> foaf:primaryTopic <#p> .
>
> <#p> a Product;
> dct:created "2013-03-00T14:52Z"^^xsd:dateTime;
> dct:creator </co#mpany> ;
> price [ dollars 22 ] .
> owl:sameAs dbpedia:AceProduct .
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> So clearly the page does not cost 22 dollars but the product does
> and the page is not the same page as the dpbedia page ( PATCHing
> dbpedia won't change this product description ). Also the product
> has a different creator time and date as the page, and is updated
> at different rates.
>
> So now nothing stops the server from generating a list of all the
> products too and of placing that somewhere and of linking to
> it. Hey perhaps it could even place that in the products collection
>
> ~~~~~ /app/BugTracker/products/ ~~~~~~~~~~~~~>
> ...
>
> <#p> a ProductCollection;
> owl:oneOf ( <Ace#p> <Base#p> ) .
>
> ...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> No matter where it is placed, the advantage is already
> that you can easily speak about products described locally
> or remotely. You are not stuck with only dealing with locally
> described resources. The LDPC as a creator of resources on the
> other is forced to only have local members: ie point to
> resources that can be PATCHed, DELETEd, ... and so that it is in
> control of.
>
> So once you have the ProductCollection, you can now create
> the bug report container and restrict what products it
> can be about
>
> ~~~~~~~~~~
> <> a ldp:Container, bt:BugReportContainer;
> val:memberPrimaryTopicRestriction [
> onProperty bt:product;
> allValuesFrom <../products#p> ;
> ];
> bt:member <bug1>, <bug2>, <bug3> .
>
> # note that we add metadata on the information resource
> # note also that the creator is the creator of the bug report,
> # not the creator of the bug
>
> <bug1> dct:title "Product A and B doesn't interoperate ";
> dct:created "2013-05-05T10:00"^^xsd:dateTime;
> dct:creator <http://example.org/users/johndoe#i> .
>
> ...
> ~~~~~~~~~~~
>
> So what did the client send to create <bug1> ?
> Would POSTing this not have been enough?
>
> ~~~~~POST~~~~~~
> <> dct:title "Product A and B doesn't interoperate ";
> dct:created "2013-05-05T10:00"^^xsd:dateTime;
> dct:creator </users/johndoe#i>;
> foaf:primaryTopic <#bug> .
>
> <#bug> bt:relatedProduct <../products/Ace#p>;
> bt:relatedProduct <../products/Base#p>;
> bt:isInState "New" .
> ~~~~~~~~~~~~~~~~
>
> The client would know what to post just by looking at the
> definition of the BugReportContainer . Some of these
> descriptions will need a vodabulary to devine the types
> of documents. Perhaps the rdf-val group will be able to
> solve that....
>
> https://www.w3.org/2012/12/rdf-val/Overview.php
>
> We need it anyway.
>
> Henry
>
>
> Social Web Architect
> http://bblfish.net/
>
>
>
Received on Thursday, 23 May 2013 05:53:08 UTC