Modularise the ontology into separate components

[jannahastings]

Description of the issue

The ontology is currently developed as a single ontology file 'oeo.omn' (rendered in OWL Manchester Syntax) which imports the Basic Formal Ontology (BFO) as upper level organising classification. The ontology has thus got a very simple imports structure and all content is edited and annotated in a single file.

In order to facilitate concurrent editing of the ontology, and to clarify the structural organisation of the content, the ontology needs to be separated into modules corresponding to distinguishable components of the overall domain.

Proposed solution

The following broad groupings of domain content are proposed as modules:

1. Modelling entities: entities for models, assumptions, parameters, data, software and all the processes that transform these, including model execution and data transformation. Some core entities from this sub-domain in the ontology together with their current definition are:

• Model: A model is a tool for computing the behavior of a system using an idealized representation.
• Dataset: A dataset is a collection of information artifacts of the same type about a common topic.
• Assumption: An assumption is a statement about a property of a system or process that is considered to be true.
• Constraint: A constraint is a condition that has to be fullfilled within a calculation.
• Model calculation: A model calculation is a transformation using at least one model.

2. Physical entities and their attributes: all those aspects of the world that are relevant for the energy systems domain, including physical entities such as generators, power lines, technologies, hardware, portions of matter; attributes of those, such as the energy they carry or release, whether they can be a pollutant, or their origins; representational transformations into maps and measures, such as coordinates, units, quantities; and the processes that modify the physical entities, such as energy production. Relevant entities from ontology:

• Energy: The property of matter and radiation which is manifest as a capacity to perform work (such as causing motion or the interaction of molecules)
• Consumption quantity: A consumption quantity is a quantity that describes the amount of consumption of some resource.
• Generator: A generator is a grid component that converts motive power (mechanical energy) into electrical power for use in an external circuit.
• Fuel: A fuel is any material that can be made to react with other substances so that it releases energy as heat energy or to be used for work.
• Energy production: Not currently defined.

3. Social, organisational and economic entities: entities that relate to people and the social, organisational and economic environment in which energy is produced and consumed, including sector, organisation, and various roles. Relevant existing ontology entities:

• Sector: A sector is a subdivision in an economic system.
• Person: A person is a human being.
• Organization: An organization is a structure with multiple people that has a collective goal.

The proposal is that three separate module files will be created and the current ontology content will be distributed such that each class (and its accompanying individuals) will belong to one and exactly one module. Each ontology module is developed beneath the appropriate classes in BFO, and the main ontology 'oeo' then imports those ontology modules, and furthermore includes those axioms that cut across the modules. However, 'oeo' will no longer contain any content in the form of classes and definitions.

The main advantages of having a modular structure for the ontology are:

• Increased clarity of ontology scope into clear sub-domains
• Expanded capability of concurrent editing without merging
• Clearer domain-focused organisation of ontology content

The main disadvantage of having a modular structure for the ontology is that it increases the complexity of editing the ontology (it is necessary to be mindful of which file must be edited).

Workflow checklist

• I discussed the issue with someone else than me before working on a solution
• I already read the latest version of the workflow for this repository
• The goal of this ontology is clear to me

I am aware that

• every entry in the ontology should have an annotation
• classes should arise from concepts rather than from words
• class or property names should follow the UpperCamelCase

[tillmo]

Good idea! Maybe oeo-model then will be interesting in its own right. Or perhaps there even are already ontologies about modelling with which we could align.

[jannahastings]

@akleinau @Bachibouzouk @MGlauer @stap-m @l-emele @han-f @solar-c @Izzet91 @Ludee Please review for Friday's teleconference.

[jannahastings]

Good idea! Maybe oeo-model then will be interesting in its own right. Or perhaps there even are already ontologies about modelling with which we could align.

@tillmo Absolutely! I think it will be a good idea to do a broad check for pre-existing and related ontology content.

[jannahastings]

Isn't the telco tomorrow?

@Bachibouzouk I have it down as Friday, 13 Dec 2019, 11:00:00am (Mitteleuropäische Zeit)

[tillmo]

Aha, and to complete the picture, also oeo-geo should be added to the overview diagram. It already is a module of oeo, see oeo_geo.omn. Moreover, there has been discussion about an ontology of measurement units that should be included. I suggest to draw a module graph covering all of these, even if measurement units will be added only later.

[Bachibouzouk]

Hello @tillmo, I see you are not assigned to any of the experts team, could you tell me for which team I should add you? (ontology, modelling, economy)

[akleinau]

Good idea! Maybe oeo-model then will be interesting in its own right. Or perhaps there even are already ontologies about modelling with which we could align.

There was also an external information artifact ontology proposed to be included in #10 and another geographical ontology in #76.

We have to assign types to all individuals without them before implementing this modularisation.

I agree with the categories and their associated entities and think this change will really help the ontology development.

[stap-m]

Thank you @jannahastings for the proposal, It seems very plausible.

We also have the very special MaStR-terms. At the last project meeting, we decided on composing those terms inside the oeo.omn instead of making it an own module. We should discuss this again, I think.

[akleinau]

We have to think about object properties too. Some can be put to one of the categories like has_author, but others, like has_part are needed everywhere and there are some that describe relationships between objects of different categories. And most dont have definitions.

[jannahastings]

We have to think about object properties too. Some can be put to one of the categories like has_author, but others, like has_part are needed everywhere and there are some that describe relationships between objects of different categories. And most dont have definitions.

I think we should be re-using object properties that are defined in the Relations Ontology wherever possible, which definitely includes has_part. (http://www.obofoundry.org/ontology/ro.html)

[tillmo]

Hello @tillmo, I see you are not assigned to any of the experts team, could you tell me for which team I should add you? (ontology, modelling, economy)

ontology

[akleinau]

what are we going to do with the pull requests?

I think most of us agree to import a geo ontology externally so we should delete feature/geo. But what about modelfactsheets?

[akleinau]

Actually I think we should merge modelfactsheets because it just adds some object properties and a new file (apart from the usual protege reordering)

[akleinau]

ok I really want to merge it because it would fix so much of #1 5, the things I missed when looking at model factsheets

Edit: changed #192 to #15

[jannahastings]

So let's do it :-)

[akleinau]

now we should have everything ready for implementing this issue