Re: Issue-71: the first bug tracking example

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

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

Good. That is my argument: please kept things seperate. IE:
 -  Don't mix documents and things documents are about.  
 -  Don't mix container membership and language to restrict what can go into a container . 
    ( or at least lets be really clear and explicit about what is going on )

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

I have no idea what you mean "define containers without forcing people to change their vocabulary".
The question is what is the UC&R for this functionality? Where does it come from? What is the
need? (I mean for the protocol)

The LDP spec is about GET, PUT, POST, DELETE. One whole section of the spec is about how those
words are used in resources we call LDPCs . Fine. So it is quite reasonable to ask what the point of
ldp:membershipPredicate is.  I gave above what seem two possible reasons for why it
is needed with respect to POSTing. If you know the restrictions on the relation, you know what type
of document you can or cannot POST. That still leaves room for a group such as RDF-Validation
group [1] to crete a language to make such definitions machine parsable, but one could argue for 
the inclusion of those relations on those grounds.

Henry

[1] https://www.w3.org/2012/12/rdf-val/Overview.php 

> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 

Social Web Architect
http://bblfish.net/