Ontology versioning when annotating data items in oem151

[chrwm]

During a discussion of editing an axiom in the ontology, the topic of backwards compatibility of OEO versions came up.

This is important if a sub-goal of the ontological annotation of a dataset is its long-term and unambiguous description. Without the option to specify the ontology version of annotated data items, it will not be clear what meaning and properties a data item had at the moment of annotation when OEO classes are allowed to change and conflict with its prior meaning/definition/axioms. In other words, the ontology version is important to clearly determine which meaning and properties an OEO class and thus the data item annotated with it had at the moment of annotation. Currently, the oem151 has no designated key to hold this information.

Do we intend for the OEO to be backwards compatible from version to version, and if not, do we want to make that explicit?

We have in every release improvements that are not backwards compatible. That's why we do versioning.

In the future, there might be more subtle cases. In a current multi-year project, we aim to annotate a whole input dataset as well as possible ontologically. With currently about five OEO releases a year, we need to know if we need to track the OEO version number for each annotated data item in case concept definition/axioms change and if backwards compatible is not paramount.

Annotating with the OEO (or any other ontology) should always specify the version used. Larger additions almost always lead to restructuring existing parts as this includes rethinking existing concepts,

Originally posted by @l-emele in https://github.com/OpenEnergyPlatform/ontology/issues/1152#issuecomment-1155079831

[chrwm]

For the annotation of a dataset in practice, this could mean either:

1. annotate the dataset only with one OEO version and save this information, for example, in the source key, e.g.

   "sources": [
        {
            "title": "Open Energy Ontology (OEO)",
            "description": "The Open Energy Ontology (OEO) to annotate this dataset is used in the specific version v.0.10.0 (https://github.com/OpenEnergyPlatform/ontology/tree/releases-v1.10.0)."
            "path": "https://github.com/OpenEnergyPlatform/ontology",
            "licenses": [
                {
                    "name": "CC0-1.0",
                    "title": "Creative Commons Zero v1.0 Universal",
                    "path": "https://creativecommons.org/publicdomain/zero/1.0/legalcode",
                    "instruction": "You are free: To Share, To Create, To Adapt",
                    "attribution": ...
                }
            ]
        },

This could mean that the annotation is limited to the state and amount of implemented concepts of the version. Or if the version is updated which each ontology release (in case of continuous annotations over time, as often in multi-year projects) one needed to check if later releases conflict with recent annotations and their intended meaning in the moment of annotation.

2. A clean solution could be another key version in isAbout, valueReference, subject, e.g.

   
   "isAbout": [
                           {
                               "name": "year",
                               "path": "https://openenergy-platform.org/ontology/oeo/UO_0000036"
               "version": "OEO_0.10.0"
                           }

"valueReference": [ { "value": "onshore ", "name": "onshore wind farm", "path": "https://openenergy-platform.org/ontology/oeo/OEO_00000311" "version": "OEO_0.10.0" }

"subject": [ { "name": "energy", "path": "https://openenergy-platform.org/ontology/oeo/OEO_00000150" "version": "OEO_0.10.0" }

[l-emele]

If I understood @MGlauer correctly, the OEP holds all versions of the OEO and it should be possible to reference classes of a specific version.

[MGlauer]

If I understood @MGlauer correctly, the OEP holds all versions of the OEO and it should be possible to reference classes of a specific version.

Yes, this is what the VersionIRI is for. But: For reasoning purposes OEO[v1.10.0]:powerplant is different than OEO[v1.10.1]:powerplant, because they are represented by different IRIs.

[l-emele]

How would the version IRI look like, in the example of https://openenergy-platform.org/ontology/oeo/OEO_00000150 ?

[MGlauer]

Given that the current VersionIRI is http://openenergy-platform.org/ontology/oeo/releases/1.10.0/oeo.omn, I suppose it would be http://openenergy-platform.org/ontology/oeo/releases/1.10.0/oeo.omn/OEO_00000150 which looks weird.

I remember that we raised that issue in the past and came to the conclusion that this is not an issue that is too pressing. Ontologies, contrary to source code, have a tendency to converge at some point. That is, that definitions of established classes do not change. Changing the definition of an established class is just a fringe occurence and the possible implications will have to be addressed on a case-to-case basis anyway. Linking instances to versioned classes only makes it hard, if not impossible to align them with other instances from different versions automatically. Therefore, I would discourage versioned IRIs as a standard procedure. But I would need to cross-check this with our RDF experts.

[l-emele]

Okay, thanks for that clarification.

[chrwm]

Thank you for the comment.

That is, that definitions of established classes do not change. Changing the definition of an established class is just a fringe occurrence

In the current development state of the OEO, there might not be as many established classes yet, as it is not used in practice that often. Thus, changing of definitions seems quite normal and accepted in the current state of development.

and the possible implications will have to be addressed on a case-to-case basis anyway

I think it won't be possible to address a definition change on a case-to-case basis. This is because even within the timeframe of a three-year project, to do so, one would need to document the OEO version number to become even aware of a changing definition (remembering each class definition/OEO version at the moment of annotation seems impossible). Documenting them but not in the metadata would be odd, in my opinion.

Also, for people external to the data, it's impossible to address a definition change on a case-to-case basis (e.g. years after annotation), as they don't know what was meant in the first place at the moment of annotation if the OEO version was not documented.

There is the risk that data annotated today will be misinterpreted in the future if the intended meaning of a concept gets lost when its definition/axioms change with time.

Linking instances to versioned classes only makes it hard, if not impossible, to align them with other instances from different versions automatically

I understand the difficulty, but I can't assess it technically.

[l-emele]

I also think, that in general, that is not that a big problem. In most cases the general concept stays practically the same. We won't redefine a PV cell to a banana. If classes change, in most cases they get just a more Aristotelian definition or a definition that link to other classes that weren't there when the class was initially defined. Also changes are often simply bugfixes.

[Ludee]

Thanks for opening this discussion @chrwm I see both points in adding versioning to the metadata and don't need them.

Since we reached OEO v1.0.0 I belief there won't be a large change in existing classes. When we reach OEO v2.0.0 we can reopen this issue. If we need further discussion, let's add this to an OEO-DEV meeting.

I think it would be good to add this to the metadata comments section.

#	Key	Description	Example
20.9	oeo	The Open Energy Ontology (OEO) provides a formal collection of terms and relationships between those terms, with clear definitions and a logical interpretation.	https://openenergy-platform.org/ontology/

[chrwm]

We won't redefine a PV cell to a banana.

I hope so ;). But it is a good illustration of the issue in the extreme.

Anyhow it seems you don't see this as a problem. Thus, I think we can close this issue and revisit this if necessary.