search

linked-statistics / COOS

Core ontology for official statistics
Creative Commons Attribution 4.0 International
5 stars 5 forks source link

GSBPM as an activity area in GAMSO #2

Closed FlavioRizzolo closed 5 years ago

FlavioRizzolo commented 5 years ago

The COOS document says that “The relation between the GSBPM as a concept scheme and as an activity area has to be precised”. However, According to GAMSO, the GSBPM doesn’t seem to be an activity area (Level 1). Rather, it seems to be an activity (Level 2) within the Production activity area. Wording in the GAMSO documentation is ambiguous in this regard, but the GAMSO diagrams clearly show GSBPM as Level 2.

image

If that is the case, then the GSBPM concept schema will end up being an individual of Statistical Activity, whereas the statistical production process is an individual of Statistical Production Activity. That doesn’t seem right, given that one class is the super class of the other.

FlavioRizzolo commented 5 years ago

One solution would be to change GAMSO so that Production equates GSBPM rather than strictly containing it, which would make GSBPM into a Level 1 GAMSO object, i.e. Activity Area.

FlavioRizzolo commented 5 years ago

Given that Production includes not only the GSBPM phases but also the overarching processes (see #1), we could add OverarchingProcess as a new subclass of StatisticalProductionActivity with a skos:broader to StatisticalProductionProcess.

FranckCo commented 5 years ago

Notes from March 7 meeting:

  1. We should make the GSBPM a Statistical Activity.
  2. In GAMSO, the production area should be the GSBPM -> to be checked with the GAMSO/GSBPM task team.
  3. Keep the GSBPM as a concept scheme, and consider the GAMSO as a bigger ConceptScheme which combine components such as the GSBPM ConceptScheme. Guillaume to check if Skos allows to capture such relationships, if not, check other vocabularies (VOAF ?)
FranckCo commented 5 years ago

Comments on the March 7 meeting notes:

  1. Actually, the statisticalProductionProcess, not the GSBPM (which is a collection or scheme of concepts) should be made a StatisticalActivity, but it is already the case (via StatisticalProductionActivity)
  2. Same: the statisticalProductionProcess, not the GSBPM.
  3. This is not allowed by SKOS, but we can have a ConceptScheme for the GAMSO and a Collection for the GSBPM.
FranckCo commented 5 years ago

Point 3 above was further discussed at April 16 meeting. The following options were mentioned:

In all cases we need by coherence to keep an « area/4 » instance corresponding to "Production" in the GAMSO, and maybe even an « activtiy/4.1 » instance:

The majority opinion seems to be around the unified view, but Flavio will provide use cases where separate concept schemes for GAMSO and GSBPM would be useful.

FlavioRizzolo commented 5 years ago

The main use case for supporting some sort of separation is the use of GSBPM in a standalone fashion for implementing business process models (BPM). For instance, a BPM for record linkage could reference/use several GSBPM sub-processes and put them in a specific workflow. People implementing BPM's might be familiar with GSBPM but not necessarily with GAMSO, since they are defined at different levels of abstraction and for different contexts. Being able to just manage and import GSBPM as an independent skos:ConceptScheme would facilitate the task and reduce confusion.

The semi-unified view above should be enough for that purpose.

FranckCo commented 5 years ago

Decision at the May 7 meeting: choice of semi-unified view. Done in commit 29a840e.