Area and Area Function

[Haigutus]

Three known options for structure implementation

1. One SKOS Concept per Area, with rdf:type per each Function
2. One SKOS Concepts per Area and separate Concept per Area Function with skos:similar link to Energy Area
3. One Concept per Area Function (meaning we will duplicated core data for all)

Functions examples: OptimisationArea, ControlArea, SchedulingArea, SubGeographicalRegion

What ontologies we will use:

1. Official ENTSO-E CIM Network Code extensions
2. Do we need to extend with old CGM BP data? - additional analyses, what can be reused from NC extensions
3. Some spatial ontologies? - need analyses what to use for commonly defined spatial data?
4. DCAT
5. SKOS

Example

1. Denmark East, will be only one Concept with multiple rdf:type [ControlArea, SchedulingArea, SubGeographicalRegion]
2. Denmark East, will be only one Concept and each function will be new Concept on it's own linked to the Denmark East Concept (the inheritance concept) Denmark East ControlArea Concept inherits form the general Denmark East Concept
3. Basically same as option 2. but without generic Concept and without inheritance, all common data will be duplicated

Disadvantages:

1. The Concept will have only one ID and if in exchange different functions are referred to it is not unique ID anymore.
2. Full data is not available directly at each Function
3. Data is duplicated

[Haigutus]

HMG 2022-09-30: Proposal to go with option 3. - the drawback of data duplication is small compared to he flexibility accuracy and alignment with different models (mainly CIM). One to one compatibility between functions is not guaranteed, what other options would expect.

[VladimirAlexiev]

@Haigutus , @Sveino
Whatever solution you adopt, should work equally well for all kinds of EIC entities: Parties, Resources, etc because they also have Functions.

I strongly believe that each EIC entity should have one identity, linking to its various functions. Example from our TEKG project:

<10YCA-BULGARIA-R> a tr:EnergyResource ;
        tr:countryCode  "BG" ;
        tr:eic          "10YCA-BULGARIA-R" ;
        tr:function     "Bidding Zone" , "Member State" , "Control Block" , "Control Area" , "Market Balance Area" , "Scheduling Area" ;
        tr:eicType <type/Eic/Y>.
<eic/10X1001A1001A38Y> a tr:EnergyResource;
  tr:name "STATNETT SF";
  tr:countryCode "NO";
  tr:eic "10X1001A1001A38Y";
  tr:function "System Operator";
  tr:eicType <type/Eic/X>.

• function is better rendered as a resource (not string), part of a Functions concept scheme. However, some functions are inconsistently spelled, so require normalization, so you may well need two fields function and functionText (latter to be used as a mini "staging area" until resolved)
• eicType is the class of EIC and decodes the third char of the EIC.
• for some EnergyResources we also added rdf:type based on function. However, some functions are inconsistent with eicType and multiple values are inconsistent between themselves (eg both "Production Unit" and "Generation Unit").

See function-related validation rules starting at https://transparency.ontotext.com/spec/#function-not-null (3.6.1). Also see 3.6.10 and 3.6.11 about EIC-functions compatibility.

[Sveino]

There are some areas that we need to include in a common reference for Pan-Europe, but there is also a need for area that it maintain inside each country:

• GeographicalRegion (need to be pan Europe)
• SubGeographicalRegion (needed for the country).

• BiddingZone and BiddingZoneBoard - should be one concept

• SynchronousArea, LFCBlock, LFCArea and LFCOperator

I think the Function should be part of the organisation and roles: #17

[Haigutus]

Related to: #51