Issue-71: the first bug tracking example

(resending to get w3c into issue tracker) 
Let me take Nandana's first bug tracking example and show how one can do
without membershipPredicate as set out by ISSUE-71.

On 21 May 2013, at 18:30, Nandana Mihindukulasooriya <nmihindu@fi.upm.es> wrote
in the email at http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0169.html

> ----------------------- Model 1 --------------------------------------
> 
> <http://example.org/app/BugTracker> a ldp:Container, bt:BugTracker ;
>       ldp:membershipPredicate bt:tracksProduct ;
> 	bt:tracksProduct <http://example.org/app/BugTracker/ProductA> .
> ------
> <http://example.org/app/BugTracker/ProductA> a ldp:Container, bt:Product;
> 	ldp:membershipPredicate bt:hasBug ;
> 	bt:hasBug <http://example.org/app/BugTracker/ProductA/Bug1> .
> ------
> <http://example.org/app/BugTracker/ProductA/Bug1> a bt:Bug;
>     dcterms:title "Product A crashes when shutting down.";
>     dcterms:creator <http://example.org/users/johndoe>;
>     dcterms:created "2013-05-05T10:00"^^xsd:dateTime
>     bt:isInState "New" .

So a few remarks on this modelling, which I think is worth opening a new issue
for by itself on.  Your model is confusing a thing - a bug - and an information resource
that describes it.
 This means that it is not going to be possible later to identify two bugs with owl:sameAs
without coming to the conclusion that it was created at different times, by potentially two 
people. It also means you cannot distinguish copyrights on the information content -
a creative commons licence - from the bug itself, which is not something that can be
licenced. 
So this is a first reason why this type of modelling is not standard, and not a good
idea. And another reason why the ldp:membershipPredicate is going to walks straight
into the -1 of a lot of people at the w3c if it is kept like that.

So let me here try to bypass this problem and see how far I can go. 
Let us say </bugs/> is our container with the following content:

~~~~~~~~~~
<> a ldp:Container, bt:BugReport;
  val:primaryTopicRestriction [ onProperty bt:product
                                hasValue  <http://example.org/app/BugTracker/ProductA> ]; 
   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> dcterms:title "Product A crashes crashes when starting up.";
           dcterms:creator <http://example.org/jack#me>;
           dcterms:created "2013-04-05T10:00"^^xsd:dateTime .

<bug2> dcterms:title "Product A crashes when shutting down.";
           dcterms:creator <http://example.org/users/johndoe#i>;
           dcterms:created "2013-05-05T10:00"^^xsd:dateTime .

<bug3> dcterms:title "My pictures looks funny when I click the red buton";
           dcterms:creator <http://facebook.com/users/grannySmith#>;
           dcterms:created "2013-05-06T11:23"^^xsd:dateTime .
~~~~~~~~~~~

So we assume we have some validation description that will be 
arrived at by the rdf-validation group:
  https://www.w3.org/2012/12/rdf-val/Overview.php 
and that allows us to restrict the primary topics of posted content to
be about ProductA . 

From this a client would know that all members of the container are 
bug reports, and that the bugs must be about about a specific topic.

We publish metadata about <bug1> and <bug2> which are bug REPORTS, not
bugs. The Bug reports may themselves be buggy, for example.
These bug reports would then say something simple like

<bug1> log:semantics {

<bug1> dcterms:title "Product A crashes crashes when starting up.";
      dcterms:creator <http://example.org/jack#me>;
      dcterms:created "2013-04-05T10:00"^^xsd:dateTime ;
      foaf:primaryTopic <bug1#y>

<bug1#y> a bt:Bug;
     bt:product <http://example.org/app/BugTracker/ProductA> ;
     bt:isInState "closed";
     bt:cause <http://other.project.org/bugs/bug100#y> .
}

And now the bug report <bug2>

<bug2> log:semantics {

<bug2> dcterms:title "Product A crashes when shutting down.";
      dcterms:creator <http://example.org/users/johndoe#i>;
      dcterms:created "2013-05-05T10:00"^^xsd:dateTime .
      foaf:primaryTopic <bug2#y>

<bug2#y> a bt:Bug;
     bt:product <http://example.org/app/BugTracker/ProductA> ;
     bt:isInState "open";
     owl:sameAs <bug3#y> .
}

Here an engineer determined that <bug2#y> was the same as <bug3#y> though
he has two different bug reports.

So now we have a case where it is clear how 
1. a client knows what to POST
2. the LDPC never uses anything else other than ldp:member
3. we correctly make the distinction between information resource and thing talked about
4. and we don't need membershipPredicate 

It is true we need a vocabulary for restrictions on contents, but that we needed
anyway and that is something that clearly can be done by a group such as the
RDF-Validation group https://www.w3.org/2012/12/rdf-val/Overview.php 

Hope this helps,

	Henry

Social Web Architect
http://bblfish.net/

Received on Tuesday, 21 May 2013 18:00:53 UTC