search

Spyderisk / domain-network

Network domain model
Apache License 2.0
1 stars 0 forks source link

Update inferring Actuator control data being related to the human the Actuator is related to only if that has not already been asserted or inferred, and changes to related construction priorities #147

Open samuelsenior opened 4 days ago

samuelsenior commented 4 days ago

Within the Patient Harms modelling it became apparent that the construction pattern inferring the data controlling a control related to a human is also related to the human (HurThcD+Rel) should only fire if the relatesTo relationship between the data and human is not already present, and that this may potentially be useful in other domain modelling. Additionally, in the Patient Harms modelling, other construction patterns are needed earlier in the sequence than this one and, due to these mentioned changes potentially causing merge conflicts between the 6a branch and the Patient Harms branch, these changes should also be made to the 6a for consistency. To this end, the following changes are proposed:

samuelsenior commented 4 days ago

@mike1813 As a quick discussion point: Should the HurSesD+Rel construction pattern (and related matching pattern) also be updated to only infer the Data-relatedTo-Human link if it is not already asserted/inferred?

mike1813 commented 4 days ago

In principle, yes.

samuelsenior commented 4 days ago

Sure ok. Then in this issue I also propose adding in a prohibited link to the matching pattern HurSesD so that it only fires if Data is not already relatedTo Human (the matching pattern becoming HurSesD-Rel) and updating the matching pattern in HurSesD+Rel to this (becoming HurSesD-Rel+Rel)

mike1813 commented 4 days ago

That makes sense. The Data is usually inferred so it usually won't have a pre-existing relationship, but if a user chooses to connect the device to an asserted data type, they could also add their own relationship. If this is 'relatesTo' then there is no problem as the inferred relationship is just a duplicate triple which should be ignored. But if they assert a subtype like 'definesTreatmentFor', then we would prefer not to have a redundant 'relatesTo', of course.