Re: Issue-71: the first bug tracking example

On 21 May 2013, at 23:10, Roger Menday <roger.menday@uk.fujitsu.com> 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.
> 
> Henry, 
> 
> Can you be more explicit about the connection between the modelling style and the implication for the general usefulness of membershipPredicate ? 

If you use membershipPredicate without using membershipSubject, then you 
are relating the container to the created resource, the thing that can be DELETEd,
PATCHed, etc... That is an information resource, or what you'd call a document,
which is a URL that does not end in #xxx as per the URI definition.

The membershipPredicate way of doing things is proposing a pattern that
will lead developers to think of the problem in the wrong way, and as 
Nananda did lead them to make the created resource be some
object in the world other than the GETable PUTable etc document.

As I showed you can get the same information you need whilst still keeping
the distinction between the container and its members - things the Web
Server deals with - distinct from the logic of the things described by
those documents. 

Furthermore it is close to the Atom way of doing things so it should be 
relatively easy to understand, and as Erik Wilde pointed out a few times
it allows clients to keep track of resources on the server by following 
ldp:member properties from a root container.

Since we can solve this bug tracking use case without ldp:membershipSubject
at least as elegantly, it cannot be used as an argument to keep it.

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

Social Web Architect
http://bblfish.net/

Received on Tuesday, 21 May 2013 21:26:43 UTC