Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementing SensorThings API for OpenIoT #30

Closed
hylkevds opened this issue Jul 7, 2014 · 3 comments
Closed

Implementing SensorThings API for OpenIoT #30

hylkevds opened this issue Jul 7, 2014 · 3 comments
Labels

Comments

@hylkevds
Copy link

hylkevds commented Jul 7, 2014

I'm planning to implement the SensorThings API on top of the OpenIoT platform and I've got some questions before I start coding:

Since it's inspired by OData, does the demo server actually use an OData server library, or is it a custom implementation?

Where/how does the SensorThings API differ from OData?

Do you intend to open-source the demo server implementation?

@liangsteve
Copy link
Contributor

Hi Hylke,

It is great to know you will be implementing SensorThings!! Awesome!!

Here are my answers / views, and I hope they can capture the SensorThings
API and the SWG's view. I also include the OGC mail list in the reply.

1: The demo server isn't using Odata server library. It's an
implementation from scratch.

2: What's the difference between SensorThings and Odata? Big question and
good timing. Here is my long answer. And hopefully it's useful for anyone
who is following this list as well as the OGC mail list.

Background:
At the beginning (back in last 2012 and 2013), we were thinking to design
SensorThings on top of Odata. And one of the benefits is implementers may
directly use Odata libraries to implement SensorThings API. At the time, we
referenced to Odata 3.0 (which is not an OASIS standard). However, during
last year Odata was evolving from 3.0 to 4.0 (in OASIS). Odata officially
became an OASIS standard earlier this year (yes, v4.0 is the first official
standard). And today's Odata 4.0 is quite different from Odata 3.0. Odata
3.0 were the version we were referencing at the time. Odata 4.0 becomes
more "powerful" now (what I want to say is more complex now :p). And in my
opinion, if we want to be 100% compliant to Odata, SensorThings will become
too complicated and heavy. And I think most of the SWG members will agree
with me that an IoT standards needs to be simple and easy.

And in Crystal TC (March 2014), the SWG decides to consider looking into
JSON-LD, as JSON-LD is a web standard on the rise. With some further
research, Odata 4.0 and JSON-LD has some conflicts (details here
http://www.w3.org/2011/rdf-wg/track/issues/162) and that makes things more
interesting now. And in both Crystal TC and Geneva TC, the SWG also decides
to look into MQTT as pub/sub is a core IoT use case and members are
requesting pub/sub functions. So we looked into MQTT and OdataŠ.ahŠ.we
opened another can of worms. Odata is using a unique URL convention. E.g.,
http://rootURL/Datastreams(1) rather than http://rootURL/Datastreams/1/.
And the Odata URL convention makes it difficult to integrate with MQTT. So
we have some design decisions to make now. But I still believe some Odata
concepts are very useful and innovative, and we should keep them. To make
the answer short, in my opinion, SensorThings API will follow some aspects
from Odata but will not claim that it is Odata compliant. And in fact,
SensorThings API is pretty different from today's Odata 4.0.

The important similarities include:

  1. The concept of the collection of entities
    http://docs.oasis-open.org/odata/odata/v4.0/os/part1-protocol/odata-v4.0-os-
    part1-protocol.html#_Toc372793657
  2. Relationships from one entity to another can be represented as navigation
    properties.
    (http://docs.oasis-open.org/odata/odata/v4.0/os/part1-protocol/odata-v4.0-os
    -part1-protocol.html#_Toc372793592)
  3. We use the same query options specified by Odata such as server-side
    paging ($select, $expand, $top, $skip, etc.) and queries (eq, nq, gt, gt,
    lt, etc.) More here:
    http://docs.oasis-open.org/odata/odata/v4.0/os/part1-protocol/odata-v4.0-os-
    part1-protocol.html#_Toc372793681

3: Yes. We will open source the implementation. But I cannot confirm
timeline at the moment though (it's part of our research projects, so it
involves funders and stake-holders).

Cheers,

Steve

Dr. Steve H.L. Liang, Ph.D. P.Eng.
Associate Professor
AITF-Microsoft Industry Chair in Open Sensor Web
Department of Geomatics Engineering
Schulich School of Engineering
University of Calgary
2500 University Drive NW
Calgary, Alberta T2N 1N4
Tel: (403)220-4703 Fax: (403)284-1980
http://sensorweb.geomatics.ucalgary.ca
http://www.geocens.ca
Twitter: @SteveLiang

From: Hylke van der Schaaf notifications@github.com
Reply-To: OGC-IoT/ogc-iot-api
<reply+i-37250123-2b9548f5997329eef215316e13fa5928fa0db6e0-4602885@reply.git
hub.com>
Date: Monday, 7 July, 2014 2:56 AM
To: OGC-IoT/ogc-iot-api ogc-iot-api@noreply.github.com
Subject: [ogc-iot-api] Implementing SensorThings API for OpenIoT (#30)

I'm planning to implement the SensorThings API on top of the OpenIoT
platform and I've got some questions before I start coding:

Since it's inspired by OData, does the demo server actually use an OData
server library, or is it a custom implementation?

Where/how does the SensorThings API differ from OData?

Do you intend to open-source the demo server implementation?


Reply to this email directly or view it on GitHub
#30 .

@hylkevds
Copy link
Author

Thank you for that in-depth reply. Quite a bit longer than expected :)

It's good to know that OData is currently only used as an inspiration, that means I won't have to look into any OData libraries. OData does indeed have many interesting ideas in it.

@liangsteve
Copy link
Contributor

No problem. BTW, since you are an OGC member, did you subscribe to the OGC SWE-IoT mailing list? If not, it would be a good idea to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants