-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Terms from the IAMC template to be implemented by the LOD-GEOSS project #4
Comments
We also just converted some of our model output data in this IAMC format for another project. So for the LOD GEOSS prototyp I can also give the intended output data in this format (but we added some variables). I think all these variables don't need to be implemented in the ontology individually. For exapmle for "Primary energy|coal/gas/oil" I would use the term |
So you have seen the light :) What data did you report?
Gosh, I hope this is true. The potentials OpenEnergyPlatform/ontology#481 didn't raise my hopes in this regards …
Do you know how this ("assembling") works? So far I haven't been able to get any answers regarding the use of the ontology. I wonder how unambiguous |
We will report the final energy consumptions, the capacities, the secondary energy|electricity|..., and the emissions.
I think this is done with the relations between classes of the ontology. I understood that a user of the ontology can add relations for their specific needs in between classes, even if they aren't implemented yet. But someone from @OpenEnergyPlatform/oeo-general-expert-formal-ontology can propably answer this question better than me. |
You would not use an intersection for this -- logically, the intersection of |
So you are describing adding a new class to the ontology. As I understood Vera, her approach was to link data items (e.g. our variable
I read that as
but maybe I got that wrong. And again, a real-world example of some data (any data, really) that is annotated by an ontology (any ontology, really) would be very handy. |
Yes, there are two approaches. Technically these two approaches are called "pre-composition" (adding new classes to the ontology for combinations of existing classes) and "post-composition" (using combinations of ontology classes on-the-fly in annotations). You can read a nice description of the difference in this paper: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2847714/. At the stage where the OEO is currently at in its development (it is not so large an ontology) and tool support available for our users (we do not have a budget to develop custom tools to support all use cases), I would recommend that we add classes to the OEO for all the terms needed for annotations (i.e. using the pre-composed approach) because this reduces the burden on the users for adoption. |
Thank you for the clarification! I thought both options can be easily realised. So in this example we would have the class |
Me too. I always thought we should better not flush the OEO with all these subclasses if users can use relations. But I understand that for users it might be more comfortable with the pre-composed approach at this state...
we have the brand new @0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q the first two mandatory entries are "Final Energy" and "Primary Energy". According to the def it is similar to
|
There's a material difference between the definitions of So maybe we should distinguish between PE excluding non-energy use (PE according to Eurostat) and PE including non-energy use (PE according to UNSTATS). |
We use Eurostat and AG Energiebilanzen to calibrate the TIMES PanEU model. These statistics report energy consumption excluding non-energy uses. So I would vote for distinguishing between those two reporting options. |
How do we proceed with this long meta issue? I suggest adding an additional column in the long table indicating what is there and what is missing. |
Out of the 29 mandatory variables I would judge two to be implemented in usable form.
|
Seems you need a special type of primary energy consumption. We can define a subclass for that. Regarding the combined classes: We probably cannot include every combined concept, but there is also option of post composition. For example Emission|CO2 can be expressed as |
I know of post composition, but not about it. Has its technical realisation been discussed in one of the OEO dev meetings? |
What is the state of this issue? Last comment is more than 1½ years. Is it still planned to align the IAMC template and the OEO? If not, I suggest to close this issue. EDIT: If this the IAMC alignment is still on the agenda, the IAMC terms are a good candicates for the planned OEO composed module. |
A majority of the composed concepts can be implemented here. Thus, I transferred the issue. |
Description
This originated from the OEO Dev Meeting 11 and inteded to provide an overview of the variables from the "IAMC-Template" (which isn't concretely defined) that should be implemented in the ontology for use with Integrated Assessment Models. As a basis I used the submission template to the scenario data base underlying the IPCC Special Report on Global Warming of 1.5°C. This might be extended with variables from the submission template of the Sixth Assessment Report once it is finalised, but I do not expect much development of the variables in the energy domain.
The submission template covers 540 variables which are subdivided in four tiers (mandatory, high priority, medium priority, other). Variables of the first two tiers (mandatory and a sizeable share of high priority) should be included in the ontology for use within the LOD-GEOSS project.
Variable definitions are quite orthogonal, with different subdivisions repeating over many top-level variables within specific groups.
Mandatory Variables (29 Variables)
HIgh Priority Variables (173 Variables)
Medium Priority (235 Variables)
Other (103 Variables)
The text was updated successfully, but these errors were encountered: