|
+ Note
+ |
+
+ Foreword
+This document is developed and published by the EXPRESS Language
+Foundation. All rights reserved.
+ |
+
The EXPRESS Language Foundation, maintainer of the EXPRESS data modeling language, +develops and maintains language standards and technologies. The work of +preparing EXPRESS standards is carried out through technical working groups. +Each member interested in a subject for which a working group has been +established has the right to participate in that group. International +organizations, both governmental and non-governmental, also take part in the +work.
+The procedures used to develop this document and those intended for its further +maintenance are described in the EXPRESS Language Foundation’s documentation +guidelines. In particular, different approval criteria are needed for different +types of documents. This document was drafted in accordance with the EXPRESS +Language Foundation’s editorial rules and guidelines.
+Attention is drawn to the possibility that some of the elements of this document +may be the subject of patent rights. The EXPRESS Language Foundation shall not +be held responsible for identifying any or all such patent rights. Details of +any patent rights identified during the development of the document will be in +the Introduction.
+Any trade name used in this document is information given for the convenience of +users and does not constitute an endorsement.
+For an explanation of the voluntary nature of standards and the meaning of +EXPRESS Language Foundation specific terms and expressions related to conformity +assessment, please refer to the Foundation’s documentation guidelines.
+This document was prepared by the EXPRESS Language Foundation’s Technical +Working Group.
+EXPRESS is organized as a series of specifications, each published separately. +The structure of EXPRESS is described in the Core Language Specification.
+Each specification is a member of one of the following series: description +methods, implementation methods, conformance testing methodology and framework, +integrated generic resources, integrated application resources, application +protocols, abstract test suites, application interpreted constructs, and +application modules. This part is a member of the description methods series.
+Introduction
+EXPRESS-Q is a query language designed to work with EXPRESS schemas, +particularly in the context of STEP (Standard for the Exchange of Product model +data) application protocols. It provides a formal mechanism for defining +mappings between Application Reference Model (ARM) and Model Implementation +Model (MIM) schemas, as well as specifying constraints on datasets that comply +with these schemas.
+The primary purpose of EXPRESS-Q is to bridge the gap between conceptual models +(ARM) and their implementations (MIM), ensuring that data exchange between +different systems maintains semantic consistency. By providing a standardized +way to express these mappings and constraints, EXPRESS-Q facilitates more robust +and reliable data exchange in complex engineering and manufacturing +environments.
+Scope
+This document specifies EXPRESS-Q, including its syntax, semantics, and usage within the context of EXPRESS schemas and STEP application protocols.
+The specification covers:
+-
+
-
+
The grammar and syntax of EXPRESS-Q
+
+ -
+
The semantics of EXPRESS-Q constructs
+
+ -
+
The reference path syntax used for defining detailed mappings
+
+ -
+
Validation rules for EXPRESS-Q files
+
+ -
+
Guidelines for implementing EXPRESS-Q parsers and validators
+
+
This specification is intended for use by software developers, data modelers, +and systems integrators working with EXPRESS schemas and STEP application +protocols.
+Normative references
+ +Terms and definitions
+EXPRESS-Q
+query language for EXPRESS schemas, used to define mappings and constraints +between ARM and MIM schemas
+EXPRESS-Q language specification
+Overview
+EXPRESS-Q is designed to work alongside EXPRESS schemas, providing a mechanism +to define mappings between ARM and MIM schemas, as well as specifying +constraints on datasets. The language uses a syntax similar to EXPRESS but +introduces new constructs specific to querying and mapping.
+An EXPRESS-Q file typically consists of one or more entity mappings, each of +which defines how an ARM entity and its attributes correspond to MIM elements. +These mappings can include various declarations such as extensibility, AIM +elements, sources, EXPRESS references, reference paths, and alternative +mappings.
+EBNF grammar
+The following EBNF (Extended Backus-Naur Form) grammar defines the syntax of +EXPRESS-Q:
+express_q_file = { entity_mapping } ;
+
+entity_mapping = "ENTITY_MAPPING" entity_name ";" newline
+ [ extensible_decl ]
+ [ aim_element_decl ]
+ [ source_decl ]
+ [ express_ref_decl ]
+ [ refpath_decl ]
+ [ alt_map_decl ]
+ { attribute_mapping }
+ "END_ENTITY_MAPPING" ";" ;
+
+extensible_decl = "EXTENSIBLE" ":" boolean ";" newline ;
+
+aim_element_decl = "AIM_ELEMENT" ":" string ";" newline ;
+
+source_decl = "SOURCE" ":" string ";" newline ;
+
+express_ref_decl = "EXPRESS_REF" ":" "[" [ string { "," string } ] "]" ";" newline ;
+
+refpath_decl = "REFPATH" ":" "{" newline
+ refpath_content
+ "}" ";" newline ;
+
+refpath_content = { refpath_line } ;
+
+refpath_line = [ indentation ] reference_expression newline ;
+
+reference_expression = entity_reference [ relationship { relationship } ] ;
+
+relationship = path_relation | supertype_relation | subtype_relation |
+ select_extension | constraint ;
+
+entity_reference = identifier ;
+
+path_relation = "->" entity_reference ;
+
+supertype_relation = "=>" entity_reference ;
+
+subtype_relation = "<=" entity_reference ;
+
+select_extension = "*" ">" entity_reference | "<" "*" entity_reference ;
+
+constraint = "[" constraint_expression "]" ;
+
+constraint_expression = ? expression following EXPRESS syntax ? ;
+
+indentation = ? one or more spaces or tabs ? ;
+
+alt_map_decl = "ALT_MAP" ":" "[" [ string { "," string } ] "]" ";" newline ;
+
+attribute_mapping = "ATTRIBUTE_MAPPING" attribute_name ";" newline
+ "ASSERTION_TO" ":" string ";" newline
+ [ aim_element_decl ]
+ [ source_decl ]
+ [ express_ref_decl ]
+ [ refpath_decl ]
+ "END_ATTRIBUTE_MAPPING" ";" newline ;
+
+entity_name = identifier ;
+
+attribute_name = identifier ;
+
+identifier = letter { letter | digit | "_" } ;
+
+boolean = "TRUE" | "FALSE" ;
+
+string = '"' { character } '"' ;
+
+letter = "A" | ... | "Z" | "a" | ... | "z" ;
+
+digit = "0" | ... | "9" ;
+
+character = ? any printable character ? ;
+
+indentation = ? one or more spaces or tabs ? ;
+
+newline = ? line break character(s) ? ;This grammar defines the overall structure of an EXPRESS-Q file, including +entity mappings, attribute mappings, reference paths, including various types +of relationships between entities and constraints, and various declarations.
+Semantics
+This section describes the meaning and usage of each major construct in EXPRESS-Q.
+Entity mapping
+entity_mapping = "ENTITY_MAPPING" entity_name ";" newline
+ [ extensible_decl ]
+ [ aim_element_decl ]
+ [ source_decl ]
+ [ express_ref_decl ]
+ [ refpath_decl ]
+ [ alt_map_decl ]
+ { attribute_mapping }
+ "END_ENTITY_MAPPING" ";" ;An entity mapping defines how an ARM entity corresponds to one or more MIM entities or constructs. It encapsulates all the information needed to map a single ARM entity to its MIM counterpart(s).
+-
+
- Usage +
-
+++
-
+
-
+
Begin with "ENTITY_MAPPING" followed by the ARM entity name.
+
+ -
+
Include optional declarations for extensibility, AIM element, source, EXPRESS references, reference path, and alternative mappings.
+
+ -
+
Include attribute mappings for the entity’s attributes.
+
+ -
+
End with "END_ENTITY_MAPPING".
+
+
+ -
+
ENTITY_MAPPING Product;
+EXTENSIBLE: FALSE;
+AIM_ELEMENT: "product";
+SOURCE: "ISO 10303-41";
+EXPRESS_REF: ["product_definition_schema"];
+REFPATH: {
+ product <= product_definition_formation
+ product_definition_formation.of_product -> product
+};
+ATTRIBUTE_MAPPING id;
+ASSERTION_TO: "id";
+AIM_ELEMENT: "product.id";
+END_ATTRIBUTE_MAPPING;
+END_ENTITY_MAPPING;
+Extensible declaration
+extensible_decl = "EXTENSIBLE" ":" boolean ";" newline ;The extensible declaration specifies whether the entity mapping is extensible, corresponding to the extensibility of SELECT types in EXPRESS schemas.
+-
+
- Usage +
-
+++
-
+
-
+
Use "EXTENSIBLE: TRUE;" for extensible mappings.
+
+ -
+
Use "EXTENSIBLE: FALSE;" for non-extensible mappings.
+
+
+ -
+
ENTITY_MAPPING ProductCategory; +EXTENSIBLE: TRUE; +... +END_ENTITY_MAPPING;+
AIM element declaration
+aim_element_decl = "AIM_ELEMENT" ":" string ";" newline ;The AIM element declaration specifies the corresponding AIM (MIM) element for the ARM entity, providing a direct link between the ARM and MIM schemas.
+-
+
- Usage +
-
+++
-
+
-
+
Specify the AIM element name as a string.
+
+
+ -
+
ENTITY_MAPPING Product; +AIM_ELEMENT: "product"; +... +END_ENTITY_MAPPING;+
Source declaration
+source_decl = "SOURCE" ":" string ";" newline ;The source declaration indicates the source (typically an ISO standard) of the MIM element, which is crucial for traceability and maintaining consistency with relevant standards.
+-
+
- Usage +
-
+++
-
+
-
+
Specify the source as a string, typically an ISO standard number.
+
+
+ -
+
ENTITY_MAPPING Product; +SOURCE: "ISO 10303-41"; +... +END_ENTITY_MAPPING;+
EXPRESS reference declaration
+express_ref_decl = "EXPRESS_REF" ":" "[" [ string { "," string } ] "]" ";" newline ;The EXPRESS reference declaration lists EXPRESS references related to the mapping, used to link the mapping to specific parts of the EXPRESS schemas or other relevant documentation.
+-
+
- Usage +
-
+++
-
+
-
+
Provide a comma-separated list of references enclosed in square brackets.
+
+ -
+
Use an empty list "[]" if there are no references.
+
+
+ -
+
ENTITY_MAPPING Product; +EXPRESS_REF: ["product_definition_schema", "management_resources_schema"]; +... +END_ENTITY_MAPPING;+
Reference path declaration
+General
+The reference path syntax in EXPRESS-Q is based on the ISO 10303 Mapping +Specification and is used within the REFPATH sections to define precise mappings +between ARM and MIM elements. This syntax allows for complex relationships and +constraints to be expressed concisely.
+refpath_decl = "REFPATH" ":" "{" newline
+ refpath_content
+ "}" ";" newline ;The reference path declaration defines the detailed mapping between ARM and MIM elements using the reference path syntax described earlier.
+-
+
- Usage +
-
+++
-
+
-
+
Begin with
+REFPATH: {and end with};.
+ -
+
Each line in the content describes a step in the mapping path.
+
+ -
+
Use indentation to indicate nested structures.
+
+ -
+
Use symbols like
+⇐,⇒,→to indicate relationships between entities and attributes.
+
+ -
+
ENTITY_MAPPING Product;
+REFPATH: {
+ product <= product_definition_formation
+ product_definition_formation.of_product -> product
+ {product.name -> product.name
+ product.description -> product.description}
+};
+...
+END_ENTITY_MAPPING;
+Symbols and meaning
+The reference path syntax uses several symbols to express relationships and constraints. These symbols are derived from the ISO 10303 Mapping Specification:
+-
+
[]
+-
+
Enclosed section constrains multiple MIM elements or sections of the reference +path required to satisfy an information requirement.
+
+ ()
+-
+
Enclosed section constrains multiple MIM elements or sections of the reference +path identified as alternatives within the mapping.
+
+ {}
+-
+
Enclosed section constrains the reference path to satisfy an information +requirement.
+
+ <>
+-
+
Enclosed section constrains one or more required reference paths.
+
+ ||
+-
+
Enclosed section constrains the supertype entity.
+
+ →
+-
+
The attribute whose name precedes the symbol references the entity or select type whose name follows the symbol.
+
+ ←
+-
+
The entity or select type whose name precedes the symbol is referenced by the entity attribute whose name follows the symbol.
+
+ [i]
+-
+
The attribute whose name precedes the symbol is an aggregate; any element of that aggregate is referred to.
+
+ [n]
+-
+
The attribute whose name precedes the symbol is an ordered aggregate; member n of that aggregate is referred to.
+
+ ⇒
+-
+
The entity whose name precedes the symbol is a supertype of the entity whose name follows the symbol.
+
+ ⇐
+-
+
The entity whose name precedes the symbol is a subtype of the entity whose name follows the symbol.
+
+ =
+-
+
The string, select, or enumeration type is constrained to a choice or value.
+
+ \
+-
+
The reference path expression continues on the next line.
+
+ *
+-
+
One or more instances of the relationship entity data type may be assembled in a relationship tree structure.
+
+ --
+-
+
The text following is a comment or introduces a clause reference.
+
+ *>
+-
+
The select or enumeration type whose name precedes the symbol is extended into the select or enumeration type whose name follows the symbol.
+
+ <*
+-
+
The select or enumeration type whose name precedes the symbol is an extension of the select or enumeration type whose name follows the symbol.
+
+ !{}
+-
+
Section enclosed by
+{}indicates a negative constraint placed on the mapping.
+
Usage and examples
+The reference path syntax is used to define precise mappings between ARM and MIM +elements. Here are some examples demonstrating various aspects of the syntax:
+REFPATH: {
+ product.id -> id
+}REFPATH: {
+ mechanical_context <= product_context
+}REFPATH: {
+ shape_representation <= representation
+ {representation.items[i] -> representation_item
+ representation_item =>
+ (geometric_representation_item
+ [geometric_representation_item.dim = 3] |
+ mapped_item)
+ }
+}REFPATH: {
+ person_and_organization_select *> organization
+}REFPATH: {
+ product_definition_formation
+ !{product_definition_formation.make_or_buy = bought_item}
+}Validation rules for reference paths
+When validating reference paths, the following rules should be applied:
+-
+
-
+
All referenced entities and attributes shall exist in the corresponding ARM or MIM schema.
+
+ -
+
The relationships between entities (supertype, subtype, attribute reference) shall be consistent with the schema definitions.
+
+ -
+
Constraints shall be syntactically correct and use only attributes or functions that are valid for the constrained entity.
+
+ -
+
Select type extensions shall be consistent with the schema definitions.
+
+ -
+
Aggregate references (using
+[i]or[n]) shall be applied only to attributes defined as aggregates in the schema.
+ -
+
Alternative mappings (using parentheses) shall all be valid according to the schema.
+
+ -
+
Negative constraints shall be logically consistent with the rest of the mapping and the schema definitions.
+
+ -
+
The overall structure of the reference path shall form a valid path through the schema, connecting the source ARM entity to the target MIM entity or attribute.
+
+
Alternative mapping declaration
+alt_map_decl = "ALT_MAP" ":" "[" [ string { "," string } ] "]" ";" newline ;The alternative mapping declaration specifies alternative mappings, allowing for flexibility in cases where multiple valid mappings exist.
+-
+
- Usage +
-
+++
-
+
-
+
Provide a comma-separated list of alternative mappings enclosed in square brackets.
+
+ -
+
Use an empty list "[]" if there are no alternative mappings.
+
+
+ -
+
ENTITY_MAPPING GeometricRepresentation; +ALT_MAP: ["shape_representation", "tessellated_shape_representation"]; +... +END_ENTITY_MAPPING;+
Attribute mapping
+attribute_mapping = "ATTRIBUTE_MAPPING" attribute_name ";" newline
+ "ASSERTION_TO" ":" string ";" newline
+ [ aim_element_decl ]
+ [ source_decl ]
+ [ express_ref_decl ]
+ [ refpath_decl ]
+ "END_ATTRIBUTE_MAPPING" ";" newline ;An attribute mapping defines how an individual attribute of an ARM entity corresponds to elements in the MIM schema.
+-
+
- Usage +
-
+++
-
+
-
+
Begin with "ATTRIBUTE_MAPPING" followed by the attribute name.
+
+ -
+
Specify the ASSERTION_TO value, which indicates the corresponding MIM element or type.
+
+ -
+
Optionally include AIM_ELEMENT, SOURCE, EXPRESS_REF, and REFPATH declarations.
+
+ -
+
End with "END_ATTRIBUTE_MAPPING".
+
+
+ -
+
ENTITY_MAPPING Product;
+ATTRIBUTE_MAPPING id;
+ASSERTION_TO: "id";
+AIM_ELEMENT: "product.id";
+REFPATH: {
+ product.id -> id
+};
+END_ATTRIBUTE_MAPPING;
+
+ATTRIBUTE_MAPPING name;
+ASSERTION_TO: "label";
+AIM_ELEMENT: "product.name";
+SOURCE: "ISO 10303-41";
+EXPRESS_REF: ["product_definition_schema"];
+REFPATH: {
+ product.name -> name
+};
+END_ATTRIBUTE_MAPPING;
+END_ENTITY_MAPPING;
+Validation rules
+General
+Validation of EXPRESS-Q files is crucial to ensure the correctness and consistency of mappings between ARM and MIM schemas. The following rules should be applied when validating EXPRESS-Q files.
+Entity mapping validation
+-
+
-
+
Each ENTITY_MAPPING shall correspond to an entity defined in the ARM schema.
+
+ -
+
The AIM_ELEMENT specified shall exist in the MIM schema.
+
+ -
+
The SOURCE referenced shall be a valid ISO standard or other recognized source.
+
+ -
+
All EXPRESS_REF entries shall refer to valid EXPRESS schemas.
+
+ -
+
The REFPATH shall form a valid path from the ARM entity to the specified AIM_ELEMENT.
+
+ -
+
If ALT_MAP is specified, all alternative mappings shall be valid MIM entities.
+
+
Attribute mapping validation
+-
+
-
+
Each ATTRIBUTE_MAPPING shall correspond to an attribute of the ARM entity being mapped.
+
+ -
+
The ASSERTION_TO value shall be a valid type or entity in the MIM schema.
+
+ -
+
If specified, the AIM_ELEMENT shall exist in the MIM schema.
+
+ -
+
The REFPATH for an attribute shall form a valid path from the ARM attribute to the specified MIM element.
+
+
Reference path validation
+-
+
-
+
All entities and attributes referenced in the REFPATH shall exist in either the ARM or MIM schema, as appropriate.
+
+ -
+
Relationships between entities (e.g., subtype, supertype) shall be consistent with the schema definitions.
+
+ -
+
Constraints specified in the REFPATH shall use valid attributes or functions for the entities they constrain.
+
+ -
+
SELECT type extensions shall be consistent with the schema definitions.
+
+ -
+
Aggregate references (using
+[i]or[n]) shall only be applied to attributes defined as aggregates in the schema.
+
Overall consistency
+-
+
-
+
The complete set of mappings shall cover all entities and attributes in the ARM schema.
+
+ -
+
There should be no conflicting mappings (e.g., two different mappings for the same ARM entity or attribute).
+
+ -
+
The overall set of mappings should form a consistent and complete transformation from the ARM to the MIM schema.
+
+
Implementation guidelines
+General
+When implementing an EXPRESS-Q parser and validator, consider the following guidelines.
+Parsing
+-
+
-
+
Implement a lexical analyzer to tokenize the EXPRESS-Q input.
+
+ -
+
Develop a parser based on the EBNF grammar provided in this specification.
+
+ -
+
Create an abstract syntax tree (AST) or similar internal representation of the parsed EXPRESS-Q file.
+
+
Schema loading
+-
+
-
+
Implement an EXPRESS schema parser or use an existing library to load and interpret ARM and MIM schemas.
+
+ -
+
Create internal representations of the schemas that allow for efficient querying of entities, attributes, and relationships.
+
+
Validation
+-
+
-
+
Implement validation checks based on the rules outlined in the "Validation rules" section.
+
+ -
+
Perform two-pass validation:
+++-
+
-
+
First pass: Check syntax and basic semantic rules (e.g., entity and attribute existence).
+
+ -
+
Second pass: Validate complex semantic rules (e.g., consistency of reference paths).
+
+
+ -
+
-
+
Provide clear and informative error messages for validation failures.
+
+
Reference path interpretation
+-
+
-
+
Implement a separate parser for the reference path syntax.
+
+ -
+
Develop algorithms to traverse reference paths within the context of the loaded schemas.
+
+ -
+
Implement functions to evaluate constraints specified in reference paths.
+
+
Performance considerations
+-
+
-
+
Use efficient data structures (e.g., hash tables) for quick lookups of schema elements.
+
+ -
+
Implement caching mechanisms for frequently accessed schema information.
+
+ -
+
Consider parallel processing for validating multiple entity or attribute mappings simultaneously.
+
+
Extensibility
+-
+
-
+
Design the implementation to be extensible, allowing for future enhancements to the EXPRESS-Q language.
+
+ -
+
Use modular design to separate concerns (e.g., parsing, schema handling, validation).
+
+
Integration
+-
+
-
+
Provide APIs or interfaces for integrating the EXPRESS-Q parser and validator into larger systems or workflows.
+
+ -
+
Consider implementing export functionality to generate reports or machine-readable representations of the validation results.
+
+
Use cases and examples
+General
+This section provides examples of how EXPRESS-Q can be used in various scenarios +related to STEP application protocols.
+Use case 1: Mapping a complex product structure
+In this example, we’ll demonstrate how EXPRESS-Q can be used to map a complex product structure from an ARM schema to a MIM schema.
+ENTITY_MAPPING Product;
+AIM_ELEMENT: "product";
+SOURCE: "ISO 10303-41";
+REFPATH: {
+ product <= product_definition_formation
+ product_definition_formation.of_product -> product
+};
+
+ATTRIBUTE_MAPPING id;
+ASSERTION_TO: "id";
+AIM_ELEMENT: "product.id";
+END_ATTRIBUTE_MAPPING;
+
+ATTRIBUTE_MAPPING name;
+ASSERTION_TO: "label";
+AIM_ELEMENT: "product.name";
+END_ATTRIBUTE_MAPPING;
+
+ATTRIBUTE_MAPPING description;
+ASSERTION_TO: "text";
+AIM_ELEMENT: "product.description";
+END_ATTRIBUTE_MAPPING;
+
+ATTRIBUTE_MAPPING components;
+ASSERTION_TO: "SET OF Component";
+REFPATH: {
+ product <- product_definition_formation
+ product_definition_formation <- product_definition
+ product_definition <- product_definition_relationship.relating_product_definition
+ product_definition_relationship ->
+ product_definition_relationship.related_product_definition
+ product_definition_relationship.related_product_definition -> product_definition
+ product_definition -> product_definition_formation
+ product_definition_formation -> product
+};
+END_ATTRIBUTE_MAPPING;
+
+END_ENTITY_MAPPING;
+
+ENTITY_MAPPING Component;
+AIM_ELEMENT: "product";
+SOURCE: "ISO 10303-41";
+REFPATH: {
+ product <= product_definition_formation
+ product_definition_formation.of_product -> product
+};
+
+ATTRIBUTE_MAPPING id;
+ASSERTION_TO: "id";
+AIM_ELEMENT: "product.id";
+END_ATTRIBUTE_MAPPING;
+
+ATTRIBUTE_MAPPING name;
+ASSERTION_TO: "label";
+AIM_ELEMENT: "product.name";
+END_ATTRIBUTE_MAPPING;
+
+ATTRIBUTE_MAPPING quantity;
+ASSERTION_TO: "measure_with_unit";
+REFPATH: {
+ product <- product_definition_formation
+ product_definition_formation <- product_definition
+ product_definition <- product_definition_relationship
+ product_definition_relationship.related_product_definition_quantity -> measure_with_unit
+};
+END_ATTRIBUTE_MAPPING;
+
+END_ENTITY_MAPPING;
+This example demonstrates how a product with multiple components can be mapped from an ARM schema to a MIM schema using EXPRESS-Q. It shows the use of complex reference paths to navigate relationships between entities in the MIM schema.
+Use case 2: Mapping with alternative representations
+This example shows how EXPRESS-Q can handle cases where an ARM entity might be mapped to different MIM representations based on certain conditions.
+ENTITY_MAPPING GeometricRepresentation;
+ALT_MAP: ["shape_representation", "tessellated_shape_representation"];
+SOURCE: "ISO 10303-42";
+
+REFPATH: {
+ (shape_representation <= representation
+ [representation.context_of_items->geometric_representation_context]) |
+ (tessellated_shape_representation <= representation
+ [representation.context_of_items->geometric_representation_context])
+};
+
+ATTRIBUTE_MAPPING items;
+ASSERTION_TO: "SET OF geometric_representation_item";
+REFPATH: {
+ representation.items[i] -> geometric_representation_item
+};
+END_ATTRIBUTE_MAPPING;
+
+END_ENTITY_MAPPING;
+This example demonstrates how EXPRESS-Q can handle alternative mappings for a single ARM entity. The GeometricRepresentation entity can be mapped to either a shape_representation or a tessellated_shape_representation in the MIM schema, depending on the specific requirements of the application.
+Summary
+EXPRESS-Q provides a powerful and flexible language for defining mappings between ARM and MIM schemas in the context of STEP application protocols. By offering a standardized way to express these mappings, EXPRESS-Q facilitates more robust and reliable data exchange in complex engineering and manufacturing environments.
+Key features of EXPRESS-Q include:
+-
+
-
+
A syntax that is familiar to users of EXPRESS, reducing the learning curve.
+
+ -
+
The ability to define detailed mappings between ARM and MIM entities and attributes.
+
+ -
+
Support for complex reference paths, allowing for navigation through intricate schema relationships.
+
+ -
+
Mechanisms for specifying constraints and alternative mappings.
+
+ -
+
Clear separation of entity and attribute mappings for improved readability and maintainability.
+
+
The validation rules and implementation guidelines provided in this specification aim to ensure consistent interpretation and implementation of EXPRESS-Q across different tools and systems.
+Future considerations
+As the use of EXPRESS-Q grows and evolves, several areas may be considered for future enhancements:
+Extended constraint language
+Future versions of EXPRESS-Q might benefit from a more expressive constraint language, allowing for more complex conditions and transformations to be specified within mappings.
+Integration with other standards
+Consideration should be given to how EXPRESS-Q can be integrated with other relevant standards and technologies, such as ontology languages or model transformation frameworks.
+Tool support
+Development of standardized libraries and tools for parsing, validating, and processing EXPRESS-Q files would greatly facilitate its adoption and use.
+Reverse mapping capabilities
+Future versions might include capabilities for defining bi-directional mappings, allowing for the generation of ARM instances from MIM data.
+Performance optimizations
+As EXPRESS-Q is used with increasingly large and complex schemas, performance optimizations in both the language design and implementation guidelines may become necessary.
+Appendix A: Complete EXPRESS-Q file example
+This annex provides a complete example of an EXPRESS-Q file, demonstrating +various features of the language in a cohesive context.
+-- Example EXPRESS-Q file for a simplified product data model
+
+ENTITY_MAPPING Product;
+EXTENSIBLE: FALSE;
+AIM_ELEMENT: "product";
+SOURCE: "ISO 10303-41";
+EXPRESS_REF: ["product_definition_schema"];
+REFPATH: {
+ product <= product_definition_formation
+ product_definition_formation.of_product -> product
+};
+
+ATTRIBUTE_MAPPING id;
+ASSERTION_TO: "identifier";
+AIM_ELEMENT: "product.id";
+REFPATH: {
+ product.id -> id
+};
+END_ATTRIBUTE_MAPPING;
+
+ATTRIBUTE_MAPPING name;
+ASSERTION_TO: "label";
+AIM_ELEMENT: "product.name";
+REFPATH: {
+ product.name -> name
+};
+END_ATTRIBUTE_MAPPING;
+
+ATTRIBUTE_MAPPING description;
+ASSERTION_TO: "text";
+AIM_ELEMENT: "product.description";
+REFPATH: {
+ product.description -> description
+};
+END_ATTRIBUTE_MAPPING;
+
+ATTRIBUTE_MAPPING category;
+ASSERTION_TO: "product_category";
+REFPATH: {
+ product <- product_category_assignment.products[i]
+ product_category_assignment -> product_category_assignment.assigned_category
+ product_category_assignment.assigned_category -> product_category
+};
+END_ATTRIBUTE_MAPPING;
+
+END_ENTITY_MAPPING;
+
+ENTITY_MAPPING Assembly;
+EXTENSIBLE: FALSE;
+AIM_ELEMENT: "product";
+SOURCE: "ISO 10303-44";
+EXPRESS_REF: ["product_structure_schema"];
+REFPATH: {
+ product <= product_definition_formation
+ product_definition_formation.of_product -> product
+ [product <- product_definition_formation
+ product_definition_formation <- product_definition
+ product_definition <- assembly_component_usage.relating_product_definition]
+};
+
+ATTRIBUTE_MAPPING components;
+ASSERTION_TO: "SET OF AssemblyComponent";
+REFPATH: {
+ product <- product_definition_formation
+ product_definition_formation <- product_definition
+ product_definition <- assembly_component_usage.relating_product_definition
+ assembly_component_usage -> assembly_component_usage.related_product_definition
+ assembly_component_usage.related_product_definition -> product_definition
+ product_definition -> product_definition_formation
+ product_definition_formation -> product
+};
+END_ATTRIBUTE_MAPPING;
+
+END_ENTITY_MAPPING;
+
+ENTITY_MAPPING AssemblyComponent;
+EXTENSIBLE: FALSE;
+AIM_ELEMENT: "product";
+SOURCE: "ISO 10303-44";
+EXPRESS_REF: ["product_structure_schema"];
+REFPATH: {
+ product <= product_definition_formation
+ product_definition_formation.of_product -> product
+};
+
+ATTRIBUTE_MAPPING quantity;
+ASSERTION_TO: "measure_with_unit";
+REFPATH: {
+ product <- product_definition_formation
+ product_definition_formation <- product_definition
+ product_definition <- assembly_component_usage
+ assembly_component_usage.quantity -> measure_with_unit
+};
+END_ATTRIBUTE_MAPPING;
+
+END_ENTITY_MAPPING;
+
+ENTITY_MAPPING GeometricRepresentation;
+EXTENSIBLE: TRUE;
+ALT_MAP: ["shape_representation", "tessellated_shape_representation"];
+SOURCE: "ISO 10303-42";
+EXPRESS_REF: ["geometric_model_schema"];
+
+REFPATH: {
+ (shape_representation <= representation
+ [representation.context_of_items->geometric_representation_context]) |
+ (tessellated_shape_representation <= representation
+ [representation.context_of_items->geometric_representation_context])
+};
+
+ATTRIBUTE_MAPPING items;
+ASSERTION_TO: "SET OF geometric_representation_item";
+REFPATH: {
+ representation.items[i] -> geometric_representation_item
+};
+END_ATTRIBUTE_MAPPING;
+
+END_ENTITY_MAPPING;This example demonstrates a simplified product data model, including mappings +for products, assemblies, assembly components, and geometric representations. It +showcases various features of EXPRESS-Q, including:
+-
+
-
+
Entity and attribute mappings
+
+ -
+
Reference paths with complex relationships
+
+ -
+
Alternative mappings
+
+ -
+
Constraints within reference paths
+
+ -
+
Use of SELECT types (implied by the EXTENSIBLE: TRUE; in GeometricRepresentation)
+
+
This example is not exhaustive but provides a realistic scenario that +illustrates how EXPRESS-Q can be used to define mappings between ARM and MIM +schemas in a STEP application protocol context.
+