DataArray Extension

[hylkevds]

DataArrays are grouped by (Multi)Datastream:

When a SensorThings service returns a dataArray response, the service groups Observation entities by Datastream or MultiDatastream, which means the Observation entities that link to the same Datastream or the same MultiDatastream are aggregated in one dataArray.

So when I do a get on http://example.org/v1.0/Observations?$resultFormat=dataArray the "value" array in the response might contain one or more objects, depending on the number of Datastreams that the resulting Observations belong to.

The questions: 1: The example shows a "dataArray@iot.count" element for each value object that is not further defined. Is this:

• The count of the items in the current response for this Datastream. Since it is also present in the POST request when creating Observations, this seems to be the correct definition.
• The total count of the items for the query for this Datastream. So what you get for $count=true, for the given query but on only this datastream. If the query returns more than one datastream this is different from the total count for the query, since that sums up the observations for all those datastreams.
• Not supposed to be there, and should be removed from the example.

2: OrderBy: Since the Observations are grouped per Datastream, when I request an orderby=id I could end up with the following, which means the ordering is partly un-done:

    {
      "value": [
        {
          "Datastream@iot.navigationLink": "Datastreams(1)",
          "components": ["id"],
          "dataArray@iot.count": ??,
          "dataArray": [
            [1],
            [3]
          ]
        },{
          "Datastream@iot.navigationLink": "Datastreams(2)",
          "components": ["id"],
          "dataArray@iot.count": ??,
          "dataArray": [
            [2]
          ]
        }
      ]
    }

3: The test section "A.6 SensorThings API Data Array Extension" states:

Create at least two Datastreams by using the data array format as defined in Section 13.

Since the Data Array is only specified for Observations, you can not create Datastreams using it. So I suppose this should be "Create at least two Observations ..." or "Create Observations for at least two Datastreams ..."

4: Should the data array response contain a global @iot.nextLink and @iot.count?

5: The navigation link to the Datastream is incorrect in the example:

GET /v1.0/Datastreams(1)/Observations?$resultFormat=dataArray
...
"Datastream@iot.navigationLink": "Datastreams(1)",

Since the page url is /v1.0/Datastreams(1)/Observations, this would link to /v1.0/Datastreams(1)/Datastreams(1), so the navigation link should be to ../Datastreams(1)

[hylkevds]

6: When posting Observations using DataArrays, you can specify the FeatureOfInterest by adding the component FeatureOfInterest/id. However when getting Observations using DataArrays this is not specified. Is this intentional, or should it also be possible to specify that you want to fetch the ids of the FeatureOfInterest of the Observations?

[hylkevds]

Some simple solutions:

1. Remove the dataArray@iot.count elements from the examples.
2. Order being partially undone is by design (and in most cases not an issue).
3. Fix the wording.
4. Add @iot.nextLink and @iot.count to the examples.
5. Fix the relative link in the example
6. This could be something for V2.0: Allow expand of FoI items when using DataArrays

[hylkevds]

It would be good to have a bit more text explaining how the dataArray extension relates to query parameters. Something like:

$select, $top, $skip, $count and $orderby work the same as they would with a non-dataArray request, only the formatting of the result is different, as the Observations are grouped by (Multi)Datastream. The result can contain @iot.count and @iot.nextLink fields just like with normal requests for Observations. The $expand query parameter is not allowed for dataArray requests.

[hylkevds]

Fixed with the publication of Sensing v1.1.