- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 6 Nov 2013 18:26:45 +0100
- To: Steve K Speicher <sspeiche@gmail.com>
- Cc: Alexandre Bertails <bertails@w3.org>, Linked Data Platform WG <public-ldp-wg@w3.org>
- Message-Id: <F32C63B7-F5AC-4FE0-A964-3752F3381F4A@bblfish.net>
On 6 Nov 2013, at 15:01, Steve Speicher <sspeiche@gmail.com> wrote: > Hi, > > > On Tue, Nov 5, 2013 at 7:49 PM, Alexandre Bertails <bertails@w3.org> wrote: > Hi guys, > > I understand ldp:containerResource, ldp:containsRelation and > ldp:insertedContentRelation as a _set of instructions_ for the LDPC to > manage some domain-based relations, but I don't see a way to find the > LDPRs created by the LDPC. > > Please consider the following example: > > $ GET http://example.com/shopping/cart/ > > [[ > </shopping/cart/> a ldp:Container; > ldp:containerResource <#>; > ldp:containsRelation order:contains; > ldp:insertedContentRelation foaf:primaryTopic. > ]] > > $ POST http://example.com/shopping/cart/ > > [[ > <> foaf:primaryTopic <urn:isbn:0470396792> . > ]] > > $ GET http://example.com/shopping/cart/ > > [[ > </shopping/cart/> a ldp:Container; > ldp:containerResource <#>; > ldp:containsRelation order:contains; > ldp:insertedContentRelation foaf:primaryTopic. > > <#> order:contains <urn:isbn:0470396792> > ]] > > Question: from the last GET, what is the LDPR for <urn:isbn:0470396792>? > > If the ldp:member relation does not exist, how would a client deduce > the members that were created > ? > > One would assume that the POST would return a 201-Created status message and Location header of the URL for the new resource created. The server may produce another triple to link the created resource (LDPR), not sure what it might be: > <> ex:describes <#>. yes, the post returns a Location header. But that only allows the client that POSTed the resource to know the address of the LDPR created. It would be useful if other clients could also find that resource by asking the LDPC. > > > What really matters as client is to know what interactions are > possible. If an interaction model were to be defined, I would expect > to see something like that: > > 1. HTTP HEAD on </foo/> tells client "I am an LDPC" as it returns a header > Link: <http://www.w3.org/ns/ldp#Container>; rel="type" > > 2. from a GET on </foo/>, a client finds/deduces the LDPRs managed by > </foo/> eg. with triples like { </foo/> ldp:member </foo/bar> } > > 3. HTTP HEAD on </foo/bar> tells client "I am an LDPR" as it returns a header > Link: <http://www.w3.org/ns/ldp#Resource>; rel="type" > > 4. HTTP DELETE on </foo/bar> MUST remove the LDPR and remove > { </foo/> ldp:member </foo/bar> } from the LDPC > > This is the interaction model defined by LDP ... with the exception of ldp:member this isn't defined but think you are saying ldp:containsRelation. I can't tell if you are saying there is something missing or you are just describing roughly how it works. I think alex meant ldp:created which we had defined in Spain, but which is still not in the ldp ontology http://www.w3.org/ns/ldp ldp:created a rdf:Property; :comment "The subject LDPC created the object Resource."; :domain ldp:Container; :isDefinedBy ldp:; :label "created"; :range ldp:Resource; vs:term_status "unstable" . ldp:member is probably a better name, as it better matches the intution that deleting the resource makes the relation false. "created" tends to make one think that the relation remains true even when the object has been deleted. ( even though for pragmatic reasons one would want to remove the relation because it can no longer be dereferences ). Here is a definition of ldp:member I think Alexander is thinking of: ldp:member a rdf:Property; :comment "The subject LDPC created the object Resource, and that resource has not yet been deleted"; :domain ldp:Container; :isDefinedBy ldp:; :label "created"; :range ldp:Resource; vs:term_status "unstable" . > > - Steve > > Alexandre. Social Web Architect http://bblfish.net/
Received on Wednesday, 6 November 2013 17:27:18 UTC