Re: Issue-71: the first bug tracking example

On 22 May 2013, at 00:01, 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.
> 
> 
> If I understand your point correctly, I don't think you can blame membershipPredicate for that. 
> 
> It is possible that you could blame the *lack of* membershipObject. 
> 
> Actually, I think that is a gap in the current spec.

That's one way of looking at it. But then this gap may be a lot more difficult to fill in than
you think, and that is perhaps why it is not in the spec. And there may be other complexities
hiding behind such a relation once it is in place.

> But, I think it can be resolved without throwing everything out. e.g. my proposal at the end of [1] addresses it I think. 

And the other way of looking at it is that there is no gap. That was the point of my two
e-mails. You can do what you need without those relations. You just need to think
about the problem differently.

And since you don't loose anything you need from the UC&R we might as well throw these
out. They just clutter the visiblity to the simple underlying answer that was there all along.


> 
> Roger
> 
> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0120.html
> 
> 
>> 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/
>> 
> 

Social Web Architect
http://bblfish.net/