Re: IOTDB worldview vs EVRTHNG

1)

Sure, but really I'd like to take it up one level further and say "where
manipulating dictionaries with identifiers" and see where that leads. It
certainly makes mapping to MQTT, Firebase and a number of other
technologies easier.

2)

By JSON Model, I'm not clear what you mean? That something like

{
  "is_on": true
}

always means "this thing is on"? That is, the WG is defining a prescriptive
standard?

D.


On Wed, Jun 3, 2015 at 3:23 PM, Vlad Trifa <vladounet@gmail.com> wrote:

> David,
>
> 1) No one's obliged to use it! One can do (e.g.) PATCH /light/1 { on: true
> } or PATCH /hue/33 { powered: 1 }. But the possibility exists to introspect
> and get more information _if you want to know that "on" and "powered" mean
> the same thing for these two different devices.
>
>
> Agree - it should be there, it's useful, and it's super valuable, but as
> long as it's not a MUST. I'm not arguing if we need it or not - I'm sure we
> do. But I'd rather have something super simple that people can add
> complexity to as they need, as opposed to load it upfront.
>
> I don't like PATCH here - if I'm updating a resource, I'd like to use PUT
> because that's what it's designed for (and the last thing I want to do is
> to write a massive philosophical paragraph on when to use patch vs put in
> the wot label, this will scare the hell out of anyone just wanting to get
> things done). Saying "oh, for PUT you need to send the whole JSON document,
> if you just want to send a subset of it you use PATCH". It's confusing! I'd
> *MUCH* rather say "to update stuff, use PUT and send the fields you want to
> update (even all of them if you want to)". We remove complexity without any
> casualties!!
>
> We've been using PUT since day 1 at EVRYTHNG to update resources - both
> for partial updates and complete - and I can ensure you that not one in the
> thousands of developers that use our engine ever told us "*sorry guys,
> I'd like to use PATCH if I send a sub-resource, because using only PUT is
> too easy for me and I like challenges*".
>
>
> 2) Isn't semantics a core mission of this WG, and hence JSON-LD is a must?
>
>
> Yes, but a well-defined basic JSON model, with clear field names and
> structure, can go a loooong way. For anything more complex and spefic
> that's not covered, then JSON-LD will kick in. So once again, strongly
> disagree that JSON-LD is a must upfront.
>
> 3) I'll tediously mention again that I'm not bringing forward something
> theoretical. If you run up the HomeStar project, you'll get an API that you
> can just send JSON requests to and control a fair number of real world
> things, or you can start introspecting the models and build interfaces. I
> think we're far past the Hello World stage.
>
> Here's two screenshots of working Web and App interfaces created entirely
> through introspection
> https://twitter.com/dpjanes/status/606106181409447936
>
> I apologize for not have a working server up on the net to play with. I'm
> about 48 hours into knowing W3C actively wants to do this.
>
>
> That is really a great work and it's super valuable, and at no point I
> meant that it's theoretical!
>
> The point I'm trying to make is using JSON-LD (or other "meaning defining
> language") is overkill in many scenarios I can think of today (especially
> those where a human needs to write a piece of code that can interact with a
> few things). A proper semantic layer, profiles, with a meaning is the
> cherry on top to enable truly automated interactions in the wild, and is
> what I believe the Thing Description task force is looking at.
>
> But using the JSON model we propose you can do a lot of that already
> without needing JSON-LD. And that's what we're aiming for.
>
>
>
> D.
>
>
> On Wed, Jun 3, 2015 at 9:26 AM, Vlad Trifa <vladounet@gmail.com> wrote:
>
>> Yes, but that's exactly my point! It's not about the Web Thing who needs
>> to understand JSON-LD: it's about any client that wants to interact with
>> it! They shouldn't be obliged to use it.
>>
>> It's primordial to get sufficient information based on http/json only (by
>> predefining a set of json data model with clear semantics) and not be
>> obliged parse an additional json-ld just for this, because it's overkill in
>> 96.4% of real-world use cases I've come across (it adds a layer of
>> complexity upfront that I simply don't need for most of apps I can think
>> of).
>>
>> If we want to make something that's useful, I'm voting for lowering the
>> access barrier to get a "hello world" up & running. JSON-LD as a MUST would
>> do the opposite.
>>
>> Whatever the IG comes with should be a simple & clean model (just
>> http/json) that anyone can use easily for simple scenarios. What's
>> important iis that tis simple model comes with well-thought extension
>> points to support "advanced" features (such as MQTT/WebSockets mappings,
>> JSON-LD, etc.). If we decide to bake all these features into the basic
>> model as a "must", we're just raising the access barrier and you won't see
>> me bet any money on the success of such a bloated "standard"...
>>
>>
>>
>> On 03 Jun 2015, at 14:06, David Janes <davidjanes@davidjanes.com> wrote:
>>
>> -- 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.
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>