ISSUE-71: second bug tracking example

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 Tuesday, 21 May 2013 22:42:32 UTC