• Load
• Load area
• Power
• Demand
• Demand sector

Grid components

• Shunt Impedance
• Generator
• Transformer
• Storage Unit
• Network/Grid
• Subnetwork/-grid

GeographicRegion (subclass of spatial region) is not sorted in the subclasses one- to three- dimensional spatial region.

This issue arise from @han-f comment

This is why I am a "fan" to always explain the "why" right where I ask for something. I think this also helps to avoid confusion and saves time (no need to click somewhere else and get familiar with another issue and then click back).

I would suggest that one should at least copy-paste the issue description within the PR description.

Originally posted by @Bachibouzouk in #70 (comment)

see c8d468a as a negative example
possible solution: use a hook like git apply --whitespace=fix or https://github.com/dlenski/wtf

Currently there is a Generator class (subclass of bfo:generically dependent continuant) and an ElectricityGeneratorTechnology Class (subclass of Technology subclass of bfo:object). They have to be unified to get a more clear ontology.

Review definitions of the class Geographic Region
and its subclasses:

• City
• Continent
• Country
• FederalState
• LoadArea

Are classes missing?

Requirements:

• Must be an (approved) open license (SPDX and/or opendefinition)
• Because the ontology is like code, a suitable open license for code should be selected
• Should have no or minimal license obligations to be usable for everybody
• While further developments and extensions are welcome, forks should be published under a new name to ensure a unique version name

Options are:

• CC0 - Public Domain Dedication, no restrictions, no attribution, "as open as possible"
• CC-BY 4.0 not well suited for code!
• BSD or GNU licenses
• MIT license or ISC license

Example ontology licenses:

• http://geneontology.org/page/use-and-license
• OBOFoundry/OBOFoundry.github.io#34

we need a proper IRI for the ontology

Currently, only many subclasses of ElectricityGridComponent are part_of ElectricityGrid. However, it would be easier to have ElectricityGridComponent as part_of ElectricityGrid instead (which of course then would be inherited to the subclasses).
Also note that we have already: ElectricityGrid has_part some ElectricityGridComponent.

@fabianneuhaus questioned what the meaning and difference between:

• data
• empiricaldata
• dataset
  is

Subclasses in geographic regions could, to my understanding, be built in at least two ways.

1. continent -> subclasses (or entities): Africa, Europe, North America, South America, Australia, ....
2. continent -> subclasses: country, county, municipality (...), where the latter could again be subclasses of country and so on.

The current suggestion follows 1) having country, county, municipality being classes on the same hierarchy level. What are your thoughts?

See branch feature/geo

@stap-m
i am not sure about the terminology i should use for the parameters from MaStR. For now i just translated them like AuflagenAbschaltungSchattenwurf = RequirementsSwitchOffShadowing.

The EmpiricalDataset MaStR (Marktstammdatenregister) currently has the subclass StorageUnitDataset. This should not be a subclass but part_of MaStr.

Also StorageUnitDataset would then have to be reclassified and its subclasses sorted out, as for example EmergencyGenerator should not be a subclass of StorageUnitDataset (and therefore MaStr). It is an object, a DataSet is an InformationArtifact.

Additionally the subclasses have wrong URIs (semanticweb) which could potentially lead to classes with the same name.

Is there a reason that GreenhouseGas is not a subclass of Gas? But its subclass FlourinatedGas is?

This tags from the OEP I cannot find in the ontology
health
society
Decarbonisation Pathway
economy
environment
Commercial
Conventional
template
Further, the green tags are licenses or something (see issue#31)

e.g., uses_dataset

Related to 17a88a6 of #46

A solution could be to start a new branch from dev (git checkout dev, git pull, git checkout-b fix/restructure-scenario) and push it immediately. Then create a pull request in which one can copy the following as the PR's description :

As the whole Class ElectricityProductionUnit, rather than just it's subclass WindEntity (renamed to the more specific "WindEntityData") contains specifications of those units and is not an object. So I move it to bfo:quality (subclass of specifically dependent continuant) as it depends on the Unit it describes and add the suffix "Property"

• Add object properties "has_disposition", "has_role", "has_function" and "has_quality"
• Move Pollutant and it's subclasses GreenhouseGas and Airpollutant to bfo:disposition
• Make flourinatedGas subclass of "has_disposition some greenhousegas" instead of greenhousegas
• As "Agent" is rather a role in the energy model/ simulation I move it to role. Which gives me the opportunity to classify ist subclasses new as object aggregate (Organisation) and object (Person)
• Add subclass "has_part some Person" to Organisation because it fits the given definition
• Implement changes of issue #45 (generalize the solutions for liquid and solid too): rename "StateOfMatter" to "PortionOfMatter"
• Add prefix "PortionOf" to it's subclasses, as well as add the bfo:quality "phase_description" with its subclasses "Liquid", "Solid", and "Gas"

one can publish an ontology under a w3id URI using OnToology http://ontoology.linkeddata.es/

Here some slides with some screenshot about OnToology's features: https://www.slideshare.net/MariaPovedaVillalon/new-trends-in-ontological-engineering-practices-and-tools

Right now the subclasses of ElectricityGridComponent (classified as bfo:generically dependent continuant) are partly better classified as objects (like Generator and StorageUnit) or InformationArtifact (like CommonParameters and HydroEntityDataset). They have to be restructured.

The ontology should include specific units (e.g. inch for LengthUnit). I guess these would be implemented best as individuals of UnitOfMeasurement.

@fabianneuhaus : It seems quite redundant to include units like cm if the ontology already includes m. Is this appropriate or should we include some kind of 'scaling'?

The class GreenhouseGas (subclass of Pollutant subclass of bfo:disposition) has instances like Carbon_dioxide and Methane that dont have any other superclasses.
Because those are material entities I propose to just make them all subclasses of Gas?

I was made aware of the existing daQ ontology.
It aims at describing quality criteria for datasets and sounds interesting.
There are Sldies and a publication.

This is also highly interesting for the "review process" we are working on OpenEnergyPlatform/data-preprocessing#2

Coal is a solid, and solid is "state of matter". This means that coal is a "state of matter". But this is not true. Coal has a "state of matter" (namely, solid).

We need to represent licenses in our ontology. I just found this ontology at creativecommons.org that might be interesting.

ModelFunction is not a ModelComponent despite its definition

The current subclass hierarchy does not correctly distinguish between the different types of continuants:

• independent continuant
• specifically dependent continuant
• generically dependent continuant

Currently everything is a generically dependent continuant. We should restructure the class hierarchy.

[this is not the original post, the original post was outdated]
proposed classes:

right now there is almost no object property hierarchy and many properties are not in the right subclass (like many of the has_... properties)

• 1. Splitting Hydropower in Hydro and Ocean as two different Types of EnergyCarrier

• 2. WaterTurbine replaced with OceanPowerPlant and HydroPowerPlant
  note: not replaced but all exist now

• 3. Subclasses of OceanPowerplant are WavePowerPlant and TidalPowerPlant

• 4. Subclasses of HydroPowerplant are ReservoirPowerPlant and RunOfRiverPowerplant

• 5. Subclasses of ReservoirPowerPlant are StorageHydropowerPlant, PumpstoragePowerPlant and PumpstoragePowerPlantWithNaturalInflux

• 5.OceanPowerplant uses some Ocean

• 6.HydroPowerplant uses some Hydro

To 5. A Storage Powerplant has no Pump system. Pumpstorage Power Plants can have a natural influx but also not.

We have a few troubles:

• Protege seems to change the order of attributes in the omn file when working on the ontology.
  Thus it marks changes when comparing versions where there are none.

• It seems that Protege sorts classes alphabetically. If persons work on different branches and in different places, then changes with similar alphabetic beginnings end up in the same place when trying to merge with git - thus seemingly creating conflicts (where there should actually be none)

We have created the branch feature/geo off feature/resources and have trouble merging back into feature/resources due to the above mentioned issues. We are not sure how to resolve this. Do you have an advice on how to deal with this?

Suggestion: Potentially add this to the agenda for the next ontology meeting.

@l-emele
@wingechr

A fresh install of protege-5.5.0-beta-4 (as is the default download for linux-users on their website) is not able to import oeo.omn. The program freezes, displaying an empty error message window.

A workaround is to just use an older version. Version 5.2.0 imports the file without any problems. (available here)

Our ideas on class Sector (as they can be characterised differently), and we will work on this

Add a class SectorConcept
Each Sector has a SectorConcept
SectorConcept contains subclasses of concepts that have specific names
    These subclasses can be filled with information accordingly

The class EnergyCarrier with subclasses like Air, Heat and Fuel is currently a subclass of bfo:object. As they dont have boundaries and are uncountable (same problem as with StateOfMatter) EnergyCarrier needs to be reclassified.

There are already factsheets for energy models. The ontology should cover similar expressiveness. Yet, those sheets contain a lot of specific information, that should be abstracted.

There are some concepts that are used in many party of the ontology. They should not be redefined in every part for consistency reasons. Yet, just refencing e.g. oeo:Transformation does not import the corresponding semantics. So, we need some common module that contains basic features.

As there seem to be different opinions on workflow, especially merges, we need to discuss that in an own issue instead of the now closed pull request #58.

Requirements/demands from the Ontology hackathon meeting:

• A class should always have a definition which reflects what the class is (should be discussed)

• Every entry in the ontology should have an annotation

• The classes should arise from concepts rather than words

• The goal of this ontology (what it should help with) should be kept in mind by the collaborators (and hence must be clearly described somewhere, like in the README and/or the CONTRIBUTE)

• Names should follow the UpperCamelCase

As a user I would like to use a glossary/ontology to understand  unknown terms and ensure that my terminology and that of SzenarioDB match.

A file would be useful to know who knows what and who is currently working on the repository since when.

The metadata set DCAT-AP and GeoDCAT-AP is using some namespaces I wan't to collect and link here:

• DCMI Metadata Terms (dct)
• Asset Description Metadata Schema (adms)
• W3C Data Catalog Vocabulary (dcat)
• ISA Data Catalog Vocabulary Application Profile (DCAT-AP)
• GeoDCAT
• ISA Core Location Vocabulary (LOCN)
• Friend of a Friend (FOAF)
• SPDX
• Schema.org
• VCARD

Sources:

• GeoDCAT-AP Version 1.0.1

I'm not sure anymore if a sector is really an object aggregate. Maybe rather a generically dependent continuant? Is a sector more than the sum of its parts? What are its parts? A more detailed definition/ explanation of what a sector is would also help.

Definition of 'agent' includes the term 'person', but at the moment 'person' is subclass of 'agent'.

1. Is this a good definition?
2. Is the hirarchy correct/reasonable?

the information artefact ontology may be of some use, in particular for the representation of software artefacts

Add to scenario factsheets:

Parameter:

• Name of target
• Description of target
• Was fulfilled

How should the field 'definition source' be used? So far I've put just URLs in the field 'definition source' but this is not a complete indication of the source.

Should that be just plain text? Or should that be e.g. formatted in a machine readable format like BibTeX? Or something completely different?

Following our discussions in January I have started including emission-related information in the ontology.

In the branch feature/resources I included the class Pollutant which contains the subclasses GreenhouseGas and AirPollutant. In the subclass GreenhouseGas I also added some individuals like Carbon_dioxide and Methane. I also included in the class Quantity the subclasses GlobalWarmingPotential and EmissionFactor next to the already existing subclass Emission.

Now I want to tell Protégé that the subclasses GlobalWarmingPotential, EmissionFactor, and Emission are always connected to a pollutant. In spoken language I would say something like: "The value of a GlobalWarmingPotential (GWP) can never stand alone, it has always to be mentioned for which greenhouse gas this GWP belongs to." (EmissionFactor and Emission are identical cases.)

How can I add a property like that in Protégé? Obviously the property "subclass of" does not fit here.

cc @han-f @wingechr

P.S. If you are not familiar with the GWP concept, check here: https://en.wikipedia.org/wiki/Global_warming_potential