AAA100 UNIVERSE ITEM_CLASS {AAE001} AAA200 AAA100 ITEM_CLASS {AAE002} Figure 8 – Parcel implementation for simple classification trees 6.3 Reuse of properties, data types and documents
General
This part of IEC 62656 is an application guide for parcel users such as:
– domain experts who implement data parcels for their domain data dictionary, for registration in the IEC CDD online database by parcelling tools,
– users who download a (piece of) data dictionary from the IEC CDD online database,
– users who edit or exchange a (piece of) data dictionary,
– application vendors who develop a parcelling tool, such as an editor, viewer or equivalent
A typical use scenario of the IEC 62656 series for the IEC CDD is depicted in Figure 1
Registering or updating ontological elements to IEC CDD
Defining domain ontological elements Modifying domain ontological elements
Viewing part or whole of IEC CDD
Retrieving part or whole of IEC CDD
For ease of reading of this part of IEC 62656, “parcel” and “attribute” are used instead of
“meta-class” and “meta-property”, respectively For example, “class meta-class” is reworded as “class parcel”.
Data dictionary
ISO/IEC Guide 77-2 recommends that each data dictionary should conform to the
The ISO 13584-42/IEC 61360-2 common dictionary model organizes data dictionaries into classes with associated characteristic properties The IEC CDD serves as a comprehensive database that outlines an ontology for products and services, encompassing essential components, materials, systems, and concepts within the electro-technical sectors.
In a data dictionary, classes and properties serve as essential components A class represents a real-world object, such as a product or material, through a structured data format Conversely, a property characterizes these classes by providing additional descriptive data structures.
IEC 2288/13 defines a class as a collection of characteristic properties that must be distinctly identifiable from other classes If two classes share identical sets of properties, they cannot be differentiated in a machine-readable way However, this approach to class modeling is discouraged in IEC 61360-1.
A superclass is defined as a generalized class that encompasses multiple subclasses sharing common characteristics This relationship, known as an "is-a" relationship, allows each subclass to be categorized under a single superclass, as per the ISO 13584-42/IEC 61360-2 common dictionary model While each class can have one superclass, it may also have multiple subclasses In cases where no clear superclass exists, a universal class is assumed to act as a common superclass Consequently, the relationships among these classes create a tree structure, specifically an acyclic graph.
Shared characteristics among multiple classes are modeled as "properties," which are defined at a general class level and inherited by its subclasses.
Figure 2 gives a simple example of a data dictionary In this figure, the concepts of “Gasoline- powered vehicle” and “Electric vehicle” are two different kinds of vehicles, so their superclass
“Vehicle” may be defined with common properties, i.e those named “product name”,
“manufacturer“ and “tyre” are defined at this level in the class tree Likewise, “Vehicle” and
The superclass "Product" encompasses various computer product concepts, defining common properties such as "product name" and "manufacturer." This structure results in a data dictionary organized in a tree format, as depicted in Figure 2.
Electric vehicle product name manufacturer central processing unit tyre displacement motor power
Code: AAE004 Name: central processing unit Definition: portion of
Definition class: AAA300 Data type: STRING_TYPE Unit:
class property specialization applicable to information field
According to the ISO 13584-42/IEC 61360-2 common dictionary model, every entity is assigned a unique identifier that includes structural information, allowing it to be distinguished from others For instance, a class comprises information fields like name, definition, and superclass, while a property includes fields such as name, definition, definition class, data type, and unit The dashed lines in Figure 2 illustrate examples of the information fields associated with a class and a property.
Data parcel
IEC 62656-1, known as the "parcel standard," establishes a framework for organizing product ontology information into structured data collections These collections include lists of classes, properties, and enumerations, collectively referred to as "data parcels." Each data parcel serves a dual purpose: it can define a data dictionary and represent a library or catalog of products, detailing specific values for individual items.
The main focus of this document is the use of data parcels to represent a product ontology Each data parcel contains a consistent collection of product ontology, typically implemented as a sheet within a spreadsheet, which is commonly used in engineering Throughout this Technical Specification, the term "data parcel" will be referred to as "parcel sheet" to visually illustrate its likely implementation form.
A class parcel, also known as a class meta-class, is designed for creating and instantiating classes, featuring attributes that describe its characteristics, including class code, preferred name, definition, and superclass Similarly, a property parcel, or property meta-class, is intended for designing properties and includes attributes that detail property information such as property code, preferred name, definition, definition class, data type, and unit To effectively implement a data dictionary within homogeneous data collections in parcels, it is essential to prepare several spreadsheets, each dedicated to a specific category of the overall parcel For instance, as illustrated in Figure 2, separate sheets for class parcels and property parcels are necessary, as shown in Figure 3.
AAE006 motor power implementation implementation
Code: AAE004 Name: central processing unit Definition: portion of
Definition class: AAA300 Data type: STRING_TYPE Unit:
Figure 4 shows the basic structure of a parcel sheet Each parcel sheet consists of its header section and data section
The header section further consists of the class header section and schema header section
The class header section outlines the details found in the parcel sheet, including the data parcel identifier and default values applicable to any attribute in the header (refer to section 5.2) Meanwhile, the schema header section provides metadata that describes the values in the data section, with each attribute of the parcel defined in its respective cell column.
In the data section, each ontological element is detailed in individual rows, with each cell containing the attribute value corresponding to its designated column, thereby defining the ontological element.
Meta-class being characterized by meta-properties that are necessary to identify and specify each class in a reference dictionary
Code Revision number Preferred name Superclass
The globally unique identifier for gasoline-powered vehicles serves as a reference for the full name of the item used within this class This class is recognized as the canonical version, ensuring consistency across revisions of the same item.
STRING_TYPE STRING_TYPE STRING_TYPE
Class header sectionSchema header sectionData section Header section
{AAE004} properties that are newly specified as applicable for
Blank parcel sheets
Blank parcel sheets for editing a data dictionary from scratch will be obtained from:
– IEC CDD website at the following URL: or can be generated by:
In Annex E, a list of tools that conform to this Technical Specification is given
Four sheets comprising dictionary, class, property and supplier sheets, are mandatory for implementing a data dictionary The other sheets are optional and they are prepared only
IEC 2291/13 when they are required in the process of completing the information described in the four mandatory sheets
5 Common cases for defining ontological elements
Semantics
The IEC 62656 and ISO 13584/IEC 61360 series define product concepts through classes and model their characteristics with properties Certain attributes of these classes and properties necessitate additional parcels, including data type, enumeration, and term parcels Consequently, establishing the semantics of each ontological element represented by these parcels is essential for accurately describing the data dictionary These parcels provide a fundamental set of attributes to define the names and meanings of their respective ontological elements.
For describing names, there are 3 kinds of attributes defined in IEC 62656-1, i.e
MDC_P004_1 is the preferred name, while MDC_P004_2 serves as a synonymous name, and MDC_P004_3 is the short name To describe the meaning of an ontological element, three types of attributes are utilized: MDC_P005 for the definition, MDC_P007_1 for notes, and additional relevant attributes.
The attributes, except for MDC_P004_2, are classified as TRANSLATABLE_STRING_TYPE to facilitate content localization in the specified source language These attributes can include multiple columns identified by a language code, which may be combined with a country code to indicate language variants For instance, if a parcel sheet contains names in both English and French, the columns labeled “MDC_P004_1.en” and “MDC_P004_1.fr” will be used to present the preferred names in the sheet.
By contrast, the attribute MDC_P004_2 is defined as SET(0,?) OF LIST(2,2) OF
The STRING_TYPE attribute consists of a single column that describes synonymous names in various languages Each entry should include a combination of a name and its corresponding language code, and a country code if necessary For instance, if "battery" in English and its French equivalent "batterie" are provided as synonymous names for an ontological element, the valid value can be represented as either "{(battery,en),(batterie,fr)}" or "{(batterie,fr),(battery,en)}".
Each parcel sheet may include an optional instruction labeled #SOURCE_LANGUAGE, indicating the language of the original semantic content For instance, a description such as “#SOURCE_LANGUAGE:=en” in the instruction column signifies that the content is prepared in English.
The English content serves as the primary source, with other languages treated as translations If a language is not specified or the instruction is missing from the parcel sheet, English will be assumed as the default source language.
NOTE The description of values of the above attributes follows IEC 61360-6 [4]
Figure 5 illustrates a class parcel sheet that includes attributes defining the semantics of ontological elements The data section describes three classes, including a capacitor and its subclasses, which are present in the IEC CDD.
P004_3.en MDC_P005.en MDC_P007_1.en MDC_
NAME.en Preferred name Synonymous name Short name Definition Note Remark
Capacitor {(capacitor,en)} system of two conductors (plates) separated over the extent of its surfaces by a thin insulating medium (dielectric), its intended characteristic being capacitance
Since capacitance is a function of temperature, it may still vary with temperature.
Fixed capacitor {(fixed,en)} capacitor that has no designed provision for changing its capacitance value
Since capacitance is a function of temperature, it may still vary with temperature.
Variable capacitor {(variable,en)} capacitor designed so that its main property can be varied by mechanically changing the spatial relationship of their parts
Figure 5 – Semantic definitions of ontological elements
Assigning an identifier
Each ontological element must be identified according to the International Concept Identifier (ICID), as outlined in IEC 62656-1 This identifier serves to differentiate ontological elements and to establish relationships between them.
Each parcel sheet in a data dictionary features a unique attribute that describes the identifiers of its ontological elements, designated as MDC_P001_X, where X represents a positive integer For instance, MDC_P001_5 corresponds to a class parcel, while MDC_P001_6 is associated with a property parcel.
Each identifier is formed by combining the registration authority identifier (RAI), data identifier (DI), and version identifier (VI) in that specific sequence The RAI signifies the supplier responsible for the data, adhering to the standards set by ISO/IEC 6523.
The default RAI for the IEC CDD is “0112/2///61360_4.” Each ontological element is assigned a unique DI code, which consists of six characters: the first three are letters from the Roman alphabet, and the last three are whole numbers (format AAANNN) Additionally, the VI represents the version number of each ontological element, which must be incremented with each new release while ensuring backward compatibility with previous versions of the same concept.
To prevent misreading identifiers, it is advisable to avoid using the capital letters "I" and "O" in programming, as they can be easily confused with the numeric characters "1" and "0" on certain computer systems.
IEC 62656-1 introduces a shorthand notation for identifiers in both the header and data sections It suggests that due to the common RAI and VI present in nearly all items within a data dictionary at each meta-layer, all applications should adopt this mechanism for consistency and efficiency.
– simplifying the maintenance of a data dictionary,
– assigning temporary RAI and VI in designing a skeleton of a data dictionary,
– avoiding the repetition of inputting the same value of RAI and VI,
This document omits the RAI and VI of each attribute in the header section of each parcel for clarity, adhering to the standards set by IEC 62656-1.
In the parcel sheet description, it is essential to explicitly declare the instructions labeled “#DEFAULT_SUPPLIER” and “#DEFAULT_VERSION” in the class header section However, this document omits these instructions from each figure that illustrates the parcel sheets.
This document omits the RAI and VI of each attribute value for improved readability To exclude these elements in accordance with IEC 62656-1, they must be explicitly stated in the instructions.
In this document, the instruction lines for the attributes “#DEFAULT_DATA_SUPPLIER” and “#DEFAULT_DATA_VERSION” are omitted from each figure, which serves to clarify the explanation of parcel sheets.
Figure 6 gives an example of the class parcel sheet which contains the attribute
The MDC_P001_5 attribute serves as a unique identifier for ontological elements, effectively extending the sheet depicted in Figure 5 This attribute column contains the identifier for each class, as exemplified by the default RAI "0112/2///61360_4" and default VI, providing a standardized way to describe and distinguish between different classes.
The shorthand notation specifies that the default RAI will be assigned to the identifiers of the second ontological element, "fixed capacitor," and the third ontological element, "variable capacitor." Additionally, the default VI will be applied to the third ontological element.
P004_3.en MDC_P005.en MDC_P007_1.en MDC_
NAME.en Code Preferred name Synonymous name Short name Definition Note Remark
AAA020##002 Capacitor {(capacitor,en)} system of two conductors (plates) separated over the extent of its surfaces by a thin insulating medium (dielectric), its intended characteristic being capacitance
Since capacitance is a function of temperature, it may still vary with temperature.
AAA021##004 Fixed capacitor {(fixed,en)} capacitor that has no designed provision for changing its capacitance value
Since capacitance is a function of temperature, it may still vary with temperature.
AAA031 Variable capacitor {(variable,en)} capacitor designed so that its main property can be varied by mechanically changing the spatial relationship of their parts
Figure 6 – Identification of ontological elements
Assigning a definition class
According to IEC 62656-1, every ontological element, excluding the class parcel, must have a definition class that specifies its application domain This information is represented by the mandatory attribute MDC_P021 (Definition class) found in each parcel sheet.
Properties, data types, and documents are applicable to classes that utilize these ontological elements Information about these attributes is detailed in a class parcel sheet, with identifiers such as MDC_P014 indicating the applicable properties.
MDC_P015 (Applicable types) and MDC_P094 (Applicable documents) Further information is obtained in 6.2
Attributes to be considered
Annexes E and F of IEC 62656-1 outline the necessary attributes for each parcel, emphasizing that attributes classified as KEY, NOT NULL, or MANDATORY are crucial for defining ontological elements Consequently, it is important to ensure that these attributes are prominently displayed.
The instruction “#REQUIREMENT” signifies the necessity of each attribute When this instruction is present in a parcel sheet, it is advisable to clearly display it during implementation.
6 Specifying structures for data dictionaries
General
Data dictionaries are primarily structured in two ways: the classification tree, also known as the "is-a" or inheritance tree, and the composition tree, referred to as the "has-a" tree in some literature Both structures adhere to the principles outlined in the ISO 13584-42/IEC 61360-2 common dictionary model.
Classification tree
Each classification tree comprises a parent-child relationship between classes where a child class (called a “subclass”) inherits all the properties of its parent class (called a “superclass”)
Each class shall have just one class as its superclass and may have one or more classes as subclass(es)
Each domain data dictionary is assumed to have one root class, for logical conformity
According to the ISO 13584-42/IEC 61360-2 common dictionary model, an abstract universal class named UNIVERSE is specified as the root to collect all domain data dictionaries The
UNIVERSE class shall be a class having no properties
To prevent duplication of properties, data types, and documents across multiple branches, it is essential to define each ontological element that may be utilized by various classes within their shared general class.
Enumerations, units of measurement, and terms will be assigned to their respective definition classes, with the applicability of properties, data types, and documents clearly stated within the definition class or its corresponding subclass Once an ontological element is deemed applicable to a class, it will also apply to all subclasses of that class.
The attribute MDC_P010 (Superclass) of class parcel specifies the identifier of a superclass of a class
The attributes MDC_P014 (Applicable properties), MDC_P015 (Applicable types) and
MDC_P094 outlines the identifiers for properties, data types, and documents applicable to a class parcel Inherited elements from upper classes are already defined as applicable, so attributes for these inherited elements, referred to as “known applicable XYZ,” should be excluded to prevent inconsistencies in data exchanges with external systems Changes in upper classes regarding inherited elements must be reflected in all subclasses, which can lead to inconsistencies due to varying validation capabilities across systems While derived attributes may be displayed in tools for convenience, marked with DER for their requirement, they should not be utilized in data exchanges with external partners.
Figure 7 shows an example of a simple classification tree which contains the two classes
The class AAA200 is a subtype of AAA100, which encompasses the properties AAE001 and AAE002 While both properties are defined within AAA100, only AAE001 is relevant to the AAA200 class.
AAA100 The property AAE002 becomes applicable to the subclass AAA200 by inheritance and as a consequence, while the class AAA100 has one applicable property, the class
AAA200 has two applicable properties
class property specialization applicable to defined by
Figure 7 – Example of a simple classification tree
Figure 8 illustrates the conjunctive parcels that correspond to the classification tree depicted in Figure 7 The class parcel sheet outlines two defined classes and details their parent-child relationship through the attribute MDC_P010 Additionally, the property sheet specifies two properties, noting that property AAE001 is absent from the attribute MDC_P014 for the class.
AAA200 because the property AAE001 is a known applicable property, which is already applicable to its superclass AAA100
#PROPERTY_ID MDC_P001_5 MDC_P010 MDC_P011 MDC_P014
NAME.en Code Superclass Class type Applicable properties
AAA100 UNIVERSE ITEM_CLASS {AAE001}
AAA200 AAA100 ITEM_CLASS {AAE002}
#PROPERTY_ID MDC_P001_6 MDC_P020 MDC_P021 MDC_P022 MDC_P023_1
NAME.en Code Property data element type Definition class Data type Unit in text
Figure 8 – Parcel implementation for simple classification trees
Reuse of properties, data types and documents in other branches
The case_of mechanism, as outlined in IEC 61360-2, facilitates the reuse of properties, data types, and documents from different branches within a classification tree, allowing a class to reference other classes situated in separate branches.
IEC 2295/13 allows for the importation of relevant properties, data types, and documents from specified classes within the same or different data dictionaries Once imported, these elements become immediately applicable to the importing class and are inherited by its subclasses.
The attributes MDC_P090 (Imported properties), MDC_P091 (Imported types) and MDC_P093
Imported documents outline a list of identifiers for properties, data types, and documents This includes a description of the class identifiers from which these properties, data types, and documents are sourced, specified in the attribute.
Figure 9 illustrates the reuse of existing properties by importing them from the corresponding class The AAA100 class, depicted in Figure 7, is part of the data dictionary, while the BBA500 class belongs to a different data dictionary and includes one class along with three properties, BBE501 to BBE503.
The AAA200 class is a specific instance of the BBA500 class, inheriting certain properties from it Consequently, AAA200 incorporates the properties BBE502 and BBE503, which are part of the broader set of properties associated with the BBA500 class.
Figure 9 – Example of import mechanism
Figure 10 presents an updated sheet for the class parcel depicted in Figure 8, detailing the data dictionary illustrated in Figure 9 In the context of class AAA200, the class BBA500 is identified in the attribute MDC_P013 (Is case of), which defines the case_of relationship between these classes.
Also, the two imported properties BBE502 and BBE503 are listed in the attribute MDC_P090
(Imported properties) for the class AAA200
#PROPERTY_ID MDC_P001_5 MDC_P010 MDC_P011 MDC_P013 MDC_P014 MDC_P090
NAME.en Code Superclass Class type Is case of Applicable properties Imported properties
AAA100 UNIVERSE ITEM_CLASS {AAE001}
AAA200 AAA100 ITEM_CLASS {BBA500} {AAE002} {BBE502,BBE503}
Figure 10 – Parcel implementation for case of relationships
Composition tree
Composition trees illustrate part-whole relationships among classes, making them essential for representing products composed of multiple parts or materials This structure is also valuable for integrating information related to product life-cycle management.
According to IEC 62656-1, the relationship between classes is defined by a property known as either CLASS_REFERENCE_TYPE or CLASS_INSTANCE_TYPE Both data types identify a part-class that belongs to a whole-class, but they differ in their specific applications.
CLASS_REFERENCE_TYPE is utilized when instances of a part class exist independently within a part-class, separate from the whole-class For instance, multiple instances of the product "vehicle" can reference instances of the product "tyre." To establish the relationships between "vehicle" and "tyre" instances, CLASS_REFERENCE_TYPE is essential.
CLASS_INSTANCE_TYPE refers to instances of a part class that are embedded within a whole class When the whole class is destroyed, the embedded instances of the part class are also destroyed.
In the context of CLASS_INSTANCE_TYPE, the referenced class serves primarily as a builder for a composite property, often referred to as an "object-type property" in various literature.
Figure 11 shows an example of a composition relationship between two branches In
The class BBA500 includes the class AAA200 as a part To establish the part-whole relationship, the class BBA500 is associated with the CLASS_REFERENCE_TYPE property BBE504, which identifies the class AAA200.
Figure 11 – Composition relationship between two branches
Figure 12 illustrates the composition view of class BBA500, which is derived from the classification trees shown in Figure 11 The relationship between classes BBA500 and AAA200 is represented by a filled diamond and a solid line.
Figure 12 – Example of a composition tree
Figure 13 illustrates the sheets of conjunctive parcels used to implement the composition tree shown in Figure 11 The property BBE504 is identified as relevant to the BBA500 class, highlighting a part-whole relationship with the AAA200 class, which serves as a part-class.
#CLASS_NAME.en: Class meta-class
#PROPERTY_ID MDC_P001_5 MDC_P010 MDC_P011 MDC_P014
NAME.en Code Superclass Class type Applicable properties
BBA500 UNIVERSE ITEM_CLASS {BBE504}
#CLASS_NAME.en: Property meta-class
#PROPERTY_ID MDC_P001_6 MDC_P020 MDC_P021 MDC_P022
NAME.en Code Property data element type Definition class Data type
Figure 13 – Parcel implementation for composition trees
7 Defining ontological elements by optional parcels
Defining enumerations
To assign a potential value list to a property, it must first be defined as an enumeration in an enumeration parcel sheet, which is then assigned to properties within a property parcel sheet.
The MDC_P044 attribute, part of the enumeration parcel, is designed to create a list of values where each entry must adhere to a consistent data type or its subtype For instance, if the value list pertains to properties defined as real numbers, it should exclusively include real values.
To define the meanings of values in a value list, each value must be specified as a term in a term parcel sheet and subsequently assigned to enumerations in the enumeration parcel sheet.
The attribute MDC_P025_1 (Preferred letter symbol in text) of the term parcel is used for describing a value which may be assigned as an actual value for properties
The MDC_P043 attribute defines an enumerated list of term identifiers that can be used as value candidates for properties When term identifiers are provided, the values described in the MDC_P044 attribute will correspond to a list of values from the MDC_P025_1 attribute of those terms.
If values for both the attributes MDC_P043 and MDC_P044 are specified, then the number of elements of MDC_P043 shall be the same as the number of elements of MDC_P044
NOTE ISO 13584-42 does not provide a way to define a meaning of a value Thus, terms will be ignored for
Figure 14 shows an example of a data dictionary which contains enumerations There are five properties, four enumerations and seven terms Each property is defined as a subtype of
ENUM_TYPE which specifies an enumeration
The enumerations AFA001 to AFA003 define specific terms outlined in the term parcel sheet AFA001 includes terms AQA106 and AQA107, while AFA002 covers terms AQA104 to AQA106, specifying string values AFA003 details terms AQA101 to AQA103, which are associated with real values AFA004 lists four integer values without defining terms for each Notably, AQA106 is referenced by both AFA001 and AFA002, indicating shared meaning, whereas AQA104 and AQA107, despite both representing "green," are defined separately to reflect their distinct types Additionally, AFA003 is utilized by properties AAE202 and AAE203.
AAE202: ENUM_REAL_MEASURE_TYPE
AQA101 (1.5) AQA102 (3.0) AQA103 (5.0) AQA104 (green) AQA105 (yellow) AQA106 (red)
reference enumeration AAE205: ENUM_STRING_TYPE term
AAE203: ENUM_REAL_MEASURE_TYPE
Figure 14 – Example of a use case of enumeration
Figure 15 shows sheets of conjunctive parcels to describe the data dictionary shown in
In the property parcel sheet, which is depicted as the first sheet, five properties are described
The MDC_P022 attribute column indicates the data type of each property, categorized as a subtype of ENUM_TYPE, which defines the enumeration identifier and its corresponding list of possible values.
The second sheet of the enumeration parcel sheet outlines four enumerations The attribute MDC_P043 identifies terms used as value candidates for properties, while MDC_P044 provides the actual values for these properties Notably, enumeration AFA004 lacks a value for MDC_P043, indicating that only value candidates are specified.
In the term parcel sheet, which is depicted as the third sheet, seven terms are described
Each value that can be selected as a candidate value for properties is described in the attribute MDC_P025_1 (Preferred letter symbol in text)
#PROPERTY_ID MDC_P001_6 MDC_P023_1 MDC_P022
NAME.en Code Unit in text Data type
AAE201 ENUM_INT_TYPE(AFA004(1,2,3,4))
AAE202 m ENUM_REAL_MEASURE_TYPE(AFA003(1.5,3.0,5.0)) AAE203 m ENUM_REAL_MEASURE_TYPE(AFA003(1.5,3.0,5.0)) AAE204 ENUM_STRING_TYPE(AFA002(green,yellow,red)) AAE205 ENUM_STRING_TYPE(AFA001(red,green))
#PROPERTY_ID MDC_P001_12 MDC_P043 MDC_P044
NAME.en Code Enumerated list of terms Enumeration code list
AFA001 (AQA106,AQA107) (red,green) AFA002 (AQA104,AQA105,AQA106) (green,yellow,red) AFA003 (AQA101,AQA102,AQA103) (1.5,3.0,5.0)
NAME.en Code Preferred letter symbol
AQA107 green enumeration value candidate
Figure 15 – Parcel implementation for enumerations
Defining named data types
IEC 62656-1 includes various data types, primarily derived from those defined in IEC 61360-2, with some extensions While the predefined data types typically suffice for modeling domain-specific data, there are instances where new data types need to be created This is often necessary to assign unique names to data types that will be shared across multiple properties or to clearly differentiate them from existing data types or their original definitions These newly defined data types are referred to as
“named data type” and shall be defined as instances of a data type parcel which is identified as MDC_C006 (data type meta-class)
In a data type parcel sheet, each named data type is detailed on individual lines within the data section Each named data type must have a base data type, which can either be a predefined data type as specified in IEC 62656-1 or another named data type It is important to ensure that references between named data types and any nested references do not result in a loop structure.
A named data type is essential for defining properties within a class, as outlined in the attribute MDC_P015 (Applicable types) on a class parcel sheet Additionally, named data types can be imported from classes in other branches, with the attribute MDC_P091 (Imported types) specifying the set of imported data types, while MDC_P013 (Is case of) indicates the originating classes.
In a class, properties and named data types can utilize applicable named data types through the predefined data type NAMED_TYPE in the fields of the attribute MDC_P022 (Data type).
When a named data type is classified as a measurement or currency type, it must include a corresponding unit of measurement or currency Additionally, any property or other named data type defined as a named data type should share the same unit of measurement or currency If a property or another named data type does not specify this information, it will automatically inherit the unit of measurement or currency from the referenced named data type.
Figure 16 illustrates sheets of conjunctive parcels that outline a data dictionary, featuring a property identified as a named data type In this instance, the property AAE211 is designated as the named data type AKA001, which is derived from a predefined data type.
The named data type, defined as REAL_MEASURE_TYPE, is specified in the data type parcel sheet Its identifier is indicated in the property’s data type field using the keyword “NAMED_TYPE.” Although AAE211 does not have a specified unit of measurement, it adopts the unit “m” from the named data type AKA001 for its measurement.
#CLASS_NAME.en: Property meta-class
#PROPERTY_ID MDC_P001_6 MDC_P021 MDC_P022
NAME.en Code Definition class Data type
#CLASS_NAME.en: Datatype meta-class
#PROPERTY_ID MDC_P001_7 MDC_P021 MDC_P022 MDC_P023_1
NAME.en Code Definition class Data type Unit in text AKA001 AAA210 REAL_MEASURE_TYPE m
#CLASS_NAME.en: Class meta-class
#PROPERTY_ID MDC_P001_5 MDC_P010 MDC_P011 MDC_P014 MDC_P015
NAME.en Code Superclass Class type Applicable properties Applicable types AAA210 UNIVERSE ITEM_CLASS {AAE211} {AKA001} applicable applicable named data type
Figure 16 – Parcel implementation for named data types
Defining information of external resources
Resources beyond data parcels include binary documents, still images, audio, and video files To define and specify these resources, a document parcel identified as MDC_C007 (document meta-class) is utilized.
A document parcel sheet provides essential information about each external resource, detailing the responsible organization and access instructions for the document.
Resource information must be relevant to the specific class where it is needed, as outlined in the attribute MDC_P094 (Applicable documents) on a class parcel sheet Additionally, documents can be imported from a class in a different branch, utilizing the attribute MDC_P093 for this purpose.
The class parcel sheet utilizes imported documents to define a specific set of documents, while the attribute MDC_P013 (Is case of) indicates the classes from which these documents are sourced.
In other parcel sheets, the predefined attributes MDC_P004_4 (Name icon), MDC_P008_1
(Simplified drawing) and MDC_P008_2 (Graphics) are expected to have the identifier of a document which is defined in the document parcel sheet
Figure 17 illustrates sheets of conjunctive parcels used to describe a data dictionary, which includes details about an external file referenced by a property The external file, accessible at “http://iec.ch/image.jpg,” is identified as document AMA001 and is detailed in the document parcel sheet at the bottom of the figure The property AAE221, whose graphics are derived from the specified URL, is described in the property parcel sheet located in the middle of the figure Additionally, the class parcel sheet at the top shows that both property AAE221 and document AMA001 are applicable to class AAA220.
NOTE is used as an example and is fictitious
#PROPERTY_ID MDC_P001_6 MDC_P008_2 MDC_P021 MDC_P022
NAME.en Code Graphics Definition class Data type
AAE221 AMA001 AAA220 REAL_MEASURE
#PROPERTY_ID MDC_P001_8 MDC_P021 MDC_P061_1 MDC_P061_2 MDC_P062
NAME.en Code Definition class Document organization ID Document organization name Remote location
AMA001 AAA220 0112/2 IEC http://www.iec.ch/ image.jpg
#PROPERTY_ID MDC_P001_5 MDC_P010 MDC_P011 MDC_P014 MDC_P094
NAME.en Code Superclass Class type Applicable properties Applicable documents
AAA220 UNIVERSE ITEM_CLASS {AAE221} {AMA001} applicable applicable reference
Figure 17 – Parcel implementation for document references
Defining units of measurement
The simplest way to specify a unit for a property is to describe it in the attributes MDC_P023
(Unit structure), MDC_P023_1 (Unit in text) and MDC_P023_2 (Unit in SGML) The attribute
MDC_P023 represents a STEP expression of a unit, while the attribute MDC_P023_1 corresponds to a plain text expression of a unit Additionally, the attribute MDC_P023_2 is designated for an SGML expression of a unit, which encompasses MathML expressions.
In addition to the above simple expression of a unit, there are some more complex cases in which units should be identified, such as:
– defining not only simple SI or non-SI units, but also a combination of them,
When units are described using the same reference unit or set of units, it is crucial to distinguish between them, as they may carry different meanings depending on the specific domain of application.
– permitting accurate conversion of a value from a unit to its alternative by a computer
IEC 62720, which contains a unit dictionary for the whole electric and electronic domains, is a good example of the above requirement
In IEC 62656-1, the unit of measurement parcel (UoM parcel), which is identified as
MDC_C009, the UoM meta-class, is essential for defining units of measurement The UoM parcel sheet includes three attributes—MDC_P023, MDC_P023_1, and MDC_P023_2—that provide detailed information about a unit of measurement utilized by properties and named data types Each unit is identified by the MDC_P001_10 attribute (Code), which specifies the unique identifier for the defined unit.
A unit defined as an instance of a Unit of Measure (UoM) parcel can be utilized by properties or named data types through the attributes MDC_P041 (Code for unit) and MDC_P042 (Codes for alternative units) The MDC_P042 attribute may include a collection of identifiers for units that serve as alternatives to the primary unit specified in MDC_P041.
MDC_P041 shall have a value whenever the attribute MDC_P042 has a value
Figure 18 shows sheets of conjunctive parcels consisting of a property parcel and UoM parcel
The UoM parcel sheet outlines four
UAB197 and UAA917 for its primary unit of measurement UAA594
In the UoM parcel sheet, each unit of measurement defines its unit in text representation in the attribute MDC_P023_1 and in MathML description in the attribute MDC_P023_2
#PROPERTY_ID MDC_P001_6 MDC_P022 MDC_P023_1 MDC_P041 MDC_P042
NAME.en Code Data type Unit in text Code for unit Codes for alternative units
AAE233 LEVEL(MIN,MAX) OF
REAL_MEASURE kg UAA594 {UAB197,UAA917}
#PROPERTY_ID MDC_P001_10 MDC_P004_1.en MDC_P023_1 MDC_P023_2
NAME.en Code Preferred name Unit in text Unit in SGML
UAA726 metre m