Re: Issue-89, proposal 3: Duplication of triples & inferencing

Henry, 

Whilst the path between a product and a bug is probably something like:  

   product --hasbug--> bug 

... you are saying:

   product  --bugreportcollection-->  bugcollection  --ldpcontains-->  bug

I have a number of problems with this.
For a start, this becomes more difficult to query. 

thanks, 
Roger 



On 12 Dec 2013, at 22:28, Henry Story wrote:
> 
> On 12 Dec 2013, at 21:26, Steve Speicher <sspeiche@gmail.com> wrote:
> 
>> Hi Henry,
>> 
>> Let me try to reiterate the use case we've discussed.
>> 
>> On Thu, Dec 12, 2013 at 2:01 PM, Henry Story <henry.story@bblfish.net> wrote:
>> >
>> >
>> > On 12 Dec 2013, at 19:20, Arnaud Le Hors <lehors@us.ibm.com> wrote:
>> >
>> > > While true, it's been pointed out before, several times, that this would fall short of addressing the use case at hand: allowing one to define a container over existing data by leveraging a domain specific vocabulary.
>> >
>> > I am not sure I understand. The use case is I suppose that one should
>> > be able to publish existing data using LDP. It can't be a requirement
>> > to publish the data in an LDPC in particular.
>> >
>> > It seems obvious that one can publish any data in an LDPR ( that is not
>> > an LDPC of course ). So the use case is satisfied anyway.
>> >
>> > Can anyone explain in particular why the data MUST be placed in an
>> > LDPC?
>> 
>> Because that how my model structured being part of a container-like structure, prior to LDP spec, and I want to apply LDP to it.  I shouldn't need to setup a LDPC to the side of my model but apply to it.  Take example 6 from the primer[1], it is an example of this.  
> 
> Example 6 from the primer is very badly modelled. It is confusing the LDPContainer with a product. 
> Unless the product is the container itself, in which case it is a very odd container that has so many bugs.
> (I would not use a container that has so many bugs).
> 
> Presumably the  product should be something other than the container. It would then need 
> another LDPG that can describe that product, in order to make it easy for a client to edit 
> ( using PATCH ) without getting confused about relations that are managed by the container 
> - such as ldp:xyz, a.k.a. ldp:contains relations - and those that are relations about the product 
> ( such as its size, its date of creation, its owner, its price, etc, and that may be managed by human
> managers ).
> 
> So  we could have the following resources
> 
> </app/product1>           <-   the document about the product
> </app/product1#v1>     <-   the real product
> </app/product1/bugs/> <-   the bugs about the product
> 
> You don't even need anything more than a ldp:SimpleContainer as
> I can show below:
> 
> The product description can be found with the following
> 
> [[
> GET /app/product1
> 
> <#v1> a  
>     dc:title "Semantic Web For the Working Ontologist";
>     shop:price "38"^^currency:dollars;
>     bt:bugReportCollection <bugs/> .    
> ]]
> 
> The bugs collection linked from the product can also be found by following
> your nose from above:
> 
> [[
> GET /app/product1/bugs/
> 
> <../product1> bt:bugReportCollection <> .
> <> a ldp:SimpleCollection;
>      ldp:contains <bugReport1>, <bugReport2>, <bugReport3> .
> ]]
> 
> 
> • Looking at that  </app/product1/bugs/> collection one can find what product is the subject of the collection.
> • POSTing to /app/product1/bugs creates new bug reports 
> • DELETEing a bug report is the understood way to remove it from the LDPC
> • There is no duplication of triples here anywhere
> 
> 
>> Additional context is that there are a number of data sources that expose similar models (servers emitting Linked Data resources).  So basically it has membership predicate bt:hasBug, you can infer ldp:xyz from it.  Using the approach Henry outlined below it opposite what I need.  I already know the membership triples. 
> 
> If I map this to programming languages this seems like what you are saying is that a List or a Set is not enough 
> to represent a collection, that you need the relations in each list to be a different type of relation.
> 
> But usually in programming languages one models such things by creating an object with an attribute to a collection
> of things. Eg:
> 
> { 
>   name: "Semantic Web For the Working Ontologist";
>   bugs: [ bug1, bug2, bug3 ];
> }
> 
> where the collection [ bug1, bug2, bug3 ] here is a list, where the relation from one member of the list
> to the next is always the same relation ( e.g.: rdf:first, rdf:next ). 
> 
> Here for some reason you seem to be requiring that each collection have a different 
> type of relation, but that the subject of the collection be an LDPC and the object be an LDPR.
> There are so many other ways of modelling this that seem to be better, and that would 
> make the specification simpler, and the work of clients easier.
> 
>> 
>> We've already cover this use case quite a bit.  I believe for DirectContainers, the ldp:xyz could be inferred for those clients that need it.  Instead of requiring that burden on all servers to explicitly produce these (c, ldp:xyz, mr) triples that are very simple for those clients that need it to produce it.
> 
> I think I show above that you get what you want without the need for DirectContainers, without the need for duplicationg relations,
> and without needing clients to do odd inferencing. 
> 
>> 
>> [1] - https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html
> 
> 
> 
>> 
>>  - Steve Speicher
>> 
>> >
>> >
>> > > It's this new relationship that should be inferred.
>> > > --
>> > > Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>> > >
>> > >
>> > > Henry Story <henry.story@bblfish.net> wrote on 12/12/2013 09:27:28 AM:
>> > >
>> > > > From: Henry Story <henry.story@bblfish.net>
>> > > > To: Linked Data Platform WG <public-ldp-wg@w3.org>,
>> > > > Date: 12/12/2013 09:31 AM
>> > > > Subject: Issue-89, proposal 3: Duplication of triples & inferencing
>> > > >
>> > > > Part 3 of Issue-89 creates a relation ldp:propertiesOnlyResource
>> > > > to allow an LDPC to point in its header to the "membership properties".
>> > > > The reason for this is to avoid so called duplication of triples.
>> > > >
>> > > > The duplication of triples is an issue mostly for the
>> > > > ldp:DirectContainer as is visible for a container such
>> > > > as the following
>> > > >
>> > > > <> a ldp:DirectContainer;
>> > > >         ldp:containerResource <>;
>> > > >         ldp:containsRelation m:manages;
>> > > >     ldp:xyz <doc1>, <doc2>, <doc3> ;
>> > > >     m:manages <doc1>, <doc2>, <doc3> .
>> > > >
>> > > > ( I am using ldp:xyz for what alexander in ISSUE-89 calls
>> > > >   ldp:contains. You can replace it without loss here and
>> > > >   throughout this e-mail. )
>> > > >
>> > > > But according to the rule such as the one used in the Membership wiki [1]
>> > > > it would be very easy to determine the "membership triples" using only
>> > > > the ldp:xyz relations
>> > > >
>> > > > PREFIX ldp: <http://www.w3.org/ns/ldp#>
>> > > >
>> > > > CONSTRUCT { ?subject ?predicate ?object }
>> > > > WHERE {
>> > > >    ?ldpc a ldp:DirectContainer;
>> > > >         ldp:containerResource ?subject;
>> > > >         ldp:containsRelation ?predicate;
>> > > >
>> > > >    ?ldpc ldp:xyz ?document .
>> > > >    BIND (?document AS ?object)                             # the
>> > > > POSTed resource is the member
>> > > >  } UNION {
>> > > >    ?ldpc a ldp:DirectContainer;
>> > > >         ldp:containerResource ?object;
>> > > >         ldp:containedByRelation ?predicate.                   #
>> > > > ldp:containedByRelation is used
>> > > >
>> > > >    ?ldpc ldp:xyz ?document .
>> > > >    BIND (?document AS ?object)
>> > > >  }
>> > > > }
>> > > >
>> > > > In that case duplication is not a problem at all,
>> > > > since a client could just infer the "membership triples"
>> > > > from the ldp:xyz ones using that query.
>> > > >
>> > > > On the other hand if such a rule is not true, and cannot
>> > > > be written out, then there is no duplication, since the
>> > > > "membership triples" are in fact different triples, and
>> > > > have no necessary relation to the ldp:xyz ones.
>> > > >
>> > > > But then this does give one a good reason for having them in a
>> > > > different possibly server managed resource.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > [1]in the Membership wiki "Determining the membership  triples to be
>> > > > added when a new member
>> > > > is created"  http://www.w3.org/2012/ldp/wiki/
>> > > > Membership#Determining_the_membership_triples_to_be_added_when_a_new_member_is_created
>> > > >
>> > > >
>> > > > Social Web Architect
>> > > > http://bblfish.net/
>> > > >
>> > > >
>> >
>> > Social Web Architect
>> > http://bblfish.net/
>> >
>> >
> 
> Social Web Architect
> http://bblfish.net/
>