Re: A reference to a WebSocket stream

(cc += ldpnext since I will refer to SoLiD below)

On 11/30/2015 09:36 AM, Maxim Kolchin wrote:
> Hi Markus,
> 
>> On 27 Nov 2015 at 21:18, Maxim Kolchin wrote:
>>> I'm working on an API for IoT middleware, the API is going to be based
>>> on Hydra.
>>
>> Exciting! Is there already some documentation or a demo available somewhere?
> 
> I'm still in the beginning, so it's not ready yet to be published :)
> 
>>> In this API I want to provide a link to a websocket stream
>>> which publishes latest observations of a device. How such a link should
>>> be represented? Are there relevant approaches outside of Hydra
>>> vocabulary?
>>>
>>> Currently, I just extend hydra:Link, i.e.:
>>>
>>> {
>>>     "@context": {
>>>         "vocab": "http://example.com/#",
>>>         "hydra": "http://www.w3.org/ns/hydra/core#",
>>>     },
>>>     "@id": "vocab:observations",
>>>     "@type": "hydra:Link",
>>>     "rdfs:range": "hydra:Resource"
>>> }
>>>
>>> Probably "rdfs:range": "hydra:Resource" isn't appropriate statement,
>>> since a websocket stream is not a resource, but a kind of "continuous
>>> collection".
>>
>> I would argue it is a resource, it is just being accessed through a different protocol (Websocket vs. traditional HTTP)
>>
>>
>>> Then continuous collection could be just a subclass of
>>> hydra:Collection with subscribe/publish operations and subscribe
>>> operation could return ssn:Observation (from [0]), i.e.:
>>>
>>> {
>>>     "@context": {
>>>        "vocab": "http://example.com/#",
>>>        "hydra": "http://www.w3.org/ns/hydra/core#",
>>>        {
>>>            "@id": "vocab:ContinuousCollection",
>>>            "@type": "hydra:Class",
>>>            "rdfs:subClassOf": "hydra:Collection",
>>>            "hydra:supportedOperation": [
>>>                "@type": "hydra:Operation",
>>>                "hydra:method": "WEBSOCKET_SUBSCRIBE",
>>>                "hydra:returns": "ssn:Observation"
>>>            ]
>>>        }
>>>     },
>>>     "@id": "vocab:observations",
>>>     "@type": "hydra:Link",
>>>     "rdfs:range": "vocab:ContinuousCollection"
>>> }
>>>
>>> What do you think about that, Hydranians?
>>
>> Why would you want to subclass hydra:Collection? I think this demands a different representation. I don't think that a collection and a stream >have too much in common. Hydra is currently quite HTTP focused but people raised similar points in the past already. Till we get to work on >that, I would propose to That you just subclass hydra:Resource. I personally would call such a class something like WebsocketSource (if you >want to be able to distinguish between sources and sinks), WebsocketStream, or also WebsocketResource instead of ContinuousCollection.
> 
> I just wanted to show two options which I'm considering. I was
> considering Collection as an option, because both collection and
> stream are set of members. Although they probably should be disjoint
> classes, because collection should (or may) be navigateable (with the
> first and last links and others) and stream is definitely not.
> 
> I'll represent it as a subclass of hydra:Resource.

Hi Maxim,

Do you consider to make exactly the same data available as hydra
collection using http(s):// *and* real time stream using ws(s):// ?

How can client access observations recorded before it connects to web
socket? If the connection gets interrupted, how does the client get
observations made in a time when it disconnected?

In SoLiD draft (heavily based on LDP), I see proposal for *Updates-Via*
HTTP header: https://github.com/solid/solid-spec#subscribing

BTW If you only want to read, have you consider Server-Sent Events?
http://www.w3.org/TR/eventsource/

Cheers!

Received on Wednesday, 2 December 2015 17:05:49 UTC