Re: IOTDB worldview vs EVRTHNG

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/ <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.
> 
> 
> 
>