Matteo Lissandrini (AAU)
About why do we separate between two subclass "input" and "output", here is my reasoning.
On the one hand this is at the ontology level to restrict the domain of the input and output relationships.
Assume you are looking at a specific instance of a 10tonnes of coal in your database, then you ask yourself "is this an input for something or an output of something?" for sure you could find the answer by checking "is this the source of inputOf relationships?",
but operationally you can ask "what is the type of this?" and in my view this would be the correct way to do this because something is either input or output.
It was also because my understanding was that only an output would be a "reference flow", so now I understand this is not true.
What is the utility and the actual definition of a "reference flow"?
The existence of the reference flow to be both input and output makes things a little bit more complex.
Regarding provenance, yes, the concept is extremely loaded of semantics in the field, I'm really sure we do not want to use that.
We will use that ontology instead when we will describe, for instance, that the data produced is coming from the exiobase dataset.
There we really want to use that ontology.
The naming: the names of the classes may be not appropriate, here the instances of flow describe the tangibile things that get consumed/produced by the execution of an activty,
the instances of an activity are exactly that specific happening of the process in that place/time.
In general, we do not want, at all costs, to distinguish flows/activity types by using the "label", labels are hints for humans, but URI, classes and instances, are what provides an identity to things.