Re: Interaction model vs data model

hello all.

thanks for your explanations, arnaud, and i think you're absolutely
hitting the target when it comes to explaining some of difficulties around
combining RDF and REST.

On 2013-01-24 2:08 , "Arnaud Le Hors" <lehors@us.ibm.com> wrote:
>Discussing whether LDPCs are a subclass of LDPRs, Henry wrote [1]: "they
>are not, since POSTing a Graph on an LDPR is very different from POSTing
>on an LDPC, and since RDF is a logical vocabulary that does not work with
>the
> concept of method overloading. "
>I have to admit not to understand this statement at all and, maybe it's
>just me but, I actually believe that clarifying this might help us a
>great deal with the ongoing discussions around the interaction and data
>models.

i think the major misunderstanding here is the idea that when you POST
RDF, all you do is you add the POSTed triples to some graph. that's not
the case, as this wouldn't have anything to do with REST; this would just
be using an RDF data model, with no interactions driving the protocol.

as an illustration, let's look at a very simple example: let's assume a
product catalog and each product page has an "order" link that requires
customers to just POST their address, and then they're ordering that
product. in such a scenario, you would POST the exact same representation
to all "order" links, but different things would happen. that's because
the context of the interaction matters. in terms of an RDF back-end
implementation, you would probably need to somehow transform the POSTed
RDF to actually say that it's an order for product x, but the REST part of
this scenario would simply mean that the protocol tells clients to POST an
address, and because they do it in the context of a certain application
flow (the product listing, which exposes an order link), it means that
they are actually ordering something by doing this.

i think arnaud has made a very important point here that we must clearly
separate the data model and the interaction model. in the example above,
the "order" is not part of the exposed data model at all (other than as an
exposed "submit your address here" link), and the protocol wouldn't need
to say anything about orders. unless of course you would have another link
that would present you with a list of orders, in which case you would need
to represent those. but "ordering" itself would be a pure interaction that
has semantics defined by the application flow. how/if that would translate
to an "RDF order" in the implementation would be entirely outside of the
scope of the protocol.

we must move in the same way: we have to represent those parts of the data
model that are exposed as resources in the protocol. we have to drive the
protocol by exchanging these representations through application flows
guided by links. depending on the nature of our interactions
(safe/idempotent) we pick the appropriate method for these interactions.

>RDF doesn't have the concept of methods, so it certainly doesn't have the
>concept of method overloading, but this merely concerns the data model. I
>don't understand why this would prevent us from defining different ways
>of handling
> HTTP verbs depending on the type of LDP resource we deal with - an LDPR
>or LDPC. I would say this only concerns the interaction model and the RDF
>data model doesn't prevent us from doing so.

exactly. the result of a RESTful interaction on the data model must take
both the POSTed representation into account, and where it has been POSTed
to: these are the two "inputs" that each interaction gives the server, and
allow the server to process this request appropriately.

cheers,

dret.

Received on Thursday, 24 January 2013 08:50:56 UTC