Re: 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.

Henry, 

Can you be more explicit about the connection between the modelling style and the implication for the general usefulness of membershipPredicate ? 

Roger


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