[Requests] Fwd: Response to RFC on SensorThings API standard for Internet of Things
gbuehler at opengeospatial.org
Mon Jul 13 10:02:49 EDT 2015
From: "Simon Cox" <Simon.Cox at csiro.au>
To: "info" <info at opengeospatial.org>
Cc: "Steve Liang" <steve.liang at ucalgary.ca>, "Peter Taylor" <Peter.Taylor at csiro.au>
Sent: Monday, July 13, 2015 1:43:32 AM
Subject: Response to RFC on SensorThings API standard for Internet of Things
Some comments on SensorThings API, focussing primarily on Clause 8 (Entities).
1. The Requirements Classes are not formulated or described in detail. Each requirements class should be defined explicitly, with a tabulation of its constituent requirements, and in particular its dependencies (i.e. references to core requirements classes in the current standard, and to external requirements classes inherited from the normative references). Please consult any recent OGC standard to see a format for these.
2. Some JSON encoding details follow OData 4.0-JSON-Format specification, in particular the convention for labelling annotations (using the @iot.XXX syntax). OData is included in the Normative References, and is credited parenthetically in a number of places, but we suggest that the OData dependency should be made a bit more obvious in the text, and OData noted as a formal dependency in the requirements class(es).
3. It’s not clear what the exact relationship is to the OData parts (protocol, JSON, common schema, URL conventions). Perhaps a dependency diagram would help. There are sections that are adapted from OData. It might be worth describing why they weren’t used directly. Is this an OData compliant API?
4. The ‘ common control information ’ is not indicated in the class model Figure 1. This is OK, but consider adding it as a mixin or stereotype? Why is it called ‘control’ information – it looks like identification and linking information.
5. Some introduction to the concept of control information ( http://docs.oasis-open.org/odata/odata-json-format/v4.0/errata02/os/odata-json-format-v4.0-errata02-os-complete.html#_Toc403940614 ) would be useful. Perhaps with some text to describe why the standard odata control types were not used? E.g. odata.id, odata.nextLink, odata.navigationLink and odata.associationLink. Do these need to be redefined in the IoT namespace? Would this affect the way OData clients/libraries can interpret these encodings?
6. It appears that the @iot.navigationLink mechanism is used somehow for cross-referencing. However, it is unclear to these reviewers how this works. Please include a full example with references linking between separate objects.
7. It would be common for any or all of feature-of-interest, sensor and observed-property to refer to externally maintained descriptions. Please explain how to reference external objects , using their URIs.
8. Bug in Example 3 – the second value should have @iot.id=2
9. All Entity types are included in a single requirements class req/entities . This does not encourage re-use in other contexts. We suggest that (at least) the Observation type be re-factored into a separate requirements class. It can then be included as a dependency in req/entities.
10. The Datastream object supports collections of observations with a common observed-property and sensor. It would also be useful to have the option of a common feature of interest.
11. OGC Abstract Specification Topic 20 (Observations and Measurements) is cited as a Normative Reference. However, it is not mentioned as a formal dependency in any of the requirements classes. Furthermore, you do not indicate which requirements classes (clauses) from O&M are satisfied in Sensor Things.
12. How is a ‘ single’ observation reported? It appears that a Datastream object is always required, in order to attach the observed property and sensor. Perhaps consider adding (optional) observed-property and sensor properties to the Observation object, so that it can be used standalone.
13. In Figure 1 all associations have undefined direction . Is this deliberate? Can these relationships be used from either end?
14. Figure 1 could be enhanced by showing the classes from O&M , or maybe include a separate figure showing just the classes without attributes, and the relationships to the classes from SensorThings (subclass/specialization, or realization?)
15. In particular, clarify relationship between sensor/Sensor and procedure/OM_Process from O&M (and maybe explain why different terms are used).
16. How is resultQuality encoded ? It mentions DQ_Element, but the JSON encoding of this is not described. The conformance tests don’t refer to any schema, so it is hard to determine if an instance is valid - or what properties are available.
17. There are other initiatives standardizing internet-of-things (e.g. Open-IOT ). It would helpful to indicate how this standard complements those.
Simon Cox & Peter Taylor
Simon J D Cox
Environmental Information Infrastructures
Land and Water
E simon.cox at csiro.au T +61 3 9252 6342 M +61 403 302 672
37 Graham Road, Highett, Vic 3190
PO Box 56, Highett, Vic 3190
Bayview Avenue, Clayton, Vic 3168
Private Bag 10, Clayton South, Vic 3169
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Requests