Re: Issue-71: the first bug tracking example

Henry Story <henry.story@bblfish.net> wrote on 05/22/2013 05:47:57 AM:

> From: Henry Story <henry.story@bblfish.net>
> To: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>, 
> Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
> Date: 05/22/2013 05:50 AM
> Subject: Re: Issue-71: the first bug tracking example
> 
> 
> On 22 May 2013, at 10:06, Nandana Mihindukulasooriya 
> <nmihindu@fi.upm.es> wrote:
> 
> > 
> > 3. we correctly make the distinction between information resource 
> and thing talked about
> > 
> > Thank you very much for pointing this out. So if I change the 
> example like the following, will it address your concern #3 ?
> > 
> > ----------------------- Model 1 --------------------------------------
> > 
> > </app/BugTracker> a ldp:Container, bt:BugTracker ;
> >         ldp:membershipPredicate bt:hasProductDescription ;
> >    bt:hasProductDescription </app/BugTracker/ProductA> .
> > ------
> > </app/BugTracker/ProductA> a ldp:Container, bt:ProductDescription;
> >         ldp:membershipPredicate bt:hasBugReport  ;
> >         foaf:primaryTopic <#p>;
> >         dcterms:title "The Ace Product Page";
> >    bt:hasBugReport </app/BugTracker/ProductA/Bug1> .
> > 
> >  <#p> a bt:Product .
> > ------
> >  </app/BugTracker/ProductA/Bug1> a bt:BugReport;
> >       foaf:primaryTopic <#b> ;
> >       dcterms:title "Product A crashes when shutting down.";
> >       dcterms:creator </users/johndoe#me>;
> >       dcterms:created "2013-05-05T10:00"^^xsd:dateTime .
> > 
> >  <#b> a bt:Bug;
> >       bt:relatedProduct </app/BugTracker/ProductA#p>;
> >       bt:isInState "New" .
> > 
> > 
> 
-------------------------------------------------------------------------------
> 
> yes. Here you distinguish correctly between the products and the page 
about 
> the products, as well as between the bug and the page about the bug. 

Thanks Nandana for updating your example.

So, Henry, this shows that, as I was saying, the modeling problem you were 
pointing out has nothing to do with membershipPredicate. You can model 
badely with or without. I agree with you that we should make sure the 
examples in the spec show good practice in modeling but it would really 
help if we didn't mix everything and keep the problems separated.

> 
> Now presumably the following rule applies:
> 
> { 
>   </app/BugTracker> bt:hasProductDescription ?member .
> } => { 
>   </app/BugTracker> rdf:member ?member .
> }
> 
> That is bt:hasProductDescription rdfs:subPropertyOf rdfs:member .
> 
> Whatever. In either case it seems we should be able to add 
> to your </app/BugTracker> graph
> 
>    <BugTracker> rdfs:member <BugTracker/ProductA> .
> 
> and to your </app/BugTracker/ProductA> graph the
> relation
> 
>    <ProductA> rdfs:member <ProductA/Bug1> .
> 
> So now the question is simply, what is the UC&R case for adding
> the membershipPredicate relation? I have the following hypothesis:
> 
> 1. by specifying that membership relation you are developing a way
>   to restrict what can be POSTed to the LDPC and hence what is contained 
in 
>   the container.
> 
>     I imagine that somewhere your definition of 
>    bt:hasProductDescription one finds that
> 
>   bt:hasProductDescription a rdfs:Property;
>      rdfs:range bt:ProductDescription .
> 
>    or perhaps some restriction that says the same thing 
>  but specifically when the subject is that particular 
>  container.
> 
> 2. You are trying to develop a simple language for making clear the 
>    consequences of POSTing to the container. You want to say:
>    by posting here you are creating a new Bug for product p that will
>    be tied via the bt:hasProductDescription to this container.
> 
> I think clarity about the role of membershipPredicate would be
> very helpful in understanding its position in the spec.
> 
> Have I guessed the reasons for the existence of membershipProperty
> correctly?
> 
> Henry
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

I frankly don't understand where all this comes from. I already told you 
in my previous email why we have membershipPredicate: to be able to define 
containers without forcing people to change their vocabulary. That's it.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group