Specification Predefined Template for IEC61360 Properties, Value Lists, and Values (normative) Data Specification IEC61360 Template Specification This specification is only valid in combination with IDTA-01001-3-1. Template: IEC61360 administration: version: 3 revision: 1 creator: IDTA id: https://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3 <<deprecated>> https://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3/0 <<deprecated>> http://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3/0 <<deprecated>> https://admin-shell.io/DataSpecificationTemplates/DataSpecificationIEC61360/3/0 <<deprecated>> http://admin-shell.io/DataSpecificationTemplates/DataSpecificationIEC61360/3/0 dataSpecificationContent: DataSpecificationIec61360 Description (EN): Data specification template for concept descriptions for properties and values conformant to IEC 61360. The ID of the data specification template was derived conformant to the rules for semantic IDs for data specifications as defined in Part 1 of the document series, IDTA-01001. This ID will be used in hasDataSpecification/dataSpecification. This namespace has the qualifier "IEC:" Examples: IEC:DataSpecificationIec61360/preferredName or IEC:DataSpecificationIec61360/levelType/min or IEC:LevelType/min Figure 1. Metamodel of Data Specification IEC61360 Data Specification IEC61360 Attributes Class: DataSpecificationIec61360 <<Template>> Explanation: Content of data specification template for concept descriptions for properties, values, and value lists conformant to IEC 61360. Note: for details, please refer to [IEC61360-1], property, value_list and term Constraint AASc-3a-010: If DataSpecificationIec61360/value is not empty, DataSpecificationIec61360/valueList shall be empty, and vice versa. Note 1: it is also possible that both DataSpecificationIec61360/value and SpecificationIec61360/valueList are empty. This is the case for concept descriptions that define the semantics of a property but do not have an enumeration (valueList) as data type. Note 2: although it is possible to define a concept description for a value list, it is not possible to reuse this value list. It is only possible to directly add a value list as data type to a specific semantic definition of a property. Constraint AASc-3a-009: If DataSpecificationIec61360/dataType is one of INTEGER_MEASURE, REAL_MEASURE, RATIONAL_MEASURE, INTEGER_CURRENCY, REAL_CURRENCY, then DataSpecificationIec61360/unit or DataSpecificationIec61360/unitId shall be defined. Inherits from: DataSpecificationContent Attribute Explanation Type Card preferredName Preferred name in different languages Note: for details, please refer to [IEC61360-1], preferred_name Constraint AASc-3a-002: DataSpecificationIec61360/preferredName shall be provided at least in English. PreferredNameTypeIec61360 1 shortName Short name Note: for details, please refer to [IEC61360-1], short_name ShortNameTypeIec61360 0..1 unit Unit in case of a quantitative property Note 1: for details, please refer to [IEC61360-1], unit_in_text Note 2: only the primary unit is supported. string 0..1 unitId Unique unit ID Unit and unitId need to be consistent if both attributes are set Note 1: for details, please refer to [IEC61360-1], unit_of_measure Note 2: it is recommended to use an external reference ID. Reference 0..1 sourceOfDefinition Source of definition Note: for details, please refer to [IEC61360-1], source_document_of_definition string 0..1 symbol Symbol Note: for details, please refer to [IEC61360-1], preferred_letter_symbol string 0..1 dataType Data Type Note: for details, please refer to [IEC61360-1], data_type DataTypeIec61360 0..1 definition Definition in different languages Note: for details, please refer to [IEC61360-1], definition DefinitionTypeIec61360 0..1 valueFormat Value Format Note: for details, please refer to [IEC61360-1], value_format ValueFormatTypeIec61360 0..1 valueList Enumerated list of allowed values Note 1: for details, please refer to [IEC61360-1], enumerated_list_of_terms. Note 2: for ease of usage, the value list is modelled as value/valueId list in this data specification template. ValueList 0..1 value Value (typically within a value list) Note: for details, please refer to [IEC61360-1], term/preferred_letter_symbol_in_text ValueTypeIec61360 0..1 levelType Value represented by up to four variants of a numeric value in a specific role: MIN, NOM, TYP and MAX. Note: for details, please refer to [IEC61360-1], LEVEL_TYPE LevelType 0..1 Note 1: IEC 61360 also requires a globally unique identifier for a concept description. This ID is not part of the data specification template. Instead, the ConceptDescription/id as inherited via Identifiable is used. The same applies to administrative information like the version and revision. Note 2: ConceptDescription/idShort and DataSpecificationIec61360/shortName are very similar. However, in this case, shortName is explicitly added to the data specification. Note 3: ConceptDescription/displayName and DataSpecificationIec61360/preferredName are very similar. However, in this case, preferredName is explicitly added to the data specification. Note 4: ConceptDescription/description and DataSpecificationIec61360/definition are very similar. However, in this case, definition is explicitly added to the data specification. Enumeration Data Type IEC61360 Figure 2. Metamodel of Data Type IEC 61360 Enumeration: DataTypeIec61360 Explanation: Enumeration of simple data types for an IEC 61360 concept description using the data specification template DataSpecificationIec61360 Set of: — Literal Explanation DATE values containing a calendar date, conformant to ISO 8601:2004 Format yyyy-mm-dd Note: for details, please refer to [IEC61360-1], specific STRING_TYPE, the DATE_TYPE. Example from IEC 61360-1:2017: "1999-05-31" is the [DATE] representation of: "31 May 1999". STRING values consisting of a sequence of characters, which cannot be translated into other languages Note 1: for details, please refer to [IEC61360-1], specific STRING_TYPE, the NON_TRANSLATABLE_STRING_TYPE. Note 2: IEC61360 does not request to use more specific string types like TRANSLATABLE_STRING_TYPE, NON_TRANSLATABLE_STRING_TYPE, DATE_TIME_TYPE, DATE_TYPE, TIME_TYPE, IRDI_STRING, URI_TYPE, and HTML5_TYPE. It is requested to use the more specific data types in the AAS, if applicable[1]. 1. This is also requested in ECLASS, see https://eclass.eu/support/technical-specification/structure-and-elements/value STRING_TRANSLATABLE values containing string, but which shall be represented as different strings in different languages Note: for details, please refer to [IEC61360-1], specific STRING_TYPE, the TRANSLATABLE_STRING_TYPE INTEGER_MEASURE values containing values that are a measure of the type INTEGER. In addition, such a value comes with a physical unit. Note: for details, please refer to [IEC61360-1], specific INTEGER (or INT_TYPE) NUMBER_TYPE, the INT_MEASURE_TYPE INTEGER_COUNT values containing values of the type INTEGER, but which are no currencies or measures Note 1: for details, please refer to [IEC61360-1], specific NUMBER_TYPE, the INT_TYPE (or just INTEGER). For more specific data types, INTEGER_MEASURE_TYPE or INTEGER_CURRENCY_TYPE may be used. Note 2: it is requested to use the more specific data types in the AAS, if applicable. INTEGER_CURRENCY values containing values of the type INTEGER, which are currencies Note: for details, please refer to [IEC61360-1], specific INTEGER NUMBER_TYPE, the INT_CURRENCY_TYPE REAL_MEASURE values containing values that are measures of the type REAL. In addition, such a value comes with a physical unit. Note: for details, please refer to [IEC61360-1], specific REAL NUMBER_TYPE, the REAL_MEASURE_TYPE REAL_COUNT values containing numbers that can be written as a terminating or non-terminating decimal; i.e. a rational or irrational number, which is neither a currency nor a measures Note 1: for details, please refer to [IEC61360-1], specific NUMBER_TYPE, the REAL_TYPE. For more specific data types REAL_MEASURE_TYPE or REAL_CURRENCY_TYPE may be used. Note 2: it is requested to use the more specific data types in the AAS, if applicable. REAL_CURRENCY values containing values of the type REAL, which are currencies Note: for details, please refer to [IEC61360-1], specific REAL NUMBER_TYPE, the REAL_CURRENCY_TYPE BOOLEAN values representing truth of logic or Boolean algebra (TRUE, FALSE) Note 1: for details, please refer to [IEC61360-1], BOOLEAN_TYPE. Note 2: in IEC 61360, the values are Yes and No. In the AAS, the values are TRUE (for "Yes") and FALSE (for "No"). IRI values containing values of the type STRING conformant to Rfc 3987 Note 1: for details, please refer to [IEC61360-1], specific STRING_TYPE, the URI_TYPE. Note 2: However, the AAS supports the more generic IRI. An IRI type particularly allows to express a URL or a URI. If the IRI represents an address to a file, FILE shall be used. IRDI values conforming to ISO/IEC 11179 series global identifier sequences Note 1: for details, please refer to [IEC61360-1], specific STRING_TYPE, the IRDI_STRING. Note 2: IRDI can be used instead of the more specific data types ICID or ISO29002_IRDI. Note 3: ICID values are values conformant to an IRDI, where the delimiter between RAI and ID is "#", while the delimiter between DI and VI is confined to "##". Note 4: ISO29002_IRDI values are values containing a global identifier that identifies an administrated item in a registry. The structure of this identifier complies with the identifier syntax defined in ISO/TS 29002-5. The identifier shall fulfil the requirements specified in ISO/TS 29002-5 for an “international registration data identifier” (IRDI). RATIONAL Values containing values of the type RATIONAL, which are no measures Examples: ½, ¾ or 7/2 Note 1: for details, please refer to [IEC61360-1], specific NUMBER_TYPE, the RATIONAL_TYPE. Note 2: it is requested to use the more specific data types in the AAS, if applicable. RATIONAL_MEASURE values containing values of the type RATIONAL. In addition, such a value comes with a physical unit. Note: for details, please refer to [IEC61360-1], specific RATIONAL NUMBER_TYPE, the RATIONAL_MEASURE_TYPE TIME values containing a time conformant to ISO 8601:2004 but restricted to what is allowed in the corresponding type in xml. Format hh:mm (ECLASS) Example from IEC 61360-1:2017: "13:20:00-05:00" is the [TIME] representation of: 1.20 p.m. for Eastern Standard Time, which is 5 hours behind Coordinated Universal Time (UTC). Note: for details, please refer to [IEC61360-1], specific STRING_TYPE, the TIME_TYPE TIMESTAMP values containing a time conformant to ISO 8601:2004 but restricted to what is allowed in the corresponding type in xml. Format yyyy-mm-dd hh:mm (ECLASS) Note: for details, please refer to [IEC61360-1], specific STRING_TYPE, the DATE_TIME_TYPE. FILE values containing an address to a file. The values are of the type URI and can represent an absolute or relative path. Note: [IEC61360-1] does not explicitly support the file type. It would map to the URI_TYPE. HTML Values containing string with any sequence of characters, using the syntax of HTML5 (see W3C Recommendation 28:2014) Note: for details, please refer to [IEC61360-1], specific STRING_TYPE, the HTML5_TYPE. BLOB values containing the content of a file. Values may be binaries. HTML conformant to HTML5 is a special blob. In IEC61360, binary is a sequence of bits, each bit being represented by "0" and "1" only. A binary is a blob. However, a blob may also contain other source code. Note: for details, please refer to [IEC61360-1], BINARY_TYPE Level Type Figure 3. Metamodel of Level Type Class: LevelType Explanation: Value represented by up to four variants of a numeric value in a specific role: MIN, NOM, TYP, and MAX. True means that the value is available, false means the value is not available. Note: for details, please refer to [IEC61360-1], LEVEL_TYPE Note: for details, please refer to [IEC61360-1], LEVEL_TYPE Inherits from: DataSpecificationContent Attribute Explanation Type Card. min Minimum of the value boolean 1 nom Nominal value (value as designated) boolean 1 typ Value as typically present boolean 1 max Maximum of the value boolean 1 Note: This is how the AAS deals with the following combinations of level types: Case 1: If all attributes are false, the concept is mapped to a Property and level type is ignored. Case2: If a maximum of one attribute is set to true, the concept is mapped to a Property. Case 3: If min and max are set to true, the concept is mapped to a Range. Case 4: If more than one attribute is set to true, does not include min and max only (see second case), the concept is mapped to a SubmodelElementCollection with the corresponding number of Properties. Example: If the attributes min and nom are set to true, the concept is mapped to a SubmodelElementCollection with two Properties: min and nom. The data type of both Properties is the same. In the cases 2 and 4, the semanticId of the Property or Properties within the SubmodelElementCollection needs to include information about the level type. Otherwise, the semantics is not described in a unique way. In [27], IRDI paths are introduced[2]. It is not recommended to use level type when defining concept descriptions for Properties, except for ranges (i.e. min and max). This is considered to be a deprecated way of defining property sets. See also [27], where one proposal on how to deal with level type is to remove the level type and to define several properties instead. Value List Attributes "ValueList" allows to define an enumeration type for a property. The value list is a set of value reference pairs. Figure 4. Metamodel of Value List Class: ValueList Explanation: A set of value reference pairs Note: for details, please refer to [IEC61360-1], value_list/enumerated_list_of_terms. Inherits from: — Attribute Explanation Type Card. valueReferencePair A pair of a value together with its global unique ID. ValueReferencePair 1..* Class: ValueReferencePair Explanation: A value reference pair within a value list. Each value has a global unique ID defining its semantic. Inherits from: — Attribute Explanation Type Card. value the value of the referenced concept definition of the value in valueId. ValueTypeIec61360 1 valueId Global unique ID of the value Note: it is recommended to use an external reference. Reference 1 Mapping IEC 61360 Data Types to XSD Data Types Using a concept description requires mapping the data type of the concept description to a conformant type in xsd (for example in Property/valueType). Examples for the different IEC 61360 data types can be found here: https://eclass.eu/support/technical-specification/structure-and-elements/value. Table 1. Mapping IEC 61360 Data Types to xsd Data Types Data Type IEC 61360 xsd Value Type[3] Example Values IEC 61360[4] DATE xs:date 1979-01-15 STRING xs:string "DN 700" "10 Mbps" STRING_TRANSLATABLE Mapped to MultiLanguageProperty, i.e. type MultiLanguageText Note: for details, please see Part 1 of the document series "Specification of the Asset Administration Shell". INTEGER_MEASURE xs:integer 1 10 111 INTEGER_COUNT xs:integer 1 10 111 INTEGER_CURRENCY xs:integer 1 10 111 REAL_MEASURE xs:double or xs:float (depending on needed precision) 1.5 102.35 REAL_COUNT xs:double or xs:float (depending on needed precision) 1.5 102.35 REAL_CURRENCY xs:double or xs:float (depending on needed precision) 1.5 102.35 BOOLEAN xs:boolean with "Yes" mapped to "true" and "No" mapped to "false" Yes No IRI xs: anyURI or mapped to ReferenceElement http://www.eclass-cdp.com IRDI xs:string or mapped to ReferenceElement Note: for details, please see Part 1 of the document series "Specification of the Asset Administration Shell". 0173-1#01-ADG629#001 RATIONAL xs:string 1/3 1 2/3 RATIONAL_MEASURE xs:string 1/3 1 2/3 TIME xs:time 12:45 TIMESTAMP xs:dateTime 1979-01-15T12:45:00Z FILE Mapped to submodel element File, i.e. type PathType Note: for details, please see Part 1 of the document series "Specification of the Asset Administration Shell". ./documents/example.pdf HTML Mapped to submodel element Blob, i.e. type BlobType Note: for details, please see Part 1 of the document series "Specification of the Asset Administration Shell". BLOB Mapped to submodel element Blob, i.e. type BlobType Note: for details, please see Part 1 of the document series "Specification of the Asset Administration Shell". Category of Concept Descriptions Note: the attribute category of referables was set to deprecated in V3.0 of Part 1. Hence, this clause informs about the meaning, in case applications are still using the attribute category. Although the IEC 61360 attributes listed in this template are defined for properties and values only, it is also possible to use the template for other definitions as long as no specific data specifications for concept descriptions for these elements are available. This is shown in Table 2, Table 3 and Table 5. For the meaning of the content attributes of the IEC 61360 data specification template, please refer to IEC 61360 and/or ECLASS. The data specification template can be used to describe both properties and values. See Overview Relationship Metamodel Part 1 & Data Specifications IEC 61360 on how data specification templates are related to concept descriptions. Figure 5 lists all categories used for concept descriptions[5]. The following tables recommend using specific categories to distinguish which kind of concept is described. They also give advice on which attributes need to be filled for which category of concept description. Figure 5. Categories of Concept Descriptions (non-normative) Table 2. IEC61360 Data Specification Template for Properties and Ranges Attribute [6] Property Property Property MultiLanguageProperty Range Category of Concept Description VALUE PROPERTY PROPERTY PROPERTY PROPERTY Category of SubmodelElement CONSTANT VARIABLE PARAMETER — — preferredName[7] m m m m m shortName (m) (m) (m) (m) (m) unit (m) (m) (m) — (m) unitId (m) (m) (m) — (m) sourceOfDefinition o o o o o symbol o o o — — dataType m[8] m8 m8 STRING_TRANSLATABLE INTEGER_* or REAL_* definition (m) m m m m valueFormat o o o — o valueList — o o — — value m — — — — valueId o — — — — levelType — — — — Min = true Max = true Table 3. IEC61360 Data Spec. Template for Other Data Elements,Relationships Elements and Capabilities Attribute*6* ReferenceElement *File*[9] Blob9 Capability9 RelationshipElement9 AnnotatedRelationshipElement9 Category of Concept Description REFERENCE DOCUMENT DOCUMENT CAPABILITY RELATIONSHIP RELATIONSHIP Category of SubmodelElement -- -- -- -- -- -- preferredName7 m m m m m m shortName (m) (m) (m) (m) (m) (m) unit — — — — — — unitId — — — — — — sourceOfDefinition o o o o o o symbol — — — — — — dataType string or Iri or Irdi or Icid or iso29002Irdi file blob or html5 — — — definition m m m m m m valueFormat — — — — — — valueList — — — — — — value — — — — — — valueId — — — — — — levelType — — — — — — Table 4. IEC612360 Data Specification Template for Other Submodel Elements Attribute SubmodelElementList9 SubmodelElementCollection9 Operation9 EventElement9 Entity9 Category of Concept Description COLLECTION ENTITY FUNCTION EVENT ENTITY Category of SubmodelElement -- -- -- -- -- preferredName7 m m m m m shortName (m) (m) (m) (m) (m) unit — — — — — unitId — — — — — sourceOfDefinition o o o o o symbol — — — — — dataType — — — — — definition m m m m m valueFormat — — — — — valueList — — — — — value — — — — — valueId — — — — — levelType — — — — — Table 5. Other Elements with semanticId Attribute Submodel9 Qualifier9 SpecificAssetId Category of Concept Description APPLICATION_CLASS QUALIFIER_TYPE PROPERTY Category of Element -- -- -- preferredName m m m shortName (m) (m) (m) unit — — unitId — — — sourceOfDefinition o o o symbol — — — dataType — m m definition m m m valueFormat — o o valueList — o — value — — — valueId — — — levelType — — — Cross-Constraints and Invariants for Predefined Data Specifications (normative) General This clause documents constraints in the context of the predefined data specifications that cannot be assigned to a single class, i.e. that are no class invariants. A class invariant is a constraint that must be true for all instances of a class at any time. Note: these constraints include elements of Part 1 Metamodel, IDTA-01001. Constraints for Data Specification IEC61360 Constraint AASc-3a-004: For a ConceptDescription with category PROPERTY or VALUE using data specification template IEC61360 (http://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3), DataSpecificationIec61360/dataType is mandatory and shall be one of DATE, STRING, STRING_TRANSLATABLE, INTEGER_MEASURE, INTEGER_COUNT, INTEGER_CURRENCY, REAL_MEASURE, REAL_COUNT, REAL_CURRENCY, BOOLEAN, RATIONAL, RATIONAL_MEASURE, TIME, TIMESTAMP. Note: categories are deprecated since V3.0 of Part 1 of the document series "Specification of the Asset Administration Shell". Constraint AASc-3a-005: For a ConceptDescription with category REFERENCE using data specification template IEC61360 (http://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3), DataSpecificationIec61360/dataType shall be one of STRING, IRI, IRDI. Note: categories are deprecated since V3.0 of Part 1 of the document series "Specification of the Asset Administration Shell". Constraint AASc-3a-006: For a ConceptDescription with category DOCUMENT using data specification template IEC61360 (http://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3), DataSpecificationIec61360/dataType shall be one of FILE, BLOB, HTML. Note: categories are deprecated since V3.0 of Part 1 of the document series "Specification of the Asset Administration Shell". Constraint AASc-3a-007: For a ConceptDescription with category QUALIFIER_TYPE using data specification template IEC61360 (http://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3), DataSpecificationIec61360/dataType is mandatory and shall be defined. Note: categories are deprecated since V3.0 of Part 1 of the document series "Asset Administration Shell Specification". Constraint AASc-3a-008: For a ConceptDescription using data specification template IEC61360 (http://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3), DataSpecificationIec61360/definition is mandatory and shall be defined at least in English. Exception: the concept description describes a value, i.e. DataSpecificationIec61360/value is defined. [underline]#Constraint AASc-3a-002:#For a ConceptDescription referenced via ValueList/valueId and using data specification template IEC61360 (http://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3), DataSpecificationIec61360/value shall be set. Constraint AASc-3a-050: If the DataSpecificationContent DataSpecificationIec61360 is used for an element, the value of HasDataSpecification/dataSpecification shall contain the external reference to the IRI of the corresponding data specification template https://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3. Primitive and Simple Data Types (normative) Predefined Simple Data Types The metamodel of the Asset Administration Shell uses some of the predefined simple data types of the XML Schema Definition (XSD) as its basic data types [10]. For an overview of the types used in this document, see Table 6. Their definition is outside the scope of this document. The meaning and format of xsd types is specified in https://www.w3.org/XML/Schema. The simple type "langString" is specified in the Resource Description Framework (RDF)[11]. Table 6. Simple Data Types Used in Metamodel Source Basic Data Type Value Range Sample Values xsd boolean true, false true, false xsd string Character string (but not all Unicode character strings) "Hello world", "Καλημέρα κόσμε",ハローワールド" rdf langString Strings with language tags "Hello"@en, "Hallo"@de. Note that this is written in RDF/Turtle syntax, and that only "Hello" and "Hallo" are the actual values. Simple data types start with a small letter. Basic and Primitive Data Types Table 7 lists the Primitives used in the metamodel. Primitive data types start with a capital letter. Table 7. Primitive DataTypes Used in Metamodel Primitive Definition Value Examples DefinitionTypeIec61360 LangStringSet Each langString within the array of strings has a length of maximum 1023 and a minimum of 1 characters. "Greatest permissible rotation speed with which the motor or feeding unit may be operated." Note: see Figure 2. Example Property from ECLASS LangStringSet Array of elements of type langString Note 1: langString is a RDF data type. Note 2: a langString is a string value tagged with a language code. The realization of a langString depends on the serialization rules for a technology. Note: as defined in Part 1 Metamodel, IDTA-01001. In xml: <aas:langString lang="EN">This is a multi-language value in English</aas:langString> <aas:langString lang="DE"> Das ist ein Multi-Language-Wert in Deutsch </aas:langString> In rdf: "This is a multi-language value in English"@en ; "Das ist ein Multi-Language-Wert in Deutsch"@de In JSON: "description": [ { "language":"en", "text": "This is a multi-language value in English." }, { "language":"de", "text": "Das ist ein Multi-Language-Wert in Deutsch." } ] PreferredNameTypeIec61360 LangStringSet Each string with a length of maximum 255 and minimum of 1 characters. Note 1: it is advised to keep the length of the name limited to 35 characters. Note 2: for details, please refer to [IEC61360-1], preferred_name "max. rotation speed"@EN Note: see Figure 2. Example Property from ECLASS ShortNameTypeIec61360 LangStringSet Each string with a length of maximum 18 and a minimum of 1 characters. Note: for details, please refer to [IEC61360-1], short_name "d_out" Note: See Figure 6. Example for Property with Level Type from IEC CDD ValueFormatTypeIec61360 string Note: for details, please refer to [IEC61360-1], value_format. The value format is based on ISO 13584-42 and IEC 61360-2. "NR3..3.3ES2" Note: See https://portal.bosch.com/ ValueTypeIec61360 string with a length of maximum 2048 and minimum of 1 characters. "Blue" "1000" Mappings to Data Formats to Share I4.0-Compliant Information (normative) General Part 1 of this document series (IDTA-01001) introduces different serialization formats: XML, JSON and RDF. Part 1 also introduces the implementation guide for embedded data specifications. This is why the different formats are described in IDTA-01001. 2. see also https://eclass.eu/support/technical-specification/data-model/irdi-path 3. Property/valueType, Range/valueType, etc. are each of type DataTypeDefXsd. Note: for submodel elements like Blob and File or MultiLanguageProperty and ReferenceElement, there is no explicitly defined valueType attribute because the data type is implicitly defined and fix (BlobType, PathType or MultiLanguageTextType, Reference). 4. Source for most examples for the different IEC 61360 data types: https://eclass.eu/support/technical-specification/structure-and-elements/value. The IRDI example for STRING was moved to IRDI. 5. Note: although the possible categories are listed as enumeration, no enumeration has been defined for Referable/category. 6. m = mandatory, o = optional, (m) = conditionally mandatory or recommended to be added 7. Mandatory in at least one language. Preferably, an English preferred name should always be defined. 8. All IEC 61360 data types except STRING_TRANSLATABLE, IRI, IRDI, HTML, FILE, BLOB. 9. Template only used until explicit template is available for defining the corresponding types of elements. 10. https://www.w3.org/XML/Core/, former https://www.w3.org/XML/Schema 11. see: https://www.w3.org/TR/rdf11-concepts/