hylkevds
commented
1 year ago Response from the SWG Telco:
GENERAL
I’m not fully convinced this approach is well aligned with the overall OGC architecture and API guidelines. The proposal will develop the SensorThings API as a silo, adding features that could be provided by combining SensorThings with other OGC APIs and data models.
Alignment with the API guidelines is not applicable, since STA pre-dates these guidelines.
In general, I would like to see standardization efforts looking at leaner solutions and removing complexities such as transactional logic instead of adding more.
Removing transactional logic makes no sense, since the goal of the spec is to support CRUD.
As an example, there has been earlier discussion on asynchronous STA to make it easier in cases when registering a sensor is not feasible, as an example when a lot of sensors are as part of an automation system and integrated through a gateway and mapped to STA schema.
The procedure for registering Sensors in STA is out of scope for STAPlus.
CHAPTER 2.2
When mentioning MQTT Subscribe as a requirement, it would be important to tackle with the challenging part: Do changes on any related entity trigger MQTT update on subscription on any other entities?
Even though this is off-topic for STAPlus, if updates on related entities are desired, subscriptions on those related entities can be made.
CHAPTER 6.0
While backwards compatibility is granted, this change will essentially create a fork and there is no/can’t be no future commitment on aligning STAplus with next versions of STA. Sometimes this has to be accepted but should be clear that this is not a desired path.
This comment is on the implications of modular specifications (modspec) and can not be resolved by STAPlus. They are thus off-topic for STAPlus.
CHAPTER 6.4
The statement that STA ”does not support to express relations” is misleading or incorrect. In ObservedProperty the definition of property is URI which means it can link to external ontologies such as the SKOS -compliant FINTO UCUM: https://finto.fi/ucum/en/page/r295 . From the OGC architecture point more relevant mechanism for relations is however the FeatureOfInterest -entity that allows to link SensorThings data stream with geospatial context as standard features.
While it is true that the STA ObservedProperty Entity Type supports links to external resources, the Observation Entity Type does not. The STAPlus Relation Entity Type adds external linking support to Observations. Possible links from the FeatureOfInterest Entity Type are a separate topic, not covered by STAPlus. The wording will be improved to resolve this issue.
When thinking about GDPR or other privacy or ownership frameworks, a common mistake is to assume that the owner of sensor is also owner of the data.
The Sensor class is the generic description of the Observer. The Hardware of the "sensor" is represented by the Thing entity. From UML Diagram 1 we can see that Party is associated with Datastream and Thing. From this it follows that Datastream and Thing can belong to different Parties. Thus STAPlus does not assume that the owner of the (hardware) sensor is also the owner of the data. The Best Practice on STAPlus covers such a use case. A reference in the introduction will be added to clarify this.
If there is a smart home sensor provided by the housing company, the data subject is however the person(s) living in the apartment where the sensor is located and the consent to use the data would be needed for her - assuming there is no other type of legitimate interest such as maintenance of the building. Defining this kind of context as additional entities in SensorThings is unnecessary and overlaps with other structures, since the apartment is a geospatial feature and could be easily delivered with OGC API Features and then linked with STA FeatureOfInterest. It could also be an object in CityGML and/or IndoorGML where such relations can be further defined. There is an earlier pilot where the ISO 55000 asset management standards was implemented as part of the IndoorGML and the same could be done with the GityGML ADE structures, allowing freely define events, processes, stakeholders and roles on any entity. The ownership, consent and data usage rights are complex and depend on the context which makes it essential to not overcomplicate them with overlapping data governance structures.
This does not address a topic in the current STAPlus draft standard. However, this is a great topic for future work.
The ownership, consent and data usage rights are complex and depend on the context which makes it essential to not overcomplicate them with overlapping data governance structures.
Enforcing content and data usage rights are not of concern to STAPlus. However, the implementation of a proper business model (e.g. concept of ownership) is complex and varies on a deployment basis, as described in the Best Practices document. The STAPlus standard foresees the conformance class "business logic" to describe the detailed realisation for a given deployment.
CONCLUSION
Based on the previous use cases I have had, including various citizen science cases, I fail to see the need for this approach. This might however provide a nice case for an OGC implementation guideline type of document, as an example focusing on how to implement data governance, security and privacy in citizen science cases by building on OGC APIs and data models. This work could also introduce useful external projects such as Open Policy Agent. The example of smart home sensor suggests that from the OGC side, it is all there already.
There may exist use cases that do not need this standard. That does not invalidate the fact that there also exist use cases that benefit from this standard.
securedimensions
This comment was received on the STAplus RFC: