Re: How to find the members of an LDPC?

On 6 Nov 2013, at 23:53, Eric Prud'hommeaux <eric@w3.org> wrote:

> * Wilde, Erik <Erik.Wilde@emc.com> [2013-11-06 16:52-0500]
>> On 2013-11-06, 12:20 , "Eric Prud'hommeaux" <eric@w3.org> wrote:
>>>>> 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.
>>> If an LDP client POSTs an appropriate RDF message to an LDP server, the
>>> server creates a new resource and tells that client what the resource is.
>>> What other clients would want to know about the newly created resource?
>>> How would they even know it exists?
>> 
>> - by clients sharing URIs (bookmarks) of resources through whatever means?
>> 
>> - by clients listing collection contents and expecting a new resource
>> being made availabel to them through a navigable link?
> 
> Yeah, the client shared it after getting it back from the server that
> created the resource,

What if the client looses that information? 
I can just see the army volunteering service find your protocol extremely
useful. A few bad proxies along the way correctly distributed, and 
how convenient: a nice batch of new volunteers.

(see my use case:
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Nov/0022.html )

> or some other client interrogated the container
> and found some member which matched some interesting properties.

As I see it Alexandre's example shows exactly that this cannot
be relied on. You cannot reliably infer from information in the 
LDPC what the LDPRs are. 

Or are you saying that where those triples live is pretty immaterial:
as long as a SPARQL endpoint is available it should be easy to query the 
whole server to find this info?

> 
> The text I was replying to is included above: "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." This implies to me that some other
> client is known to be interested in a resource as it is created.

The server at the very least it seems to me, would want to know.
But there is also the following spec text:

5.6.1 When a LDPC member resource originally created by the LDPC (for example, one whose representation was HTTP POSTed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion (for example, the member is managed by the same server), the LDPC server must also remove it from the LDPC by removing the corresponding membership triple.
5.6.3 When the conditions in 5.6.1 hold, and the LDPC tracks member resources that it created using the ldp:created predicate, the LDPC server must also remove the deleted member'ldp:created` triple.
5.6.4 When a LDPC member resource originally created by the LDPC (for example, one whose representation was HTTP POSTdd to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server created an associated LDPR (see 5.4.12), the LDPC server must also remove the associated LDPR it created.

So it seems to me from the above that it was quite clearly the intent
of the protocol that one way to remove triples was to remove the
created LDPR. But now we don't have PATCH, so we can't just PATCH the LDPC,
and an error along the way could make it impossible for the poor citizen 
to remove himself from the list of volunteers in the period of 7 days voted 
by congress to allow people to reconsider their volunteering commitment.

> 
> What protocol does this imply? Is it that some client subscribes to
> every new resource created by POST to a container? Is it that it has a
> special pairing with the POSTing client but the POSTing client won't
> share the newly created resource?

Alexandre's use case was a shopping cart service, which seems to be pretty 
simple to me and quite clearly in the domain of our use cases:

You have a number of clients, one doing shopping, perhaps another checking your
accounts, and each of them would like to be able to go from a URL of your LDPC to your
shopping cart contents.


> 
> 
>> cheers,
>> 
>> dret.
>> 
> 
> -- 
> -ericP
> 
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
> 
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.

Social Web Architect
http://bblfish.net/

Received on Thursday, 7 November 2013 08:43:17 UTC