- From: Steve Speicher <sspeiche@gmail.com>
- Date: Wed, 3 Apr 2013 15:17:26 -0400
- To: "Wilde, Erik" <Erik.Wilde@emc.com>
- Cc: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>, Richard Cyganiak <richard@cyganiak.de>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
On Wed, Apr 3, 2013 at 11:14 AM, Wilde, Erik <Erik.Wilde@emc.com> wrote: > hello nandana. > > On 2013-04-03 05:28 , "Nandana Mihindukulasooriya" <nmihindu@fi.upm.es> > wrote: >>My attempt was to see your example under this proposal but as both you >>and Raul pointed out, I fell into the trap of mixing protocol data and >>resource data. As this is protocol data, it has to be ldp:index and it >>should only appear in a page of >> a container but not in member's description. > > there really is no such trap. instead, mixing protocol data into your > resource representations is one of the essential design steps in REST, > when you design your hypermedia controls. because that's what REST > requires you to do: create representations that are self-contained, i.e. > they represent what the client needs as state at a given moment, and they > also represent the navigation capabilities for the client to engage in > further interactions. so don't worry about mixing, instead, see it as > moving in the right design direction. > > cheers, > > dret. > > In thinking about it more as well, I see it as that as well (adding some protocol behavior into the representation). If a client happens to take the triples and store what it gets as-is with these ldp:index triples, it then needs to understand that if it is mixing updates from further fetches of resources and that ldp:index value changes, it is then undefined for the first container/page representation. I client that stores these resources, may decide to strip any triples with ldp:index as the predicate without concern. The question is, if we go with Raul's original proposal, we may want to provide appropriate guidance on usages such as this. -- - Steve
Received on Wednesday, 3 April 2013 19:17:53 UTC