- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 20 Nov 2013 14:57:27 +0100
- To: Alexandre Bertails <bertails@w3.org>
- Cc: Steve K Speicher <sspeiche@gmail.com>, "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
On 18 Nov 2013, at 22:58, Alexandre Bertails <bertails@w3.org> wrote: > 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. I agree, but I would not put things in terms of triple creation, but in terms of truth conditions. What makes a triple of the form <ldpc, ldp:xyz, ?resource> true? To that my answer is it is true if the LDPC and the LDPR that stand in that relation are such that the various REST interactions defined by the spec hold. That at least leaves the definition distinct from questions about which resources SHOULD/MUST/MAY publish what. > >> - 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. yes. > >> >> - 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. agree. > > Actually, the current approach in the read-write-web implementation is > to refuse PATCH 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. agree, though it is not part of the definition of ldp:xyz that it should be published in an LDPC. The pragmatic reasons for publishing those relations there, is that that the LDPC is the creator of the resources, and so in the best position to tell what it is managing. You'd expect an LDPC that lists the resource that it manages, that it manages them. Where else would one look to find the managed resources? The search space would be infinite... > 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 yes, that is a very good use case for publishing the ldp:xyz relation in the LDPC. > >> - 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. I believe the spec is built on an unvoiced ldp:xyz, that it would be better to be expressed clearly. > >> 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. yes, or in terms of Truth conditions the triple <ldpc, ldp:xyz, ?resource> is false after the delete of ?resource, or of lpdc for that matter. And since LDPCs SHOULD NOT lie - a rule that applies to every agent of course - then an LDPC that publishes it, it is understood to be expressing a truth. At the very least the LDPC has made itself liable to certain expectations when publishing that triple. > > 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/ >> >> >> > Social Web Architect http://bblfish.net/
Received on Wednesday, 20 November 2013 13:58:00 UTC