- From: Alexandre Bertails <bertails@w3.org>
- Date: Mon, 18 Nov 2013 16:58:43 -0500
- To: Steve Speicher <sspeiche@gmail.com>, Henry Story <henry.story@bblfish.net>
- CC: "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
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