Re: A reference to a WebSocket stream

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

Yes, I plan to provide a way to get recorded observations. But I can't
navigate the recorded observations with indexes, instead I'll need to
use date and time range. Also I want to *somehow* use templated links
(hydra:TemplatedLink) or filters (hydra:filter or hydra:Filter which
are not in the vocabulary yet, as I know), to allow the user to
request observations from a particular date and time range.

Is this Updates-Via header standardised already? Have you consider a
representation of this link/concept with a JSON-LD/RDF vocabulary,
instead of an HTTP header?

The pub/sub protocol is also a new thing, right? Did you consider
existing websocket-based pub/sub protocols, e.g. WAMP [0]?

> BTW If you only want to read, have you consider Server-Sent Events?

No, I don't. But now, I see that the main reason to use websocket
instead of SSE could be the support of non-browser clients.

[0]: http://wamp-proto.org/

Cheers,
Maxim

On Wed, Dec 2, 2015 at 8:05 PM, elf Pavlik
<perpetual-tripper@wwelves.org> wrote:
> (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 19:12:17 UTC