sveino / nordic44 Goto Github PK

Synthetic Power System of the Nordic high voltage transmission System

License: Other

nordic44's Introduction

Nordic44

Introduction

This is the repository for the Nordic44, that is a synthetic power system model of the Nordic high voltage transmission system, described in IEC Common Information Model (CIM) .

Purpose

The main objective of Nordic44 is to provide the necessary CIM model information to simulation business and application processes and information exchanges relevant for the Nordic electrical power grid.

Relevant business function that the model aim to support are:

Network Operation (NO)
Emergency Simulation (ES)
Engineering Design Management (EDM)
Fault Management (FM)
Network Model Management (NMM)
Predictive Operation Planning (POP)
System Development Planning (SDP)

Relevant application function that the model aim to support are:

Static Power Flow (SPF)
Remedial Action and Contingency Analysis (RACA)
Short-Circuit Analysis (SCA)
Capacity Calculation Analysis (CCA)
Transient Dynamic Stability Analysis (TDSA)
Market information and transparency

Content

Related work

DIGIN10

The Nordic44 is intendent to be created so that it can be merged with the DIGN10 project so that is possible to do analysis accross High Voltage (HV), Medium Voltage (MV) and Low Voltage (LV).

NYPA Model Transformation

A version of Nordic44 has been used in the NYPA Model Transformation. In the repository there are multiple version of Nordic44 and relevant PSSE.

Accreditation

The first released version of the Nordic44 model was published in the following paper, with the following authors: L. Vanfretti, S.H. Olsen, V.S. Narasimham Arava, G. Laera, A. Bidadfar, T. Rabuzin, S. H. Jakobsen, J. Lavenius, M. Baudette and F.J. Gómez-López, “An Open Data Repository and a Data Processing Software Toolset of an Equivalent Nordic Grid Model Matched to Historical Electricity Market Data,” Data in Brief (Elsevier), February 17th 2017. http://dx.doi.org/10.1016/j.dib.2017.02.021 The original PSSE based model was provided by Emil Hillberg at STRI (https://www.stri.se/).

The original Nordic44 model was created to support static power flow and dynamic stability analysis under relevant marked condition for the nordic power system based on the market data published by Nord Pool (https://www.nordpoolgroup.com/en/). It was trained and validated for all electricity market's operation hours during 2015 with power flow and dynamic response. The result was used to train and test Machine Learning techniques (e.g. Decision Trees) and other computational techniques that are essential in the work flows used for dynamic security assessment of electrical power systems.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

nordic44's People

Contributors

Stargazers

Watchers

nordic44's Issues

remove values like `other`

<urn:uuid:9b669974-9309-43ea-bab4-013376a79e3b>
        rdf:type                       cim:Asset ;
        cim:Asset.kind                 <http://iec.ch/TC57/2013/CIM-schema-cim16#AssetKind.other> ;
        cim:IdentifiedObject.name      "TC201 Tap Changer" .

IMHO AssetKind.other is useless because it does not provide any info, and should be removed

is namespace CIM-schema-cim16 intended?

The main namespace is <http://iec.ch/TC57/CIM/CIM100#>, but many files also refer to <http://iec.ch/TC57/2013/CIM-schema-cim16#> (I think only for objects, not subjects or props).

Here's a count per file:

# grep -cr cim16 *|grep -Ev ":0|.ttl"
CDPSM_2_0/Nordic44_02_OPA-OPB_ElectricalProperties.xml:1
CDPSM_2_0/Nordic44_03_Asset.xml:15
CDPSM_2_0/Nordic44_03_Common_ElectricalProperties.xml:8
CDPSM_2_0/Nordic44_03_inc.xml:2
CDPSM_2_0/Nordic44_03_OPA_ElectricalProperties.xml:1
CDPSM_2_0/Nordic44_03_OPB_ElectricalProperties.xml:10
CDPSM_2_0/Nordic44_07_AssetCatalogue.xml:12
CGMES_2_4/Nordic44_CGM_36d_SSH.xml:113
CGMES_2_4/Nordic44_CGM_36e_DL.xml:6
CGMES_2_4/Nordic44_CGM_36f_GL.xml:2
CGMES_2_4/Nordic44_CGM_36g_SV.xml:2
CGMES_2_4/Nordic44_CGM_36g_TP.xml:2
CGMES_2_4/Nordic44_CGM_37a_EQ.xml:306

Add GeoJSON(-LD)

Investigate the possibility to use GeoJSON(-LD) as a replacement for GeographicalLocationProfile described in IEC 61968-13:2021.

We would to use JSON-LD since this could be the first step to create IEC 61970-553 that describe how JSON-LD should be used for exchanging RDFS based profiles (IEC 61970-450-series and IEC 61968-13).

We would also like to be complaint with the latest version of GeoSparql v1.1:
https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html
Relevant issue: opengeospatial/ogc-geosparql#1
https://www.ogc.org/standards/geosparql

Best practice: https://www.w3.org/TR/sdw-bp/

JSON-LD 1.1: https://www.w3.org/TR/json-ld11/
JSON-LD test site:
https://json-ld.org/playground/

The GeoJSON Format: https://datatracker.ietf.org/doc/rfc7946/
A Uniform Resource Identifier for Geographic Locations ('geo' URI): https://datatracker.ietf.org/doc/html/rfc5870

Schema.org: https://schema.org/GeospatialGeometry

Header information should be based on Data Catalog Vocabulary (DCAT) - Version 3: https://www.w3.org/TR/vocab-dcat-3/

Map test site:
https://azuremapscodesamples.azurewebsites.us/?sample=Drag%20and%20Drop%20GeoJSON%20File%20onto%20Map
http://geojson.io/#map=2/20.0/0.0

Relevant examples:
https://docs.ogc.org/is/17-003r2/17-003r2.html

GraphDB:
https://graphdb.ontotext.com/documentation/10.0/geo-spatial-extensions.html

problems with Nordic44-30-HV1_GL.geojson

I converted Nordic44-30-HV1_GL.geojson to nquads at https://json-ld.org/playground/,
saved as Nordic44-30-HV1_GL.nt
made file prefixes.ttl because nquads doesn't retain prefixes:

@prefix geojson: <https://purl.org/geojson/vocab#>.
@prefix cim: <http://iec.ch/TC57/CIM100#>.
@prefix nc: <http://entsoe.eu/ns/nc#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix dct: <http://www.w3.org/ns/dcat#>.
@prefix prov: <http://www.w3.org/ns/prov#>.

converted to Nordic44-30-HV1_GL.ttl :

cat prefixes.ttl Nordic44-30-HV1_GL.nt | riot --syntax ttl --formatted=ttl >Nordic44-30-HV1_GL.ttl

Problems:

name it .jsonld rather than .geojson because it's first and foremost JSONLD, even though it also carries geo info
WARN riot :: [line: 29, col: 89] Lexical form '2022-07-11T17:20:00' not valid for datatype XSD date
the prefix "dct": "http://www.w3.org/ns/dcat#" is misspelt: later you use dcat, which results in an invalid URL like <dcat:version>
the prop <dcterm:created> is misspelt: you've defined prefix dcterms. However, I strongly suggest you switch to the shorter dct, which is more commonly used
there are 5 URLs eg "https://statnett.no/Nordic44/HV1/GL" that are rendered as strings. Render them as URLs, eg <https://statnett.no/Nordic44/HV1/GL>
dcterms:LocationPeriodOrJurisdictionis a class not a property (the property is dct:coverage). But you better use the more specific propertydct:spatial`

Most importantly: you use https://github.com/geojson/geojson-ld to attach geo regions to assets, eg:

<urn:uuid:1c46e73d-6333-48ac-9367-1610caf1d3df>
        cim:IdentifiedObject.description
                "Right-of-Way Kristiansand Arendal" ;
        cim:IdentifiedObject.name  "RoW 300KRISTIAN-ARENDAL" .

<urn:uuid:ce9450ba-f145-4a83-bcbb-cc9098f4fa23>
        rdf:type            geojson:Feature ;
        geojson:geometry    [ rdf:type geojson:MultiPolygon ; geojson:coordinates (list of lists)
        geojson:properties  [ nc:RightOfWay  <urn:uuid:1c46e73d-6333-48ac-9367-1610caf1d3df> ] .

There are numerous problems with this approach:

this is a non-standard way by "Sean Gillies" and a few other guys. It's not an OGC standard.
It doesn't conform to OGC GeoSPARQL. GeoSPARQL 1.1 includes GeoJSON literals (https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#_a_3_4_geojson_serialization), but not in the way you've use GeoJSON
Capturing coordinates as a list of lists doesn't facilitate indexing by repositories, and doesn't enable any region algebra operations (eg touches, intersects, within...). Please express coordinates as ^^geo:asWKT literals, which is one of the ways mandated by GeoSPARQL (the other is asGML)
How would one know what to look for in geojson:properties to find the related asset?
Why are these properties spelled with leading capital?

dangling reference TransformerTankInfo

Nordic44_07_AssetCatalogue.ttl:

<urn:uuid:bdeebee8-9178-40a1-993d-571c47209f4d>
        rdf:type                       cim:TransformerEndInfo ;
        cim:IdentifiedObject.name      "TEI S Transformer End Secondary" ;
        cim:TransformerEndInfo.TransformerTankInfo
                <urn:uuid:3ac55233-7ca0-4b39-afc1-d6f777fc3c0e> ;

<urn:uuid:be53e1d0-1147-44af-b624-77c9ff829bb4>
        rdf:type                       cim:TransformerTankInfo , cim:TransformerEndInfo ;
        cim:IdentifiedObject.name      "TTI Transformer Tank" , "TEI P Transformer End Primary" ;
        cim:TransformerEndInfo.TransformerTankInfo
                <urn:uuid:3ac55233-7ca0-4b39-afc1-d6f777fc3c0e> ;

<urn:uuid:3ac55233-7ca0-4b39-afc1-d6f777fc3c0e> doesn't appear anywhere else, so it is undefined?
aren't property names supposed to start in lowercase?
why the second subject has two types cim:TransformerTankInfo , cim:TransformerEndInfo? I think the first type is wrong

missing datatypes

Take a look e.g. at this node:

<file:///d:/Onto/proj/Nordic44/Instances/CGMES_2_4/Nordic44_CGM_36d_SSH.xml#_f176999f-9aeb-11e5-91da-b8763fd99c5f>
        rdf:type                     cim:SynchronousMachine ;
        entsoe2:Equipment.inService  "true" ;
        cim:RegulatingCondEq.controlEnabled "true" ;
        cim:RotatingMachine.p        "-611.6982" ;
        cim:RotatingMachine.q        "-131.620667" ;
        cim:SynchronousMachine.operatingMode cim:SynchronousMachineOperatingMode.generator ;
        cim:SynchronousMachine.referencePriority "0" .

It includes literals that don't have proper datatypes.

I'd assume these are appropriate datatypes

<file:///d:/Onto/proj/Nordic44/Instances/CGMES_2_4/Nordic44_CGM_36d_SSH.xml#_f176999f-9aeb-11e5-91da-b8763fd99c5f>
        rdf:type                     cim:SynchronousMachine ;
        entsoe2:Equipment.inService  "true"^^xsd:boolean ;
        cim:RegulatingCondEq.controlEnabled "true"^^xsd:boolean ;
        cim:RotatingMachine.p        "-611.6982"^^xsd:decimal ;
        cim:RotatingMachine.q        "-131.620667"^^xsd:decimal ;
        cim:SynchronousMachine.operatingMode cim:SynchronousMachineOperatingMode.generator ;
        cim:SynchronousMachine.referencePriority "0"^^xsd:integer .

bad relative URLs

All XML files use node IDs like rdf:ID="_f1769b90-9aeb-11e5-91da-b8763fd99c5f".
These are fragment URLs relative to the file location.
Because xml:base is not set, they end up as random URLs depending on where the file is placed, eg:

<file:///d:/Onto/proj/Nordic44/Instances/CGMES_2_4/Nordic44_CGM_37a_EQ.xml#_393332ba-86c3-4257-b77b-006e41b78a71>
        rdf:type                   cim:OperationalLimitSet ;
        entsoe2:OperationalLimitSet.RateTemperature
                <file:///d:/Onto/proj/Nordic44/Instances/CGMES_2_4/Nordic44_CGM_37a_EQ.xml#_92e7d859-88ee-49ed-8a3e-9a7a1464c196> ;
        cim:IdentifiedObject.description
                "OperationalLimitSet 15 degree Celsius" ;
        cim:IdentifiedObject.name  "OLS_15dg_5101_5103_1" ;
        cim:OperationalLimitSet.Equipment
                <file:///d:/Onto/proj/Nordic44/Instances/CGMES_2_4/Nordic44_CGM_37a_EQ.xml#_f1769bc0-9aeb-11e5-91da-b8763fd99c5f> .

Add support for temperature dependent limits

As part of Statnett change request to get support for dynamic line rating.

8.1 Calculating the OperationalLimits based on temperature
The Operational Limits calculated with the temperature-based method should be allocated to the same OperationalLimitSets that is exported in the EQ, that does not have an association to RateTemperature and is not linked to Auxiliary Equipment. The OperationalLimitSets' OperationalLimits is updated with the calculated value. Operational Limits could be any or several of the following types: VoltageLimit, CurrentLimit, ApparentPowerLimit and ActivePowerLimit. The OperationalLimits' OperationalLimitType could be of any of the LimitTypes specified in QoCDC 3.3.

8.2 Equipment (EQ) export
The EQ export should only contain the OperationalLimitSets without association to Rate Temperature, and without a link to Auxiliary Equipment. These should be the same OperationalLimitSets that is used by the Seasonal Limits method. It shall export all related OperationalLimits to these OperationalLimitSets.

8.3 Steady State Hypothesis (SSH) export
Add the possibility to enable/disable the inclusion of Operational Limits in the SSH. This is not a must requirement.
The SSH export file should include the update of the Operational Limits referring to the same OperationalLimit that is in the EQ. Therefore, the Operational Limits will be rdf:about. All the condition A, B and C limits shall be exported.

8.4 Operational Limits in an EQ-diff instance file
Add the possibility to enable/disable the creation and export of an EQ-diff instance file for the Operational Limits change, per MTU.
The Operational Limit EQ-diff instance export file shall remove (reverse differences) the values of the Operational Limits in the EQ export and replace them (forward differences) with the values that has been calculated based on the temperature-based method. All the condition A, B and C limits shall be exported.

8.5 File reference dependency
The file header depending on shall follow the instruction in Figure 6. If the EQ-diff instance file is produced, the header in the SSH "DependingOn" needs to point to the EQ-diff file rather than the EQ file.

Figure: File dependency

EIC linked data publication?

Nordic44-30-HV1_GL.geojson uses <urn:eic:10X1001A1001A38Y> for Statnett.
I saw this URN scheme was registered by IANA in Dec 2021: https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
This is great since it allows to make semantic statements directly about this EIC.
More statements should be made: all the info from the EIC XML file.

Furthermore, URN are worse than URLs because you cannot resolve them to obtain information.
It would be great if ENTSOE would publish EIC data as individual per-EIC pages and semantic formats (eg Turtle, JSON-LD).

Eg here's the data we have at https://transparency.ontotext.com/graphdb/sparql about Statnett (ask me for login and password if interested).
The same data is available at https://transparency.ontotext.com/resource/eic/10X1001A1001A38Y .

@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> .

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:

tr:vatNumber was missing the prefix "NO" whereas most other participant VATs have a country code prefix. We added it using a simple data correction rule.
According to patterns we have, "7080000923168" is not a valid VAT for NO. That is confirmed by NO BRREG, Wikidata and OpenCorporates, the valid VAT is "962986633":

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

For more details:

Transparency EKG Requirements Specification, Architecture and Semantic Model, https://transparency.ontotext.com/spec/
Advanced SHACL Data Validation for the Transparency Energy KG (https://docs.google.com/presentation/d/1Hhxmx2YDnaxlaU5KeafjRJSDlVgHRz1z/edit, https://youtu.be/4JGSui7Uq_Y)

Add JSON-LD Example

Investigate the possibility to JSON-LD as an alternative serialization format to CIMXML, IEC 61970-552, that can for the start of the development of IEC 61970-553 that describe how JSON-LD should be used for exchanging RDFS based profiles (IEC 61970-450-series and IEC 61968-13).

JSON-LD 1.1: https://www.w3.org/TR/json-ld11/
JSON-LD test site:
https://json-ld.org/playground/

Header information should be based on Data Catalog Vocabulary (DCAT) - Version 3: https://www.w3.org/TR/vocab-dcat-3/

some literals that should be URLs

The following literals should be expressed as URLs:

<urn:uuid:eb4d92e6-d4da-11e7-9296-cec278b6b50a>
        fw:FrameworkIdentifiedObject.modelAuthority                "http://www.Statnett.no/Asset/Nordic44_CDPSM" ;
        fw:Model.profile             "http://iec.ch/TC57/CIM/Asset/2/0" , "http://iec.ch/TC57/CIM/AssetCatalogue/2/0" , "http://iec.ch/TC57/CIM/ElectricalProperties/2/0" ;

<urn:uuid:392035c0-730e-4408-bae1-17a4ea313b2f>
        fw:ModelSpecification.ontology  "http://entsoe.eu/CIM/CGMES/2/5#" ;

no connection of CIM nodes to model

If you convert Nordic44_CGM_36d_SSH.xml to ttl, you see this:

<urn:uuid:1d8b61bc-c7f3-4e9e-a3bd-f4ec24beb586>
        rdf:type                       md:FullModel ;
        md:Model.DependentOn           <urn:uuid:2dd9014f-bdfb-11e5-94fa-c8f73332c8f4> ;
        md:Model.created               "2017-11-24T09:03:09.9446768Z" ;
        md:Model.description           "CGM Test model developed by Statnett SF. Nordic 44 bus system for the Nordic region" ;
        md:Model.modelingAuthoritySet  "http://www.Statnett.no/IGM/Nordic44_CGM" ;
        md:Model.profile               "http://entsoe.eu/CIM/SteadyStateHypothesis/1/1" , "http://entsoe.eu/CIM/SteadyStateHypothesis/1/2" ;
        md:Model.scenarioTime          "2015-03-06T01:30:00.0000000Z" ;
        md:Model.version               "36" ;
        pti:Model.createdBy            "Statnett SF" .

<file:///d:/Onto/proj/electrical/Nordic44/Instances/CGMES_2_4/Nordic44_CGM_36d_SSH.xml#_e2f56599-a78e-494f-8db3-c0b0bdab1d70>
        rdf:type                    cim:Terminal ;
        cim:ACDCTerminal.connected  "true" .

CIM nodes use relative URLs, which is bad (#5)
The model uses a URN. This is ok, although a resolvable URL is better
Most importantly, there's no relation between CIM nodes and the model whatsoever.
The fact that you've put them in one file doesn't matter a bit.
If you load this file to a repo, these triples will be mixed with millions of other triples. losing all connection

One way to solve this is:

use named graphs, where the model URN is also the graph name (URN)
load all triples into that graph (the model triples could be inside or outside of the graph, depending on needs)

You could express this in TriG as follows (also fixed the relative URL to a URN):

graph <urn:uuid:1d8b61bc-c7f3-4e9e-a3bd-f4ec24beb586> {
  <urn:uuid:1d8b61bc-c7f3-4e9e-a3bd-f4ec24beb586>
        rdf:type                       md:FullModel ;
        md:Model.DependentOn           <urn:uuid:2dd9014f-bdfb-11e5-94fa-c8f73332c8f4> ;
        md:Model.created               "2017-11-24T09:03:09.9446768Z" ;
        md:Model.description           "CGM Test model developed by Statnett SF. Nordic 44 bus system for the Nordic region" ;
        md:Model.modelingAuthoritySet  "http://www.Statnett.no/IGM/Nordic44_CGM" ;
        md:Model.profile               "http://entsoe.eu/CIM/SteadyStateHypothesis/1/1" , "http://entsoe.eu/CIM/SteadyStateHypothesis/1/2" ;
        md:Model.scenarioTime          "2015-03-06T01:30:00.0000000Z" ;
        md:Model.version               "36" ;
        pti:Model.createdBy            "Statnett SF" .

  <urn:uuid:e2f56599-a78e-494f-8db3-c0b0bdab1d70>
        rdf:type                    cim:Terminal ;
        cim:ACDCTerminal.connected  "true" .
}

problems converting xml files to turtle

I tried to convert the xml files to turtle:

# cd CGMES_2_4
# riot --formatted=turtle Nordic44_CGM_36f_MF.xml  1>Nordic44_CGM_36f_MF.ttl
19:03:13 WARN  riot            :: [line: 8, col: 31] {W119} A processing instruction is in RDF content. No processing was done.
## this is at <?iec61970-552 version="2.0"?>

# riot --formatted=turtle Nordic44_CGM_38_CO.xml  1>Nordic44_CGM_38_CO.ttl
19:03:19 ERROR riot            :: [line: 8, col: 2 ] Element type "rdf:RDF" must be followed by either attribute specifications, ">" or "/>".
## this is at   <!-- Header namespace -->. You cannot include comments in the middle of attributes

# cd ../CDPSM_2_0
## ALL files return this error:
19:07:55 WARN  riot            :: [line: 2, col: 31] {W119} A processing instruction is in RDF content. No processing was done.

# riot --formatted=turtle Nordic44_03_inc.xml  1>Nordic44_03_inc.ttl
19:07:55 WARN  riot            :: [line: 22, col: 37] {W107} Bad URI: <http:://iec.ch/TC57/61970-552/DifferenceModel/1#DifferenceModel> Code: 57/REQUIRED_COMPONENT_MISSING in HOST: A component that is required by the scheme is missing.
19:07:55 WARN  riot            :: [line: 23, col: 57] {W107} Bad URI: <http:://iec.ch/TC57/61970-552/DifferenceModel/1#reverseDifferences> Code: 57/REQUIRED_COMPONENT_MISSING in HOST: A component that is required by the scheme is missing.
19:07:55 WARN  riot            :: [line: 30, col: 57] {W107} Bad URI: <http:://iec.ch/TC57/61970-552/DifferenceModel/1#forwardDifferences> Code: 57/REQUIRED_COMPONENT_MISSING in HOST: A component that is required by the scheme is missing.
## the problem is the double colon

19:07:55 WARN  riot            :: [line: 23, col: 57] {W106} Unknown rdf:parseType: 'Statements' (treated as 'Literal'.
19:07:55 WARN  riot            :: [line: 30, col: 57] {W106} Unknown rdf:parseType: 'Statements' (treated as 'Literal'.
# the problem is that rdf:parseType: 'Statements' is a non-standard CIM invention

Such statements are captured as rdf:XMLLiteral rather than RDF, eg:

dm:forwardDifferences  "\n\t  \t\t<cim:OperatingShare xmlns:cim=\"http://iec.ch/TC57/CIM/CIM100#\"
 xmlns:rdf=\"http://www.w3.org/1999/02/22-rdf-syntax-ns#\" 
rdf:about=\"urn:uuid:85e930e3-5409-4f2a-b343-5fd271d1a348\">\n\t\t\t\t
<!--Operating Participant B -->\n\t\t\t\t
<cim:OperatingShare.OperatingParticipant rdf:resource=\"urn:uuid:18e06751-54c1-44c8-86d9-0e9f5f358289\">
</cim:OperatingShare.OperatingParticipant>\n\t\t\t
</cim:OperatingShare>  \n\t  \n      "^^rdf:XMLLiteral