I question question the utility to introduce the class "Task", because using the class "StatisticalActivity" is enough,to describe activities at at any level of granularity. The actual level of the activity is given by its type.
What will happen if you have StatisticalActivity + Task is that 1/ implementers will always question which one to use and 2/ data consumers will always have to deal with receiving one or the other type (because most data consumers are not ontology aware and cannot deduce that a Task is a StatisticalActivity).
We follow this pattern in ELI-DL.
Remaining subclasses of StatisticalActivity (ProductionActivity, StatisticalProgramme + Cycle, Phase, Subprocess) could be formally defined by an equivalence based on the dcterms:type (to be checked for StatisticalProgramme + Cycle), but don't need to be used to explicitely type instances.
See #119
I question question the utility to introduce the class "Task", because using the class "StatisticalActivity" is enough,to describe activities at at any level of granularity. The actual level of the activity is given by its type. What will happen if you have StatisticalActivity + Task is that 1/ implementers will always question which one to use and 2/ data consumers will always have to deal with receiving one or the other type (because most data consumers are not ontology aware and cannot deduce that a Task is a StatisticalActivity). We follow this pattern in ELI-DL.
Remaining subclasses of StatisticalActivity (ProductionActivity, StatisticalProgramme + Cycle, Phase, Subprocess) could be formally defined by an equivalence based on the dcterms:type (to be checked for StatisticalProgramme + Cycle), but don't need to be used to explicitely type instances.