Analysis: Ontology Change Management (Draft)

Analysis: Ontology Change Management (Draft)

The purpose of this page is to document the analysis of impact changes.

Change to Term

Let’s take the ‘viral filtration’ class as an example. And let’s assume that the IRI of the term is fix and does not depends on module, i.e., the pattern is

https://spec.industrialontologies.org/ontology/construct/[term]

It is important to note that IOF ontologies get versioned as a whole suite. [Note more thinking needed here what this means to industry releases]

The principles are 1) to minimize impact to the existing ecosystem as much as possible, 2) give time to adapt to changes when possible, 3) make the significant changes programatically evident to existing implementation??……..

Case 1: Annotation changes such as examples, explanatory note, natural language definition and FOL axioms that do not change the semantics of the term.

Make the changes and there is no other action needed.

Case 2: Bug fix. There is no intention to change the semantics but there are unintentional errors in:

2.1 OWL Axioms

Because this only impacts reasoning and not code compatibility, make in the fix and there is no other action needed.

2.1 Spelling in the Preferred Label

Make in the fix and there is no other action needed. The assumption is there is no data access, manipulation code depending on the label. It is only for display.

2.2 Spelling in the term IRI

Use the deprecation strategy that includes 1) deprecate the incorrect IRI, 2) create a new construct with the correct IRI, 3) assert equivalent, 4) remove the deprecated construct at the defined time.

Case 3: There is no intention to change the semantics but the definition or axioms should be remodeled

Make the necessary remodeling, no change to the IRI.

Case 4: There is an intention for semantics change. Causing:

4.1 Changes only to annotations, no axiom changes, but there is, in principle, no need to change the label or IRI. This is especially possible in a primitive construct.

4.1.1 The change is backwardly compatible, i.e., the new semantics is more general.

Make the necessary changes. Keep the IRI.

4.1.2 The change is backwardly incompatible.

Replace the IRI by inserting a version token into the IRI. [And may use this IRI for a defined period and then replace it with an IRI with no version token.]

4.2 Changes to annotations and axiom but there is, in principle, no need to change the label or IRI. I.e., the meaning given to the term is not quite right.

4.2.1 The change is backwardly compatible, i.e., any assertions made w.r.t. to the prior semantics will not become invalid with the new semantics. This is, for example, moving up the class hierarchy.

Make the necessary changes. Keep the IRI.

4.2.2 The change is backwardly incompatible.

Replace the IRI by inserting a version token into the IRI. [And may use this IRI for a defined period and then replace it with an IRI with no version token.]

4.3 No change to annotation nor axiom, but need to change the label and short name. For example, change mind about label or need to use the existing label for something else. OR Change only to annotation, no axiom changes, and need to change the label and short name. OR Change to annotation and axiom, and need to change the label and short name.

4.3.1 Don’t need to recycle the existing label yet.

Use the deprecation strategy. The existing label can be recycle when the deprecation period has ended.

4.3.2 Need to recycle the existing label right away or ASAP.

Option 1: Use short deprecation strategy, i.e., deprecation strategy with short removal period.

Option2: Use deprecation strategy and temporary IRI strategy. The temp IRI has ‘tmp’ as a token in the IRI. It is used temporarily with the existing term but the new semantics. At the end of the deprecation period, retire the temp IRI and use the deprecated one instead.

Option 3: Switch the IRIs right ways, use semantic version to indicate a breaking change.

4.4 There is no longer need for the construct. For example, it is decided that the construct is too application specific

Use the deprecation strategy but in this case there is no need for the equivalence assertion. Remove the construct after the defined period.