In certain cases however, it could be useful to define standard sub-classes of Task for some widely used and specific types of tasks, for example record linkage or hot-deck imputation
While it is not impossible of course to declare subClassOf Task, in practice it is easier to extend the loose-typing typing, here GSBPM, with new Concepts, that would be declared skos:broader to some more generic GSBPM concepts.
The additionnal information to be captured (e.g. methodology, or relevant GSIM input/output) is then declared on that new Concept.
Declaring a new OWL class only make sense if that new class can hold additionnal information in addition to what can be expressed on the superclass.
For this reason, I even question the utility to introduce the class "Task", while using the class "StatisticalActivity" is enough, at any level of granularity.
The spec reads as follow:
While it is not impossible of course to declare subClassOf Task, in practice it is easier to extend the loose-typing typing, here GSBPM, with new Concepts, that would be declared skos:broader to some more generic GSBPM concepts.
The additionnal information to be captured (e.g. methodology, or relevant GSIM input/output) is then declared on that new Concept.
Declaring a new OWL class only make sense if that new class can hold additionnal information in addition to what can be expressed on the superclass. For this reason, I even question the utility to introduce the class "Task", while using the class "StatisticalActivity" is enough, at any level of granularity.