membershipX: the first bug tracking example

Let me take Nandana's first bug tracking example and show how one can do
without membershipPredicate.

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 17:52:23 UTC