liangsteve
commented
10 years ago split this issue into smaller issues (#16~#28). Easier to read, respond, and track.
Closed xiangsu closed 10 years ago
liangsteve
commented
10 years ago split this issue into smaller issues (#16~#28). Easier to read, respond, and track.
About Data Model:
**One of most important things is, SensorThings API is based on REST principles. However, some cases in this document shows it does NOT follow a pure REST way. For example, in Section 4, I understand SensorThings API works in a similar way as OWS - It's a soap -like fashion, not REST. It normally be considered to be too heavy for resource-constrained devices. in Section 4.1, REST "verbs" are based on basic HTTP methods, which are considered universal. It is normally not allowed to add own vocabulary, such as filters.
**What's the relation of this API with communication patterns? Can this API works with Pub/Sub system?
**Figure 1, to my understanding, Sensor (shown in Sensing Profile) should be a subclass of Thing. In "DataStream" component, should we also consider binary data? Value of "observation": Any. Is this correct? Should we introduce a standard way, for example, XML Schema datatypes (http://www.w3.org/TR/xmlschema-2/)? Maybe data types of Result Value should be considered in a similar way. "ResultType:Any" is unclear for me. Metadata of "Actuator", "Thing", "Sensor" are represented in text, SensorMl or JSON, I would suggest to represent in a semantic way, RDF or JSON-LD would be good options for this. Moreover, Thing, Sensor, Actuator, Location, Task, etc presented in the figure, could be considered RESTful resource, accessed with their own URLs in the physical device, and with their state exposed as the representation of the particular instance. For example, when a new Task is created for a Thing, it is automatically assigned URL address.. POST http://Thing/Task. Then with GET we are able to receive the representation of the task, such as the state of the task.
**Sensing Profile: How do we guarantee that this is universally unique, who does issue these values.
**Section 2.1: Could there be "groups" of Things and can we address the groups with virtual group URL, of course following REST principles, but unknown to others if the root URL is not known for them? This way we could create application/system-specific overlays of Things that operate with HTTP atop the basic communication. For example http://garden/water_tank/level could also be presented as absolute URL http://192.168.1.12/~john_smith/rooms/13/water_tank/level?time=now.
\ Section 2.3: How historical data cached and stored? Can we access previous, already streamed data. This is a feature in REST, we should be able to access "old" with URL by defining the scope, for example with time-parameter.
**Figure in Section 3.1 is unclear for me, maybe something missing?
**More points about Section 4.1 1) Defining system/application-specific vocabulary, the version update problem is faced, deploying the changes for use in existing deployments would be difficult. 2) This interpretation of specific vocabulary outside HTTP / CoAP methods could also add some burden to the most resource-constrained devices, something that could be avoided with defining the scope in the URL, without app-specific filters. 3) The key issue here is interoperability, which is not guaranteed if not any HTTP client/server/browser can not understand the scope of URL because it includes some app-specific vocabulary. Perhaps with different versions. However, every HTTP-compliant software knows what to do with basic HTTP methods.
About SensorThings API Reference
_Section 2.2.4: Examples here is a hybrid REST/RPC fashion, not pure REST. _Secton 6: Batch processing seems to be an interesting feature, questions are: what happens if one HTTP request fails? Will every operation lost?
Contributors: Xiang Su, Teemu Leppänen