Re: LDP would benefit from being RESTful

On Monday 19. November 2012 14.40.36 Martynas Jusevičius wrote:
> I haven't had time to implement write operations yet, but it's a
> question of how JAX-RS @POST/@PUT/@DELETE methods map to Jena's
> OntResource add(Model) and remove() etc.

Heh, and I have yet to integrate Toby Inkster's RDF::ACL module in my 
RDF::LinkedData. :-) I've written a bunch of tests though.


> I think ex:replaced and similar metadata belongs to provenance, i.e.
> metadata about previous versions of the state. Provenance adds another
> (ideally, transparent) level of complexity.

Mmmm, I really don't want to go that far. Basically, what I have formulated 
does everything the current spec currently does, with just a tiny vocab and 
no spec :-) Except for PUTting a new resource, which is just because it 
doesn't have a URI yet for obvious reasons. Perhaps a URI pattern thing 
could do, that's an open question. But really, I think what I have is the 
simplest thing that could possibly work (but not simpler :-) ).


> Why I'm arguing HTTP is perfect for that... well, isn't HTTP what
> works and what the Web is built on?

Yup, but that's not a reason to break or at least compromise the 
"orthogonal specifications" principle of webarch.

> Its semantics are well-defined and
> implementations abundant. Adding a new vocabulary to augment HTTP
> state changing semantics would be superfluous, it would just make the
> LDP uptake very hard.

I think exactly the opposite. Adding "view source" is way better than 
adding yet another spec. 
 

> Yes, I saw that point coming  But how do you retrieve the
> representation of the resource in the first place? Presumably by GET
> method?

Yup.

> What if the resource is, say, write-only, and the GET method is not
> allowed? You would either have to invoke OPTIONS and check the
> available methods first, or invoke GET right away and fail. You can of
> course use the representation you had cached earlier, but that can
> very soon become obsolete and inconsistent with the current resource
> state and capabilities (such as allowed HTTP methods).
> 
> In other words, you generally cannot avoid this round-trip anyway, and
> again HTTP plays the crucial role here.

Weeeell... I think that we really need to twist our minds to ensure that 
round-trip, given the pushback around 303, doesn't occur needlessly. If a 
HTTP request needs to be done for small amounts of data, and lots of them 
are needed to deliver the stuff that's needed for a given application, 
that's certainly a big problem.

In this case, I think you clearly need to put the triples needed to tell 
the client what it *can* do in the error message itself. For HTTP, that's 
straightforward, you just respond with a 403 with the hypermedia triples. 
So, no need for round-trip! *phew* :-) 


> Is it only me who sees POST as appending the RDF graph (server mints a
> new resource URI if needed), while PUT can be used to create or
> replace a resource with request URI and its RDF description?

Not at all, that's the common interpretation, and the sane interpretation. 
But that's also the reason why you don't need an elaborate spec to say it, 
as there are only details left to be told, and that can be better expressed 
in a vocabulary so that clients can just "view source". 

Let me reiterate my example: The thing with "appending the RDF graph", is 
that there are (at least) two perfectly reasonable ways of doing this: One 
is a simple union of the graphs, in the other case, called RDF Merge where 
you do some magic on the blank nodes before the union. That's the sort of 
thing I'd much prefer can be expressed in-band rather than out-of-band.

> > Moreover, well, I guess it is a rather contrived example, but I
> > couldn't
> > come up with a better right now: Say you have a pizza representation:
> > You could then just order it, or you could add more toppings, both
> > resulting in PUT operations. You'd like to describe the distinctions,
> > but again OPTIONS can't do that, RDF can. Though, I admit that it
> > would be better to come up with a real, distinguishing use case.
> 
> You don't have to work on the same pizza URI and the same
> representation to achieve this, do you? If "pizza order", "pizza", and
> "pizza toppings" are different concepts, then they might (and probably
> should) have different URIs, different representations, and implement
> different HTTP methods.

Ah, indeed, I wasn't suggesting that they wouldn't. Let me try to clarify 
my position (I have to admit that this is pretty far from the research I'm 
involved in, I write this as a old-time keyring-carrying semwebber with a 
practical viewpoint, which may contribute to any lack of clarity). Anyway, 
my motivation is the case where you need a whole bunch of resources to do 
useful stuff and enable useful interactions... Let me continue the pizza 
example, with the following Turtle:

</pizza/margherita> a ex:Pizza ;
 dc:title "Pizza Margherita" ;
 ex:order </pizza/margherita/order/> ;
 ex:toppings </topping/tomato>, 
  </topping/basil>, 
  </topping/mozzarella>; 
 ex:extra-toppings </topping/anchovies/order/> ; # bleh
 ex:side-orders </drink/coke/order/>, </movie/the-moon/order/> .
</pizza/margherita/order/> hm:createNewPattern 
"/pizza/margherita/order/{\w}" ;
 dc:title "Order a Pizza Margherita" .
</topping/anchovies/order/> hm:createNewPattern 
"/topping/anchovies/order/{\w}"  ;
 dc:title "Add Anchovies to your Pizza" .
 
The {\w} means that the client may create a URI with a word. It is 
basically what was lacking from my paper, I'm just throwing it out as an 
idea, haven't thought carefully about it.

So, again excuse the contrived example. :-) I hope the idea gets clear 
though: In a case where you want to order a pizza, the online pizzeria 
isn't likely to sell only the pizza, there may be a bunch of other things, 
like more toppings, drinks, even movies and whatnot... To achieve a 
sensible balance between the number of (HTTP) requests you need to do get 
all the data required and the size of the messages, at some point you'll 
need a Linked Data Information Architect who gets to decide how the graph 
looks like, and in some case, dereferencing the pizza yields not only the 
description of the pizza, but also triples concerning how to order, as well 
as extra information of the toppings. The reason why the toppings are there 
is that the Linked Data Information Architect has decided that most 
customers will order them, so the information needs to be immediately 
available without any HTTP requests required, whereas drinks and movies are 
not that frequently interesting, so they are loaded on demand. 

So, my position is that if all you can do is to use HTTP verbs, you can 
only work on the Request-URI, resulting in awful latency in interactions, 
and possibly the need to make tens if not hundreds of HTTP requests. I 
think this flexibility is critical, and I think it comes at basically no 
cost in terms of complexity.

In conclusion, if all you ever do is to work on a few resources, you might 
well be OK, but I don't think that's the way things are done in today's 
environment.

> If we could reformulate the pizzas into a software bugs, then we could
> extend my initial example and cover more use cases

Yeah, that'd be nice, but I was kinda into pizzas right now, for no 
particular reason. :-)


Kjetil

Received on Monday, 19 November 2012 21:36:46 UTC