Ontology: add concept 'analysis scope'

Created on 8 Jan 2021  路  13Comments  路  Source: OpenEnergyPlatform/ontology

Description of the issue

For the scenario description (factsheet) a concept analysis scope is required. It contains basic information about e.g. study region, scenario year etc.

related to #474

Ideas of solution

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 a definition
  • [ ] classes should arise from concepts rather than from words
[A] new term

Most helpful comment

A study is a project and a project is a process so we cannot use is about without extending its range either.

If we extend the range of covers again we might think about extending the range to a short list of more abstract classes than having in the end a long list of very specific classes.

All 13 comments

It seems to me like analysis scope should be an information content entity. Based on that I would suggest the definition
_An analysis scope is an information content entity that describes the boundaries of what a ... covers._

I left a gap there because I'm not sure what we want to use this term for. Are they scenarios, models or even information content entities in general?

We could use has part to relate analysis scope to concepts like scenario year or study region (as soon as we have them in the ontology)

The analysis scope should refer to sceanrio and study.

I think analysis scope is a special kind of spatiotemporal region. What about: _An analysis scope is a spatiotemporal region that covers a study region and an X of a scenario or study._

For that definition we need X: _X is a one-dimensional temporal spatial region that is under investigation and consists entirely of one or scenario years._ I would call X something like scenario horizon, but I am open to better suggestions for a label. For the concept of a scenario year there is already issue #474.

I think you're mixing up x-d-spatial region (continuant) and spatiotemporal region (occurant). And the latter doesn'T seem to be the right parent class:
_"A spatiotemporal region is an occurrent entity at or in which occurrent entities can be located. A spatiotemporal region is part of spacetime (that is: it is a part of the whole of spacetime) and each spatiotemporal region is defined relative to some frame of
reference involving a four-dimensional system of coordinates."_ (Arp et.al, Building Ontologies with BFO, p. 123)

The question for me is, what is included in analysis scope.

  • Only study regionand scenario year / horizon (tbd) or also
  • weather year?
  • sector?
  • other kind of basic scenario information...?

The spati(otemporal)al region approach makes sense to me. Especially since we already have study region as a spatial region which is a part of the analysis scope.

I'm not quite sure where the border between the "real thing" (i.e. the spatial region) and the information content entity describing the real thing lies. Maybe we can consider this from a practical perspective: As @stap-m pointed out, we might want to include other kinds of boundaries, e.g. a sector, for an analysis scope. Then it could get hard to find a place for a multidimensional abstract concept as an "entity in reality". It would be easier to use analysis scope as a collection concept that then refers to study region, study horizon and other concepts which can be part of an analysis scope.

Especially your point about the sectors convinces me. That's definitely some different type of dimension and spatiotemporal region does not work for that. So lets go back to the initial thought on using information content entity has parent class.

_An analysis scope is an information content entity that describes the boundaries of what a study or scenario covers._

analysis scope covers some study region, study horizon, sector ?!

covers can only be applied to study, model or model calculation. If we want to use it for analysis scope, we should change the definition. Alternatively, we could use is about (see #415 )
We could also relate analysis scope to study or scenario via is about.

A study is a project and a project is a process so we cannot use is about without extending its range either.

If we extend the range of covers again we might think about extending the range to a short list of more abstract classes than having in the end a long list of very specific classes.

A study is a project and a project is a process so we cannot use is about without extending its range either.

That's right, thanks for noticing.

If we extend the range of covers again we might think about extending the range to a short list of more abstract classes than having in the end a long list of very specific classes.

Maybe we don't have to extend the domain of neither covers nor is about. We just need study covers analysis scope, scenario is about analysis scope and analysis scope is about study region / horizon / sector.

Sounds good to me!

Ready for implementation?

I think so.

Was this page helpful?
0 / 5 - 0 ratings