(RDF) typing of GAMSO and GSBPM entries

[tfrancart]

I now understand that ActivityCategory is used to type both entries from the GAMSO and from the GSBPM schemes. This is fine I guess (although not common), but in that case I suggest that ActivityArea, which is used to type only the first level of GAMSO entries, is made a subclass of ActivityCategory. This would better reflect the fact that all entries from the GAMSO are ActivityCategories, but some only are also ActivityArea. This would also make is consistent because these Concepts are part of the hierarhy, and as such could be used as values for a dcterms:type predicate from a prov:Activity.

[tfrancart]

When we want to describe an activity that is not a production activity, it will be an instance of coos:Activity, and it is expected that its dcterms:type is taken from the GAMSO (and not the GSBPM). The model currently does not allow this distinction because both GSBPM and GAMSO entries share the same OWL class : ActivityCategory.

It is then suggested to introduce a new OWL class ProductionActivityCategory (or rather ProductionActivityType) as a subClassOf ActivityCategory. Concept in the GAMSO scheme would have the type ActivityCategory, and concepts from the GSBPM would have the type ProductionActivityCategory. This would reflect the fact that GSBPM is an extension of the GAMSO.

[tfrancart]

Regarding the question on ActivityArea, the spec reads "The GAMSO activity areas are not really activities by themselves, but rather “boxes” used to classify the activities". From a SKOS perspective, this should entail that these entries are skos:Collection and not skos:Concept. This way it is clear that they cannot be used as a value to type real activities.

[tfrancart]

Note : the option described above would entail that ActivityArea is a subClassOf skos:Collection instead of skos:Concept.

[tfrancart]

The proposition above is consistent with SKOS, however, if ActivityAreas are turned into skos:Collection, we cannot express the skos:exactMatch relation between gamso activityArea/4 and gsbpm statisticalProductionProcess. Either :

1. this relation is dropped
2. it is replaced by an rdfs:seeAlso to gsbpm statisticalProductionProcess (there is already a seeAlso to the gsbpm scheme)
3. this collection adds skos:member relationship to all Concepts from the GSBPM. This is somehow the solution described further in the document:

... and the GSBPM would not be a concept scheme anymore but rather a skos:Collection

With solution 3 above, the GAMSO activity area 4 would act as such a skos:Collection of all GSBPM entries

[tfrancart]

It is then suggested to introduce a new OWL class ProductionActivityCategory

If this is implemented, this would allow to introduce a formal axiom on ProductionActivity, to indicate that it corresponds to any StatisticalActivity with a dcterms:type that takes its value in a ProductionActivityCategory.