Re: decentralized use cases

hello kevin.

you are making some great points, thanks a lot for weighing in!

On 2012-08-06 20:58 , "Kevin Page" <kevin.page@oerc.ox.ac.uk> wrote:
>I've been catching up on the WG and have noticed this being raised --
>but not, afaict, resolved -- in a number of threads. So this is mostly
>to say: yes, I think there is a distinction here; yes, I am interested
>in this and the issues it entails, e.g. non-RDF resources; and I would
>be happy if this were on-topic for the WG (doesn't mean it is!).

just reiterating here: in REST, all you do is define the service surface,
so if you specify interactions with collections, you define a media type
that exposes the required resources, and codified interactions with them.
this does not mean that you have to make any statement about what is being
managed in that collection; this can be handled by a different media type
(and this is how it is done in atom).

>I see a difference between a service providing RDF data that is browsed,
>retrieved, combined, etc. where the resources are exposed and organised
>according to how the data itself is modelled. Here an interaction with
>the service is primarily about directly modifying that graph. I think
>this covers traditional Linked Data, the SPARQL graph store protocol
>(and perhaps even the member submission?). Are we saying that all
>RESTful application interactions can be boiled down to adding, removing,
>or changing bits of a graph?

RDF's value proposition and starting point is that one of a unified
metamodel. in such a world, it is possible to map many operations to
manipulating the metamodel. REST, on the other hand, does not care about
the metamodel of a resource behind the scenes, it only cares about
codifying the service surface based on a model that is sufficient to
support the interactions of a media type. i think it is this difference in
approach (RDF's "let's all agree on a metamodel" vs. REST's "let's not
even talk about the service's metamodel apart from parts we need for the
service surface") that makes it a bit tricky to think of RDF and REST
together. very different mindsets and sets of constraints.

>From experience in a couple of projects, we haven't found this
>sufficient when designing a service to support RESTful client-server
>interaction -- particularly for writing data (no guarantee we haven't
>just been wrongheaded, of course ;)  ). You need additional resources to
>support the application that's being performed over/on/with the data
>(the RESTful application state changes, if you like) and also a
>mechanism to codify that interaction through e.g. link relations or
>media types -- and here I think there is scope for the WG to provide
>clarify and best practice (if it's on topic)

that was my starting point: REST is all about media types, and media types
are a codified way how to handle interactions with a service in a specific
application domain. mike amundsen has done terrific work to clarify this
area a little better. but essentially, REST is the opposite of "defining
metamodel-level CRUD and declare victory", it is about taking the
application domain, analyzing the interaction patterns and state
transfers, and then designing a media type that allows servers and clients
to engage in this kind of interaction. and as you say, apart from the most
simplistic scenarios, this almost always implies designing things in a way
that do things such as representing transient server state (a pending
transaction, for example), and codifying the affordances provided by those
resources.

>I think it is this "control" over the API Erik refers to -- the control
>beyond generic graph manipulation of the complete underlying dataset.
>Not to say access control isn't also important, of course.

REST is, to some extent, the opposite of reaching into the back-end with
operations that directly work on the back-end metamodel.

>(and fwiw, in the uses cases I've experienced this inevitably involves
>resources that aren't RDF-derived, although you'll likely have reached
>them via an RDF resource. RDF is not the right encoding or
>representation for everything. These resources may sensibly be out of
>scope for an LDP spec, but I think there are many cases where they will
>be provided by the same server, so consideration of this interaction
>seems important.)

great point. web architecture give us a good starting point because media
types allow us to separate these things nicely. clients follow the flow of
a media type and at some point may be taken into the context of a new
media type. this is good and how the web works, but what we should say,
and it's a great point to make, is where clients should expect this kind
of "crossing the boundaries of media types". web clients almost always
must be able to "speak" several media types to be able to get their job
done, and the platform should be clear about which media types are
essential, which ones are nice to have, and how these types connect.

>Now if we consider a description of the service (what's been sometime
>referred to as the surface here) to *be* (part of?) the data exposed by
>the LDP does the distinction become blurred? Is there one combined graph
>of both whereby the "internal" data could kept private using access
>controls while the surface resources are public? Can the same mechanisms
>be used to interact with service surface resources or direct data
>manipulation, i.e is this a false distinction? Are BPRs and BPCs
>sufficient for this and can we build RESTful application interactions
>with them in combination with other resources?

that would be the REST way of doing it, and for the use cases presented in
the submission, for many of the problems described there are existing and
established standards. which was my initial point, but then the general
feedback from the WG was that these were not based on RDF, and thus could
not be used.

cheers,

dret.

Received on Tuesday, 7 August 2012 07:45:11 UTC