Re: IOTDB worldview vs EVRTHNG

-- Just splitting this conversation, so we don't have to many concurrent
threads! --

JSON-LD

There's no dependency on Things themselves actually understanding JSON-LD,
just that there exists a Model that's written in JSON-LD that explains how
to interact with that Thing.

For example, back to the WeMo Socket. Here's the Model for this in our
authoring language (JavaScript):

https://github.com/dpjanes/homestar-wemo/blob/master/models/WeMoSocket.js


Here's what it looks like in JSON-LD

https://gist.github.com/dpjanes/79a256c02c0a31c9aa42


What's great is that I can use introspection to create user interfaces for
this, just based on the JSON-LD. But yeah, the WeMo itself doesn't know
anything about JSON-LD. In fact, the protocol is some horrible UPnP XML
stuff, but the end user doesn't need to know that.

D.




On Wed, Jun 3, 2015 at 8:48 AM, Vlad Trifa <vladounet@gmail.com> wrote:

> Hey David,
>
> I partially agree with this.
>
> I'll rarely need to get the metadata of what properties & co are, so they
> obviously shouldn't be returned every time, and that's why you'd call the
> end-point below only once (to discover it and understand it). Then you'll
> only need to interact with ".../sensors/humidity" directly where you don't
> get that data model anymore - but just the definition.
>
> I'm not OK with the idea that any property and sensor MUST use JSON-LD. If
> we can all agree here on one basic model that is good enough and
> sufficiently flexible to deal with (yes, you are introducing some coupling,
> which you're doing with JSON-LD anyway, and even more so), then I don't
> need JSON-LD.
>
> But I'm obviously OK with the idea that any device can (and even should)
> expose its services with json-id so that it has more flexibility to expose
> metadata & co and more (non-wot) clients can also process it.
>
>
> Now, where I disagree is the "actions" model is RPC and non-RESTful. This
> is most likely because I didn't explain them well, so let's see:
>
> Doing a PUT .../actions/lockdoor is indeed non-RESTful (or worse: GET
> .../actions/lockdoor?lock=true ---> horrible, I know!!), because you're
> putting rpc semantics in the URL. That's bad!
>
> BUT, this is *not* how actions work!
>
> When you do an action, you're creating a REST resource (so you MUST use
> POST), and this resource is a "request to do something" (that might happen
> or not).
>
> The way you'd unlock the door would look like this:
>
> POST http://mydoorlock.com/lock29/actions/changestatus
> {
> "status":"lock"
> }
>
> 202 ACCEPTED  (or 201 CREATED, if instantaneous)
> Location: http://mydoorlock.com/lock29/actions/changestatus/66373
>
> Then you can retrieve this resource any later time and see whether it's
> been successfully executed or not. This has the added advantage that you
> naturally have a buffer where different clients can schedule several
> requests simultaneously (and the device decides when & how to schedule
> those), which is particularly helpful, clean, and RESTful.
>
> I'll happily sit down and watch you demonstrate what's not RESTful about
> this ;)
>
> What do you think?
>
>
> Vlad
>
>
>
> On 03 Jun 2015, at 00:50, David Janes <davidjanes@davidjanes.com> wrote:
>
> So just taking these as examples (make sure to add Accept:
> application/json)
>
> http://devices.webofthings.io/pi/sensors/
>
>   "humidity": {
>
>     "description": "A temperature sensor.",
>
>     "frequency": 5000,
>
>     "name": "Humidity Sensor",
>
>     "timestamp": "2015-06-02T16:06:26.398Z",
>
>     "type": "float",
>
>     "unit": "percent",
>
>     "value": 40.2
>
>   },
>
> From IOTDB's POV, there's a bunch of stuff being mixed together here:
>
> The model, comprising the values: description, type, unit
> The metadata, comprising the value: name, frequency
> The ostate, comprising: timestamp, value
>
> In IOTDB world, the value record would look something like this:
>
> {
>  "@context": "...",
>  "value": 40.2,
>  "timestamp": "2015-06-02T16:06:26.398Z",
> }
>
> @context is JSON-LD magic to provide meaning to "value" and "timestamp",
> defined in the Model (@vocab may be needed too, JSON-LD needs some
> tightening).
>
> The Model is then basically static, and the part that defines value e.g.
> looks like this
>
> {
>  "@id": "#value",
>  "iot:unit": "iot:float",
>  "iot:purpose": "iot-attribute:sensor.humidity",
> }
>
> A lot of those iot: can be taken out, but you get used to it.
>
> Metadata is less frequently changing data and is to taste, but you'll note
> that the value will only reference the Model, not the Metadata.
> Furthermore, Metadata will typically draw it's definitions from the core
> vocab, rather than having to be defined on a case by case basis.
>
>
> D.
>
>
>
>
>