Closed FlavioRizzolo closed 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.
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.
Notes from March 7 meeting:
Comments on the March 7 meeting notes:
Point 3 above was further discussed at April 16 meeting. The following options were mentioned:
Unified view: GAMSO is a skos:ConceptScheme containing all instances of coos:Activity, and GSBPM is a skos:Collection of all instances of coos:StatisticalProductionActivity.
Semi-unified view: GAMSO is a skos:ConceptScheme containing all instances of coos:Activity, and GSBPM is a skos:ConceptScheme of all instances of coos:StatisticalProductionActivity. GSBPM is "included" in GAMSO and instances of coos:StatisticalProductionActivity belong (skos:inScheme) to both GAMSO and GSBPM. The relation between GAMSO and GSBPM as SKOS concept schemes could be dcterms:hasPart/dsterms/isPartOf.
Separated view: GAMSO and GSBPM are distinct concept schemes. The relation between GAMSO and GSBPM as SKOS concept schemes could be seeAlso.
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 statisticalProductionProcess individual would be in direct broader/narrower (or broaderMatch/narrowerMatch if in different schemes) relationship with the « area/4 » area.
Or the statisticalProductionProcess individual would be which would be owl:sameAs or skos:exactMatch to the « activtiy/4.1 ».
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.
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.
Decision at the May 7 meeting: choice of semi-unified view. Done in commit 29a840e.
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.
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.