Connector / origin

[Kattouw]

Hi all,

Thanks to @justinschembri's work, we're now ingesting a healthy volume of Observations into the server.

What we're missing: given a Datastream or Observation, there's no reliable way to tell which connector produced it. In OGC SensorThings a "connector" isn't a concept at all (it's just a Thing) so at the protocol level nothing marks a Thing as a connector, nor links a Datastream back to the connector that writes to it. (We do have a small type extension on Thing today, but it's optional, not enforced, and doesn't bind the datastreams to it.)

Why I think this is worth solving:

Traceability: answering "where did this data come from?" end to end.
Ownership & transformation: which connector wrote a stream, and therefore which decoding/transformation was applied.
Operations: catching orphaned or duplicate data and attributing issues to the right source.

A few questions for the group:

1. Do you see this as valuable enough to make first-class?
2. Is there any way to express (or even enforce) this within the OGC STA protocol itself, or does it have to remain a Collaborall extension?
3. If it stays an extension: do we enforce it at write time (reject data from an unlinked source), or keep it optional and just surface it in the UI?

Keen to hear how you all look at this.

Current datastreams (in screenshot all from @justinschembri)

[hylkevds]

In the OpenCitySense data model, the Thing of the Device is connected to the Thing of the Connector using the ControllingConnector / ControlledDevices relation.

The Decoder that is used can also be found from the Device-Thing, through the DeviceModel.

Of course this doesn't cover all aspects of ownership and provenance, since that goes further. Ownership and provenance are definitely topics that could be standardised.

[justinschembri]

I've been thinking about this question for a while :)

For now, I only have a strong opinion on the Traceability and Operations part.

Regarding traceability, I believe it is best to keep a Thing centric approach: the origin any Observation will always be a Thing. Do I really need to know more than that? That is why I think the Thing having a UUID is so important - irrespective of if the Things are real or not.

As for caching and duplicates, I agree it is important - in my implementation before creating any STA entity the system checks for "object existence". Perhaps it is more important to define what equivalence and identity in the STA context.