Skip to content

Simplified RDF syntax

General

RDF syntax provides many ways to represent the same set of data. For example, an association between two resources can be written with a resource attribute or by nesting one element within another. This could make it difficult to use some XML tools, such as XSL processors, with the CIMXML document.

Therefore, only a subset of the RDF Syntax is to be applied in creating CIMXML documents. This syntax simplifies the work of implementers to construct model serialization and deserialization software, as well as to improve the effectiveness of general XML tools when used with CIMXML documents.

Notation

Each kind of element is defined in a subclause beginning with a model of the element, followed by some defining text, and a reference to the RDF grammar.

The notation for the element model is as follows:

  1. A symbol in italics in the position of an element type, attribute name or attribute value indicates the type of name or value required. The symbol will be defined in the text.
  2. The symbol rdf stands for whatever namespace prefix is chosen by the implementation for the RDF namespace. Similarly the symbol cim stands for the chosen CIM namespace prefix.
  3. A comment () within the element model indicates the allowed content.
    • A symbol in italics stands for a kind of element or other content defined in the text.
    • A construction (a | b) indicates that a and b are alternatives.
    • A construction a* indicates zero or more repetitions of a.
  4. All other text in the model is literal.

Syntax definition (normative)

General

The syntax definition is enriched with examples. The examples should help to get a better understanding of the formal syntax definition. The same example is used for several syntax definitions.

UTF-8 is the standard for file encoding. UTF-16 is not supported.

Name space URIs defined in this specification

The following name spaces are defined in this specification:

  • cim-model-description_uri described by xmlns:md
  • difference-model-namespace-uri described by xmlns:dm

Their values are defined as:

  • xmlns:md="http://iec.ch/TC57/61970-552/ModelDescription/1#"
  • xmlns:dm="http://iec.ch/TC57/61970-552/DifferenceModel/1#"

Document element

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cim="cim-namespace-uri" xmlns:md="cim-model-description_uri" xml:base="urn:uuid:">
    <!-- Content: full-model (definition|description)* -->
</rdf:RDF>

Example:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cim="http://iec.ch/TC57/2004/CIM-schema-cim10#" xmlns:md="http://iec.ch/TC57/61970-552/ModelDescription/1#" xml:base="urn:uuid:">
    <md:FullModel rdf:about="urn:uuid:26cc8d71-3b7e-4cf8-8c93-8d9d557a4846">
    <md:Model.created>2008-12-24T03:19:13</md:Model.created>
    <md:Model.Supersedes rdf:resource="urn:uuid:26cc8d71-3b7e-4cf8-8c93-8d9d557a4847"/>
    <md:Model.DependentOn rdf:resource="urn:uuid:26cc8d71-3b7e-4cf8-8c93-8d9d557a4848"/>
    <md:Model.version>32</md:Model.version>
    <md:Model.modelingAuthoritySet>http://polarenergy.com/2008/NorthPoleTSO</md:Model.modelingAuthoritySet>
    <md:Model.description>Santa Claus made a study case peak load summer base topology solution</md:Model.description>
    <md:Model.profile>http://iec.ch/TC57/61970-452/Equipment/1</md:Model.profile>
    <md:Model.profile>http://iec.ch/TC57/61970-452/EquipmentShortCircuit/1</md:Model.profile>
</md:FullModel>
 …
</rdf:RDF>
  1. The element type is rdf:RDF.
  2. The RDF namespace must be declared as http://www.w3.org/1999/02/22-rdf-syntax-ns#.
  3. The CIM namespace must be declared. With newer versions of the CIM schema the version needs to be adjusted in the CIM name space. Parties exchanging documents have to agree on the used version.
  4. Other namespaces may be declared.
  5. The full model header element appears before the full model definition/description elements.

Full-model element

<md:FullModel rdf:about=model-uri>
    <!-– Content: (literal-property|resource-property|compoundproperty)* –->
</md:FullModel >

Example:

<md:FullModel rdf:about="urn:uuid:26cc8d71-3b7e-4cf8-8c93-8d9d557a4846">
    <md:Model.created>2008-12-24T03:19:13</md:Model.created>
    <md:Model.Supersedes rdf:resource="urn:uuid:26cc8d71-a002-4c2b-bcf4-7bc97430bf87"/>
    <md:Model.DependentOn rdf:resource="urn:uuid:26cc8d71-a002-4c2b-bcf4-7bc97430bf88"/>
    <md:Model.version>32</md:Model.version>
    <md:Model.modelingAuthoritySet>http://polarenergy.com/2008/NorthPoleTSO</md:Model.modelingAuthoritySet>
    <md:Model.description>Santa Claus made a study case peak load summer base topology solution</md:Model.description>
    <md:Model.profile>http://iec.ch/TC57/61970-456/StateVariables/1</md:Model.profile>
</md:FullModel>
  1. The full model element introduces a new model.
  2. The value of the about attribute, model-uri, is a name chosen by the implementation. The model-uri uniquely identifies a document and is the name referenced by other documents
  3. The FullModel rdf:about attribute identifies a CIMXML document.

Definition element

<classname rdf:ID=identity>
    <!–- Content:
    (literal-property|resource-property|compound-property)*
    -->
</classname>
<classname rdf:about=resource-uri>
    <!–- Content:
    (literal-property|resource-property|compound-property)*
    -->
</classname>

Example:

<cim:SynchronousMachine rdf:about="#_31dcf429-6bfb-4e2e-b2996-42491b3abc1">
    <cim:IdentifiedObject.name>IN-2</cim:IdentifiedObject.name>
    <cim:SynchronousMachine.minimumMVAr>-9999</cim:SynchronousMachine.minimumMVAr>
    <cim:SynchronousMachine.operatingMode rdf:resource="http://iec.ch/TC57/2001/CIMschema-cim10#SynchronousMachineOperatingMode.generator"/>
    <cim:RegulatingCondEq.RegulationSchedule rdf:resource="#_ca32746f-a002-4c2bbcf4-7bc97430bf87"/>
    <cim:Equipment.EquipmentContainer rdf:resource="#_6cb8701a-12f1-4de9-9e68-125d95073a75"/>
</cim:SynchronousMachine>
  1. The definition element introduces a new resource and gives its type. There are two forms: the first as an rdf:ID attribute and the second as an rdf:about attribute.
  2. The element type, classname, is the XML qualified name of a class from the CIM schema or other schema declared as a namespace in the document element.
  3. The value of the id attribute, identity, is chosen by the implementation. It must be unique in the document. (It is not necessarily related to the power system resource name.) Typically, it is a UUID.
  4. A Definition element with the same identification may appear in different documents. The meaning of this is that the properties in the different documents describe the same object and that the description is split over multiple documents. This is the case when data for a class is divided in multiple profiles and each profile is exchanged as its own CIMXML document.

Description element

<rdf:Description rdf:about=resource-uri>
    <!–- Content:
    (literal-property | resource-property | compound-property)*
    -->
</rdf:Description>

Example:

<rdf:Description rdf:about="#_26cc8d71-a002-4c2b-bcf4-7bc97430bf87">
    <cim:IdentifiedObject.name>TROY</cim:IdentifiedObject.name>
</rdf:Description>
  1. The description element adds information about a resource introduced elsewhere in this or another document.
  2. The resource-uri is a URN-reference that identifies the subject resource.
  3. The Description element is used only in difference models. It is never used in full models.
  4. A Description element with the same identification may appear in different documents. The meaning of this is that the properties in the different documents describe the same object and that the description is split over multiple documents. This is the case when data for a class is divided in multiple profiles and each profile is exchanged as its own CIMXML document.

Compound element

<classname>
    <!–- Content:
    (literal-property | resource-property | compound-property)*
    -->
</classname>

Example:

<cim:DateTimeInterval>
    <cim:DateTimeInterval.start>2013-02-28</cim:DateTimeInterval.start>
    <cim:DateTimeInterval.end>2013-02-29</cim:DateTimeInterval.end>
</cim:DateTimeInterval>
  1. The compound element introduces a structured value. The value does not represent a resource nor have any identity. It can only appear as the object of a property.
  2. The element type, classname, is the XML qualified name of a compound class.
  3. A compound element is treated as an indivisible unit. Hence a compound element is not supposed to be split in multiple elements having different sets of members.
  4. A compound element is always part of another element and cannot be a root element.

Compound-Property element

<propname>
    <!–- Content: (compound-element) -->
</propname>

Example:

<cim:TimeSchedule>
    <cim:TimeSchedule.scheduleInterval> <!-- the compound property -->
         <cim:DateTimeInterval> <!-- another compound element -->
             <cim:DateTimeInterval.start>2013-02-28</cim:DateTimeInterval.start>
             <cim:DateTimeInterval.end>2013-02-29</cim:DateTimeInterval.end>
         </cim:DateTimeInterval>
    </cim:TimeSchedule.scheduleInterval>
</cim:TimeSchedule>
  1. The compound property element contains a compound element.
  2. As a compound element may contain compound properties an indefinitely deep hierarchy is possible.
  3. A Compound-Property element with the same propname may appear multiple times if the cardinality of the corresponding schema attribute is larger than 1.

Literal-Property element

<propname>
    <!–- Content: text --> 
</propname>

Example:

<cim:SynchronousMachine rdf:about="#_31dcf429-6Bfb-4e2e-b2996-42491b3abc1">
    <cim:IdentifiedObject.name>IN-2</cim:IdentifiedObject.name>
    <cim:SynchronousMachine.minimumMVAr>-9999</cim:SynchronousMachine.minimumMVAr>
    <cim:SynchronousMachine.operatingMode rdf:resource="http://iec.ch/TC57/2001/CIMschema-cim10#SynchronousMachineOperatingMode.generator"/>
    <cim:RegulatingCondEq.RegulationSchedule rdf:resource="#_ca32746f-a002-4c2bbcf4-7bc97430bf87"/>
    <cim:Equipment.EquipmentContainer rdf:resource="#_6cb8701a-12f1-4de9-9e68-125d95073a75"/>
</cim:SynchronousMachine>
  1. The literal-property element introduces a property and a literal value applying to the enclosing resource.
  2. The element type, propname, is the XML qualified name of a property from the CIM schema or other schema declared as a namespace in the document element.
  3. The content text is any XML text with <, >, and & escaped representing the value of the property.
  4. Floating point numbers may slightly change due to rounding effects when imported and reexported again. This is allowed and need to be managed by applications, e.g. by use of a dead band in case the values are compared.
  5. A Literal-Property element with the same propname may appear multiple times if the cardinality of the corresponding schema attribute is larger than 1.

Resource-Property element

<propname rdf:resource=resource-uri/>
  1. The resource-property element introduces a property and a resource as its value applying to the enclosing resource.
  2. The element type, propname, is the XML qualified name of a property from the CIM schema or other schema declared as a namespace in the document element.
  3. The resource-uri is an URN-reference that identifies a resource.
  4. For relations with roles having cardinality greater than one the resource property element shall be repeated as many times as there are references
  5. An association in a schema is bidirectional and has two roles (ends). Including ResourceProperty elements for both roles is allowed but preferably elements for one side only is included. Then the side with the lowest cardinality is preferred but not required.
  6. A Resource-Property element with the same propname may appear multiple times if the cardinality of the corresponding schema role is larger than 1.

Example 1 – URN-Reference:

The example contains two references one for a RegulationSchedule and the other to the parent represented as EquipmentContainer.

<cim:SynchronousMachine rdf:about="#_31dcf429-6bfb-4e2e-b299-642491b3abc1">
    <cim:IdentifiedObject.name>IN-2</cim:IdentifiedObject.name>
    <cim:SynchronousMachine.minimumMVAr>-9999</cim:SynchronousMachine.minimumMVAr>
    <cim:SynchronousMachine.operatingMode rdf:resource="http://iec.ch/TC57/2001/CIMschema-cim10#SynchronousMachineOperatingMode.generator"/>
    <cim:RegulatingCondEq.RegulationSchedule rdf:resource="#_cd32746f-a002-4c2bbcf4-7bc97430bf87"/>
    <cim:Equipment.EquipmentContainer rdf:resource="#_6cb8701a-12f1-4de9-9e68-125d95073a75"/>
</cim:SynchronousMachine>

Example 2 – Enumeration:

The example defines the attribute value of SynchonousMachine.operatingMode as “generator". The operatingMode is specified in the CIM schema as the enumeration SynchronousMachineOperatingMode.

<cim:SynchronousMachine rdf:about="#_31dcf429-6bfb-4e2e-b2996-42491b3abc1" >
    <cim:IdentifiedObject.name>IN-2</cim:IdentifiedObject.name>
    <cim:SynchronousMachine.minimumMVAr>-9999</cim:SynchronousMachine.minimumMVAr>
    <cim:SynchronousMachine.operatingMode rdf:resource="http://iec.ch/TC57/2001/CIMschema-cim10#SynchronousMachineOperatingMode.generator"/>
    <cim:RegulatingCondEq.RegulationSchedule rdf:resource="#_cd32746f-a002-4c2bbcf4-7bc97430bf87"/>
    <cim:Equipment.EquipmentContainer rdf:resource="#_6cb8701a-12f1-4de9-9e68-125d95073a75"/>
</cim:SynchronousMachine>

Example 3 – Role with cardinality greater than one:

<cim:SynchronousMachine rdf:about="#_31dcf429-6bfb-4e2e-b299-642491b3abc1">
    <cim:IdentifiedObject.name>IN-2</cim:IdentifiedObject.name>
    <cim:SynchronousMachine.minimumMVAr>-9999</cim:SynchronousMachine.minimumMVAr>
    <cim:SynchronousMachine.operatingMode rdf:resource="http://iec.ch/TC57/2001/CIMschema-cim10#SynchronousMachineOperatingMode.generator"/>
    <cim:RegulatingCondEq.RegulationSchedule rdf:resource="#_cd32746f-a002-4c2bbcf4-7bc97430bf87"/>
    <cim:Equipment.EquipmentContainer rdf:resource="#_6cb8701a-12f1-4de9-9e68-125d95073a75"/>
    <cim:Equipment.ReactiveCapabilityCurves rdf:resource="#_6cb8701a-12f1-4de9-9e68-125d95073a76"/>
    <cim:Equipment.ReactiveCapabilityCurves rdf:resource="#_6cb8701a-12f1-4de9-9e68-125d95073a77"/>
    <cim:Equipment.ReactiveCapabilityCurves rdf:resource="#_6cb8701a-12f1-4de9-9e68-125d95073a78"/> 
</cim:SynchronousMachine>

Syntax extension for difference model

General

The general syntax definition in the first part of this clause is used for partial and full model data exchange. Once the initial complete set of model data is exchanged, only updates are required to maintain the model as changes occur. In general, those changes can be specified as a set of differences between two models. The difference document is itself an RDF model (a collection of RDF statements) and therefore can be processed by an RDF infrastructure.

Requirements

Given two RDF models, B1 and B2, called base models, the requirement is for a difference model that:

  • Represents the differences between the two base models.
  • Is itself an RDF model (a collection of RDF statements) and therefore can be processed by RDF infrastructure.
  • Efficiently represents a small difference between two large base models.
  • When an object is deleted, the system applying the differences will not perform any the “cascading deletions", i.e. finding and deleting all other contained objects. Instead it is the responsibility of the system sourcing a deletion to include any cascading deletions.
  • Remove operations are not reversible (at least, not from the information in the difference model)
  • May contain information about itself such as authorship, purpose and date.
  • May contain information to protect against conflicts arising when two difference models are created concurrently from the same base model.

Structure of difference document

Given two base RDF models, B1 and B2, the difference model is made up of four groups of statements, each encoded as a sequence of resource description structures:

  • Forward difference statements, comprising statements found in B2, but not in B1.
  • Reverse difference statements, comprising statements found in B1, but not in B2.
  • Precondition statements, comprising statements found in both B1 and B2 and considered to be dependencies of the difference model in an application defined sense.

Any or all of the three groups can be empty.

The difference model itself is represented by a compound element of type dm:DifferenceModel.

The following properties apply to the difference model resource:

  • dm:forwardDifferences is a property of the difference model whose value is a collection of statements (i.e., resources of type rdf:Statement) representing the forward difference statements.
  • dm:reverseDifferences is a property of the difference model whose value is the collection of reverse difference statements.
  • dm:preconditions is a property of the difference model whose value is the collection of precondition statements.

Header properties also apply to the difference model resource. These may indicate authorship, date and purpose. These properties can be drawn from the Dublin Core vocabulary or any other convenient schema.

The namespace for the difference model vocabulary, represented by the prefix dm: in the foregoing, is: http://iec.ch/TC57/61970-552/DifferenceModel/1#.

Preconditions and concurrency

The precondition statements are a subset of both B1 and B2 and carry no difference information. In simple, sequential model revision scenarios they can be omitted.

For a large shared model, sequential revision is not always feasible. Revisions are likely to be constructed concurrently by different participants, without reference to each other. Concurrency issues must be handled, but the conventional database-oriented approach of using locks to detect incompatible concurrent transactions is not feasible on a web-scale.

The precondition statements are an alternative to locks. Informally, they represent the information that would have been read-locked in an equivalent database transaction. Software agents that process difference models can check that the preconditions hold and, if not, warn of incompatible model revisions.

The choice of statements to include as preconditions is application-specific (as is the choice of which information to lock in a database transaction). Preconditions should include statements that would affect decisions of the agent that produced the model revision.

Difference model template

The following is a template for the conventional syntax of a difference model.

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cim="cim-namespace-uri" xmlns:md="cim-model-description_uri" xmlns:dm="difference-model-namespace-uri" xml:base="urn:uuid:">
<dm:DifferenceModel rdf:about=model-uri>
    <!--Content:(literal-property|resource-property|compound-property)* –->
    <dm:preconditions parseType="Statements">
    <!-– Content: (definition|description)* –->
    </dm:preconditions>
    <dm:forwardDifferences parseType="Statements">
    <!-– Content: (definition|description)* –->
    </dm:forwardDifferences>
    <dm:reverseDifferences parseType="Statements">
    <!-– Content: (definition|description)* –->
    </dm:reverseDifferences>
</dm:DifferenceModel>
</rdf:RDF>
  1. Simply for clarification with the namespace “dm" new statements are introduced that are valid extensions to the standard RDF syntax through the new property rdf:parseType, which is called Statements.
  2. The content model of an element with rdf:parseType="Statements" is the same as the content model of the rdf:RDF element.
  3. The content generates the same RDF statements as if it appeared in an rdf:RDF element.
  4. The DifferenceModel rdf:about attribute identifies a CIMXML document