Closed Antoine-Zimmermann closed 7 months ago
On my side, I cannot identify a problem with the suggested change (e.g., through a counter-motivating scenario).
I can update the scenario on Discovery of Behavior Specifications so that its dataset does not use the class hmas:Input
, without compromising the coherence of the scenario.
Can you clarify this for me please? I find it useful to have this, and one motivation is that if another action execution comes along from some other entity that specifies that it :hasParameter, we can establish equivalence to :hasInput . Then, if :hasInput indeed gets removed, the comment of :ActionExecution should be updated to reflect that this can have inputs.
@smnmyr, I want to clarify that the update suggests the removal of the class :Input
, and not the removal of the property :hasInput
.
Ah, ok. Yes from me.
addressed in PR #180 awaiting validation of the removal from @Antoine-Zimmermann and @andreiciortea
In the interaction ontology, there is a class
hmas:Input
, which is used as the range ofhmas:hasInput
. I'd argue that knowing that something is an input is useless if we do not know for what it is an input. So the relevant information is the binary relation between a thing (like a process of action) and its inputs. Moreover, anything can be an input, it's just a role that something is playing at some point for some process.In the hearbeat meeting of 2023-10-24T17:00:00+02:00, we suggested that this class cound be deleted and the range of
hmas:hasInput
be left unspecified.