Meta-Issue: Example case for instance data description in triples

[kknos]

Description of the issue

Although I did not not participate in the developer meeting (but will do in the next one) I understood from discussions with @p-kuckertz that a central goal of the ontology development is to use it to describe real world data for modeling purposes.

OWL can give an umambiguous definition to instance data. This makes different data sources comparable and mergable. Futher, it allows to validate the instance data for ontological consistency and constraints to identify missing, false or inconsistent data using a Shapes Constraint Language (SHACL).

To describe instance data we require a trible of class, attribute and constraint.

In this issue I would like to present a short example of instance data for an electrolyzer to discuss the development of such triples in the ontology. Please note, that this is just an example to identify the requirements for decribing instance data in the OEO and as a basis for further discussions.

EXAMPLE:

• A electrolysis system has none or many

  • electrolysis stack
  • gas compression
  • gas cooling
  • gas purification
  • water conditioning
  • water cooling
  • water pump
  • power electronics

• A electrolysis system has none or one

  • container

General properties:

attribute	quantity value	example unit	example range	example data
manufacturer	-	-	-	AREVA H2GEN
series	-	-	-	E10
reference year	year	-	-	2020

Economic properties:

attribute	quantity value	example unit	example range	example data
Investfix	currency	EUR	>0	-
Invest variable	currency per power	EUR/kW	>0	-
OPEX fix	currency	EUR	>0	-
OPEX variable	currency per power	EUR/kW	>0	-

Technical Properties:

attribute	quantity value	example unit	example range	example data
input	List[commodity]	-	-	DC power, water
output	List[commodity]	-	-	hydrogen, oxygen, waste-heat
electrical power	power	kW	>0	80
specific energy consumption	energy per volume	kWh/Nm^3	>0	5.3
voltage level	voltage	V	>0	400
frequency	frequency	Hz	>0	50
part load min	ratio	%	[0,100]	-
part load max	ratio	%	[0,100]	-
input water mass flow max	volume per time	l/h	>0	20
input water conductivity max	conductivity per length	μS/cm	>0	2000
input water PH value min	PH value	-	[0,14]	4
input water PH value max	PH value	-	[0,14]	10
input water temperature min	temperature	°C	>0	5
input water temperature max	temperature	°C	>0	40
input water pressure min	pressure	barg	>0	2
input water pressure max	pressure	barg	>0	6
output hydrogen mass flow nom	volume per time	Nm^3/h	>0	10
output hydrogen pressure max	pressure	barg	>0	50
output hydrogen purity min	-	-	>0	3.0
output hydrogen purity max	-	-	>0	-
output oxygen mass flow nom	volume per time	Nm^3/h	>0	5
output oxygen pressure nom	pressure	barg	>0	13
output oxygen purtiy min	-	-	>0	-
output waste-heat mass flow	volume per time	m^3/h	>0	2
output waste-heat energy flow	power	kWh/h	>0	-
output waste-heat temperature	temperature	K	>0	-
lifetime	time	a	>0	20
ambient temperaturem min	temperature	°C	>0	3
ambient temperature max	temperature	°C	>0	40
ambient humidity min	humidity	%	[0,100]	0
ambient humidity max	humidity	%	[0,100]	95

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

[Vera-IER]

That's a quite specific and huge example. I would suggest that we focus first on how to implement only the economic properties. These are the most important attributes in energy system models and I use them in my model for nearly every process. But I am not an ontology expert, so my question to @OpenEnergyPlatform/oeo-general-expert-formal-ontology is: is it possible that we include for example a class "fix investment costs" and link it somehow to every process or artificial object which could have invest costs?

[p-kuckertz]

Yes it is not small - but we did not want to leave anything out in order to show how complex it can get.

But it is not our primary purpose to fully implement everything what is mentioned in the example. We would rather like to learn how attributes, constraints, units, etc are to be properly incorporated.

[han-f]

Related to OpenEnergyPlatform/ontology#268

[stap-m]

Until now, we've never really implemented the connection between "objects" and "attributes". From the past discussions on quantity values I tried to understand how this could be done within the OEO. With the help of @jannahastings I made a slide to illustrate the process. I hope it is helpful for you, too.
This topic should definitely be on the agenda for the next developer meeting.

[stap-m]

is it possible that we include for example a class "fix investment costs" and link it somehow to every process or artificial object which could have invest costs?

That should be no problem. I am not sure if we've already an appropriate relation for that, though. We have produces, but that doesn't really fit in my opinion. Maybe something like causes / caused by or more specific has costs?!

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

attribute	quantity value	example unit	example range	example data
output waste-heat mass flow	volume per time	m^3/h	>0	2

A mass of heat that is measured as a volume 🤔🤣

[carstenhoyerklick]

Hi everybody,
we dicussed this issue todoay in a LOD-GEOSS working group and we would propose to put this up again on the next developer meeting.
The graph from @stap-m and @jannahastings illustrates on how to write down e.g. a hub hight. But we think this is quite a complex nesting of triples to describe a property. To our understanding it would make using the ontology much easier if we add predicates as "has hubhight" to the ontology. I would incraese the size of the ontology, but would make (RDF-) data bases easier and slimmer. The inclusion of the predicates would be a one time work in the ontology and can be used in all data bases in the future. The generation of the predicates should not create a lot of discussion, they should be quite straight forward.
Can we put this up on the next meeting (Nov. 4th, Patrick and I would have time to present this).

[l-emele]

Once we implement the composed module, we can work on this issue.

[l-emele]

@chrwm @stap-m : I think this is also something that can be implemented now with the extended module. Shall we transfer this issue to the oeo-extended repo?