Re: Issue-71: the first bug tracking example

A few minor clarifications... 

On 21 May 2013, at 20:00, Henry Story <henry.story@bblfish.net> wrote:

> (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;

This should be named something like bt:BugReportContainer rather that bt:BugReport.
One could perhams even use owl Restrictions to define a class like that.

>  val:primaryTopicRestriction [ onProperty bt:product
>                                hasValue  <http://example.org/app/BugTracker/ProductA> ]; 

So again this is a restriction of the primaryTopic of the members of the container.
another name could be val:memberPrimaryTopicRestriction .

>   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

... these bug reports describe ...

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

( I of course mean that the bug reports contain what is inside the 
  parenthesis ie, after " <bug1> log:semantics { " )

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

which clearly are not owl:sameAs each other

> 
> So now we have a case where it is clear how 
> 1. a client knows what to POST
   
    by looking at the restrictions on what the members are.
    
> 2. the LDPC never uses anything else other than ldp:member

   I meant he never uses anything other than rdf:member

> 3. we correctly make the distinction between information resource and thing talked about
    (the bug report and the bug)
   
> 4. and we don't need membershipPredicate 

which makes it easier to find the members since all members can be found simply
by searching 
  SELECT ?m WHERE { <> rdf:member ?m }

> 
> 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:40:36 UTC