Add `conceptual model`
Description of the issue
The ontology does not contain a way to separate the concept, implementation and the representation inside a computer of a model. (related issue #1953) The conceptual model should be the part of a model, that specifies variables and relationships within a system boundary.
This is a term needed for modeling uncertainties, more specifically the location of an uncertainty within a model. See issue https://github.com/OpenEnergyPlatform/ontology/issues/1829
Ideas of solution
The term should be defined similarly to how it is described within this paper to properly work in the needed context.
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
@LillyG901 could you cite the relevant part of the paper for finding a definition, please?
Maybe adding the proposed definition here would be good. This is the current draft from @LillyG901
A conceptual modelis a model that specifies variables and relationships within a system boundary.
The conceptual model specifies the variables and relationships inside the boundaries. The conceptual model gives the interpretation of the computer model (Petersen, 2006). Petersen (2006) has this as a separate category, while Walker et al. (2003) include it under model uncertainty.
- This is the definition given within the paper.
I feel like the second sentence The conceptual model gives the interpretation of the computer model. should be part of the definition if we end up adding computer model too. I like how it links those.
That's a good idea. Maybe we could add two alternate definitions to conceptual model?
One being the one I proposed and another could be
A conceptual model is a model that gives the interpretation of the computer model
Or we could merge them and define conceptual model in one definition as
A conceptual modelis a model that specifies variables and relationships within a system boundary. It gives the interpretation of the computer model.
We should however, wait for the resolution of #1953. Just in case we don't add computer model at all.
We also need to be careful not to add cyclic defintions, since we could also define computer model as A computer model is a model that implements a conceptual model.
I feel like the second sentence The conceptual model gives the interpretation of the computer model. should be part of the definition if we end up adding
computer modeltoo. I like how it links those.
A conceptual model may provide the interpretation for a (computer) model, or just be a conceptual model on its own. Therefore, we should leave out the extension for conceptual model, in my view. However, I agree to the relation the other way round: a computer model is based on a conceptual model. I already commented on that in #1953.
Alright, then the definition will stay as:
A conceptual model is a model that specifies variables and relationships within a system boundary.
If there are no further comments on this proposal I would add a PR to add this term to the oeo once #1945 has been merged.
Maybe we can find a relation between conceptual model and system boundry? is about might be a simple approach, although not very specific.
I'm not sure if is about fits, since it's defined as : A (currently) primitive relation that relates an information artifact to an entity.
Neither of the entities are information artifacts currently. If we wanted to use this relation we might have to redefine at least one of them.
Since the current draft of their definitions makes conceptual model a model and system boundary a model component they are already related loosely through the part of relation.
If we want something that relates the two terms more closely we could maybe use is used by/uses or define a more specific relation such as has boundary.
I moved this discussion to #1989.