- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Tue, 3 Jun 2014 20:39:28 +0200
- To: <public-hydra@w3.org>
- Cc: "'Kjetil Kjernsmo'" <kjetil@kjernsmo.net>
Hi Kjetil, On Friday, May 30, 2014 4:38 PM, Kjetil Kjernsmo wrote: > Since this is my first message to the Hydra WG, I'd like to present myself > quickly: I've been around the semweb community since 1998, but started most > activities around 2005-ish. I've been a member of several W3C groups, WCL, > POWDER, and SWEO (where I took the initiative to the Community Projects, out > of which the Linking Open Data project grew), and the SPARQL WG. In 2010, I > left the industry to pursue a Ph.D., which I'm still doing, on SPARQL stuff. Given your experience, I'm thrilled to have you on board. Good luck with your PhD. > While I love SPARQL, I think the vast majority of semweb application would > be hypermedia-based, thus it is a prominent side-interest of mine. I had a > paper about on the LAPIS 2012 workshop: > http://folk.uio.no/kjekje/2012/lapis2012.xhtml > and recently, I've started hacking a hypermedia application with a more > narrow motivation: > http://folk.uio.no/kjekje/projects/orienteering/byodnfyor.html Great stuff! > Anyway, to the point: I think Hydra is a really good start, but one thing > that surprised me is that it has a pretty tight tie-in to HTTP. Since REST > is expressedly *not* tied to HTTP, or any other protocol for that matter it > feels odd, and it also seems to be bad decision for pragmatic reasons too: > My BYOD+FYOR scenario above doesn't only do HTTP, it does RTSP too (but it > could do HTTP Live Streaming, MMS or a number of other protocols instead). Hmm.... you are right. It certainly has been optimized for HTTP, but wouldn't it be quite trivial to extend it to other protocols if needed? > I was thinking about this when I wrote my LAPIS paper too, and I decided > that the individuals I used should not nessarily look like HTTP verbs. > Rather, they should make sense when read out as part of the interaction: > Instead of saying POST, I would say what you would do when POSTing, i.e. you > would do an RDF Merge of the payload into the referenced resource, thus > :mergedInto. PUT would do a replace, delete happens to be the same as the > HTTP verb, though :-) Right, that's exactly what operations are supposed to do. The method just tells you how you can invoke that operation over HTTP. Nothing would stop us from introducing other properties that would allow to invoke the same operation over other protocols. The questions however is: is that really something people are looking for? Does it make that much sense to send, e.g., MMS or e-mails with JSON-LD/Turtle/whatever payloads? How would you reference resources with those protocols? > Then, what the client should do if the protocol happens to be HTTP, that's > something the description of the the :mergedInto should express. I.e. the > description of the API should not need to contain protocol implementation > details, that's something the API should describe itself. And that extends > beyond HTTP, when an API tells the client it may stream some video resource, > the individual is :play. That's basically what an operation does. You might have an AddItem operation which tells you that it can be invoked by POSTing. I think the difference is that operations are somewhat self-contained whereas you would like to strictly separate those two things. Is that correct? > I think this is important to acheive independent evolution of protocols and > API description, and frankly, I think it would also make more sense for > developers, they should think first and foremost about what the API is > supposed to do for them, not how it happens to be implemented on some > protocol. Fully agree with your second point but I'm not so convinced about the first one. The API description should tell me everything I need to know about an API. That necessarily also includes protocol details such as the HTTP method to use. > The next step is then that the description of how something actually is done > on e.g. HTTP. That too possibly belongs in Hydra, but only when the top > layer has been established. IMHO. ;-) So, let's try to make this a bit more concrete. What do you think would need to be changed in Hydra to make "the top layer" more established? -- Markus Lanthaler @markuslanthaler
Received on Tuesday, 3 June 2014 18:40:12 UTC