Re: Issue-71: the first bug tracking example

On 22 May 2013, at 03:52, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi Henry, 
> 
> Henry Story <henry.story@bblfish.net> wrote on 05/21/2013 11:40:01 AM:
> 
> > A few minor clarifications... 
> 
> Thanks but I think you need a few more actually. :-) 
> 
> > 
> > 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. 
> 
> The modeling chosen in Nandana's example might not be correct but the point you're making is orthogonal to the question at hand. 

Not at all. The current spec is pushing people to make bad modelling 
decisions, which is why I think it is very problematic.
In any case I had to deal with that issue first before  moving on to 
the main topic of this thread.

I can open another issue on the bad modelling of the examples in the
spec later.

> 
> > > 
> > > 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. 
> 
> Indeed. I guess your proposal isn't immune to confusion either, is it? ;-) 
> 
> > 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 .
> > 
> 
> I have to admit not to understand what this has to do with the question at hand.

Clearly part of the point of ldp:membershipPredicate is to tell people
that by POSTing to the container they will be creating a new resource
and they will be adding this new relation from the container to the 
created resource. The idea is that a client is then supposed to understand
what this relation means and agree to the addition of this relation, on 
POSTing the content.

I think that this way of doing things is confusing three things:

 1. the role of containers as creators of resources
 2. the role of restrictions on what can be POSTed
 3. the meaning of POSTing a resource ( a new 
    relation gets added somewhere )

Since these are orthogonal issues, they should be kept 
separate. Not doing so is pushing people to bad 
modelling practices, since you don't for example 
specify the object of the  membership predicate, 
and thereby corner any ontologist who would like to 
implement your protocol into confusing the document 
with the thing the document is speaking about.


> And if we can't defined LDP without OWL we've failed. 

You would not need to define LDP with OWL. OWL is already defined. And this owl
vocabulary was just a way of showing how using something close to existing standards,
that is without inventing anything much new  a group such as the RDF Validator group 
you pointed me to in a conversation on irc at the end of the last teleconf
 https://www.w3.org/2012/12/rdf-val/Overview.php 
could end up creating a way to describe restrictions on what you POST to the
LDPC.
  
  Clearly writing a restriction vocabulary is not impossible, and the above shows
it is probably not that difficult. If you don't like owl, the group could do it
with SPARQL such as by only allowing POSTs of contents on which the following 
query returns true

ASK {
   <> a bt:BugReport;
      bt:product <ProductA> .
}

And if they don't like SPARQL they could certainly invent yet
a further way to do this.

All of this is just meant to show that there is a way to specify
a collection by the types of documents in it. In this case there
is a way to specify something like

 "the container's members primary topics have a product with value <ProductA> "

So this solves problem 2. in my list above. 


> > >   bt:member <bug1>, <bug2>, <bug3> . 
> 
> How does a client know that bt:member is the predicate used in your container to list the member resources? 
> Given your criticism of Nandana's modeling shouldn't you list bug reports in your container rather than bugs here? 

Sorry that should have been rdf:member .

> 
> > > 
> > > # 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 . 
> 
> Why are you talking about validation here? How validation is performed has nothing to do with the question at hand. 

What is missing in what I am expressing that Nananda needed to express?
That is the question.

> 
> > > 
> > > 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> .
> > > } 
> 
> Same point as earlier: you're calling "bug1" what is actually a bug report, aren't you?

yes. Since the member is something created by LDPC it is somthing that one should
be able to GET, DELETE, etc. That is always going to be a document of some form: ie
something with a log:semantics or an atom:content .

> > 
> > ( I of course mean that the bug reports contain what is inside the 
> >   parenthesis ie, after " <bug1> log:semantics { " ) 
> 
> Yeah, I don't think it helps to introduce such a syntax which isn't Turtle here. 

You prefer if I use ~~~~~~~<ref>~~~~~~> to distinguish the human 
text and the code that I am describing? 

> 
> > 
> > > 
> > > 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 
> 
> I take it you meant to use that rather than bt:member in your example? 

yes. :-)

> 
> > 
> > > 3. we correctly make the distinction between information resource 
> > and thing talked about
> >     (the bug report and the bug) 
> 
> Not quite, as I pointed out, but that's again orthogonal anyway. You could easily fix Nandana's example in that regard without throwing out membershipPredicate. 

It is not orthogonal. We should be working with examples that are using the 
best practices from Web Architecture and best modelling practices when discussing
things here. 

Secondly what UC&R feature is Nandanda missing in my reconstruction of her example
without the membershipPredicate ?


> I don't understand why you're tying the two - membershipPredicate and the bug vs the bug report. 

Because your membershipPredicate is linking a container to an information resource, and 
that with this only tool in the Toolbox Nananda feels obliged to make the modelling 
decisions she is making which goes against the first principles of the linked information 
that Tim Berners Lee  expressed as early as 1994 http://www.w3.org/Talks/WWW94Tim/


> 
> >    
> > > 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 }
> > 
> 
> I really think there is a misunderstanding here. There is no question that we could define a container model without membershipPredicate. The whole point of having that predicate is to allow a container to be defined over a resource that uses a different predicate from the one we would impose so that people can define containers without having to abandon the vocabulary they are already using. 
> 
> I would also point out that people have expressed the need and we have agreed to add membershipPredicateInverse for the same reason. 
> 
> It also allows  to define several containers over the same resource, as example 3 in the spec demonstrates: https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-ex-membership-full 
> 
> We would lose all of this with what you are proposing and I'm still not sure why. 
> 
> For what it's worth we also have a mechanism that allows specifying which predicates are used for ordering. The motivation behind it is the same. We don't want to force people to use a specific predicate to specify the order and instead allow people to specify which one(s) they use. It would certainly simplify the spec if we removed that functionality but we'd also be crippling the spec. 
> 
> > > 
> > > 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 
> > > 
> 
> Again this isn't why we need membershipPredicate and for what it's worth we cannot possibly depend on what "the RDF-Validation group" might do. There is no such group at this point. There is merely a workshop to find out whether there is anything the W3C should do in that space. 
> 
> > > Hope this helps,
> > > 
> > >    Henry
> > > 
> > > Social Web Architect
> > > http://bblfish.net/
> > 
> > 
> 
> I thank you for taking the time to write this down but I think we need to reconcile our objectives. you seem to be wanting to get rid of a lot of functionality for the sake of simplicity. I don't think that's reasonable. I like simplicity too but not at the cost of losing functionality people want. 
> 
> Regards. 
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 22 May 2013 08:13:35 UTC