Re: ACTION-115 / ACTION-116 (proposing text for ISSUE-89 and ISSUE-90)

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.


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


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


> Cheers.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> From:   Alexandre Bertails <>
> To:     Linked Data Platform WG <>,
> 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:
> *
> *
> 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