Re: How to find the members of an LDPC?

Hi,


On Thu, Nov 7, 2013 at 9:42 AM, Henry Story <henry.story@bblfish.net> wrote:

>
> 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.
>

+1

As a developer implementing LDP, I find it very strange not to be able to
list the contents of an LDPC, especially since it's the LDPC's job to
create or remove the resources. Why would a protocol that is supposed to
work at the Web scale, impose such limitations?

There are a lot of reasons why one might want to get a list of LDPRs. For
instance, take any collaborative service (e.g. a wiki, a CRM, etc.) where
you want to make sure the information you intend to add does not already
exist. Generally, _any_ client that is not capable of persistency will face
this problem, which is the case for most javascrip-based Web applications,
which depend on the server hosting the LDPC for data persistency.



> 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.
>

+1

Andrei


>
> >
> >
> >> 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/
>
>
>