Giter VIP home page Giter VIP logo

energy-reference-data's Introduction

Energy Reference Data

Project to create common reference data to be used for Energy related business processes using Simple Knowledge Organization System (SKOS) for structure, Data Catalog Vocabulary (DCAT) for additional metadata and Common Information Model (CIM) as energy domain data

Content

Here will be examples and tooling to convert existing data:

  • CIM/CGMES enumerations
  • ENTSO-E codelists
  • EIC
  • Common data from CGMES boundary
  • CIM Meter Reading Type and Quality

Structure

At the moment ther are 4 folders:

  • GeneratedData: data generated by scripts in Tools and can contain any serialisation
  • SampleData: data generated manually for exploring and providing examples for discussions
  • Tools: Tools to generate data (collect, transform, serialize) form different sources
  • docs: Data published to webpage (experimental for now)

Publications of data

Official publication:

Unofficial Resolvable publication:

Example

energy-reference-data's People

Contributors

griddigit avatar haigutus avatar pingviinituutti avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

energy-reference-data's Issues

Consider using VOID

(Maybe this is more for @Sveino 's private repo but I think it is also for her. Cc @griddigit @Haigutus )

You keep talking about DCAT. That's fine and dandy for government datasets that are typically CSV.

However, the ontology that describes semantic datasets is VOID. You can describe semantic formats, stats per class and prop, ontologies used, link sets, etc. This is served from a well known location of the server.

Eg see http://vocab.getty.edu/doc/#Descriptive_Information where we used VOID, DCAT and (for good measure) ADMS. That was as early as 2014. In this case redundant data representation made it more future proof.

CIM WG Maintenance Request - Support DCAT3

Description of issue:
Dataset version handling is very important. This is now addressed in DCAT-3 and our Metadata specification should rely on DCAT-3 so that we can easier implement support for Common Energy Data Space.
This change request is addressing the particular need from CSA and are therefor just adding the additional attributes that is needed without evaluating other elements.

Proposed resolution

  • Suggest to make the following updates:

  • Update line 161 to refer to DCAT-3.

  • Update Figure 3 by removing time (it is no longer used) and update the diagram with the changes done on the attributes.

  • Update Figure 7 based on the update done on the attribues

  • Update the following attributes in Table 2:

    • Change hasCurrentVersion from String to IRI and it shall be serielized as rdf:resource.
    • Change isVersionOf from String to IRI and it shall be serielized as rdf:resource.
    • Change previousVersion from String to IRI and it shall be serielized as rdf:resource.
    • Change wasGeneratedBy form 0..n to 0..1
    • Should considere changing the following from String to stringIRI and it shall be serilized as literal.
      • dcterms:license
      • dcterms:rights
      • dcterms:rightHolder
  • Add the following attributes:

    • All IRI shall be serielized as rdf:resource
name mult type description
issued 0..1 Date
title 0..1 String
spartial 0..1 IRI

Need to add the addtional fields.

Provenance instance file specification

This is related to issue #40
The activity (http://energy.referencedata.eu/CGM/Action) and for that matter Model (http://energy.referencedata.eu/CGM/Model and Frame (http://energy.referencedata.eu/CGM/Frame) could all be defined as skos:ConceptScheme - like "pure" reference data.
In addition or as an alternative (the business process and tool vendor would in principle decide) they can be implemented as dcat:Dataset and expended to the level needed.
For active this could include initial action (abstract and concrete), process and execution. For W3C support this could be all they way to Manifest vocabulary for test cases
Following:

<> a mf:Manifest ;
     rdfs:label "...Manifest label"
     rdfs:comment "...Manifest comment" ;
     dc:creator "...creator..."
     mf:entries
     (
     ....list of ManifestEntries
     ) .

Example:

<entry1> a sht:Validate ;
   mf:name "Validate simple RDF data with a simple shapes graph" ;
   mf:action [
        sht:shapesGraph <example-shapes.ttl> ; 
        sht:dataGraph <example-data.ttl> ; 
   ] ;
   mf:result [
        a sh:ValidationReport ;
        sh:conforms true ;
   ] ;
   mf:status sht:proposed .

In ENTSO-E RCC Services we would like to include process for CSA, but as a minimum we would need to include automatic validation.

Abstract Action specification: "20230514_ENTSO-E_CGM-Action.jsonld":

{
    "@context": {
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "dcterms": "http://purl.org/dc/terms/",
        "dcat": "http://www.w3.org/ns/dcat#",
        "prov": "http://www.w3.org/ns/prov#",
		"@base" : "http://energy.referencedata.eu/CGM/Action/",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@id": "urn:uuid:e715ded1-4bbb-4948-bda4-e327738dd702",
    "@type": "dcat:Dataset",
    "prov:generatedAtTime": {
        "@value": "2023-05-14T15:24:37Z",
        "@type": "xsd:dateTime"
    },
    "dcterms:title": "20230514_ENTSO-E_CGM-Action",
    "dcterms:temporal": {
        "@type": "dcterms:PeriodOfTime",
        "dcat:startDate": {
            "@value": "2023-05-14T23:00:00Z",
            "@type": "xsd:dateTime"
        }
    },	
    "dcterms:publisher": {
        "@id": "urn:uuid:8bcf30f5-8bdb-460e-b261-f4f0f6e4ebbf",
        "dcterms:title": "ENTSO-E"
    },
     "dcat:isVersionOf": {
        "@id": "http://energy.referencedata.eu/CGM/Action/",
        "dcterms:title": "CGM-Action"		 
    },
	"dcat:version": "1.0",

    "@graph": [
        {
            "@id": "urn:uuid:a494e864-4109-465e-a401-294e18025447",
            "@type": "prov:Activity",
			"prov:type": "modeling",
			"dcterms:title": "CGM-RA",
			"dcterms:description": "Creating the offline Remedial Action definition for Common Grid Model (CGM)."	
 		},
        {
            "@id": "urn:uuid:b608c04c-a256-4966-8cc4-fdaeac24cab9",
            "@type": "prov:Activity",
			"prov:type": "valdating",
			"dcterms:title": "CGM-RA-VF",
			"dcterms:description": "Verifiying (VF) the offline Remedial Action definition for Common Grid Model (CGM)."	
 		}		
    ]
}

The action log file from APG:

{
    "@context": {
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "dcterms": "http://purl.org/dc/terms/",
        "dcat": "http://www.w3.org/ns/dcat#",
        "prov": "http://www.w3.org/ns/prov#",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@id": "urn:uuid:e715ded1-4bbb-4948-bda4-e327738dd702",
    "@type": "dcat:Dataset",
    "prov:generatedAtTime": {
        "@value": "2023-05-14T15:24:37Z",
        "@type": "xsd:dateTime"
    },
    "dcterms:title": "Provenance",
    "dcterms:publisher": {
        "@id": "urn:uuid:a7ce59a4-9b5f-438c-be71-afe6722111ce",
        "dcterms:title": "APG"
    },
     "dcat:isVersionOf": {
        "@id": "http://apg.com/CGM/Provenance"
    },
	"dcterms:references": [
        {
            "@id": "urn:uuid:e715ded1-4bbb-4948-bda4-e327738dd702",
			"dcterms:title": "20230514_ENTSO-E_CGM-Action"			
        }
    ]
	"dcat:version": "1.0",

    "@graph": [
        {
            "@id": "urn:uuid:f5dc9c54-4de6-4dff-8824-00ecb8a40d8b",
            "@type": "prov:Activity",
			"prov:specializationOf": {
				"@id": "urn:uuid:a494e864-4109-465e-a401-294e18025447",
				"dcterms:title": "CGM-RA"
			},
			"dcterms:title": "20230512T2230Z_APG_CGM-RA",
			"dcterms:description": "Creating the APG offline Remedial Action definition for Common Grid Model (CGM).",
			"prov:wasAssociatedWith": {
				"@id": "http://energy.referencedata.eu/CGM/SoftwareAgent/178a3674-e685-47d8-af57-6619dd925df4",
				"dcterms:title": "The Best RA modelling tool"
			},
			"prov:generated": {
				"@id": "urn:uuid:6e39b3ee-045d-42c0-9f99-2479640080ac",
				"dcterms:title": "20230512T2230Z_APG_CGM-RA"
			},
			"prov:endedAtTime": {
				"@value": "2023-05-14T15:24:37Z",
				"@type": "xsd:dateTime"
			},
 		}		
    ]
}

BaseVoltage.ttl issues

I've converted files to turtle and will start posting issues per file.
If you answer specific items (bullets), please use the item number!
I also add checkboxes so we can track what's been resolved: fixed or canceled (dismissed)

<http://energy.referencedata.eu/BaseVoltage/b0966c6c-9e5e-11e5-a575-c01885dc2c80>
        rdf:type                        cim:BaseVoltage , skos:Concept ;
        cim:BaseVoltage.nominalVoltage  "130" ;
        cim:IdentifiedObject.description
                "Base voltage 130 kV" ;
        cim:IdentifiedObject.name       "AC-130" ;
        dcterms:identifier              "urn:uuid:b0966c6c-9e5e-11e5-a575-c01885dc2c80" ;
        skos:definition                 "Base voltage 130 kV"@en ;
        skos:inScheme                   <http://energy.referencedata.eu/BaseVoltage> ;
        skos:prefLabel                  "AC-130" ;
        skos:topConceptOf               <http://energy.referencedata.eu/BaseVoltage> .

<http://energy.referencedata.eu/BaseVoltage/55c363d2-b10c-46dd-b851-9a014b68d031>
        rdf:type                        skos:Concept , cim:BaseVoltage ;
        cim:BaseVoltage.nominalVoltage  "35" ;
        cim:IdentifiedObject.description
                "Base voltage defined by ENTSO-E 35 kV" ;
        cim:IdentifiedObject.name       "AC-35" ;
        dcterms:identifier              "urn:uuid:55c363d2-b10c-46dd-b851-9a014b68d031" ;
        skos:definition                 "Base voltage defined by ENTSO-E 35 kV"@en ;
        skos:inScheme                   <http://energy.referencedata.eu/BaseVoltage> ;
        skos:prefLabel                  "AC-35" ;
        skos:topConceptOf               <http://energy.referencedata.eu/BaseVoltage> .
  • 1: remove urn:uuid: from identifier: the identifier is just the GUID, the rest turns it into a URI.
    To use the URI you need to write it <urn:uuid:55c363d2-b10c-46dd-b851-9a014b68d031> but it's not needed since you use a URL at energy.referencedata.eu
  • 2: switch all URLs to use https: not http:. All modern sites use https, and browsers issue ugly warnings for http sites
  • 3: It really would be better to use meaningful URLs not GUIDs (but only if you can guarantee stability!)
  • 4: topConceptOf is a bit redundant: inScheme is mandatory, and topConceptOf is only used in hierarchical thesauri (which this is not)
  • 5: unify definition: IMHO remove "defined by ENTSO-E" since it's not present in all entries.
  • 6: must define the http://energy.referencedata.eu/BaseVoltage ConceptScheme
  • 7: use dct rather than dcterms, because it's more commonly used
  • 8: is this prefix needed, and why at not eg eu-auth, and where can I read about it?
    @prefix at: <http://publications.europa.eu/ontology/authority/> .

Fix UUID for BaseVoltage AC-12

Issue:

The mRID for Base Voltage AC-12 is not valid UUID.

Badly formed hexadecimal UUID string:
urn:uuid:17267756-c569-4c24-a32f-993908dd9d0 Not valid UUID
(the 12 character section, beginning with 9939, contains only 11 characters.)

Issue discovered in:

#15
https://github.com/Sveino/CGMES/issues/15

Proposed solution:

This needs to be fixed on NMD application

allocated-eic.ttl issues; representation at ONTO TEKG

@prefix at:   <http://publications.europa.eu/ontology/authority/> .
@prefix cim:  <http://iec.ch/TC57/2013/CIM-schema-cim16#> .
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix eic:  <urn:iec62325.351:tc57wg16:451-n:eicdocument:1:0> .
@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

<http://data.europa.eu/energy/EIC/10X1001A1001A38Y>
        rdf:type           skos:Concept ;
        at:start.use       "2016-10-18" ;
        skos:altLabel      "STATNETT SF" ;
        skos:definition    "Transmission System Operator" ;
        skos:inScheme      <http://data.europa.eu/energy/EIC> ;
        skos:prefLabel     "STATNETT_SF" ;
        skos:topConceptOf  <http://data.europa.eu/energy/EIC> ;
        eic:EICCode_MarketDocument.Function_Names.name "System Operator" ;
        eic:EICCode_MarketDocument.attributeInstanceComponent.attribute "International" ;
        eic:EICCode_MarketDocument.description "Transmission System Operator" ;
        eic:EICCode_MarketDocument.display_Names.name "STATNETT_SF" ;
        eic:EICCode_MarketDocument.docStatus.value "A05" ;
        eic:EICCode_MarketDocument.eICCode_MarketParticipant.streetAddress.townDetail.country "NO" ;
        eic:EICCode_MarketDocument.eICCode_MarketParticipant.vATCode_Names.name "7080000923168" ;
        eic:EICCode_MarketDocument.lastRequest_DateAndOrTime.date "2016-10-18" ;
        eic:EICCode_MarketDocument.long_Names.name "STATNETT SF" ;
        eic:EICCode_MarketDocument.mRID "10X1001A1001A38Y" .

<http://data.europa.eu/energy/EIC/50WP000000016964>
        rdf:type           skos:Concept ;
        at:start.use       "2019-08-13" ;
        skos:altLabel      "Røyrvatn" ;
        skos:inScheme      <http://data.europa.eu/energy/EIC> ;
        skos:prefLabel     "NO-ROYRVATN_PL" ;
        skos:topConceptOf  <http://data.europa.eu/energy/EIC> ;
        eic:EICCode_MarketDocument.Function_Names.name "Production Unit" ;
        eic:EICCode_MarketDocument.attributeInstanceComponent.attribute "International" ;
        eic:EICCode_MarketDocument.display_Names.name "NO-ROYRVATN_PL" ;
        eic:EICCode_MarketDocument.docStatus.value "A05" ;
        eic:EICCode_MarketDocument.eICResponsible_MarketParticipant.mRID <http://data.europa.eu/energy/EIC/10X1001A1001A38Y> ;
        eic:EICCode_MarketDocument.lastRequest_DateAndOrTime.date "2019-08-13" ;
        eic:EICCode_MarketDocument.long_Names.name "Røyrvatn" ;
        eic:EICCode_MarketDocument.mRID "50WP000000016964" .

<http://data.europa.eu/energy/EIC/Function#ProductionUnit>
        rdf:type        skos:Collection ;
        skos:member     <http://data.europa.eu/energy/EIC/50WP000000016964> , <http://data.europa.eu/energy/EIC/45W000000000145G> , <http://data.europa.eu/energy/EIC/26WIMPI-S04SRNT9> , <http://data.europa.eu/energy/EIC/50WP00000002048Y> , <http://data.europa.eu/energy/EIC/50WP00000001630Y> , <http://data.europa.eu/energy/EIC/50WP00000001538M> ...
  • 1: EIC resources and parties are NOT Concepts.
    • Concepts should be used only for generic things (eg Generator, Party, etc). Eg it makes sense to represent these as concepts: Functions, EIC Types (determined from the 3rd char), doc status, etc.
    • But not for specific real-world entities.
  • 2: Where is this at: ontology? (Its namespace doesn't resolve). I'd guess it doesn't include a at:start.use prop. Use schema.org for this.
  • 3: Using <urn:iec62325.351:tc57wg16:451-n:eicdocument:1:0> as the EIC ontology namespace is wrong. That's the namespace of the EIC XSD, but the ontology is a different thing. You need to create it, and then put it at a URL so it's resolvable
  • 4: Needs a type, eg eic:EnergyResource
  • 5: Consider more specific subtypes per function, eg eic:ProductionUnit.
    But please mind that functions are inconsistently spelled, some multiple values are incompatibly used, and some functions don't conform to the EIC type (3rd char). See TEKG Validation below.
    So we only used ProductionUnit and GenerationUnit, assigned after cleaning function values.
  • 6: The eic: props are awfully long since they follow the XML nesting. I dare say people will hate using them.
    Eg EICCode_MarketDocument.eICCode_MarketParticipant.vATCode_Names.name talks about a document and a name, but what it means is the VAT of that party.
    Eg eic:EICCode_MarketDocument.eICCode_MarketParticipant.streetAddress.townDetail.country is an awful way to say country
    PLEASE use simpler names, eg as below.
  • 7: rename mRID to eic to make it clear what kind of identifier that is
  • 8: If docStatus is always "A05" then omit it. In semantics, you first of all model real-world entities, not messages or documents about them
  • 9: explicate data by converting strings to things. Eg
    • a: add `eic:eicType <.../type/Eic/X> (see below for what info we have about it)
    • b: If docStatus is important, use a URL value like <type/docStatus/A05>
    • c: consider turning functions into classes
  • 9: Using a skos:Collection to gather all ProductionUnits is not a good practice. Use a class eic:ProductionUnit
  • 10: eic:EICCode_MarketDocument.eICResponsible_MarketParticipant.mRID is wrong because the value is not a mRID!
    It is a URL representing an energy resource (party).
    So rename to eic:responsibleParticipant.
  • 11: I didn't see any links between ProductionUnits and GenerationUnits, nor details about MW and kV.
    The latter are in the Production Units ("master data") message but I didn't see this converted.

I'll repost from Sveino/Nordic44#12 how we represented EIC data in our ONTO TEKG knowledge graph.

@prefix tr: <https://transparency.ontotext.com/resource/tr/> .
@prefix eic: <https://transparency.ontotext.com/resource/eic/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

eic:10X1001A1001A38Y a tr:EnergyResource;
  tr:name "STATNETT SF";
  tr:countryCode "NO";
  tr:dateUpdated "2016-10-18"^^xsd:date;
  tr:eic "10X1001A1001A38Y";
  tr:function "System Operator";
  tr:notation "STATNETT_SF";
  tr:description "Transmission System Operator";
  tr:vatNumber "NO7080000923168";
  tr:eicType <https://transparency.ontotext.com/resource/type/Eic/X> .

<.../type/Eic/X> a eic:CodeValue; # could also use skos:Concept
  eic:codeList <type/Eic>;
  eic:notation "X" ; # third char
  eic:description "An EIC code to identify parties.";
  eic:name "Party";
  eic:functionValid # possible functions of "Party"
    "Balance Group Responsible Party",
    "Balance Responsible Party", "Balancing Service Provider", "Capacity Trader", "Consumer",
    "Consumption Responsible Party", "Coordination Center Operator", "Distribution System Operator",
    "Energy Supplier", "Grid Access Provider", "Grid Operator", "Imbalance Settlement Responsible",
    "Information Provider", "Interconnection Trade Responsible", "LNG System Operator",
    "Market Area Operator", "Market Operator", "Measurement Service Provider", "Meter Administrator",
    "Metered Data Aggregator", "Metered Data Responsible", "Metering Point Administrator",
    "Metering Point Operator", "Network User", "Nomination Validator", "Party Connected To Grid",
    "Platform Operator", "Producer", "Production Responsible Party", "Profile Maintenance Party",
    "Resource Capacity Mechanism Operator", "Resource Provider", "Storage System Operator",
    "System Operator", "Trade Responsible Party", "Transmission Capacity Allocator".

eic:50WP00000000883A tr:providerParticipant eic:10X1001A1001A38Y .

eic:50WP00000000685E tr:providerParticipant eic:10X1001A1001A38Y;
  tr:responsibleParticipant eic:10X1001A1001A38Y .

eic:50WG00000001921T tr:responsibleParticipant eic:10X1001A1001A38Y .

## ...  many more tr:providerParticipant and tr:responsibleParticipant statements

<https://transparency.ontotext.com/resource/validationResult/VAT-country-prefix/eic/10X1001A1001A38Y>
  <http://www.w3.org/ns/shacl#focusNode> eic:10X1001A1001A38Y .

<https://transparency.ontotext.com/resource/validationResult/VAT-per-country-syntax/eic/10X1001A1001A38Y>
  <http://www.w3.org/ns/shacl#focusNode> eic:10X1001A1001A38Y .

The last two are results of advanced SHACL validation that we performed:

You can see validation results at https://transparency.ontotext.com/app/validations, and further details about NO participants eg at

Align version numbering

Proposal is to have

<major>.<minor>.<revision>

This needs to be agreed and documented

Current state
image

Update base URI/URL

Initial idea was to use EC data Publication Office to publish Energy Reference data with uri/url of http://data.europa.eu/energy or http://data.europa.eu//energy, but due to:

  • ENTSO-E not qualifying as EU institution
  • Publishing Office not wanting to take the responsibility for publishing
  • ENTSO-E and Publish Office not able to find anyone within DG energy to reguest base url on behalf on ENTSO-E
  • Time pressure, where missing reference data would stop implementation of CGM realated services

ENTSO-E CIM EG decided on 2022-06-15 to use http://energy.referencedata.eu as the base URI and publish the data on ENTSO-E website

Task: change base URI from http://data.europa.eu/energy to http://energy.referencedata.eu

Duplicated mRID in FaultCauseType

ID KEY VALUE
02ada721-1e81-49c9-8c1a-4c7561da8d2c IdentifiedObject.name externalInfluences.humanThirdParty.constructionWork
02ada721-1e81-49c9-8c1a-4c7561da8d2c IdentifiedObject.name operationAndMaintenance.personnel.constructionWork
389299f2-c3ee-4eb5-b34c-6df7b87470e9 IdentifiedObject.name externalInfluences.humanThirdParty.logging
389299f2-c3ee-4eb5-b34c-6df7b87470e9 IdentifiedObject.name operationAndMaintenance.personnel.logging
59ee68fb-28e8-4ac6-9c29-69a02c892742 IdentifiedObject.name externalInfluences.humanThirdParty.diggingExcavation
59ee68fb-28e8-4ac6-9c29-69a02c892742 IdentifiedObject.name operationAndMaintenance.personnel.diggingExcavation
9b62ccc2-f92c-4e4d-9c72-e00aef0bd93a IdentifiedObject.name externalInfluences.humanThirdParty.trafficDamage
9b62ccc2-f92c-4e4d-9c72-e00aef0bd93a IdentifiedObject.name operationAndMaintenance.personnel.trafficDamage

OPC R4 - OR reference data

Goal:

  • To agree on the content of the header (content of FullModel).
  • Feedback from the Header and Metadata group is needed

Context: messages received

Initial message

I understood the reference data are final. We will not receive on regular basis and we will not include them in the output files generated by OPC Tool. So we basically do not need to process the file with reference data automatically in the application.

We could save the three lists of NamingAuthorities, NameTypes and ObjectTypes to our internal configuration and use it during OR file reception and OR file export. The configuration can be updated when needed (i.e. without the need of new version deployment). So it would be possible to make changes if needed (for example new naming authority).

Would this approach be acceptable for you? Do you see any problem with it?

Answer (ENTSO-E)

Regarding your first point, we agreed that this should be a final version. Regarding term “regular basis” we definitely do not expect such file to be delivered for instance every week or every month but only when new release of OR specification which highly depends on need for development and CIM Experts approval. It should not be included in output files generated by OPC Tool. This is supposed to be an official file (like Boundary set for instance in IGM/CGM creation service) that should be used by different tools in mapping process. Today it is PE OPC Tool, tomorrow it can be STA Tool, CSA Tool or any other so the best would be that all those tools are able to automatically process it.

On the other side I don’t see any obstacles in your proposal to not process it automatically but to have those 3 lists configurable. I’m just not sure if I understood you well - do you propose that we ignore reference data as an input file and define the data that we expect in reference data as dedicated configurable attributers (lists) in PE OPC Tool? Or you say that we should import it once and then make those 3 lists configurable so that in future we do not need to import new version just to reconfigure it?

The whole idea is that we want to reuse the reference data across multiple processes and the alignment process is ongoing, but this should not block OPC project. We do not really have many questions on the CIM expression of the things, but mostly on what the right authority is e.g. ENTSO-E, IEC, UCAIUG or OPC profile for different things which is all mostly instance data alignment.
When implementing the solution in the tool we need to be sure changes of reference data can be done with simple task and not big change requests.

rename `*TypeList` files and resources

There are 39 files with names like the following, using resource URLs like the following:

  • entsoe-codelist-StandardObjectAggregationTypeList:
    <http://energy.referencedata.eu/StandardObjectAggregationTypeList/A12>
  • entsoe-codelist-StandardTarifTypeTypeList.ttl:
    <http://energy.referencedata.eu/StandardTarifTypeTypeList/A05>

They're pretty bad (the second one is awful: what is TypeType?):

  • an individual resource is NOT a list, so this word should not be in the URL
  • it's better to use common prefixes delimited by /, rather than common suffixes

So I propose to change the naming as follows:

  • entsoe-codelist-ObjectAggregation:
    <http://energy.referencedata.eu/type/standard/ObjectAggregation/A12>
  • entsoe-codelist-Tariff.ttl:
    <http://energy.referencedata.eu/type/standard/Tariff/A05>

/standard is only needed if you expect other non-standard types to be added later.

Notice that "tariff" is spelled with "ff".

ACK for CGMES and NC

In the CGM process there is no ACK (Acknowledgement) for the exchange using CGMES. QoCDC do introduce validation report. This validation report and ACK for CGMES and NC is something that must be standardized. It has validity and usage outside the CGM process.

The CGM validation can be found in: Quality of CGMES datasets and calculations v3.3

ESMP uses IEC 62325-451-1: Acknowledgement business process and contextual model for CIM European market.

The Norwegian AutoFos project is using CGMES 2.5 IOP as based and extended it: https://github.com/digin-energi/Grunnprofil/issues/283

IEC 61968-100 is have a ACK error handling looking like

W3C SHACL https://www.w3.org/TR/shacl/#severity

https://swagger.io/docs/specification/describing-responses/

https://www.w3.org/TR/EARL10-Guide/

https://github.com/w3c/data-shapes/blob/gh-pages/data-shapes-test-suite/reports/pyshacl-earl.ttl

Interoperability:
image

Problem Details for HTTP APIs
image

Q: Should we refer to Acknowledgement or PayloadStatus?
The RFC referes to "application/problem+json" - but we would like to use this as part of testing/certification so that it included acknowledgement e.g. I have imported 12 cim:GeneratingUnit without any issue.

PayloadStatus/Acknowledge
TopStatus: OK | Info | Warning | Error | Feital
LegalStatus: [

{
    "@context": {
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "dcterms": "http://purl.org/dc/terms/",
        "dcat": "http://www.w3.org/ns/dcat#",
        "prov": "http://www.w3.org/ns/prov#",
		"foaf": "http://xmlns.com/foaf/0.1/",
		"cim": "http://ucaiug.org/ns/CIM#",
		"cdm": "http://ucaiug.org/ns/CDM#",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@id": "urn:uuid:c1888008-380e-463b-b7f4-e1910eec707e",
    "dcterms:title": "20230520T2230Z_APG_CGM-RA-ACK",

    "dcterms:conformsTo": [
        {
            "@id": "http://cim-profile.ucaig.com/ns/PayloadStatus/1.0",
			"dcterms:title": "Payload Status - Acknoledge",
			"dcat:keyword": "ACK"
        }
    ],
    "dcterms:references": [
        {
            "@id": "urn:uuid:83523b72-c63d-4e48-8c42-ebc76e10a99d",
			"dcterms:title": "20230520T2230Z_APG_CGM-RA"			
        }
    ] 
 
    "@graph": [
        {
            "@id": "urn:uuid:b1ae9ff8-ee0a-4c4c-b235-a7427381957f",
            "@type": "cdm:PayloadStatus",
			"cdm:type": "https://example.com/probs/out-of-credit",
			"dcterms:title": "You do not have enough credit.",
			"detail": "Your current balance is 30, but that costs 50.",
			"instance": "/account/12345/msgs/abc",
			"balance": 30,
			"accounts": ["/account/12345",
						 "/account/67890"]

 		}	
    ]
}

In a flat ConceptScheme should we use topConceptOf

In energy.referencedata.eu/PropertyReference.ttl we include skos:topConceptOf "http://energy.referencedata.eu/PropertyReference" on all Concept. Do we need it?

https://www.w3.org/TR/skos-reference/#schemes

Example:

<A> rdf:type skos:Concept ;
  skos:prefLabel "love"@en ;
  skos:altLabel "adoration"@en ;
  skos:broader <B> ;
  skos:inScheme <S> .

<B> rdf:type skos:Concept ;
  skos:prefLabel "emotion"@en ;
  skos:altLabel "feeling"@en ;
  skos:topConceptOf <S> .

<S> rdf:type skos:ConceptScheme ;
  dct:title "My First Thesaurus" ;
  skos:hasTopConcept <B> .

file cleaning in GeneratedData

This folder has mostly RDF files (though turtle is better: #18)

  • But there are 2 XML files: cim_MeterReadings_ReadingQualityTypes.xml cim_MeterReadings_ReadingTypes.xml: remove them
  • The folder name GeneratedData can imho be more specific. Maybe rdf?

Fix header namespace issue

Current issue
dcterms:Model.identifier attribute is serialized in header, but this is not correct as dcterms namsecapse does not have our cim:Model class

Possible options

  1. eumd:Model.identifier
  2. dcterms:identifier

cim_MeterReadings_ReadingQualityTypes.ttl issues

<http://data.europa.eu/energy/MeterReadingsQualityTypes>
        rdf:type            skos:ConceptScheme ;
        dcterms:identifier  "6074aa6b-de29-41bc-a4b5-b2bedbeaeffd" ;
        dcterms:modified    "2022-02-18" ;
        skos:definition     "Meter Reading Quality Types"@en ;
        skos:prefLabel      "MeterReadingsQualityTypes" ;
        dcat:version        "1" .

<http://data.europa.eu/energy/MeterReadingsQualityTypes/1.4.131>
        rdf:type                   "cim:ReadingQualityType" ;
        rdf:type                   skos:Concept ;
        cim:IdentifiedObject.description
                "Value Acquired By HHT" ;
        cim:IdentifiedObject.mRID  "f989e6a8-0371-52e1-bd8e-70144a92e936" ;
        cim:IdentifiedObject.name  "1.4.131" ;
        cim:ReadingQualityType.category
                "Data collection related" ;
        cim:ReadingQualityType.subCategory
                "Manual Read" ;
        cim:ReadingQualityType.systemId
                "End Device" ;
        dcterms:identifier         "1.4.131" ;
        skos:definition            "Value Acquired By HHT"@en ;
        skos:inScheme              <http://data.europa.eu/energy/MeterReadingsQualityTypes> ;
  • 1: uses different base http://data.europa.eu/energy/
  • 2: rename to cim_MeterReadingsQualityTypes.ttl to more closely reflect the contnts
  • 3: "2022-02-18" -> "2022-02-18"^^xsd:date
  • 4: type "cim:ReadingQualityType" is broken (string not URL)
  • 5: prefLabel "MeterReadingsQualityTypes" is no label, which should be an English phrase not CamelCasedPhrase
  • 6: definition "Meter Reading Quality Types"@en is no definition: that's the prefLabel
  • 7: put the GUID in dct:identifier as in BaseVoltage.ttl.
  • 8: put "1.4.131" in skos:notation and remove it from name
  • 9: put "Value Acquired By HHT"@en in skos:prefLabel
  • 10: dcat:version might be a bit problematic:
  • 11: category, subCategory suggest that you should make another ConceptScheme, turn these values to Concepts and add broader relation between them
  • 12: Similarly, systemId could be turned into a resource. At least, you can later attach multilingual labels to it; and it might be possible there is extra data about these system types?
  • 13: systemId is not a precise name, systemType would be better. But I guess you generate all this automatically from CIM, so no manual tweaking is "allowed"

semantic resolution and content negotiation

Eg see how we did it for Getty LOD some 8 years ago: http://vocab.getty.edu/doc/#Semantic_Resolution.
Requirements:

  • the same URL should serve HTML and various semantic formats
  • Use content negotiation to select an appropriate format (content type)
  • Use a 303 redirect ("semantic redirect") to send to the final destination
  • Ideally: also use file extension for direct links that don't need content negotiation

I guess the purpose of docs/ is something like this.
But it's thoroughly broken.
See the recipes in https://www.w3.org/TR/swbp-vocab-pub/. You need a simple web server (eg Apache with mod_rewrite) to do the redirects.

Use turtle as master format

May I strongly suggest that you use turtle as master format

  • easier to read
  • smaller
  • can expose errors made in RDF XML, especially re rdf:ID that you use extensively but is obsolete because it's relative and calls for trouble when you don't specify xml:base

Header aligned with DCAT and JSON-LD

We currently have the attributes:

  • (add atttribute names)

In CIMJSON-LD the suggestion is to use:

    "dcterms:temporal": {
        "@type": "http://purl.org/dc/terms/PeriodOfTime",
        "dcat:startDate": {
            "@value": "2022-03-30T23:00:00Z",
            "@type": "xsd:dateTime"
        }
    },

In CIMXML we should flatten the same attribute that belong to dcterms:teporal:

Confidentiality Levels

After a meeting with Rado (from OPDE) and Semir (OPC/STA).

Context:

  • OPDE

    • "OPDE Confidential" and "OPDE Secrets" are the current confidentiality levels.
    • These levels are defined after the security controls used to share the data. It is a non-trivial definition and they cannot provide it.
    • Four new levels will be used next year: "Normal", "High", "Very High" and "OPDE Confidential". The first three ones are taken from the GSP and the fourth is an edit of the "Very High" level.
  • OPC/STA

    • "OPC/STA Confidential" is the only level that is used.
    • In principle, once the new definitions for OPDE are put in place and if it is ok for the OPDE team, we should be able to assimilate "OPC/STA Confidential" as "OPDE Very High".

Tasks for Eduardo:

  • Speak with Daiga from ICT Solutions and obtain the new definitions of the confidentiality levels
  • For now, we could include in the reference data the definition provided by Semir for "OPDE Confidential".
  • Once I have the four levels, I will make OPC/STA Confidential == OPDE Very High

"OPDE Confidential" (by Semir): "Information/data which if disclosed to or modified by unauthorized persons, or subject to unplanned unavailability would cause either: substantial financial loss or substantial damage to the reputation or embarrassment to ENTSO-E; inability to deliver a critical service to the TSO community resulting in a loss of confidence; the breaking of any legal, regulatory or statutory laws or rules which could result in penalties or fines"

Manifest payload naming standard

CIM in general shall not include any naming standard. The main idea to include manifest and DCAT is to avoid implementation to rely on naming standard. However, as part of testing and where user interaction on the technical level is needed there is a need for a naming recommendation.
The shall follow the same logic that cim:IdentifiedObject.mRID and cim:IdentifiedObject.name where mRID is the machine interpreted identification and name is the user "identification".
A naming standard can also be useful for simple file based archiving tools that is based on the file name.

The updated naming standard need to cover the needs from CGMES profiles in CGM and TYNDP process in addition to the CSA, CCC, OPC and STA processes.

The current CGM names standard is document in: Quality of CGMES datasets and calculations v3.3
3.2 FILE NAME AND FILE HEADER
The following mask is to be used to have a valid file name:
(snip)
image

Example from QoCDC:

  • 20180118T0930Z_1D_APG_SSH_001.xml
  • 20180117T2230Z_1D_APG_EQ_001.xml
  • 20180117T2230Z__APG_EQ_001.xml
  • 20180118T1130Z_1D_TSCNET-EU_SV_001.xml
  • 20180118T1130Z_1D_TSCNET-EU-APG_SSH_001.xml

The item in the naming standard need to be found in the header so that tools can generate it based on an information model and that is consistent with the content of the payload.

<dcat:startTime>_<dcterms:publisher>_<prov:wasGeneratedBy>_[dcat:version]

dcat:startTime:
Taken from the dcat:Dataset - if there are multiple dataset with different startTime the prov:generateedAtTime for the manifest (collection) is used.

dcterms:publisher:
Taken from the dcat:Dataset - if there are multiple dataset with different publisher the publisher of the manifest (collection) are used.

prov:wasGeneratedBy
Taken from the dcat:Dataset - if there are multiple dataset with different wasGeneratedBy the wasGeneratedBy of the manifest (collection) are used.
prov:wasGeneratedBy is an association to the abstract prov:Activity that produced the prov:Entity.
The name include:

  • Process Type: CGM, TYNDP etc
  • Time Horizon: Year-ahead, Month-ahead etc
  • Run
  • Iteration
  • Profile
    E.g. for the following instance file the relevant activity are relevant:
    EQ/RA -> CGM, CGM1Y, TYNDP
    SSH/TP/SV -> IN, TYNDP, 1Y, 1M, 1W, 6...1D, ID
    RAS -> IN, TYNDP, 1Y, 1M, 1W, 6...1D, ID

_[dcat:version]:
This is referring to the dcat:Dataset where a new dcat:Dataset is replacing, make the previous version not valid any longer, by a new version that has the same validity period. The naming should follow semantic versioning, e.g. https://semver.org/ where _[1.0.0] is the default and is optional to use. Other version than the default must be included in the name.
E.g. The same EQ is exchange for the TYNDP:

  • 20230101_APG_TYNDP-EQ.xml
  • 20230101_APG_TYNDP-EQ_[1.0.0].xml

Example for CGM:

  • 20180118T0930Z_1D_APG_SSH_001.xml -> 20180118T0930Z_APG_CGM-1D-SSH.xml
  • 0180117T2230Z_1D_APG_EQ_001.xml -> 0180117T2230Z_APG_CGM-1D-EQ.xml
  • 20180117T2230Z__APG_EQ_001.xml -> 20180117T2230Z_APG_CGM-EQ.xml
  • 20180118T1130Z_1D_TSCNET-EU_SV_001.xml -> 20180118T1130Z_TSCNET-EU_CGM-1D-SV.xml
  • 20180118T1130Z_1D_TSCNET-EU-APG_SSH_001.xml -> 20180118T1130Z_TSCNET-EU-APG_CGM-1D-SSH.xml

Example for TYNDP:

  • 20230101_APG_TYNDP-EQ.xml

Example for CSA:

  • 20230512T2230Z_APG_CGM-RA.xml
  • 20230512T2230Z_APG_CGM-1D-r1-RAS.xml

Organisation​ and Organisation Role

In general we would like to have all data that is outside the core processes as reference data. Organisation and Organisation role would be reference data in regards to CGM and TYNDP process.
The Roles are managed by CIO https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/ with EIC code = PartyX
The CIMXML Reference file should be generated from this list. NC/CSA include a model for Organisation and organisation role.
The UML looks like:
image

However, this model does not support "VAT Code" and issue should be generated to get this included.

UCAig have created the project COMET to look at updating the organisation model. WG16 has made update to the organisation model in the latest update.
If we shall look at W3C harmonization for organisation we would need to look at the work done by European Commission Joinup ISA Core Public Organisation Vocabulary (link)
The CPOV should be consistent with the ORG-AP-OP (used by European Commission institutes).
Other relevant vocabulary:

We are considering adding provenance,. This is included as part of the https://www.w3.org/TR/vocab-org/

For CIMXML we would like to add the following namespace:

xmlns:skos="http://www.w3.org/2004/02/skos/core"

Header:

  <md:FullModel rdf:about="urn:uuid:a6189b5a-fb98-4523-a422-902a990749ae">
    <md:Model.modelingAuthoritySet>"https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/PartyX"</md:Model.modelingAuthoritySet>
    <md:Model.description>ENTSO-E Organisation Reference data (RD)</md:Model.description>
    <dcat:keyword>RD</dcat:keyword>
    <md:Model.version>1</md:Model.version>
    <md:Model.created>2022-03-12T17:26:43Z</md:Model.created>
  </md:FullModel>

Each Organisation would be:

<cim:Organisation rdf:ID="_e9e2da91-417b-44d9-bba3-3e222d40ebc0">
      <cim:IdentifiedObject.mRID>e9e2da91-417b-44d9-bba3-3e222d40ebc0</cim:IdentifiedObject.mRID>
     <cim:IdentifiedObject.name>STATNETT SF</cim:IdentifiedObject.name>
     <EU:IdentifiedObject.shortName>STATNETT_SF</EU:IdentifiedObject.shortName>
     <cim:postalAddress>
         <cim:townDetail>
              <cim:country>NO</cim:country>
         </cim:townDetail>
         <cim:postalCode>0302</cim:postalCode>
     </cim:postalAddress>
</cim:Organisation>

Use EU:IdentifiedObject.shortName for EIC Display Name

<NC:TransmittionSystemOperator rdf:ID="_ac76d294-721f-4cfa-8a31-3a9b9993fc79">
      <cim:IdentifiedObject.mRID>ac76d294-721f-4cfa-8a31-3a9b9993fc79</cim:IdentifiedObject.mRID>
     <cim:IdentifiedObject.name>STATNETT SF</cim:IdentifiedObject.name>
     <EU:IdentifiedObject.shortName>STATNETT_SF</EU:IdentifiedObject.shortName>
     <EU:IdentifiedObject.energyIdentCodeEic>10X1001A1001A38Y</EU:IdentifiedObject.energyIdentCodeEic>
     <NC:OrganisationRole.vatID>7080000923168</NC:OrganisationRole.vatID>
</NC:TransmittionSystemOperator>

UCAig is planning to remove the use of Compound - it does not make sense to have tools implement the current address structure when it is plan to be removed.
Alt 1: Add necessary classes to NC:

<cim:Organisation rdf:ID="_e9e2da91-417b-44d9-bba3-3e222d40ebc0">
      <cim:IdentifiedObject.mRID>e9e2da91-417b-44d9-bba3-3e222d40ebc0</cim:IdentifiedObject.mRID>
     <cim:IdentifiedObject.name>STATNETT SF</cim:IdentifiedObject.name>
     <EU:IdentifiedObject.shortName>STATNETT_SF</EU:IdentifiedObject.shortName>
     <NC:country>NO</NC:country>
     <NC:postalCode>0302</NC:postalCode>
</cim:Organisation>

Alt 2: We do not exchange the address information
In this case we should not include the address attributes in the profile.

Alt 3: Use W3C and EU ISA
We would like to add the following namespace:

xmlns:org="https://www.w3.org/TR/vocab-org/"
xmlns:locn= "https://www.w3.org/ns/locn#"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:skos="http://www.w3.org/2004/02/skos/core"
<org:FormalOrganization rdf:ID="_e9e2da91-417b-44d9-bba3-3e222d40ebc0">
      <dcterms:identifier>e9e2da91-417b-44d9-bba3-3e222d40ebc0</dcterms:identifier>
     <skos:prefLabel>STATNETT SF</skos:prefLabel>
     <skos:altLabel>STATNETT_SF</skos:altLabel>
     <locn:adminUnitL1>NO</locn:adminUnitL1>
     <locn:postCode>0302</locn:postCode>
</org:FormalOrganization>

Create CSA ReferenceData

For the Coordinated Security Analysis (CSA) we will need the following:

Header Reference:

Payload Reference:

EIC list

Currently CIM flields are there

Some initial mapping:

  • eic:EICCode_MarketDocument.mRID -> dcterms:identifer
  • eic:EICCode_MarketDocument.long_Names.name -> skos:prefLabel
  • eic:EICCode_MarketDocument.display_Names.name -> skos:altLabel
  • eic:EICCode_MarketDocument.lastRequest_DateAndOrTime.date -> at:start.use?

But all fields form XSD should be mapped or then excluded

47 Missing descriptions in FaultCauseType

@Pingviinituutti was this intentional? I would propose a improvement to add one to all.

ID KEY VALUE
93992f35-49b1-4bcd-93a8-a2d16233385e IdentifiedObject.description  
ce8c4614-d014-4419-9f2c-99925ba93328 IdentifiedObject.description  
bea6bd0c-ca21-4de5-8e16-e524884bb8a3 IdentifiedObject.description  
574ad0d5-1610-47a2-bca7-4e586fb3be2b IdentifiedObject.description  
9ca7699a-e792-45ea-b40b-6b056e603143 IdentifiedObject.description  
d1304c3d-0d07-4379-841d-d2ce47025498 IdentifiedObject.description  
3ec8c0a1-6823-41d0-baef-af0def109fcd IdentifiedObject.description  
bda46d8e-9515-4678-a6c9-dd62be9c5deb IdentifiedObject.description  
9cfb8eb4-e8eb-40d3-9f1c-9a31e36717d9 IdentifiedObject.description  
540f6a96-338f-480d-8cdd-a9746545dba2 IdentifiedObject.description  
af5594ba-241b-444f-bac5-23b808a5c707 IdentifiedObject.description  
527331e7-20ec-4454-8a31-c7aa564bfeba IdentifiedObject.description  
ac03c3d2-5d34-46a8-84c2-133fd6dbe45d IdentifiedObject.description  
82cbc4cd-554f-4f09-ad48-e00fdd95d2b5 IdentifiedObject.description  
7647ea49-8129-414a-81d2-683e959723ea IdentifiedObject.description  
307de251-d9b6-4c10-8a98-9b16a7d8e0cb IdentifiedObject.description  
a6a8ee4a-d696-4382-886c-3226c613912b IdentifiedObject.description  
ddad843a-7da8-405c-9baf-dca66921f828 IdentifiedObject.description  
8fcbe2aa-fcf1-4c25-9d3c-9db818f35a11 IdentifiedObject.description  
6ffb46e3-6e7d-47e3-9bf0-f8387ffe0595 IdentifiedObject.description  
dc74466d-5115-475c-a90c-ff103487b3e0 IdentifiedObject.description  
456ac068-5c16-45e4-8d3e-108333de9344 IdentifiedObject.description  
baec6ee9-3d37-4aa9-8ff5-0f4f8547432b IdentifiedObject.description  
81d22f06-0b56-4656-a4c4-a868c79c9865 IdentifiedObject.description  
873155bb-7675-4fc3-8391-609461c3d174 IdentifiedObject.description  
5be5b488-2bca-4876-bde5-65881df424b0 IdentifiedObject.description  
7c2ef4f5-3e11-4b29-8920-6ba18fba23be IdentifiedObject.description  
f0678796-efba-4252-a16b-1a4094b90917 IdentifiedObject.description  
cae54098-a3e2-45fd-a659-ed3f42539c31 IdentifiedObject.description  
fd7bce20-cd68-4366-9db7-2815156ed3b2 IdentifiedObject.description  
389299f2-c3ee-4eb5-b34c-6df7b87470e9 IdentifiedObject.description  
59ee68fb-28e8-4ac6-9c29-69a02c892742 IdentifiedObject.description  
02ada721-1e81-49c9-8c1a-4c7561da8d2c IdentifiedObject.description  
04991d18-8994-43cb-88e1-8d2af5a61577 IdentifiedObject.description  
e0ad1933-1448-48cf-aa91-c53a5960c39b IdentifiedObject.description  
77be6f95-d7f8-4f14-aeee-1a8bab3d2916 IdentifiedObject.description  
94bd2c45-29e7-4a34-99db-9ec1e18a26c5 IdentifiedObject.description  
506f89b7-f061-443f-b05a-8c22fa33127a IdentifiedObject.description  
f91f7cd0-c9cf-4f4f-9862-6a04bb70a53f IdentifiedObject.description  
e57f023c-027d-4d75-8364-177690c8346b IdentifiedObject.description  
fccda3ac-6e0c-47fc-9591-d1297f46c0c5 IdentifiedObject.description  
0638044d-1262-4b6d-bb12-be34565b6977 IdentifiedObject.description  
75b740f4-9080-461c-ac9a-e6318cffc5e3 IdentifiedObject.description  
1485acaf-d2cb-4e02-9c5e-29e9452e743f IdentifiedObject.description  
3a647504-e22a-49b7-969e-7e806e527e8a IdentifiedObject.description  
041e2fb7-dd49-4609-9bc5-fe6df04b96cf IdentifiedObject.description  
9eb57f55-c6b2-4df1-a411-128aeac5aa6d IdentifiedObject.description  

Manifest instance file specification

The manifest instance file must provide all the attributes that give the .cimx file it name. (ref #39 ). The name of a dataset instance file is given by the header in the dataset.

The manifest instance file is an dcat:Catalog that includes dcat:Dataset that can have multiple dcat:Distribution.
The serialization syntax should follow RDF 1.1 XML Syntax or JSON-LD 1.1 with .rdf and .jsonld as respected file type. This will be the same as what is plan for IEC 61970-501:Ed2.

The example is written in JSON-LD and can then be converted to RDF/XML.

A Manifest include the listing of all the artifacts included in the collection. It can include a single instance file, or the collection of all instance file needed for a framework even including the vocabulary and profile specifications.
In similar way can a dcat:Catalog include only one instance, or it can include all the instances that build up an exchange orchestration like Common Grid Model (CGM) including all the RCC services.
All instance file in a dcat:Catalog must be consistent and follow the rules for unique and persistent identification and version control so that can be used as a knowledge graph. All element that can be handle as a named graph must be registered as a dcat:CatalogRecord.

The Manifest.rdf:

{
    "@context": {
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "dcterms": "http://purl.org/dc/terms/",
        "dcat": "http://www.w3.org/ns/dcat#",
        "prov": "http://www.w3.org/ns/prov#",
	"foaf": "http://xmlns.com/foaf/0.1/",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@id": "urn:uuid:5fb6f3ee-274f-4b0c-8500-bf6752852565",
    "@type": "dcat:Catalog",
    "prov:generatedAtTime": {
        "@value": "2023-05-13T15:24:37Z",
        "@type": "xsd:dateTime"
    },
    "dcterms:title": "Manifest",
    "dcat:keyword": "MF",
    "dcterms:temporal": {       
        "@type": "dcterms:PeriodOfTime",
        "dcat:startDate": {
            "@value": "2023-06-14T23:00:00Z",
            "@type": "xsd:dateTime"
        }
    },
    "dcterms:publisher": {
        "@id": "urn:uuid:a7ce59a4-9b5f-438c-be71-afe6722111ce",
        "dcterms:title": "APG"
    },
	"prov:wasGeneratedBy": {
        "@id": "http://energy.referencedata.eu/CGM/Action/a494e864-4109-465e-a401-294e18025447",
        "dcterms:title": "CGM-RA"
    },
     "dcat:isVersionOf": {
        "@id": "http://apg.com/CGM/Manifest"
    },
	"dcat:version": "1.0.0",
	
    "@graph": [
        {
            "@id": "urn:uuid:c7338bce-fa27-4f12-b8e9-b8132f9d4486",
            "@type": "dcat:Catalog",
			"dcterms:title": "CGM-CSA Data catalog",
			"dcterms:description": "This the main data catalog for the Common Grid Model (CGM) and Coordinated Security Assessment (CSA). In general this only need to be added once.",
			"dcat:record": [
            {
				"@id": "urn:uuid:d1f1c85a-984b-454d-a132-f5ee37ab591e",
                "dcterms:title": "Data Record for 20230512T2230Z_APG_CGM-RA"
			},
            {
				"@id": "urn:uuid:5fb6f3ee-274f-4b0c-8500-bf6752852565",
                "dcterms:title": "Data Record for 20230512T2230Z_APG_CGM-RA"
			},
            {
				"@id": "urn:uuid:d1f1c85a-984b-454d-a132-f5ee37ab591e",
                "dcterms:title": "Manifest"
			}
        ]
		},
		{
            "@id": "urn:uuid:d1f1c85a-984b-454d-a132-f5ee37ab591e",
            "@type": "dcat:CatalogRecord",
			"dcterms:title": "Data Record for 20230512T2230Z_APG_CGM-RA",
			"foaf:primaryTopic": {
				"@id": "urn:uuid:9e82351f-4177-4389-9f6f-507e6d33a3c2"
			}
		},
		{
            "@id": "urn:uuid:161e5dad-8413-4ed4-bfeb-cc1f35bb9a53",
            "@type": "dcat:Dataset",
			"dcterms:title": "20230512T2230Z_APG_CGM-RA",
			"dcat:distribution": {
				"@id": "urn:uuid:9e82351f-4177-4389-9f6f-507e6d33a3c2",
		        "@type": "dcat:Distribution",
			    "dcterms:title": "20230512T2230Z_APG_CGM-RA.xml",
                "dcat:accessURL": {
                    "@id": "file://./NCv22/20230512T2230Z_APG_CGM-RA.xml"
                },
				"dcat:mediaType": {
				    "@id": "http://www.iana.org/assignments/media-types/application/rdf+xml"
                },
                "dcat:conformsTo": "urn:iso:std:iec:61970-552:2016"
			}
		}
    ]
}

The header of 20230512T2230Z_APG_CGM-RA.xml:

{
    "@context": {
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "dcterms": "http://purl.org/dc/terms/",
        "dcat": "http://www.w3.org/ns/dcat#",
        "prov": "http://www.w3.org/ns/prov#",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@id": "urn:uuid:6e39b3ee-045d-42c0-9f99-2479640080ac",
    "@type": "dcat:Dataset",
    "dcterms:identifier": "6e39b3ee-045d-42c0-9f99-2479640080ac",
    "prov:generatedAtTime": {
        "@value": "2023-05-13T15:24:37Z",
        "@type": "xsd:dateTime"
    },
    "dcterms:title": "20230512T2230Z_APG_CGM-RA",
    "dcterms:description": [
        {"@value": "This is an example of remedial action offline spesification.", "@language":"en"},
        {"@value": "Dette er et eksempel på spesifikasjoner for offline avhjelpende handlinger.", "@language":"no"}
    ] ,
    "dcat:keyword": ["RA", "Remedial Action"],
    "dcterms:temporal": {
        "@type": "dcterms:PeriodOfTime",
        "dcat:startDate": {
            "@value": "2023-05-12T23:00:00Z",
            "@type": "xsd:dateTime"
        }
    },	
    "dcterms:publisher": {
        "@id": "urn:eic:10XAT-APG------Z",
        "dcterms:title": "APG"
    },
    "dcterms:accessRights": {
        "@id": "http://energy.referencedata.eu/Confidentiality/OPDEConfidential",
        "dcterms:title": "OPDEConfidential",
        "dcterms:identifier": "4cd9b326-1275-4da7-9724-28c5e1deeb87"
    },
	"prov:wasGeneratedBy": {
        "@id": "http://energy.referencedata.eu/CGM/Action/CGM-RA",
        "dcterms:title": "CGM-RA",
        "dcterms:identifier": "a494e864-4109-465e-a401-294e18025447"
    },
     "dcat:isVersionOf": {
        "@id": "http://energy.referencedata.eu/CGM/Model/APG_CGM-RA",
        "dcterms:title": "APG_CGM-RA",
        "dcterms:identifier": "9237179a-1115-40d4-be41-89ac0b1bc58d"
    },
	"dcat:version": "1.0.0",
    "dcterms:spatial": {
        "@id": "http://energy.referencedata.eu/CGM/Frame/AT_Power-Transmission-System",
        "dcterms:title": "AT_Power-Transmission-System",
        "dcterms:identifier": "81524a5b-435d-4183-8fd5-4a60e1d9c0cf"
    },
    "dcterms:conformsTo": [
        {
            "@id": "http://entsoe.eu/ns/CIM/RemedialAction-EU/2.2",
			"dcterms:title": "RemedialActionProfile",
			"dcat:keyword": "RA"
        }
    ],
    "dcterms:references": [
        {
            "@id": "urn:uuid:a71dd8ab-371a-4106-b344-23ff915c523c",
			"dcterms:title": "20230512T2230Z_APG_CGM-EQ",
            "dcat:keyword": "EQ"		
        }
    ],
    "@graph": [
        {
 		}	
    ]
}

The same model serialized using CIM XML:

<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF
   xmlns:dcat="http://www.w3.org/ns/dcat#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   xmlns:prov="http://www.w3.org/ns/prov#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>
  <!--Header -->
  <md:FullModel rdf:about="urn:uuid:6e39b3ee-045d-42c0-9f99-2479640080ac">
  <!-- ID of the Full Model in RDF-->
    <dcterms:identifier>6e39b3ee-045d-42c0-9f99-2479640080ac</dcterms:identifier>
     <!-- creation time of the Document  -->
    <prov:generatedAtTime>2023-05-13T15:24:37+00:00</prov:generatedAtTime>
    <dcterms:title>20230512T2230Z_APG_CGM-RA</dcterms:title>
    <!-- Description of the model -->
    <dcterms:description xml:lang="en">This is an example of remedial action offline spesification.</dcterms:description>
    <dcterms:description xml:lang="no">Dette er et eksempel på spesifikasjoner for offline avhjelpende handlinger.</dcterms:description>

    <dcat:keyword>RA</dcat:keyword>
    <dcat:keyword>Remedial Action</dcat:keyword>
    <!-- temporal only shown as startDate and endDate using CIM XML -->
    <dcat:startDate>2023-05-12T23:00:00+00:00</dcat:startDate>

    <dcterms:publisher rdf:resource="urn:eic:10XAT-APG------Z"/>
    <dcterms:accessRights rdf:resource="http://energy.referencedata.eu/Confidentiality/OPDEConfidential"/>
    <prov:wasGeneratedBy rdf:resource="http://energy.referencedata.eu/CGM/Action/CGM-RA"/>
    <dcat:isVersionOf rdf:resource="http://energy.referencedata.eu/CGM/Model/APG_CGM-RA"/>
    <!-- Semantic Version of the Model -->
    <dcat:version>1.0.0</dcat:version>
    <!-- The Frame that the model are describing -->
    <dcterms:spatial rdf:resource="http://energy.referencedata.eu/CGM/Frame/AT_Power-Transmission-System"/>
    <!-- Refering the schema spesification that the model confirmes to  -->
    <dcterms:conformsTo rdf:resource="http://entsoe.eu/ns/CIM/RemedialAction-EU/2.2"/>
    <!-- Referencing any dependnet model - this case is the EQ model -->
    <dcterms:references rdf:resource="urn:uuid:a71dd8ab-371a-4106-b344-23ff915c523c"/>
  </md:FullModel>

<!-- Here below is the content of the RA (remedial action) instance data --> 

</rdf:RDF>

The RA model version 20230512T2230Z_APG_CGM-RA.xml is updated with next week model 20230519T2230Z_APG_CGM-RA.xml

{
    "@context": {
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "dcterms": "http://purl.org/dc/terms/",
        "dcat": "http://www.w3.org/ns/dcat#",
        "prov": "http://www.w3.org/ns/prov#",
		"foaf": "http://xmlns.com/foaf/0.1/",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@id": "urn:uuid:216eeb7c-9e7a-454d-bc7a-c24868f01f7e",
    "dcterms:title": "20230519T2230Z_APG_CGM-RA",
    "dcterms:temporal": {
        "@type": "dcterms:PeriodOfTime",
        "dcat:startDate": {
            "@value": "2023-05-19T23:00:00Z",
            "@type": "xsd:dateTime"
        }
    },	
    "dcat:isVersionOf": {
        "@id": "http://energy.referencedata.eu/CGM/Model/APG_CGM-RA",
        "dcterms:title": "APG_CGM-RA",
        "dcterms:identifier": "9237179a-1115-40d4-be41-89ac0b1bc58d"
    },
	"dcat:previousVersion": {
        "@id": "urn:uuid:6e39b3ee-045d-42c0-9f99-2479640080ac",
        "dcterms:title": "20230512T2230Z_APG_CGM-RA"		 
    },
    "@graph": [
        {
 		}	
    ]
}

The same model serialized using CIM XML:

<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF
   xmlns:dcat="http://www.w3.org/ns/dcat#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>

<!--Header -->
  <md:FullModel rdf:about="urn:uuid:216eeb7c-9e7a-454d-bc7a-c24868f01f7e">
  <!-- ID of the Full Model in RDF-->
    <dcterms:title>20230519T2230Z_APG_CGM-RA</dcterms:title>
    <!-- temporal only shown as startDate and endDate using CIM XML -->
    <dcat:startDate>2023-05-19T23:00:00+00:00</dcat:startDate>

    <dcat:isVersionOf rdf:resource="http://energy.referencedata.eu/CGM/Model/APG_CGM-RA"/>
    <dcat:previousVersion rdf:resource="urn:uuid:6e39b3ee-045d-42c0-9f99-2479640080ac"/>
  </md:FullModel>

<!-- Here below is the content of the RA (remedial action) instance data --> 

</rdf:RDF>

The examples above be inline with DCAT-3 version-history
The dcat:version can be used for human consumption in the case where the title is the same between the different versions. Each version will have a unique id and will refere to the same dcat:isVersionOf.
adms:versionNotes are used to inform user about changes that is made from one version to the next.

Insert a new RA that is only valid for 2023-05-20:

{
    "@context": {
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "dcterms": "http://purl.org/dc/terms/",
        "dcat": "http://www.w3.org/ns/dcat#",
        "prov": "http://www.w3.org/ns/prov#",
		"foaf": "http://xmlns.com/foaf/0.1/",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@id": "urn:uuid:83523b72-c63d-4e48-8c42-ebc76e10a99d",
    "dcterms:title": "20230520T2230Z_APG_CGM-RA",
    "dcterms:temporal": {
        "@type": "dcterms:PeriodOfTime",
        "dcat:startDate": {
            "@value": "2023-05-20T23:00:00Z",
            "@type": "xsd:dateTime"
        },
		"dcat:endDate": {
            "@value": "2023-05-21T23:00:00Z",
            "@type": "xsd:dateTime"
        }
    },	
    "dcat:isVersionOf": {
        "@id": "http://energy.referencedata.eu/CGM/Model/APG_CGM-RA",
        "dcterms:title": "APG_CGM-RA",
        "dcterms:identifier": "9237179a-1115-40d4-be41-89ac0b1bc58d"
    },
	"dcat:previousVersion": {
        "@id": "urn:uuid:216eeb7c-9e7a-454d-bc7a-c24868f01f7e",
        "dcterms:title": "20230519T2230Z_APG_CGM-RA"		 
    },
	"dcat:nextVersion": {
        "@id": "urn:uuid:216eeb7c-9e7a-454d-bc7a-c24868f01f7e",
        "dcterms:title": "20230519T2230Z_APG_CGM-RA"		 
    },
    "@graph": [
        {
 		}	
    ]
}

The same model serialized using CIM XML:

<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF
   xmlns:dcat="http://www.w3.org/ns/dcat#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>
  <md:FullModel rdf:about="urn:uuid:83523b72-c63d-4e48-8c42-ebc76e10a99d">
    <dcterms:title>20230520T2230Z_APG_CGM-RA</dcterms:title>
    <dcat:startDate>2023-05-20T23:00:00+00:00</dcat:startDate>
    <dcat:endDate>2023-05-21T23:00:00+00:00</dcat:endDate>
    <dcat:isVersionOf rdf:resource="http://energy.referencedata.eu/CGM/Model/APG_CGM-RA"/>
    <dcat:previousVersion rdf:resource="urn:uuid:216eeb7c-9e7a-454d-bc7a-c24868f01f7e"/>
    <dcat:nextVersion rdf:resource="urn:uuid:216eeb7c-9e7a-454d-bc7a-c24868f01f7e"/>
  </md:FullModel>
  
</rdf:RDF>

The last RA is being replaced with a new one. This should be aligned with DCAT-3 version-replace. The title is the same so dcat.version is added:

{
    "@context": {
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "dcterms": "http://purl.org/dc/terms/",
        "dcat": "http://www.w3.org/ns/dcat#",
        "prov": "http://www.w3.org/ns/prov#",
	"adms": "http://www.w3.org/ns/adms#",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@id": "urn:uuid:5d2a586c-6aa0-40bb-9acb-2a19b70e5fd1",
    "dcterms:title": "20230520T2230Z_APG_CGM-RA",
    "dcat:isVersionOf": {
        "@id": "http://energy.referencedata.eu/CGM/Model/APG_CGM-RA",
        "dcterms:title": "APG_CGM-RA",
        "dcterms:identifier": "9237179a-1115-40d4-be41-89ac0b1bc58d"
    },
	"dcterms:replaces": {
        "@id": "urn:uuid:216eeb7c-9e7a-454d-bc7a-c24868f01f7e",
        "dcterms:title": "20230520T2230Z_APG_CGM-RA"		 
    },
	"dcat:version": "1.1.0",
	"adms:versionInfo": [
        {"@value": "One new RA was added to the set.", "@language":"en"},
        {"@value": "En til RA ble lagt til settet.", "@language":"no"}
    ] ,
    "@graph": [
        {
 		}	
    ]
}

The same model serialized using CIM XML:

<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF
   xmlns:adms="http://www.w3.org/ns/adms#"
   xmlns:dcat="http://www.w3.org/ns/dcat#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>
  <md:FullModel rdf:about="urn:uuid:5d2a586c-6aa0-40bb-9acb-2a19b70e5fd1">
    <dcterms:title>20230520T2230Z_APG_CGM-RA</dcterms:title>
    <dcat:isVersionOf rdf:resource="http://energy.referencedata.eu/CGM/Model/APG_CGM-RA"/>
    <dcterms:replaces rdf:resource="urn:uuid:216eeb7c-9e7a-454d-bc7a-c24868f01f7e"/>
    <dcat:version>1.1.0</dcat:version>
    <adms:versionInfo xml:lang="en">One new RA was added to the set.</adms:versionInfo>
    <adms:versionInfo xml:lang="no">En til RA ble lagt til settet.</adms:versionInfo>
  </md:FullModel>

</rdf:RDF>

Use both name and UUID as resolvable reference

The reference data for SynchronousMachine.operatingMode is in Turle:

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix nc: <http://entsoe.eu/ns/nc#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

<http://energy.referencedata.eu/PropertyReference/SynchronousMachine.operatingMode> a <http://iec.ch/TC57/CIM100#PropertyReference>,
        skos:Concept ;
    nc:PropertyReference.mRID "1d3bb064-b765-4d06-992a-70f1ce3d0bd4" ;
    nc:PropertyReference.name "SynchronousMachine.operatingMode" ;
    dcterms:identifier "urn:uuid:1d3bb064-b765-4d06-992a-70f1ce3d0bd4" ;
    skos:definition "Current mode of operation." ;
    skos:inScheme "http://energy.referencedata.eu/PropertyReference" ;
    skos:prefLabel "SynchronousMachine.operatingMode" ;
    skos:topConceptOf "http://energy.referencedata.eu/PropertyReference" .

Only http://energy.referencedata.eu/PropertyReference/SynchronousMachine.operatingMode is resolvable should http://energy.referencedata.eu/PropertyReference/[SynchronousMachine.operatingMode](urn:uuid:1d3bb064-b765-4d06-992a-70f1ce3d0bd4) also be resolvable.

Area and Area Function

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.