Decouple membership between classification items and levels from the levels and/or items themselves

[FlavioRizzolo]

Classification items are merged or split for multiple reasons, e.g. variants, new versions, analytical purposes, etc. Formal changes between versions and variants occur less often; ad-hoc changes for analytical purposes occur more frequently. Regardless of the frequency of change, changes to the items shouldn’t require the creation of new levels if the definition of the level, and it’s associated concept, haven’t changed. For instance, take the changes occurred to Classification Items in NAICS 2017. The fact that some items were split and other merged at level 5 doesn’t mean the level itself has changed: NAICS level 5 is still about Industries regardless of what happened to its individual item members over time.

Changes occur more frequently in geography classifications, especially non-standard ones. For instance, a common geography classification consists of Geographical regions of Canada, Provinces and territories and Municipalities (Cities, Townships, Villages, etc.) instead of Census division and subdivisions. Amalgamations, name changes, boundaries redefinitions occur with certain frequency. For instance, today’s city of Ottawa consists of the former cities of Ottawa, Nepean, Kanata, Gloucester, Vanier, Cumberland and other smaller townships. Those changes affected membership to the Municipalities level over time but didn’t change the actual level definition, i.e. they were and are municipalities. From a classification management point of view, it’s better to maintain a single Municipalities level with a time-varying item membership.

[FlavioRizzolo]

Related to #78

[LucaGramaglia]

It would seem to me that the "xkos:OrganisedBy" property, which allows linking a classification level to a more generic concept, e.g. to the concept of a "Municipality" or to the concept of sections in NACE, already provides a certain level of decoupling between levels and membership. These more generic concepts can be reused across different versions of a given classification to indicate that while membership of a level may have changed, its meaning has remained the same.

I recognise however that I may have misunderstood the issue raised: would it be possible to specify to what extent the use case mentioned cannot be covered by "xkos:OrganisedBy"?

[FlavioRizzolo]

It would seem to me that the "xkos:OrganisedBy" property, which allows linking a classification level to a more generic concept, e.g. to the concept of a "Municipality" or to the concept of sections in NACE, already provides a certain level of decoupling between levels and membership. These more generic concepts can be reused across different versions of a given classification to indicate that while membership of a level may have changed, its meaning has remained the same.

I recognise however that I may have misunderstood the issue raised: would it be possible to specify to what extent the use case mentioned cannot be covered by "xkos:OrganisedBy"?

If I understand correctly, that approach would create a new level every time there is a membership change. Using xkos:OrganisedBy would capture the fact that all those new levels are related to the same concept, e.g. "municipality", but wouldn't address the underlying issue of not reusing the actual level: we will have to duplicate the skos:member properties for the hundreds of unchanged municipalities every time a handful of municipalities are merged or split.

A more efficient solution would be to sort of "reify" the membership property so that small, local changes, wouldn't trigger a large number of changes to unrelated entities. We should probably look at change management/time variance across the board for XKOS v2 given that similar re-usability issues occur elsewhere, e.g. when trying to plugin the same classification item in different hierarchies for different classifications.

[laurentlefort]

List handling requirements in the context of the maintenance of statistical classifications and their changes over time are worth sharing with the broader community, especially those working on this issue in SPARQL.

Some of the issues discussed here for geo-spatial areas can also have geo-specific solutions e.g. the ones Camille Bernard has worked on (see reference below).
I think in this context, it would be useful to also consider the requirememts associated to classifications used for trade (AHECC in Australia, itself derived from the Harmonized Commodity Description and Coding Systems (HS)

Lists

Albert Meroño's recently presented work on Modelling and Querying Lists in RDF:
paper & slides

The broader SPARQL issue on this topic w3c/sparql-dev#46

Change

Work by Camille Bernard and colleagues at IMAG https://camillebernard.github.io/tsndoc/