Implementing SensorThings for OpenIoT

Contributed by: 
Steve Liang

Editor’s note:

Earlier this month, Steve Liang, chair of the OGC SensorThings Standards Working Group (SWG) received an email from someone planning to implement the candidate SensorThings API on top of the OpenIoT platform. She wanted to get answers to these questions about SensorThings before 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?

 

Steve replied:

Hi Hylke,

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

Here are my answers / views, and I hope they capture the SWG’s view about the current status of the SensorThings API.  

#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.  Hopefully it's useful for anyone who is following this list as well as the OGC mail list.

Background:

At the beginning (back in 2012 and 2013), we, the members of the OGC SensorThings Standards Working Group (SWG), were thinking to design SensorThings on top of Odata.  One of the benefits would have been that implementers could directly use Odata libraries to implement SensorThings API.  At the time, we referenced to Odata 3.0 (which is not an  OASIS standard). However, 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 was the version we were referencing at the time. Odata 4.0 has become more "powerful" now, or, what I want to say is “more complex now” :p). 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 IoT standards need to be simple and easy.

At the OGC Technical Committee (TC) meeting in Crystal City last March 2014, the SWG decided to consider looking into JSON-LD, as JSON-LD is a web standard on the rise.  Further research showed that Odata 4.0 and JSON-LD have some conflicts (details here http://www.w3.org/2011/rdf-wg/track/issues/162).  In meetings at both Crystal City and at the Geneva TC in June, the SWG decided to look into  the OASIS Message Queuing Telemetry Transport MQTT  pub/sub messaging transport protocol as a core IoT use case, as our SWG members are requesting pub/sub functions.  

So we looked into MQTT and Odata, and ….ah…. we opened up 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:

• 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

• 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

• 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

Yes, we will open source the implementation. But I cannot confirm a timeline at the moment. It's part of our research projects, so it involves funders and stakeholders.

Cheers,

Steve

 

Dr. Steve Liang is an assistant professor in Geographical Information Systems at the Department of Geomatics Engineering, Schulich School of Engineering, University of Calgary.