RE: Tie-in to HTTP in Hydra

On 15 Jun 2014 at 12:11, Kjetil Kjernsmo wrote:
> Hello and sorry for my hit-and-run email, things are rather busy around
> here.

Not problem at all. We are all busy people :-)


> On Tuesday 3. June 2014 20.39.28 Markus Lanthaler wrote:
>> 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?
> 
> Well, that's what I would want to know, and I don't think we know before
> it's done. :-) So, that's why I think the Hydra group should take that
upon
> their shoulders. And I think a description of how you would do it for more
> protocols would also be an important deliverable.

True. The thing, however, is that we don't have a lot of resources and it is
not something people have been asking for. In fact (if I remember correctly
and setting aside a couple of discussions with Sam), you are the first to
bring this topic up. So if you would like to spearhead that effort, please
write up a little draft to get this off the ground. It doesn't need to be
formal at all... a simple wiki page or GitHub issue would be more than
enough to start discussions and see if people are interested.


>> 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?
> 
> Right, good question!
> 
> So, the thing is that I don't think the payload has to go across the
> protocol to be useful hypermedia! :-)
> 
> Since the dawn of RDF, you could just stuff any triples in a "file" on a
> webserver, and the URL of that "file" wouldn't need to appear in the RDF
> at all. This newfangled thing that that URL should be a URI in a
> subject, or a concise bounded description or something, that's a
> restriction that may be useful in a Linked Data scenerio, but it is not
> a general requirement. :-) Moreover, nowadays, that URL can easily be
> thought of as a graph name. Or the URI of a hydra:Collection, or
> something, so it is not anymore constrained to files in a filesystem
> either, quad stores can easily accomodate.
> 
> So, that's what I did in the implementation of my one-off RTSP scenario:
> https://github.com/kjetilk/Sport-Orienteering-
> FYOR/blob/master/lib/Sport/Orienteering/FYOR.pm#L123 (please bear over
> with the code quality here, it was a one-off hack I wrote in a week).
> What it does is that for the cameras, that has rtsp-URLs in their
> subjects and thus isn't terribly good at carrying RDF payload (though I
> suppose they could stream RDF statements...?), I retrieve all triples
> with the graph name that matches the Request-URI using HTTP.

Yeah, it's easy for you to do because you know all of this. But what if I
send a friend of mine the URL

  rtsp://camhost1.orienteering.org/stream

He can stream the video, but that's it. There's no way for him to get any
data about this camera. On the other hand, if I would send him

  http://venue.orienteering.org/cam/1

He would be able to get to that data.. and if you include the link to the
stream there, he can also stream the video. Why make it more complicated to
consumers than necessary?


> And I'll claim that this is hypermedia is good as anything. :-)

Is it really?


>> 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?
> 
> Mmmmm, perhaps modularize it...? Like, having something that is just an
API
> description module ("top level") and then an HTTP module, and then pick
> another protocol and use that to learn what changes are needed in the top
> level to accomodate for more protocols?

Would you be interested to try to add another protocol? If so, which one?


--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 15 June 2014 19:39:07 UTC