- From: Alexandre Bertails <bertails@w3.org>
- Date: Thu, 05 Dec 2013 18:28:41 -0500
- To: Arnaud Le Hors <lehors@us.ibm.com>
- CC: Linked Data Platform WG <public-ldp-wg@w3.org>
On 12/05/2013 05:32 PM, Arnaud Le Hors wrote: > Hi Alexandre, > Thanks for completing your actions. I'm happy for us to discuss this on > Monday. Nice. > > A couple of observations: > > I noticed that as you defined LDPR you also introduced the notion of LDPG. > I think it's worth a note. My understanding is that an LDPG is essentially > what's called an LDPR today. You're right. Currently, the spec speaks about LDPRs and non-LDPRs, and the LDPR are the ones with the RDF data. The motivation behind that is the unification of all the concepts under LDPR. I wanted to be able to consistently say that an LDPC contains all the LDPRs it created. Another option would have been to create a new concept Foo to unify the LDPC, the LDPR and the Binary, and would be saying that an LDPC contains Foos. That'd be isomorphic to my proposal. It just felt natural to use LDPResource for the top concept. > If I understand correctly, your proposal on containment doesn't really > avoid doubling the triples. It's just that you're saying each set > (membership and containement) live in two different graphs/resources > (containerResource and ldpc, respectively) and by modifying the > non-member-property filtering mechanism we have one can manage to only see > the former. Correct. > I think we'd have to go beyond that because in the case of a > DirectContainer where the containerResource is the container/lpdc itself, > the two sets are actually in the same graph/resource. I actually asked myself that question. Because the DirectContainer was the first kind of Container to explicitly introduce the indirection on the subject membership, I thought that its use-case *was* to specify a ContainerResource different from the LDPC itself. For many people, the doubling-triple problem is not a problem. I just adapted the spirit of 5.9.1 to accommodate the people who don't want to see double. So the idea is to provide an opt-out option through a Linked resource to avoid those triples. We have at least those options: * keeping non-member resource * adding a non-containment resource * adding a property-only resource Or something in that spirit. It really depends on the use-case for those of us who expect to have applications with a lot of LDPRs in non-SimpleContainers. I'll be more than happy to update the proposal to reflect the use-cases when I know them. I can do it for Monday's call if I know it before the week-end. Otherwise, this can easily be handled in a future proposal that would amend mine. Alexandre. > > Cheers. > -- > Arnaud Le Hors - Software Standards Architect - IBM Software Group > > > > > From: Alexandre Bertails <bertails@w3.org> > To: Linked Data Platform WG <public-ldp-wg@w3.org>, > Date: 12/05/2013 11:03 AM > Subject: ACTION-115 / ACTION-116 (proposing text for ISSUE-89 and > ISSUE-90) > > > > Hi guys, > > I've been working on my actions ACTION-115 and ACTION-116. > > You can find a set (should say list as it's ordered) of proposals for > ISSUE-89 and ISSUE-90 at: > > * http://www.w3.org/2012/ldp/wiki/Issue-89 > * http://www.w3.org/2012/ldp/wiki/Issue-90 > > A few comments: > > * it proposes to make a Binary resource an LDPR (for unification and > consistency) > * it introduces the notion of containment > * containment is not related to membership > * membership is not changed at all > * it builds upon the new Containers, just replacing ldp:member with > ldp:contains (I explain the rational in the proposal) > * the "it doubles the number of triples" issue is addressed > * it specifies where the triples live, including the membership > triples > > I think it's now up to Arnaud to decide if the proposals can be > discussed during the next meeting. > > You guys should really look into it as soon as possible and provide > feedback (or just ask questions), so that I can improve the proposals. > > Cheers, > Alexandre. > > >
Received on Thursday, 5 December 2013 23:28:46 UTC