Re: ldp-ISSUE-89 (ldp:xyz): Tie the interaction model with the LDP data model through the notion of Managed Resources [Linked Data Platform Spec]

Hi Steve,

On 11/18/2013 03:50 PM, Steve Speicher wrote:
> Hi,
>
> On Mon, Nov 18, 2013 at 3:32 PM, Henry Story <henry.story@bblfish.net
> <mailto:henry.story@bblfish.net>> wrote:
>
>     Can we try to work on a definition of ldp:xyz that would be
>     satisfactory to everyone. Here's a
>     first shot at this:
>
>     @prefix ldp: <http://www.w3.org/ns/ldp#> .
>     @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>     @prefix rdfs: <http://www.w3.org//2000/01/rdf-schema#> .
>     @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
>
>     The rdf for ldp:xyz could be the following:
>
>
>     ldp:xyz a rdf:Property;
>        rdf:domain ldp:Container;
>        rdf:range ldp:Resource; //<- this is intended to refer to the set
>     of LDPRs and LDP Binaries. Find a name for it.
>        rdfs:comment """
>          ldp:xyz relates an LDPC to the resources that it manages [link
>     to the spec for Managed Resource]
>        """.
>
>
> This doesn't help me as I'm mostly interested in what the details of
> what "relates" and "it manages" mean? From that, it should fall out what
> "xyz" should be.

ldp:xyz was intentionally chosen for people to focus on the feature,
without all the history and tears behind ldp:member, ldp:created,
ldp:membershipXXX, etc.

> Do you have a link to one of the wiki pages you created that defines
> "spec for Managed Resource"?  The entire LDP spec is about "managed
> resources" today...LDPRs, LDPCs, binary resources, etc.

Arnaud made clear several times that the spec was all about the
membership concept, not resource management. The only mention I could
find in the spec is at [1], "for example, the member is _managed_ by
the same server", where "membership" and "being managed" are
conflated.

[1] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-5_6_1

> Questions this issue/proposal for ldp:xyz should answer which would help
> find the right name for it:
>
>    - When should a triple of the form <ldpc, ldp:xyz, ?resource> be
> created?  I would assume when a resource is created by POSTing its
> representation to a container.

Quoting myself from issue-89:

[[
*Being managed* is defined by any successful REST interaction (with
  side-effects) with an LDPC/LDPR, eg. creation through POST on LDPC or
  deletion through DELETE on LDPR.
]]

ldp:xyz is the dual of the REST interactions in the LDP data model.

>      - When creating a non-LDPR resource, a 2nd LDPR may be
> created...are there 2 triples of the form: <ldpc, ldp:xyz, ?nonLDPR> and
> <ldpc, ldp:xyz, ?LDPR> ?

The specification says [[ When a LDPC creates a non-LDPR (e.g. binary)
member [snip] it might create an associated LDPR ]]. It does not say
that the associated resource is managed, and must not say it, because
the successful creation (HTTP 201) was only for the binary resource.

>
>   - Can someone PATCH ADD <ldpc, ldp:xyz, ?resource> ?  Does the server
> need to fixup any other membership triples?

No, the ldp:xyz triples are managed by the server and a client cannot
mess with them.

Actually, the current approach in the read-write-web implementation is
to refuse PATH and PUT on an LDPC as it acts as a guard for the
managed resources with special semantics. Its configuration data
(eg. ldp:membershipXXX) should be configured through a Linked
resource. I'm saving this issue for later.

>
>   - Does this ldp:xyz need to be listed explicitly in the result of a
> GET on a LDPC or can it be inferred from non-member properties?  In
> other words, is it required?

It is mandatory and cannot be derived from anything else.

The proposed data model for an LDPC is that those triples belong to
the Named Graph at the LDPC URI and therefore are returned with a GET
on that URI.

The feature being proposed here can serve as the basis for a service
to retrieve specific managed resources, using SPARQL for example. This
is not discussed with this issue but I've given a complete description
of that idea at [2] as a response to John Arwe, where I tie all those
concepts together.

[2] http://lists.w3.org/Archives/Public/public-ldp/2013Nov/0009.html

>   - Does this <ldpc, ldp:xyz, ?resource> triple need to exist for EVERY
> member resource that is a member of the LDPC?

The relationship with the current notion of membership was discussed
by Henry and is linked from the issue. The proposal cannot be easily
tied with the current notion of membership.

> or under what conditions
> is it needed (created, created by a certain means -- POSTing to LDPC,
> what to do with existing large data sources)?

I don't understand that question.

>   - What happens to the triple <ldpc, ldp:xyz, ?resource> when a DELETE
> is done on ?resource ?

It's the same reasoning than for POST-on-LDPC earlier: HTTP DELETE is
a REST interaction with side-effects (deletion) therefore there is an
impact on the corresponding managed triples in the LDPC: the triple
has to be removed.

Alexandre.

>
> Perhaps there are more.
>
> - Steve
>
>
>     On 18 Nov 2013, at 17:19, Linked Data Platform (LDP) Working Group
>     Issue Tracker <sysbot+tracker@w3.org
>     <mailto:sysbot%2Btracker@w3.org>> wrote:
>
>      > ldp-ISSUE-89 (ldp:xyz): Tie the interaction model with the LDP
>     data model through the notion of Managed Resources [Linked Data
>     Platform Spec]
>      >
>      > http://www.w3.org/2012/ldp/track/issues/89
>      >
>      > Raised by: Alexandre Bertails
>      > On product: Linked Data Platform Spec
>      >
>      > Proposal: make `ldp:xyz` mandatory.
>      >
>      > `ldp:xyz` as a URI is left open for discussion, this issue is
>     about the requirements and the invariants for the needed feature.
>      >
>      > This proposal has *no intention* to mix with the notion of
>     membership as defined by the specification at the time I created
>     this issue.
>      >
>      > The idea for `ldp:xyz` is to answer the question of what
>     resources are *managed* by an LDPC (it's not about membership).
>     *Being managed* is defined by any successful REST interaction (with
>     side-effects) with an LDPC/LDPR, eg. creation through POST on LDPC
>     or deletion through DELETE on LDPR.
>      >
>      > Corollary: the presence/absence of `ldp:xyz` triples is directly
>     derived from the REST interactions. And they entail the possible
>     interactions.
>      >
>      > Note: the membership relations can be derived from an LDP model
>     having `ldp:xyz` at its heart, as showed by Henry at
>     http://www.w3.org/2012/ldp/wiki/Issue-88#make_ldp:member_mandatory
>     (where Henry uses `ldp:member` instead of `ldp:xyz`).
>
>
>
>
>     Social Web Architect
>     http://bblfish.net/
>
>
>

Received on Monday, 18 November 2013 21:58:53 UTC