mike1813
commented
4 months ago Reviewed the pull request, which is now merged and in a new release. I think we can close this issue. @samuelsenior should reopen it if he thinks there are still aspects that can't be considered as separate issues and still need to be addressed.
Currently, through the construction patterns Co+cD, Se+cD and Se+sd, the IoT Actuator and Sensor asset types, respectively, infer ControlData and Data as data that they store and which controls them, as well as the Sensor type inferring that it senses data of the Data type. However, this means that if the user wants to assert a specific subclass data type as controlling the IoT Actuator or Sensor, or being sensed by the IOT Sensor, then they cannot as the Data type will still be inferred from the construction pattern and so added in as an inferred asset and used instead.
It would be good for these to be updated so that user-asserted data can be used rather than the inferred Data type, allowing e.g., a Sensor to sense a specific subclass data type, as determined by the requirements of a user and a given scenario.
To do this, this issue proposes adding prohibited Data nodes to the three construction patterns Co+cD, Se+cD and Se+sd along with controlsThing, controlsThing and senses relationships between each and the root node IoT Actuator/Sensor, respectively, so that the Data asset is not inferred if another data asset of Data type or any subclass is already user-asserted. For this, the matching patterns of these construction patterns are to be separated from each other and updated instead with the prohibited node and relevant relationship. Additionally, this deprecates the IOT Health Sensor as the user-asserted data type sensed by an IOT Sensor achieves its functionality.