Re: ISSUE-71: second bug tracking example

On 23 May 2013, at 07:52, Nandana Mihindukulasooriya <nmihindu@fi.upm.es> wrote:

> 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" .
> ------------------------------------------------------------------------

So this is definitely an improvement. But I would like to argue that each
Container should list the members it creates. Above you have the bt:BugTracker list the
members, which have a completely different URL.  That means that if I go to the Container,
I then have to go to another resource to find the container members. Would the following not
be better?

The </BugTracker> resource lists different relationships

~~~~~~~~GET /BugTracker HTTP/1.1~~~~~~~~~
 <> tracksProduct 
           </BugTracker/productsContainer/ProductA#p> ,
           </BugTracker/productsContainer/ProductB#p> ;
    hasBug </BugTracker/bugsContainer/bug1#b> .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The productsContainer lists the members of the container.

~~~~~GET /BugTracker/productsContainer/ HTTP/1.1 ~~~~
<> a ldp:Container;
   ldp:membershipSubject </BugTracker>;
   ldp:membershipPredicate bt:tracksProduct ;  
   rdfs:member <ProductA>, <ProductB> .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The we have ProductA and ProductB described very cleanly 
as you suggested

~~ GET /BugTracker/productsContainer/ProductA> ~~~~~~
<> a bt:ProductDescription;;
   foaf:primaryTopic <#p>;
   dcterms:title "The Product A Page";
<#p> ... # description of product
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


~~ GET /BugTracker/productsContainer/ProductB> ~~~~~~
<> a bt:ProductDescription;;
   foaf:primaryTopic <#p>;
   dcterms:title "The Product A Page";
<#p> ... # description of product
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The bugsContainer lists its only member <bug1> 
(It's a very young project clearly )

~~~~ GET /BugTracker/bugsContainer/ HTTP/1.1 ~~~~~~~~
<> a ldp:Container;
   ldp:membershipSubject </BugTracker>;
   ldp:membershipPredicate bt:hasBug ;
   rdfs:member <bug1> .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

And <bug1> contains all the info as you suggested again.

~~~GET /BugTracker/bugsContainer/bug1 HTTP/1.1 ~~~~~~ 
<> 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" .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So this seems a lot cleaner and easy to understand.
We can always find the members of a container by looking
at the container itself. 

The ldp:memberXXX relations would probably best be renamed
to something that describes a bit better what they are doing:
namely explaining that they will add a relation to some other
resource on content creation.

So I could also open a simple issue that would require that each 
collection lists its members using rdf:member , where the collection
is the resource on which the initial POST was done.

Henry

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

Social Web Architect
http://bblfish.net/

Received on Thursday, 23 May 2013 09:11:38 UTC