CEN CWA 15141
WORKSHOP December 2004
AGREEMENT
ICS 35.240.99
English version
European eConstruction Meta-Schema (EeM)
This CEN Workshop Agreement has been drafted and approved by a Workshop of representatives of interested parties, the constitution of which is indicated in the foreword of this Workshop Agreement.
The formal process followed by the Workshop in the development of this Workshop Agreement has been endorsed by the National Members of CEN but neither the National Members of CEN nor the CEN Management Centre can be held accountable for the technical content of this CEN Workshop Agreement or possible conflicts with standards or legislation.
This CEN Workshop Agreement can in no way be held as being an official standard developed by CEN and its Members.
This CEN Workshop Agreement is publicly available as a reference document from the CEN Members National Standard Bodies.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36 B-1050 Brussels
© 2004 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members.
Ref. No.:CWA 15141:2004 E CWA 15141:2004 (E)
Contents
Contents ...... 2 Figures...... 4 Tables...... 4 Foreword ...... 5 Introduction...... 6 1 Scope ...... 7 2 References ...... 8 3 Information Modelling Framework...... 11 3.1 Aims of a Model...... 11 3.2 Model Approach ...... 11 4 Formal Languages...... 13 4.1 EXPRESS...... 13 4.2 UML ...... 14 4.2.1 Main Packages...... 14 4.3 XSD ...... 15 4.4 Topic Maps ...... 16 4.5 Semantic Web ...... 17 4.5.1 RDF ...... 17 4.5.2 OWL ...... 18 4.6 Software Tools...... 19 5 Schema ...... 20 5.1 Why is a Schema Important? ...... 20 5.2 Methodologies and Concepts Used in Schema Development ...... 20 5.2.1 Abstraction and Hierarchy ...... 20 5.2.2 Generalisation Versus Specialisation...... 21 5.2.3 Objectified Relationships...... 21 5.2.4 Definition/Specification Distinction ...... 22 5.2.5 Type/Occurrence Distinction ...... 23 5.3 Existing Schema Definitions...... 24 6 Recommendations...... 25 6.1 Language...... 25 6.2 Technical Schemas ...... 26 6.3 Business Schemas...... 26 6.4 Ontology ...... 27 6.5 Related Actions ...... 27 7 Approaches to Development and Adoption...... 28 Appendix A Schema Developments ...... 29 A.1 ISO 12006 Part 2...... 29 A.1.1 Key concepts...... 30 A.2 ISO 12006-3 ...... 30 A.2.1 BARBi/Lexicon...... 32 A.3 IFC...... 33 A.3.1 Basic Structure ...... 34 A.3.2 Object Entities ...... 37 A.3.3 Relationship Entities...... 37 A.3.4 Property Sets...... 38 A.3.5 Ifc2x Release Series ...... 39 A.3.6 Lifecycle Concepts ...... 39 A.3.7 Application of Ontology...... 39 A.3.8 ifcXML ...... 40
2 CWA 15141:2004 (E)
A.4 ISO 15926 / EPISTLE...... 40 A.4.1 ‘thing’ ...... 40 A.4.2 ‘individual’ ...... 40 A.4.3 ‘relation’ ...... 41 A.4.4 ‘class’...... 42 A.4.5 Taxonomy...... 42 A.4.6 Reference Data ...... 43 A.5 STEP ...... 43 A.5.1 Backbone Architecture ...... 43 A.5.2 STEP in Building Construction ...... 45 A.6 PLIB...... 46 A.7 bcXML ...... 47 Appendix B Current manifestations...... 49 B.1 Glossaries of Terms ...... 49 B.2 Thesauri...... 49 B.3 Classifications...... 49 B.3.1 The IFC Classification Model ...... 49 Appendix C Interrelationships among schemas...... 52 C.1 Integration of ISO PAS 12006-3 and IFC ...... 52 C.1.1 bcXML/ ISO DIS 12006-3...... 52 C.1.2 Integration of OWL with IFC and Catalogue ...... 52 C.1.3 Core Ontology ...... 53 C.1.4 Catalogue Ontology...... 54 C.1.5 Comparison ...... 55 C.1.6 OWL Potential ...... 56 Appendix D Comparison...... 57 D.1 Comparison of the EPISTLE Core Model and IFC Entities ...... 57 D.1.1 High Level Concepts ...... 57 D.1.2 Reference Data Property Sets...... 59 D.1.3 Conclusions...... 59 D.2 Comparison of STEP and IFC Entities ...... 60 D.2.1 Comparison of STEP and IFC Property Mechanisms...... 61 D.2.2 ISO 10303 Part 225 and IFC Entities ...... 63
3 CWA 15141:2004 (E)
Figures Figure 1: Three layers of the approach architecture...... 12 Figure 2: Three approach layers compared with different paradigms...... 14 Figure 3: Top level packages in UML 1.4...... 15 Figure 4: Foundation packages in the UML ...... 15 Figure 5: three approach layers in XSD ...... 16 Figure 6: Basic concepts in the topic map meta-schema ...... 17 Figure 7: Topic in ISO 13520 topic map meta-schema ...... 17 Figure 8: Basic structure of an RDF graph...... 18 Figure 9: Specialisation tree ...... 21 Figure 10: Objectified relationships...... 22 Figure 11: General space definition ...... 22 Figure 12: Specific functional uses of space...... 22 Figure 13: Type/occurrence differentiation...... 23 Figure 14: Example of definition, specification/type and occurrence levels ...... 24 Figure 15: Overview of recommendations...... 25 Figure 16: Potential Future Route...... 26 Figure 17: Approach to defining communal schemas ...... 28 Figure 18: Simplified view of ISO 12006-2 meta-schema...... 29 Figure 19: Top level structure of ISO 12006-3 ...... 31 Figure 20: Relationship structure in ISO 12006-3 ...... 32 Figure 21: Lexicon screen showing dictionary terms in English ...... 33 Figure 22: Entity structuring of the IFC model...... 34 Figure 23: An overview of the key parts of the IFC model...... 36 Figure 24: Where the IFC model terminates at 'leaf nodes' ...... 38 Figure 25: Tank type and occurrence entities ...... 39 Figure 26: Type based property sets for a tank...... 39 Figure 27: Definition of
Tables Table 1: Model approach layers...... 12 Table 2: Type specifications for meta level concepts ...... 23 Table 3: Subtypes of individual and IfcObject ...... 58 Table 4: Comparison of IFC and STEP entities ...... 61 Table 5: Representation of type of property and individual property ...... 62 Table 6: Representation of single property and collection of properties ...... 62
4 CWA 15141:2004 (E)
Foreword
This CEN Workshop Agreement was approved by the CEN/ISSS Workshop on eConstruction at the final plenary meeting held in Delft (NL) on 2004-05-13. The final endorsement round for this CWA started on 2004-03-23 and was successfully closed on 2004-05-13.The final text of this CWA was submitted to CEN for publication on 2004- 06-03.
The CEN/ISSS Workshop on eConstruction, launched on 2003-01-22 in Brussels, gathered organizations from the building and construction sector. The Workshop run in parallel to the European project SPICE (Specifications for Integrated Construction E-standards). Input was received from various other European R&D activities: FP5 IST eConstruct, eCognos, OSMOS, Divercity, E-CORE network, ICCI cluster, ROADCON Roadmap and PRODAEC.
The present CWA is the third of a set of five CWAs describing ICT in the construction industry, drafted and agreed by consensus in the CEN/ISSS Workshop on eConstruction:
1) European eConstruction Framework
2) European eConstruction Architecture
3) European eConstruction Meta-schema
4) European eConstruction Ontology
5) European eConstruction Software Toolset
This CEN Workshop Agreement is publicly available as a reference document from the National Members of CEN : AENOR, AFNOR, BSI, CSNI, CYS, DIN, DS, ELOT, EVS, IBN/BIN, IPQ, IST, LST, LVS, MSA, MSZT, NEN, NSAI, NSF, ON, PKN, SEE, SFS, SIS, SIST, SNV, SUTN, UNI.
Comments or suggestions from the users of the CEN Workshop Agreement are welcome and should be addressed to the CEN Management Centre.
5 CWA 15141:2004 (E)
Introduction
The ICT landscape in the Construction industry sector is typically as fragmented as the industry itself. This is not necessary a problem (since fragmentation is often related to flexibility) but it often results in a lot of misconception and miscommunication among the different stakeholders and their supporting ICT systems involved, all having their own understanding and view on activities, results and mechanisms in construction processes.
Ask three stakeholders what a ‘wall’ is and they almost certainly come with three descriptions that barely overlap. The same situation or worse is true for ICT: ask three ICT people about the way they think about process-related concepts like ‘total life-cycle’, ’knowledge management’ or ‘performance-driven’ or even about things belonging to their core-competence like ‘model-based’ or ‘open-integrated’ or ‘object-oriented’ and they all tell part of the(ir) story, sometimes overlapping, sometimes clashing but always giving room for miscommunication resulting in a situation where the right co-ordination between construction processes and co-operation between stakeholders is an exception.
Yet behind this, and regardless of the technology used, there are some consistent ideas about how to frame ideas in building construction. Such ideas do not go into the detail of the various components, processes and lifecycle within the building construction domain but they do describe general concepts within which it is possible to describe such detail. The detail can then be described using an ontology.
This document discusses approaches to the definition of such a framework. There are several frameworks, or meta-schemas to be more precise, that exist and these are discussed. The distinction is made between meta- schemas that describe very general and abstract concepts that are necessary in the structuring of an information model and those that describe broadly sharable ideas usually being specific to building construction. A meta- schema can therefore be seen as a schema on a high level of abstraction.
A schema is nothing more than an agreed structure expressed in some suitable and mostly formal language for describing the things on the different ‘description levels’. It should be able to handle definitions, specifications and occurrences of construction-related products and services.
As well as describing the concepts of ‘language’, ‘schema’ and the various ‘description levels’, the document reports on a number of initiatives that are applying meta-schemas and compares their scope and usage.
Finally, an overview of ideas that might be brought together within a unified meta-schema for the building construction industry are described.
6 CWA 15141:2004 (E)
1 Scope
This document defines the difference between meta-schemas operating as a definition for data provision and ontology acting as the specification of value and relationship at an operational level. It describes a number of meta-schemas that have been developed to support ‘ICT in Construction’ (or any synonym thereof as described in CWA 14946:2004).
The purpose of this document is to define the required content of a meta-schema that is within the ‘space’ of eConstruction and to recommend approaches to their use in a consistent way.
This document can function as a reference for meta-schema for all stakeholders, not just researchers but also clients, owners, users, founders and the building industry parties themselves (architects, engineers, consultants, main/sub-contractors, suppliers, manufacturers and their umbrella and service organisations). Especially strategists and people having to decide on future ICT innovation steps are within the intended audience.
This document provides foundation material that describes the concept of a meta-schema and develops some key ideas that may be described within such a meta-schema that is applied to the domain of building construction. A distinction is made between the concept of the meta-schema and the broader idea of ontology that is further described in the CWA “European eConstruction Ontology”.
In the context of this document, the term meta-schema is used to make a set of fundamental ideas explicit using a formal language. A meta-schema can then be used by extension in the actual creation of a schema or ontology that will do something useful.
Section 1 defines the scope of this Agreement.
Section 2 identifies the references that constitute provisions of this Agreement.
Section 3 provides an overview of an information modelling framework in which the separation of ideas between language, schema and objects is defined.
Section 4 provides information on formal languages in which meta-schemas applicable to building construction are, or may be, expressed.
Section 5 describes the concept of a set of schemas that allow us to make an abstraction of the real world in a useful form.
Section 6 considers the current state of development of schemas relevant to building construction and defines recommendations for progress in further development.
Appendix A provides information on current schema developments in building construction.
Appendix B provides information on schemas that underlie some basic working ideas in building construction and that are particularly relevant to further expansion in discussions on ontology.
Appendix C discusses the interrelationships that may be seen amongst schemas.
Appendix D makes some comparisons between leading candidates for schema standardisation.
7 CWA 15141:2004 (E)
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this document are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies.
For definition of terms and abbreviations, see CWA 14946:2004.
Data-oriented:
ISO 10303-1:1994 Industrial automation systems and integration -- Product data representation and exchange -- Part 1: Overview and fundamental principles ISO 10303-11:1994 Industrial automation systems and integration -- Product data representation and exchange -- Part 11: Description methods: The EXPRESS language reference manual ISO 10303-21:2002 Industrial automation systems and integration -- Product data representation and exchange -- Part 21: Implementation methods: Clear text encoding of the exchange structure ISO 10303-22:1998 Industrial automation systems and integration -- Product data representation and exchange -- Part 22: Implementation methods: Standard data access interface ISO 10303-28:2003 Industrial automation systems and integration -- Product data representation and exchange -- Part 28: Implementation methods: XML representations of EXPRESS schemas and data ISO 10303-41:2000 Industrial automation systems and integration -- Product data representation and exchange -- Part 41: Integrated generic resource: Fundamentals of product description and support ISO 10303-42:2003 Industrial automation systems and integration -- Product data representation and exchange -- Part 42: Integrated generic resource: Geometric and topological representation ISO 10303-43:2000 Industrial automation systems and integration -- Product data representation and exchange -- Part 43: Integrated generic resources: Representation structures ISO 10303-44:2000 Industrial automation systems and integration -- Product data representation and exchange -- Part 44: Integrated generic resource: Product structure configuration ISO 10303-45:1998 Industrial automation systems and integration -- Product data representation and exchange -- Part 45: Integrated generic resource: Materials ISO 10303-46:1994 Industrial automation systems and integration -- Product data representation and exchange -- Part 46: Integrated generic resources: Visual presentation ISO 12006-2:2001 Building construction -- Organization of information about construction works – Part 2: Framework for classification of information ISO/PAS 12006-3:2001 Building construction -- Organization of information about construction works – Part 3: Framework for object oriented information exchange ISO/CD 13520: 2003 Information Technology -- Document Description and Processing Languages – Topic Maps -- Data Model ISO 13584-1:2001 Industrial automation systems and integration -- Parts library -- Part 1: Overview and fundamental principles ISO/CD 15926 -1:2000 Industrial automation systems and integration -- Integration of life-cycle information for oil and gas production facilities -- Part 1: Overview and fundamental principles ISO/CD 15926 -2:2000 Industrial automation systems and integration -- Integration of life-cycle information for oil and gas production facilities -- Part 2: Data model ISO/PAS 16739: 2002 Industrial automation systems and integration -- Integration of life-cycle information for building construction – IFC2x platform specification ISO/TS 18876-1:2003 Industrial automation systems and integration -- Product data representation and exchange -- Part 1: Architecture overview and description
8 CWA 15141:2004 (E)
IFC 2x Industry Foundation Classes Release 2x: IAI 2000 http://www.iai-international.org IFC 2x2 Industry Foundation Classes Release 2x Edition 2: IAI 2003 http://www.iai-international.org
Functionality-oriented:
ebXML ebXML Technical Architecture Specification v1.0.4: ebXML, UN/CEFACT, OASIS 16 February 2001 http://www.ebxml.org/specs/ebTA.pdf
Base ICT Infrastructure:
HTTP Hypertext Transfer Protocol -- HTTP/1.1: The Internet Society 1999. http://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf IP IETF RFC791: Internet Protocol: DARPA Internet Program Protocol Specification: September 1981 ftp://ftp.rfc-editor.org/in-notes/rfc791.txt OWL OWL Web Ontology Language Overview : W3C Candidate Recommendation 18 August 2003 http://www.w3.org/TR/owl-features/ RDF Resource Description Framework : (RDF) Model and Syntax Specification: W3C Recommendation 15 December 2003 http://www.w3.org/TR/rdf-syntax-grammar/ RDF Schema RDF Vocabulary Description Language 1.0: RDF Schema: W3C Working Draft 10 October 2003 http://www.w3.org/TR/rdf-schema/ RELAX NG ISO/IEC 19757-2:2002(E), Document Schema Definition Languages (DSDL) — Part 2:Regular-grammar-based validation — RELAX NG, ISO/IEC JTC1 SC34 [added 28 April 2004] http://www.y12.doe.gov/sgml/sc34/document/0362_files/relaxng-is.pdf SOAP SOAP Version 1.2 Part 0: Primer: W3C Recommendation 24 June 2003 http://www.w3.org/TR/2003/REC-soap12-part0-20030624/ SMTP IETF RFC2821: Simple Mail Transfer Protocol: The Internet Society 2001. http://www.ietf.org/rfc/rfc2821.txt TCP IETF RFC793: Transmission Control Protocol: DARPA Internet Program Protocol Specification: September 1981 ftp://ftp.rfc-editor.org/in-notes/rfc793.txt UML Object Management Group (OMG): Unified Modeling Language, Version 1.5: March 2003 http://www.omg.org/technology/documents/formal/uml.htm URI Uniform Resource Identifiers (URI): Generic Syntax: The Internet Society 1998 http://www.ietf.org/rfc/rfc2396.txt XHTML XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition): A Reformulation of HTML 4 in XML 1.0 : W3C Recommendation 26 January 2000, revised 1 August 2002 http://www.w3.org/TR/xhtml1/ XML Extensible Markup Language (XML) 1.0 (Second Edition): W3C Recommendation 6 October 2000 http://www.w3.org/TR/REC-xml XML Namespace Namespaces in XML 1.1: W3C Proposed Recommendation 05 November 2003 http://www.w3.org/TR/2003/PR-xml-names11-20031105/ XML Schema Part 0 XML Schema Part 0: Primer: W3C Recommendation, 2 May 2001 http://www.w3.org/TR/xmlschema-0/
9 CWA 15141:2004 (E)
XML Schema Part 1 XML Schema Part 1: Structures: W3C Recommendation 2 May 2001 http://www.w3.org/TR/xmlschema-1/ XML Schema Part 2 XML Schema Part 2: Datatypes: W3C Recommendation 02 May 2001 http://www.w3.org/TR/xmlschema-2/ XPath XML Path Language (XPath): Version 1.0 : W3C Recommendation 16 November 1999 http://www.w3.org/TR/xpath XSL Transformations XSL Transformations (XSLT): Version 1.0 : W3C Recommendation 16 November 1999 http://www.w3.org/TR/xslt XTM XML Topic Maps (XTM) 1.0 : TopicMaps.Org Specification http://www.topicmaps.org/xtm/1.0/
10 CWA 15141:2004 (E)
3 Information Modelling Framework
3.1 Aims of a Model
Developing a schema (or model)1 for a robust software or data application before constructing it is the same as the architectural and engineering design for a complex building. It describes the intent of design and a framework for construction. In particular, it provides an abstraction of the information domain concerned at an appropriate level of detail and completeness.
Good models are essential for communication among project teams and to assure architectural soundness. Models of complex systems are developed to facilitate understanding of the whole system.
Similarly good information models are essentially for the collaboration within a software engineering projects and between the software analysis, design, and programming phase. The same holds true for software interoperability – good models behind the interoperability standards are essential for its correctness, the unambiguousness of its definitions, and its interpretation by software.
An information model is a formal description of types of ideas, facts and processes which together form a model of a portion of interest of the real world and which provides an explicit set of interpretation rules. This definition has three parts:
formal description of types i.e. the extraction of the structure or concept, the ‘idea of the thing’, that is common for all occurrences of the type, the extraction should be formal to provide for an unambiguous understanding of the types portion of interest the well-known ‘universe of discourse’, portion since only a certain section of the real world domain is considered, interest since the model depends of the particular view, driven by the intents of the creator explicit set of interpretation rules defines how an unambiguous and precise meaning, namely the semantics, can be inferred from the formal description of types – this is provided by the formal language used. Therefore a formal modeling language should include:
• Model elements — fundamental modeling concepts and semantics, • Lexical and Graphical Notation — a computer-interpretable and visual indication of model elements, • Guidelines — approaches to the manner in which a model should be developed and interpreted. Models provide a better understanding of the reality (the artefacts, processes, or ideas in investigation) as they unveil the essence of the information behind, its structure, its relations and its validity. Modelling can provide techniques that partially automate the production of software, improve software quality and reduce cost and time- to-market and assist in managing the complexity of large-scale systems.
3.2 Model Approach
A well accepted approach for modeling uses an architecture with three layers. These are shown in the table below with a description of their functions.
Layer Description Example language A formal language used to represent Class, Attribute, Relation, Operation, Rule, modeling concepts from within the universe of discourse.
1 Often the term “model” is used in the same way as “schema” to denote an information model which is denoted within a “schema”. Within some literature both terms are used interchangeable. Here a “model” is the formal description of the universe of discourse and a “schema” is its descriptive notion in some lexical or graphical notation.
11 CWA 15141:2004 (E) schema A formal representation of concepts within Cost Item, maximum Cost, Cost per item, the universe of discourse (a view onto real- Currency (model) world objects and ideas). The formal representation is governed by the language chosen. user objects An instance of a model. Defines specific purchasing cost of €102,81, cost item #123 information within the structure and attached to air outlet with tag 234 (user data) meaning imposed by the chosen schema
Table 1: Model approach layers
The language layer forms the foundation for any formal schema definition. The primary responsibility of this layer is to define the general approach for specifying a model. A data definition language such as EXPRESS or a modeling framework such as UML or XML schema definitions (XSD) are examples of such formal languages.
A schema (or model) is a formal representation of concepts created using a formal language from the language layer. The primary responsibility of the schema layer is to specify models as abstract and formal representations of real ideas and elements (such as a structural analysis model, a procurement model or an integrated model comprising several construction disciplines). Such model may represent concepts at very different levels of abstraction, e.g. the general concept of a unit or a product, or specific concepts of a wall or a motor. Therefore a distinction is made between:
A meta-schema is considered to be a framework within which the broad concepts of information for the building construction industry are expressed. A model (or schema) is specialisation of a meta-schema. It is considered to be the general ideas that define concepts in building construction such as wall, door etc. User objects or user data are the instances (or occurrences) of classes specified within a model. The primary responsibility of the user objects layer is to describe the specifics of an information domain. They may include the provision of values to the attributes of a model element and always gives an identity to the object.
Formal Language O-O languages
Schema classes
Objects instances
General Approach Object Oriented Paradigm
Figure 1: Three layers of the approach architecture
Well established methods, such as object-oriented analysis, design and programming, use these layers to describe and develop complex software systems (see Figure 1).
12 CWA 15141:2004 (E)
4 Formal Languages
Formal languages are used to define models at the schema level. For the purpose of this document, i.e. for the development and standardisation of meta-schemas for building and construction domain, formal data definition languages, structured mark-up languages and object-oriented languages are most relevant.
The following languages are mostly used to define meta-schemas:
EXPRESS UML XSD Topic Maps RDF OWL
4.1 EXPRESS
It has been developed by the ISO group TC184/SC4 in order to describe product data unambiguously [ISO 10303- 11]. It was finally published as an International Standard (IS) in 1994 and was influenced by the entity relationship model and early paradigms of object-oriented analysis and design,
EXPRESS is often described as an object-flavoured language as it incorporates some of the object-oriented principles, but not all of them. It is a conceptual information modelling language. It is defined specifically to deal with the information that is consumed or produced during product manufacturing. EXPRESS is not a programming language. It does not contain language elements that allow input/output, information processing or exception handling. EXPRESS focuses on the definition of entities consisting of data and behaviour. Data represents the properties by which an entity is realised and behaviour is represented by constraints and operations.
EXPRESS is mainly used to describe static information models (schemas) for data and interoperability standards, such as the series of STEP standards [ISO 10303], Oil and Gas standards [EPISTLE, ISO 15926], Building & Construction standard [IFC, ISO/PAS 16739, ISO 12006-3] and others.
A schema in EXPRESS defines the classes (ideas) containing the attributes that will be used characterise their state when instantiated together with the relationships (facts) existing between classes. Relationships in EXPRESS can be described bi-directionally i.e. if class A has a relationship with class B then class B has an inverse relationship with class A. EXPRESS makes no formal distinction between a relationship and an attribute (i.e. between a by-value or by-reference association).
EXPRESS also allows for:
• Derived attributes (i.e. attributes whose values may be derived from the values of other attributes) • Uniqueness rules (specifying individual or combinations of unique or key attributes) • Data constraints (i.e. rules that can be applied to data values to ensure their validity) • Functions (that can be used to hold stored computations of value) • Procedures, Constants and Types (including enumerations and select types)
Ideas and facts described by a schema specified in EXPRESS define the semantics of the domain of interest and consequently the structuring of data within an instance model.
Instance models that are created in accordance with an EXPRESS schema can be exchanged using the clear text encoding or STEP physical file format (ISO 10303-21 syntax) or as database fields using SDAI (ISO 10303-22). These standards define the syntax of the file or database in which the model is presented.
EXPRESS currently has no formal notion of meta-class or template. It is likely that future versions of EXPRESS will support such constructs. Within the current version of EXPRESS the notion of an ENTITY shall be used to define meta-classes.
13 CWA 15141:2004 (E)
4.2 UML
The Unified Modeling Language (UML) Specification defines a graphical language for visualising, specifying, constructing, and documenting the artifacts of distributed object systems. The specification includes the formal definition of a common Object Analysis and Design (OA&D) meta model and a graphic notation.
The UML was created in response to a request for proposals from the Object Management Group (OMG) for a foundation for specifying and sharing CORBA-based distributed object models. Over time, it has become the principal methodology for object analysis and design of major software systems and is supported by many leading organisations in the ICT industry.
It is a ‘unified’ language in the sense that it brings together several previously separate methodologies into a single approach. As well as being able to define the entities (classes) within a system, it also includes facilities for defining the use cases (business requirements), processes, sequence of object usage and collaboration between objects, determining the state of objects at particular points, specifying the components of a system and their deployment. For current purposes, only the class specification capability of the UML is considered. The latest version of UML is version 1.5, published in 2003.
The main purpose of UML is software development for which it provides a formal method, particularly for the analysis and design phase of the software development cycle. As it is well-known within the software development community and many powerful case tools exist it has also been used for other purposes, like the development of data models and exchange standards. Example for the latter usage is the openGIS consortium.
lexical:
package - consists of schema - consists of Schema Schema/ontology stereotypes, class, entity, type, rules etc. relation etc.
model - consists of object model - consists Objects Model instances of instances
General Approach Framework Approach EXPRESS Paradigm UML Paradigm
Figure 2: Three approach layers compared with different paradigms
There is also a formal notation to depict instances (e.g. to show the type-instances relationship), however there is no clear text encoding of an UML object model (comparable to the STEP physical file structure [ISO 10303-21] for EXPRESS). However there are possibilities to use appropriate mechanisms, such as XMI in order to use XML documents to communicate UML object models.
4.2.1 Main Packages
The top level of UML comprises three packages (where a package is a convenient way of grouping together a set of concepts for consistent viewing). These packages are foundation, behavioural and model management.
14 CWA 15141:2004 (E)
Model Behavioral Management
Foundation
Figure 3: Top level packages in UML 1.4
The top level package that is of specific interest is the foundation package. This identifies the concepts that will be required for the development of information models that meet the requirements of the building construction domain. These include such ideas as classes (classifiers), attributes, operations/methods, constraints and so on together with defining the roles (relationships) between meta-classes and cardinalities (numerical constraints) of the role. Additionally, provision for the various required data-types.
Core Extension
Data Types
Figure 4: Foundation packages in the UML
UML contains model construction capabilities that allow it to be described in itself. That is, the whole capability of the UML notation can be elaborated in UML. It incorporates the concept of a meta-class whose instantiation is another class (a stateless object without identity) rather than being an instance of a class (object) whose values define its state and identity.
UML is now probably the most widely used notation for the development of schemas and user models. It is widely applied in the design of XML schemas as well as for object oriented software analysis and design and database design.
The conversion of UML models to/from the EXPRESS modelling language is a subject that is gaining increasing interest with material of significant interest being located at www.exff.org (EXPRESS For Free).
4.3 XSD
The extended mark-up language XML had been based on the broader SGML standard, both were designed to formally describe and mark-up documents (such as formula, maintenance manuals, or technical books). The broad take-up of XML (after many years of very limited use of the SGML ancestor) has triggered also other application fields for XML-based messages, communications and exchange standards. In order to enhance the capabilities of XML as a formal data and mark-up specification language the W3C consortium initiated the development of the XML Schema Definition language XSD which had been finally published as a Technical Recommendation (TR) in 2001.
XML schemas2 are used for a variety of purposes and together with its overall popularity within the web-based developments it is also used for purposes not originally intended by the previous SGML development, such as general information modelling and product data. An XML schema comprises definitions (elements, types, groups) for static models and it governs the creation of a set of XML instance documents.
2 RELAX NG may be used as an alternative XML schema language.
15 CWA 15141:2004 (E)
XSD is used for many information models for data and interoperability standards, mainly within the e-business and e-government sector, such as ebXML, but also in building and construction related areas, like GML (geography mark-up language) and others.
lexical:XSD Formal Language graphical:
schema - consists of Schema element, type, group etc.
document - consists of Objects element instances and mark up text
General Approach XSD Paradigm
Figure 5: three approach layers in XSD
Currently the XSD has no graphical notation (although XML tools may offer a graphical view onto XSD schemas). Some initiatives use UML for graphical notation and development of the schema before converting it into XSD (such as the openGIS consortium), others use EXPRESS-G and convert the resulting EXPRESS model into XSD (such as the IAI for developing the ifcXML standard).
Instance documents that are authored in accordance to an XSD definition are exchanged as XML documents (following the XML 1.0 syntax) or other forms, such as encapsulated message, database fields or XML info sets.
4.4 Topic Maps
Topic maps3 provide a means for describing knowledge structures and associating them with information resources. They have emerged from developing ideas about indexing in documents and develop the idea that it should be possible to locate information resources from an index or map of topics through the provision of locators (equivalent to resource locators on the World Wide Web)
Two possible standards are identified for topic map specification, namely ISO 13520 and XML Topic Maps (XTM). The ISO standard provides a UML meta-schema that defines the basic concepts of the model namely topics, associations, and occurrences.
3 See ‘The TAO of Topic Maps’ by Steve Pepper at http://www.ontopia.net/topicmaps/materials/tao.html
16 CWA 15141:2004 (E)
Figure 6: Basic concepts in the topic map meta-schema
A topic may be any ‘thing’ whatsoever. It can be used for a physical thing or for a concept. A topic is the object or node in the topic map that represents a subject being referred to. A one-to-one relationship should between topics and subjects. Topics have three kinds of characteristics: names, occurrences, and roles in associations. Multiple base names can be assigned to a single topic, with the possibility of having variants of each base name.
Figure 7: Topic in ISO 13520 topic map meta-schema
A topic may be linked to one or more information resources that are deemed to be relevant to the topic. Such resources are called occurrences of the topic. Occurrences may be of any number of different types. The distinctions are supported in the standard by the concepts of occurrence role and occurrence role type.
A topic association asserts a relationship between two or more topics. Associations between topics can be grouped according to their type, termed association type. Each topic that participates in an association plays a role in that association called the association role.
4.5 Semantic Web
Based on the general XML developments the W3C has initiated several specifications aiming at providing a higher semantic richness for the content of the world wide web. These developments are promising technologies to achieve better meta-schema and also for construction specific content. However there is less experience in using these technologies, than with using EXPRESS, UML or XSD based models.
The two main developments under the semantic web initiative for the scope of this document are RDF and OWL.
4.5.1 RDF
The Resource Description Framework (RDF) is a general-purpose language for representing information in the Web. It defines a language for describing relationships among resources in terms of named properties and values.
RDF provides no mechanisms for describing properties, nor does it provide any mechanisms for describing the relationships between properties and other resources. That is the role of the RDF vocabulary description language, RDF Schema (RDFS). RDFS defines classes and properties that may be used to describe classes, properties and other resources. These resources are used to determine characteristics of other resources, such as the domains and ranges of properties. RDFS vocabulary descriptions are written in RDF.
The primary goal of RDF is to define Web metadata; that is, data providing information about Web resources and the systems that use them. A metadata record consists of a set of attributes, or elements, necessary to describe the resource in question. This could include such data as author, issue date, period of validity etc. Classification reference could also be a metadata attribute.
17 CWA 15141:2004 (E)
The design of RDF has a set of objectives namely:
• have a simple data model • have formal semantics and provable inference • use an extensible URI-based vocabulary • use an XML-based syntax • support use of XML schema data-types • allow anyone to make statements about any resource
The underlying structure of any expression in RDF is a collection of triples, each consisting of a subject, a predicate and an object. A set of such triples is called an RDF graph. This can be seen in the diagram below, a triple being described by as a node-arc-node link.
Predicate Subject Object
Figure 8: Basic structure of an RDF graph
An RDF triple is conventionally written in the order subject, predicate, object. The direction of the arc is significant: it always points toward the object.
The assertion of an RDF triple says that some relationship, indicated by the predicate, holds between the things denoted by subject and object of the triple. The assertion of an RDF graph amounts to asserting all the triples in it, so the meaning of an RDF graph is the conjunction (logical AND) of the statements corresponding to all the triples it contains.
• RDF provides a data model for objects and relations between them and provides a simple semantics for the data model. • RDF Schema provides a vocabulary for describing properties and classes of RDF objects, with semantics for generalisation-hierarchies of such properties and classes. 4.5.2 OWL
The Web Ontology Language (OWL) developed by the World Wide Web Consortium (W3C)’ Semantic Web Activity is intended to provide a language that can be used to describe the classes and relations between them that are inherent in Web documents and applications. OWL is more powerful than file structuring capabilities such as Data Type Definitions (DTDs) and XML Schema Language (XSD). OWL not only allows the modelling of data structures but also of the data itself (referred to as individuals) and even more important the type-relations between them.
OWL is formally specified in RDF. There are three versions (species) of OWL that contain constrained subsets of the language and that may be used for various purposes. • OWL Lite is a simple language intended to satisfy users needing a classification hierarchy and simple constraint features. Whilst it supports cardinality (the numerical constraint on the relation between classes), it only permits values of 0 and 1. Thus Class A can have a relationship with zero or one instances of Class B. A number of other restrictions apply and a number of OWL constructs are excluded. • OWL DL uses concepts from formal Description Logic (hence the DL designation). It includes the complete OWL vocabulary, but some constraints are placed on usage. • OWL Full contains all the OWL language constructs and provides free, unconstrained use of RDF constructs.
OWL capabilities support the development of information models in much the same way that a data definition language such as EXPRESS. It enables the specification of: • classes including the development of a class hierarchy through the specification of subclasses, • complex classes that allow reasoning over the individuals that are members of other classes (including intersection, union, complement, disjoint and enumeration classes),
18 CWA 15141:2004 (E)
• properties (or attributes) of classes including both the specification of simple properties that are base data- types (string, real, integer etc.) and complex properties that are other classes, • relations between classes including the naming of the relation and the specification of cardinality, • inheritance between classes including the facility for multiple inheritance, • characteristics of properties.
A key concept OWL is that it has been developed for use on the Semantic Web. This is the vision for the future of the Web in which information is given explicit meaning, making it easier for machines to automatically process and integrate available information.
For the present purpose, we need to distinguish between specifying a model in OWL and specifying its content extension. This can be done to some extent by separating the idea of a class in OWL from that of an individual that is a member of the class. In general, the concept of the individual may be seen as the ontology and is dealt with more fully in CWA4.
However, this is not precise since there will be many cases where the ontological content may also e seen as part of the model. An example might be in the specification of spaces and systems referenced in a regulatory environment (such as building regulations). Here, interpretation of the regulations means that knowledge of the type of space or system is known as well as knowledge about the fact that a space or system (in generic terms) is present. To some extent, this could be dealt with via the specification of enumeration classes that contain all expected values. However, this is likely to be inefficient, as it cannot be expected that enumerations will be complete in every case. In such circumstances, individuals need to be specified within an ontology.
4.6 Software Tools
There are several tools available to develop information models using formal languages. Tools support several aspects of development, including (among others):
a graphical editor to develop a schema or model a lexical editor to develop a schema or model a parser to evaluate the schema or model a instantiation (or authoring) tool to generate instance models (or documents) based on a schema a compiler to compile the schema or model into executable code It cannot be the task of this document to present or evaluate those development tools. Therefore only links are provided that offer a summary or overview about available software tools:
EXPRESS see http://www.nist.gov/sc4/tools/express/etools98.htm (outdated) UML see http://www.objectsbydesign.com/tools/umltools_byCompany.html see http://www.jeckle.de/umltools.htm (German) XSD Overview at official W3C website – see http://www.w3c.org/XML/Schema Semantic Web see http://www.w3.org/2001/11/IsaViz/ for the W3C IsaViz public software for RDF browsing and authoring see http://www.research.att.com/sw/tools/graphviz/ for the GraphViz open source graph drawing software for use with IsaViz see http://protege.stanford.edu/index.html for the Protégé-2000 public software ontology editor and OWL plug ins other software applications for the semantic web exist but this list has been restricted to known publicly available applications.
19 CWA 15141:2004 (E)
5 Schema
A schema allows us to make an abstraction of the real world in a form that enables a model to be created as a virtual reality on a computer. This virtual reality may take the form of a shape (or geometric) model, a cost model, a model of the processes undertaken, the operational lifecycle of components or other forms of abstraction.
A schema is much like a physical scale model of a car or an aeroplane that might be used in wind tunnel testing. It allows only those properties that are of particular interest to be modelled; properties that are not of interest are not included. In this way, a model that is created using a schema is known to contain only data that is deemed to be significant to the part of the domain that is of interest.
This section considers the concept of schema (or schemas). Initially, some of the basic ideas that are fundamental to their development for building construction are considered. There then follows a review of the principal schemas that have been developed for building construction and that are in the public domain (either as formal standards or as openly published proposals). For each schema, where appropriate, known implementations are identified.
5.1 Why is a Schema Important?
A schema is important because:
It determines the scope of a domain of interest It captures ideas that are contained within that domain of interest It specifies a structure for the classes, attributes and relationships that express these ideas within the domain of interest. Having defined the data structure through the formal expression of a schema using a particular language (as described in section 4), a model can then be developed that incorporates objects (occurrences of individuals belonging to a class) having values that define their state. 5.2 Methodologies and Concepts Used in Schema Development
The definition of a schema includes various modelling techniques like those described within the object-oriented methodology: abstraction, encapsulation, modularity, hierarchy, typing, concurrency and persistence. Some, such as encapsulation, modularity, typing, concurrency and persistence, relate more to the design and implementation level and are not further considered here. Abstraction and hierarchy are however significant.
Concepts used within schema developments are classes (or entities) than encapsulate the internal structure, its behaviour and domain of values. Each class can be seen as a generalised representation of a product (like a wall, an air outlet, a chair), a fact (like a process or authorisation), or an idea (like a desired performance indicator). Classes have attributes, whose values determine the state of an object, and classes interact with other classes along relationships. Classes may be ordered within a generalisation/specialisation graph utilising methods, like inheritance, that allow subclasses to inherit the attributes and behaviours of super classes.
5.2.1 Abstraction and Hierarchy
Abstraction and hierarchy are of great importance to the logical structure of high quality schemas.
Abstraction essentially means finding the essential characteristics of objects at an appropriate abstraction level and perspective of the creator. It allows the grouping of certain similar concepts or objects as classes (or meta- classes) of such objects at various abstraction levels. The distinction between occurrences and types and between specifications and definitions are applications of abstraction.
Hierarchy essentially means a ranking or ordering of abstractions. It allows graphs among classes to be generated at various abstraction levels to form specialisation trees. A taxonomy is an application of hierarchy among, for instance, the various terms within a dictionary.
20 CWA 15141:2004 (E)
5.2.2 Generalisation Versus Specialisation
Most schemas utilise inheritance graphs which group (or classify) classes along a generalisation/specialisation mechanism. Those inheritance graphs may be (but do not need to be) trees, i.e. each specialised class (or subclass) has only one super class. Such inheritance trees are similar to those found in classifications or taxonomies.
Root
Object
Product
Element
Building Element
Wall Beam
Truss Girder
Figure 9: Specialisation tree
Although proper specialisation trees (or graphs) are vital for complex schemas, the categorisation principles are different to traditional classification structures. Usually the specialisations within schema developments are less detailed and the leaf nodes usually reflect a higher generalisation level.
It is not specifically necessary to have one single specialisation hierarchy. Multiple hierarchies can be used alongside each other, for instance when using OWL.
5.2.3 Objectified Relationships
Some schemas have adopted an approach whereby relationships that exist between classes are expressed as classes themselves. This approach leads to schemas that have the appearance of greater complexity but which have greater implementation flexibility.
Objectified relationships have the following advantages:
• allow the resolution of many to many relationships • allow for attributes that do not need to be asserted to be omitted entirely from a model (instead of leaving an unfilled slot for the class) • provide for the better assertion of a class having a recursive relationship with itself (thus facilitating combinatorial relationships such as whole/part decomposition)
21 CWA 15141:2004 (E)
Relation A B
Direct relationship betwen classes
Relation to Relation to Relating Class Related Class A relationAB B
Relating ClassClass making Related Class the relationship
Indirect relationship betwen classes using relationship class
Figure 10: Objectified relationships
Schemas such as the IFC model, ISO 12006 part 3 and the ISO 15926 (Epistle Core) model use the concept of objectified relationships extensively and do not allow direct relationships between classes.
5.2.4 Definition/Specification Distinction
In building construction, concepts may be defined in general terms without regard to functional or operational parameters that describe their specific usage or specifically in terms of their function or operational usage.
For instance, a space may be defined generally as representing an area or volume bounded actually or theoretically. This recognises that spaces are areas or volumes that provide for particular functions within a building without being specific as to what those functions are or may be. Definitive attributes can be applied such as size, capacity etc.
Space an area or volume bounded actually or theoretically
Figure 11: General space definition
Specificity is determined when a further parameter is applied that enables the space to be identified (or classified) according to some named function. It may apply values to definitive attributes according to function (e.g. fire classification) and add other specific attributes.
Function/Use of Space Space
(Living Room) OR (Kitchen) OR (Bedroom) OR (Office) OR (Toilet)
Figure 12: Specific functional uses of space
Both general definition and specific function may be understood as ontology. However, for the present purpose, a broad distinction is drawn between a schema that identifies concepts as general definitions (meta-schema) and a schema that identifies concepts by specific function (ontology).
There are many circumstances in building construction at which definition and specification level concepts will manifest themselves and at which there needs to be a connection between a meta-schema and an ontology (according to the above definitions). The following identifies some general concepts additional to the space example given above
22 CWA 15141:2004 (E)
System System Type Electrical Power Lighting Water Services Domestic Hot Water Potable Cold Water Non Potable Cold Water Plumbing Waste Drainage Stack Ventilation Stack …. Building Building Type Regulatory Purpose Group Residential Commercial Shop Industrial Religious Observance …. Material Material Type Brick Metal Steel Copper Composite …. Table 2: Type specifications for meta level concepts
5.2.5 Type/Occurrence Distinction
Identifying the type of an entity as an entity in its own right allows the common data to be specified at the type level. Each occurrence of an entity of a given type then has to add only those data that are particular to the occurrence.
A type entity specifies the common information to be captured about all instances of that type An occurrence entity specifies placement (position) data and references the type. An occurrence entity also specifies any other data that is particular to the occurrence
TYPE (Specification)
X (Occurrence at x1, y1, z1 )
X (Occurrence at x , y , z ) TypeObjec 2 2 2 t Properties Attribute1 Attribute2 X (Occurrence at x3, y3, z3) Attribute3 Properties ....
Figure 13: Type/occurrence differentiation
Concepts of definition/specification and type/occurrence may be combined so as to identify the relationship between:
the definition of an entity and those properties that characterise the definition, the identifiable specifications or types of an entity and those properties that enable a type to be recognised, the individual occurrences of any type of an entity
23 CWA 15141:2004 (E)
In the example in Figure 14 a generic definition of a chair is proposed. This has all the properties that essentially characterise the quality of ‘being a chair’. This could include the notion of a seat, a back and one or more legs. The specification of the chair enables information about a particular type of chair to be added; what type of back it has, how many legs specifically, material for the upholstery, colour etc. The occurrence of a chair indicates the location of a particular chair and any other information that is tied to that occurrence.
CHAIR DEFINITION Properties that Definition characterise the entity by definition
Specification/ Properties/values that Type characterise the entity by type
TYPE A TYPE B TYPE C CHAIR CHAIR CHAIR
Location 1 Location 2 Location 3 Location 4
Properties/values that Occurrence characterise an occurrence of the entity
Occurrences of Type B chairs at different locations
Figure 14: Example of definition, specification/type and occurrence levels
5.3 Existing Schema Definitions
Several schemas have been developed and standardised for the use within the AEC/FM industry. Appendix A lists the following schemas and introduces the main content of each standardised schema with the focus on its meta- schema definitions.
• ISO 12006-2 • ISO 12006-3 • IFC (ISO 16739) – The Industry Foundation Classes for AEC/FM • EPISTLE (ISO 15726) • STEP (ISO 10303) • PLIB (ISO 13584) • CIS/2 – The CIMsteel Integration Standard • PSS – The product data interface for steel structures • bcXML
24 CWA 15141:2004 (E)
6 Recommendations
This section considers the current state of development of schemas relevant to building construction and defines recommendations for progress in further development.
Figure 16 shows an overview of recommendations as discussed further below. Recommendations are grouped under the headings technical schemas, business schemas and languages. Related recommendations concerned with ontology are not considered here. Practically, to achieve a standardised usage of ICT across the building construction industry, each of these approaches needs to be focussed around a common architecture and meta- schema. Equally, there needs to be an approach to developing a rationalised set of communal schemas that can be used as a focal point. Once communal schemas are established, ontologies (see CWA4) and related actions can be developed that can support its use.
Technical Schema
CIMsteel Resolve technical/architectural differences ISO 10303 (resource) Multiple inheritance ISO 10303:225 Subtype constraints ISO 15926 IFC Others Communal B-C Schemas Business Schema Create architecture for communal schemas Select metaschema for communal schemas Trading Capture concepts in communal schemas Capture existing concepts in communal Cost Create VIEW to ensure schemas standalone use Revise existing concepts in line with Maintenance architecture/metaschema Others Add new concepts as relevant Create VIEWs to ensure standalone use
Language
EXPRESS Define schemas in appropriate multiple forms UML Create mappings between XML/XSD language forms Create mappings between Topic Map instance models derived from RDF/OWL language forms
Figure 15: Overview of recommendations
6.1 Language
EXPRESS versions of technical schemas exist and these are readily convertible to XML/XSD using optimised conversion tools that apply the ISO 10303 part 28 XML language binding. Conversions between EXPRESS and UML have been developed in the past and there is a resurgence of effort in this through the EXPRESS For Free (www.exff.org) activity which also includes for model interchange using the XML Model Interchange (XMI) standard. ‘EXPRESS For Free’ also identifies the potential for EXPRESS/OWL conversion and continuing work on bcXML and the EU ICCI project also validates this.
Given this ability to convert from one language to another, it is reasonable to suggest that the language in which a model is expressed is less important than the semantics expressed by the model. Whilst there are functional differences between the languages (for instance, WHERE rules in EXPRESS are not easily rendered in XSD or OWL at this stage), this can be overcome by explicit statements of restrictions that should be placed on implementations of the model (through implementers agreements). Such agreements on restrictions do need to be included as propositions (formal or informal) to a model.
In the short term, it is likely that the primary language that will be used for model development in building construction will continue to be EXPRESS. Alongside this, it is probable that an XML/XSD version will also be published. UML and OWL versions should also be encouraged for the following reasons:
25 CWA 15141:2004 (E)
• UML has a better capability for separating models into packages that can form ‘views’ onto the model (working subsets of the model that perform a specific business function).
• OWL offers the capability to better connect with models of individuals and ontologies. It also offers potentially enhanced capability for distribution of the model through namespace referencing.
mapping Language/ EXPRES/ OWL Meta-schema SPFF
generation core Schema/ ifcOWL IFC2x2 Ontology Ontology cOntology
translation Model/ SPFF Data RDF/XML Data (“step data”) KB
now Then i.e. via jena
Object-based Object-based CAD CAD
Figure 16: Potential Future Route
6.2 Technical Schemas
Currently, the three main technical schemas adopted within the AEC industry are CIMsteel (developed specifically for the structural steelwork supply chain), IFC (developed as an integrated, multidisciplinary, lifecycle model for all of building construction) and ISO 10303 part 225 (a part of the STEP series of standards concerned with shape representation of buildings). The PSS schema for structural steelwork has now been absorbed into the IFC model. All of these schemas are currently EXPRESS based.
In some areas, these standards are quite similar, such as geometry. In other areas, such as product structure, they are notably dissimilar. Harmonisation of these standards into a communal approach could take three forms:
Cross translator to map one schema into another and vice versa. This requires the development of comprehensive mapping tables. The better the specifications have been harmonised, the better will be the quality of the cross translation. Existing implementations will not have to be changed. This is probably the more cost and time effective solution, as it could start today and would reuse existing IT solutions. Develop a unified approach to development of communal schemas. This will require changes in current implementations since the underlying schemas will change. It is more time consuming (as the whole process of developing a schema, agreeing upon it, developing the interface implementations and introducing it has to be repeated), and can therefore only be realised in the medium or long-term. Allow the market to determine which schemas will become most widely used. If this occurs, the development of communal schemas as above would still occur but this would be based around the dominant schema.
6.3 Business Schemas
There are several standards for XML based trading schemas that could be adapted for use within building construction. These currently compete for attention with schemas derived from older EDI based trading systems. It is probable that adaptation of standard schemas will occur over time and this is certainly the recommended solution. Within the UK based CITE activity, this will become the policy for future development.
There are also several cost schemas for bills of quantities/tendering, each schema relating to particular national approaches. There are efforts to develop international standards for this purpose and it is recommended that
26 CWA 15141:2004 (E) these be supported. However, development of any such standard will need to allow for local flavouring as it is not foreseen that local cost and tendering rules will be changed in any short time frame.
Business schemas are not currently integrated with technical schemas. However, for project purposes, it is vital that such integration should occur within a communal approach. It is therefore recommended that efforts are devoted to defining communal schemas that integrate technical and business schemas such that information can be captured at the project level but that cognisance is taken of the fact that business schemas will need to continue to work on a standalone basis. This could be achieved through the definition of ‘views’.
6.4 Ontology
Ontology is dealt withy more specifically in CWA4. However, it is important to see the role of ontology within a unified model framework.
Presently, all of the defined schemas exist at the ‘class’ level. In the case of the IFC model, extensive use is made of enumerations that expand the scope of the classes and provide a semi-ontology (i.e. a generally incomplete listing of individual possibilities). Where there is clearly a longer list than could ever be attempted by enumeration, string values are used as a simple placeholder.
Much of the power and the long term capability for reasoning using instance models will come from the creation and use of ontologies that operate in conjunction with a unified model. Specification of spaces, systems, materials, processes, cost types, constraints and much more will be required. Elaborated relationships between these individuals will enable reasoning to occur.
Therefore, the development of ontologies is seen as a key to the enhanced use of schemas in building construction.
6.5 Related Actions
There are a number of related actions that are recommended around the development of communal schemas for building construction. Some key actions are identified below:
• There is a strong need for guidance to users on the best practice approaches to using their software tools to create project models that can then be shared using the communal schemas.
• Standards for the creation of objects that can be referenced from libraries (using drag/drop or web services technologies) need to be created. These can/should draw on the meta-schema present within current and proposed schemas and should be developed using ontologies that have been created to harmonise property definitions.
• Ontology development should also incorporate the need to create standard metadata that can be used for product/document/knowledge searching in building construction.
• Having created object and metadata standards, the road then becomes clear for manufacturers/suppliers and other commercial organisations to create appropriate library content that can be searched, retrieved and used.
27 CWA 15141:2004 (E)
7 Approaches to Development and Adoption
This section considers an approach to the development and adoption of a set of communal building construction schemas.
It does not make any presupposition as to whether such a set of communal schemas might be distributed or used.
It simply takes the view that they will come into existence.
Figure 18 presents a simplified view of some of the tasks that are required in the development and adoption of communal schemas. These are based on the recommendations in section 6 of this document (and therefore exclude considerations of ontology and related actions). The tasks are presented in an approximate sequence of expected occurrence although no time scales are given. This is based on the premise that, historically, all time estimates for the development of large-scale industrial information models have been very optimistic. Almost by definition, the development of such schemas requires access to the latest technology and, in many cases, has driven the development of such technology. Therefore, it is unwise to set time scales. This is particularly true in building construction which is a highly fragmented, extremely distributed industry whose product is (ultimately) the production of generally complex functional spaces over long time scales and not material products.
Create communal Create communal Select communal schema schema framework metaschema architecture
Define existing schema overlap Harmonise Add new technical technical schema schema by mapping Define existing schema gaps Create schema views Create communal schema Harmonise business schema Set policy for Add new business business schema schema Adopt/adapt relevant business schema
Figure 17: Approach to defining communal schemas
28 CWA 15141:2004 (E)
Appendix A Schema Developments
Within this appendix several existing schema developments that are relevant to the AEC/FM industry sector are shortly introduced.
A.1 ISO 12006 Part 2
The purpose of ISO12006-2 is to define a model for classification systems. It is not a classification system in itself. It sets out an approach whereby particular classification systems that meet regional or national requirements can be developed according to a common international approach.
ISO 12006-2 does not contain any tables or parts. However, the class structure of the model recommends tables/parts that can be included within a conformant classification system.
The aim of the standard is to support information use and exchange in areas such as computer aided design, specification provision and cost estimates.
Space Relationship has one or many has one or many Type of/subtype
Construction Complex
Construction composed of one or many Result Construction Entity can be viewed as Construction part or whole of Element Entity Part has one or many can be viewed as part or whole of
Designed Work Result has been Element specialised will result in according to Management
Property/ has one or many Construction Characteristic Process
Work Process
occurs during Construction Entity Lifecycle
occurs during has one or many Project Stage
is used in Construction Product
Construction Aid Construction Resource Construction Agent
Construction Information
Figure 18: Simplified view of ISO 12006-2 meta-schema
29 CWA 15141:2004 (E)
A.1.1 Key concepts The key concept in ISO 12006-2 is that:
Construction Resources are used in Construction Processes that will result in Construction Results
Construction Resources are the things that are brought together so that construction can occur. They include:
• Construction Products – the physical items used in construction • Construction Aids – physical items that are used to assist the process of construction • Construction Agents – actors (human or otherwise) that perform the construction • Construction Information – rules, instructions and guidance relating to construction resources and processes
Construction Processes are concerned with the act of construction using the resources provided. They include: • Management – tasks and activities associated with management of construction • Work Process – tasks and activities directly concerned withy construction • Construction Processes are considered to occur during the Construction Entity Lifecycle and at a Project Stage.
Construction Results are the results of processes being carried out using resources. They include: • Construction Entities – resultant products • Construction Entity Parts – identifiable sub-parts of a construction entity which may participate in or be viewed as part of or a whole Element. • Construction Complexes – multiple identifiable construction entities • Spaces – volumes formed by between construction entities • Work Results – end products of a function undertaken • Designed Elements are a subtype of Element that may be specialised according to a work result.
A.2 ISO 12006-3
ISO 12006-3 defines a schema for a taxonomy model, which provides the ability to define concepts by means of properties, to group concepts, and to define relationships between concepts. Objects, collections and relationships are the basic entities of the model. The set of properties associated with an object provide the formal definition of the object as well as its typical behaviour. Properties have values, optionally expressed in units.
30 CWA 15141:2004 (E)
Names S[1:?] 2,2 xtdName (ABS) Descriptions S[1:?] 2,3 1,2(3) xtdRoot xtdDescription References S[1:?] 2,4 xtdReference 1
(ABS) 1,1(3) 3,1 (ABS) 1,5(3) xtdObject xtdRelationship xtdCollection 1 *xtdNest xtdActor
xtdSubject xtdBag
xtdActivity 1,6(3)
xtdUnit 1,4(3)
3,2 xtdMeasureWithUnit
xtdProperty 1,3(3)
Figure 19: Top level structure of ISO 12006-3
The role that an object is intended to play can be designated through the model and this provides the capability to define the context within which the object is used. Each object may have multiple names and this allows for its expression in terms of synonyms or in multiple languages. The language name of each object must always be given in English (the default language). An object may also be named in terms of the language of the location in which it is determined or used. Objects may be related to formal classification systems through the provision of references. The model has one xtdRoot class from which the following three classes inherit: xtdObject, xtdCollection and the xtdRelationship. The root class provides the ability to assign any set of names, labels, descriptions and references, in any language, to its derived types, as well as identifiers and dates. Objects are divided into xtdSubject, xtdActivity, xtdActor, xtdUnit, xtdMeasureWithUnit and xtdProperty entities. Subjects and activities are the things and processes that are described. The other classes are description classes related to other objects and themselves through relationships.
31 CWA 15141:2004 (E)
RelatedRole 2,2 RoleNames S[1:?] (ABS) 3,1(1) xtdName xtdRelationshipRole RelatingRole xtdRelationship
1,2 RelatedThings S[1:?] 1 xtdRoot 1,5 RelatingCollection xtdRelCollects xtdCollection 1,1 RelatingObject xtdObject xtdRelAssignsCollections 1,5 RelatedCollections S[1:?] xtdCollection 1,1 RelatingObject xtdObject *xtdRelAssociates 1,1 RelatedObjects S[1:?] xtdObject 1 *xtdRelComposes
*xtdRelGroups
*xtdRelSpecializes
*xtdRelActsUpon
1,6 RelatingActivity xtdActivity 1,6 RelatedActivity *xtdRelSequences xtdActivity 2,2 MethodOfInterpretation xtdName RelatingProperty 1,3 xtdRelAssignsMeasures xtdProperty RelatedMeasures S[1:?]
1,1 RelatingObject xtdObject xtdRelAssignsProperties RelatedProperty S[1:?] 3,2(1) 1,3 xtdProperty
UnitComponent 1,4 xtdUnit xtdMeasureWithUnit ValueComponent 2,1 xtdValue
EnumerationValues *L[1:?]
*Name 2,2 xtdEnumeration xtdName
Figure 20: Relationship structure in ISO 12006-3
xtdRelationship provides an association mechanism that describes the relationship between objects (object object) and between objects and collections. Relationships are divided into association (xtdRelAssociates), property assignment (xtdRelAssignsProperties), sequencing (xtdRelSequences) and measure assignment (xtdRelAssignsMeasures). Association is further subtyped into collection (xtdRelCollects), specialisation (xtdRelSpecializes), composition (xtdRelComposes) and involvement (xtdRelActsUpon). Collections provide for all kinds of groupings of objects, including nested collections, by means of the xtdRelCollects relationship. Properties are classes that provide the context for data stored as values. Properties are differentiated according to types of data containment: enumeration values, list values, bounded list values, bounded values, single values and table values. The value content, associated to a property through an xtdMeasureWithUnit, is stored in an xtdValue component. It is language dependent and therefore derived from the xtdLanguageRepresentation entity. xtdLanguageRepresentation captures the way that any name, description, value or reference is represented on a per language basis.
A.2.1 BARBi/Lexicon BARBi and Lexicon are independent implementations of dictionaries that are compliant with the specification given in ISO 12006-3.
BARBi is a Norwegian based project that is looking to define reference data approaches that are application both to the construction industry (through the IFC model) and to the process engineering/offshore industries (through
32 CWA 15141:2004 (E) the POSC/CAESAR implementation of the EPISTLE core model through ISO 15926). It is implemented within an object-oriented database and has a browser that enables web access.
LexiCon is used nationally within the Netherlands in support of the STABU specification system and provides definitions and specifications of concepts which are of interest for the construction industry. Current development work is considering how to interpret lexical properties that can specify geometry so as to provide an image of a product directly.
Figure 21: Lexicon screen showing dictionary terms in English
A.3 IFC
The Industry Foundation Classes (IFC) model has been progressively developed by the International Alliance for Interoperability (IAI) since 1995. It is a response to interoperability requirements within building construction by a significantly large group of industry practitioners including government and other statutory bodies, clients, consultants and contractors together with a substantial number of software vendors.
33 CWA 15141:2004 (E)
The IFC model is rooted in approaches initially developed within the work of ISO TC184/SC4; most particularly in the development of the ISO 10303 series of standards (STEP q.v.). In particular, IFC has adopted and/or adapted certain parts of the STEP standards including:
• Formal specification of IFC is in the EXPRESS language from ISO 10303 part 11 • Encoding of files for data exchange is undertaken using ISO 10303 part 21 • The IFC model uses schemas that have been adopted from the resource standards within ISO 10303, particularly parts 41, 42, 43 and 46.
In order to simplify the IFC model for development and implementation, certain rules were enacted that have the effect of modifying the resulting information model relative to the original STEP version. In particular, the following rules are noted to have had an effect:
• IFC allows only single inheritance (an entity can inherit data from only one super type entity). STEP allows multiple inheritance. • IFC requires that all subtypes of a super type entity are exclusive; it is not possible for subtypes to be combined. This typically has the effect that IFC introduces interstitial entities that can handle the combination in an exclusive way.
From the release of IFC 2x (October 2000), a part of the model has been protected against change. This is referred to as the ‘Platform’ and is that part of the model that was formally accepted as ISO PAS 16739 in November 2002 under the external harvesting procedures of ISO TC184/SC4.
The IFC 2x Edition 2 release of May 2003 used the IFC 2x Platform and extended the range or scope of the model.
A.3.1 Basic Structure The IFC model is separated initially into two parts that may be considered as layers.
Resource
Kernel
Core Extension
Shared Object Elements Relationship Property Definition
Domain
Figure 22: Entity structuring of the IFC model
The upper layer contains resource entities. These are dependant entities that provide services such as shape representation, cost, units of measure, date/time etc to the operational entities. Occurrences of resource entities are dependant on occurrence of operational entities and are not uniquely identified in their own right.
The lower layers contain operational entities, i.e. those definitions that are directly used in an exchange context and consequently each occurrence of an entity (object) has its own unique identification. Operational entities are grouped in layers where the kernel and core extension layers deal with general, abstract concepts whilst the
34 CWA 15141:2004 (E) shared elements and domain layers deal with specialised concepts that relate to real world ideas. Terminating entities (i.e. entities that are not further specialised) are termed ‘leaf nodes’ in the IFC model.
The vertical sections define the basic entity structuring of the IFC model. There are three primary forms of entity namely objects, relationships and property definitions. ‘Objects’ define the principal classifying ideas that exist in the building construction world. ‘Property definitions’ define additional data characteristics that can be applied to objects through external definition. ‘Relationships’ describe the connection that can exist between objects (object object) or between an object and a property definition4.
Operational entities utilise:
basic object information (like identification and ownership information); basic relationship information to other items (like associations, aggregations); basic concept of type information applied to occurrence objects; basic concept of property information used to define the object; basic connection to the shape representations and the location within the project context.
To support these concepts, the key structures in the IFC kernel schema provide
a set of generalised object entity types; a set of generalised relationships that can occur between these entity types; a means of extending the IFC model through sets of data (property definitions) declared externally.
The non-abstract descendants of the generic object entity definitions (all rooting in the IfcObject declaration) define the leaf-node entities of the IFC model, i.e. those end-user relevant entities that establish the meaningful data exchange. Examples are IfcWall (for architecture and coordination), IfcFlowTerminal (for HVAC design), IfcTask (for production planning), IfcAsset (for FM) and others. The relationships of these entities to other information sets, as defined in the IFC Resource schemas, or within the sets of data declared externally, or to other entities define the concepts applicable to the leaf-node classes.
4 Note that the IFC model does not currently allow the existence of a relationship between property definitions (property definition property definition)
35 CWA 15141:2004 (E)
Name Global_id IfcIdentifier IfcLabel Description IfcRoot OwnerHistory IfcOwnerHistory ObjectType Select Related Entity
All Resource Entities RelatedEntities S[1:?] 1
RelatingEntity IfcPropertyDefinition IfcObject Select Relating Entity IfcRelationship 1 1
IfcRelAssigns IfcTypeObject IfcRelAssociates See CWA4 for further details on object specialisation using ontology IfcRelDecomposes IfcTypeProduct
IfcRelDefines HasPropertySets L[1:?] (INV) DefinesType S[0:1] IfcRelConnects
IfcPropertySetDefinition
HasProperties S[1:?] IfcPropertySet DependingProperty (INV) PropertyForDependance S[0:?]
DependantProperty HasProperties IfcPropertyDependency IfcProperty Relationship (INV) PropertyDependsOn S[0:?] (INV) PartOfComplex S[0:1] 1 IfcSimpleProperty 1 IfcPropertySingleValue
IfcPropertyEnumeratedValue
IfcPropertyBoundedValue
IfcPropertyTableValue
IfcPropertyReferenceValue
IfcPropertyListValue
IfcComplexProperty
Figure 23: An overview of the key parts of the IFC model
Any leaf node class is rooted at the root entity, IfcRoot that provides for the fundamental concepts of identification, ownership and change information, name and description attribution
An IfcObject, and stands for all physically tangible items, such as wall, beam or covering, physically existing items, such as spaces, or conceptual items, such as grids or virtual boundaries. It also stands for processes, such as work tasks, for controls, such as cost items, for resources, such as labour resource, or for actors, such as persons involved in the design or construction process, etc.
An object gets its context information from the relationships in which it is involved, the property information and, if available, the information about the underlying specific object type. An object may have an informal type descriptor assigned, which denotes a particular type to further specify the object.
36 CWA 15141:2004 (E)
The concept of relationships in IFC is the relationship class IfcRelationship. This class represents objectification of a relationship (literally, making a relationship into a class in its own right). The relationship class is the preferred way to handle relationships among objects. This allows relationship specific properties to be kept directly at the relationship object and enables the relationship semantics to be separated from the object attributes.
The property definition, IfcPropertyDefinition, is the generalisation of all characteristics of objects. It reflects the specific information of an object type (IfcTypeObject), versus the occurrence information of the actual object instance (subtype of IfcObject) in the project context. The property definition is applied to the objects using the concept of relationships. Instances of IfcPropertyDefinition are delivered as property sets. IfcTypeProduct, which is a subtype of IfcTypeObject, enables geometric representation properties to be attached.
A.3.2 Object Entities There are seven fundamental entity types in the IFC model, which are all derived from IfcObject.
products - are physical object (manufactured, supplied or created) for incorporation into a project. They may be physically existing or tangible. Products may be defined by shape representations and have a location in the coordinate space. processes - are actions taking place in a project with the intent of, e.g., acquiring, constructing, or maintaining objects. Processes are placed in sequence in time. controls - are concepts that control or constrain other objects. Controls can be seen as guide, specification, regulation, constraint or other requirement applied to an object that has to be fulfilled. resources - are concepts that describe the use of an object mainly within a process. actors - are human agents that are involved in a project during its full life cycle. project - is the undertaking of some engineering activities leading towards a product. It establishes the context of all representation within the project including the default global units used within the IFC file or database model. In the case of a geometric representation context it includes additionally the world coordinate system, the coordinate space dimension, the precision used within the geometric representations, and optionally the indication of the true north relative to the world coordinate system group - is an arbitrary collection of objects that can be considered as a logical unity within an AEC/FM project. A single object maybe included within several groups. A group itself maybe part of another group.
An IfcProxy is a special subtype of product that is used for objects that are not otherwise semantically declared as part of the IFC model. A proxy may have a representation and placement (attributes inherited from IfcProduct) and can be further defined by property definitions. A proxy is identified as being of one of the principal semantic types within the IFC Model and can have a tag that further qualifies its use.
A.3.3 Relationship Entities There are five fundamental relationship types in the IFC model, which are all derived from IfcRelationship.
assignment – is a generalisation of "link" relationships among instances of objects and its various subtypes. A link denotes the specific association through which one object (the client) applies the services of other objects (the suppliers), or through which one object may navigate to other objects. association – refers to external sources of information (most notably a classification, library or document) and associates it to objects or property definitions. decomposition – defines the general concept of elements being composed or decomposed. The decomposition relationship denotes a whole/part hierarchy with the ability to navigate from the whole (the composition) to the parts and vice versa. definition – uses a type definition or property set definition (seen as partial type information) to define the properties of the object instance. It is a specific - occurrence relationship connectivity – defines the connection between two (or more) objects. The specific semantics of the connection is declared within the subtypes, defined elsewhere in the IFC model. One example is IfcRelSequence, that handles the concatenation of processes over time.
The IfcRelAssigns assignment relationship establishes links between objects that supply information to a specific type of object. There is an assignment relationship, yielding particular semantics, for each subtype of IfcObject
37 CWA 15141:2004 (E) including product (IfcRelAssignsToProduct), process (IfcRelAssignsToProcess), control (IfcRelAssignsToControl), resource (IfcRelAssignsToResource), actor (IfcRelAssignsToActor) and group (IfcRelAssignsToGroup).
The IfcRelAssociates association relationship establishes links to objects, founded within the resource part of the IFC model, that provide a reference to any type of object or property definition.
The IfcRelDecomposes decomposition relationship establishes links between objects that participate in a whole/part relationship. It implies that there is a parent object that defines the whole (at the particular level of decomposition) and one or more child objects that define the parts.
The IfcRelDefines definition relationship establishes links between individual objects (occurrences) and type definitions or property set definitions.
The IfcRelConnects connection relationship establishes links between objects that are connected in some way. The connection may be physical or logical and may occur at a point in time or define a temporal connection such as a sequence.
A.3.4 Property Sets The number of different types of object that can possibly occur within the building construction domain is huge. It is virtually impossible to develop a model that can contain a complete description of every one of these object types for every purpose for which it may be required. However, it is possible to develop a model that provides a framework of the key ideas within building construction and then provide the possibility for the model to be extended by project, local, national or regional agreements. The IfcPropertySet provides the capability for extension.
IFC Model
Increasing Specialization IFC Leaf Nodes
AEC/FM Information World Sets of properties Figure 24: Where the IFC model terminates at 'leaf nodes'
The IFC model develops ideas down to ‘leaf nodes’. A leaf node is a generalised semantic concept such as door, window, beam, column etc. The principal attributes that define the generalised concept are defined at the level of the entity within the IFC model.
Below the leaf nodes, further development of the model is achieved by defining IfcPropertySets. It is a container that holds collections (or sets) of properties. Whilst a property set may be specified within the model, it is more normal for it to be developed externally.
The IfcPropertySet defines a framework within which properties may be declared. Within this framework, any property that conforms to one of the allowed property types can be included. There is no limit to the number of properties that can be defined within a property set.
The types of properties that can be contained within a property set include single values, value ranges, lists of value and tables of values. All of these properties may be with or without units. Additionally, a complex property is a property is a property that contains within itself a list of other properties (thereby providing a degree of hierarchical structure to the property set). Finally, a property is provided that enables references to objects within the resource layer (whose existence is dependant on the existence of the property set).
38 CWA 15141:2004 (E)
A.3.5 Ifc2x Release Series Both the IFC 2x and IFC 2x Edition 2 releases are developed using the base concepts outlined in the IFC platform schema. For the Edition 2 release, minor modifications exist at the platform schema level, these correcting identified inconsistencies in the previous release.
The IFC 2x release series essentially provides the key shared concepts that apply in building construction and a ‘thin’ taxonomy of elements that can be further enhanced using property set and type object/type product specifications. In particular, the form of the model in the IFC 2x Edition 2 makes it very easy to accommodate further expansions to the model that may be needed (predominantly for the purposes of dealing with new business areas rather than expanding coverage of existing business areas.
Extension can be achieved by adding a new subtype to an appropriate functional type. In general, specific attributes are not added to types in the model. Occurrences of a particular type are specified through an instance of the appropriate functional subtype of IfcObject. Thus, for a tank of a particular type (IfcTankType), its occurrence is defined as an IfcFlowStorageDevice.
1 or many occurrence specifications 1 type specification IfcRelDefinesByType
IfcFlowStorageDevice IfcFlowStorageDeviceType
... which is a type of tank
IfcTankType OCC. OCC. OCC. TYPE OCC.
Figure 25: Tank type and occurrence entities
More specific detail is given by property sets. These may be related to the type object for those properties that are consistent for all instances of a given type or they may be related to the occurrence entity for properties that may vary between occurrences.
Pset_TankTypeCommon
Pset_TankTypeSectionalTank IfcTankType
Figure 26: Type based property sets for a tank
A.3.6 Lifecycle Concepts In addition to the ability to be able to define products according to the requirements of the design and construction stages of a constructed facility development, the IFC model can also use its capabilities for arbitrary grouping to collect together product instances into operable and maintainable assets and so extend its data capture capabilities to lifecycle concepts. Lifecycle ideas are supported by a flexible cost model and by environmental impact/sustainability data.
A.3.7 Application of Ontology As for many other entities within the IFC model including building, system, space, material etc., cost is identified as to type by a label (i.e. an alphanumeric string that may be assigned for identification purposes). A label with an
39 CWA 15141:2004 (E) unspecified value is used rather than an enumeration with defined values due to the difficulties in identifying all possible types of cost that can occur and in specifying them explicitly in a data construct that must be used by all conforming software applications. It is anticipated that more formal identification of types for such classes will be achieved through the development of ontologies that may be referenced either directly through the IFC model or through property sets.
A.3.8 ifcXML Increasingly, XML variants are providing the syntax of choice for information exchange across the web. IAI has recognised this trend and has defined an XML Schema Language (XSD) variant of the EXPRESS-based IFC2x and IFC 2x2 schema called ifcXML.
Conversion of the EXPRESS schema is carried out using an optimised process; an automated conversion being undertaken initially and then optimal XML simple data structures used to replace some of the more complex structures in EXPRESS (date/time, units). The overall inheritance structure of the IFC model is not affected by this conversion. Thus, the ifcXML meta-schema remains the same as that for the EXPRESS language based version of IFC. ifcXML is also contributed as a component to the development of the 2nd edition of ISO 10303 part 28. The second version of ifcXML is meant to be fully compatible to the ISO 10303-28(2) binding of an EXPRESS structure.
Further work is considering approaches to an ifcXML structure that ‘flattens’ the inheritance structure of the IFC model whilst retaining the ability to move to and from this structure. A ‘flattened’ ifcXML would exhibit greater similarity to existing large scale XML development efforts which tend to restrict the use of inheritance.
IFC property set developments are exhibited through a derivative of ifcXML and may also be delivered to applications software in ifcXML format providing that the receiving software has a facility to interpret incoming ifcXML structures.
IfcXML is also being used as a means to develop a common interface onto an IFC database through the SABLE (Simple Access to Building Lifecycle Engineering) development.
A.4 ISO 15926 / EPISTLE
ISO 15926: Oil and gas facilities life cycle data is the standardised version of the EPISTLE Core Model [ECM]. It has been developed by the ‘European Process Industries STEP Technical Liaison Executive’ to meet the needs of the process, offshore and related industries. Process/offshore and building construction are related industries that fall under the more general heading of Architecture, Engineering and Construction (AEC) and therefore it is expected that there will be similarities in a number of model concepts developed for these industry sectors, particularly in respect of their project driven nature.
The ECM essentially provides a harness for data. Instances based on the model are identified by naming provisions and these naming provisions are defined externally. Practically, they take the form of reference data that is based on templates. It is through the instantiation of such reference data that implementations of the model operate.
A.4.1 ‘thing’ A thing is defined as ‘anything that is or may be thought about or perceived, including material and non-material objects, ideas, and actions’. It acts as the entry point to the model and provides the common super type to all entities. Its primary function is to provide an identification service to all other entities (by inheritance).
A.4.2 ‘individual’ An individual is defined as ‘a type of
Actual_individual, single_individual and whole_individual entities can be decomposed in whole part structures in the same way as an individual.
The plural_individual concept is a grouping mechanism in cases where the collection of instances is arbitrary.
40 CWA 15141:2004 (E)
State introduces the idea of process (particularly for the activity subtype) in that it exists with a non-zero time extent that is bounded by start and end (creation and destruction) times.
The concept of sequence (temporal_sequence) is defined as a relationship between processes although process logic handling (lead/lag concepts) is not immediately apparent.
The concept of state has a broader context in that it can also be applied to physical objects (that can exist at a particular state). This appears to have value for the notion that an object can exist in various states at different points in time; an important concept in a project based model.
A.4.3 ‘relation’ A relation entity, defining a timeless relation between two things, is a critical idea within ECM derived models. The semantics of relationships are refined through more specific relationship classes. All connections between entities in the model are achieved through the use of relationship. There are no directly contained attributes for any entity within the ECM.
(AE) thing
1
individual (AE) 2,1 relation class 1 1 1 1 single_individual other_relation
plural_individual classification
whole_individual (AE) composition_of_individual actual_individual 1 collection_of_individual point_in_space organization_of_individual vector_in_space 1 arrangement_of_individual (AE) temporal_boundary_of_state assembly_of_individual 1 point_in_time (AE) 1 connection_of_individual feature_whole_part event containment_of_individual temporal_whole_part (AE) cause_of_temporal_ state boundary_of_state (AE) 1 temporal_bounding_ of_state period_in_time difference_of_set 1 start_temporal_ activity union_of_set bounding_of_state
physical_object state_involved_in_connection end_temporal_ bounding_of_state
functional_physical_object relative_location
lifecycle_stage materialized_physical_object
temporal_sequence stream
involvement
Figure 27: Definition of
41 CWA 15141:2004 (E)
A classification is a relation to identify that particular ‘things’ are members of a particular class. Essentially, it is a means to tell an entity that it is a member of a class. From a naming perspective, classification in the ECM is fundamentally different to classification generally as understood in building construction where its purpose is to act as a notation for an external identification purpose.
A.4.4 ‘class’ A class is a critical concept in the ECM. It is the means by which ideas in the real world can be developed and instantiated. It provides the fundamental capability for the development of reference data that is a crucial component of any usage of the model.
The class entity of itself acts in the conventional manner of a classic ‘object oriented class’ in that it collects instance members of a similar classification through the classifier relationship. This is the occurrence level of class usage.
The three subtypes of class namely class_of_individual, class_of_relation and class_of_class essentially provide for types of things (whereby multiple instances of something can all be of a given ‘type’). This is the type level of class usage
Each class has a role that can be used to further define usage of the class.
2,1(1) class role
1
class_of_individual class_of_relation class_of_class
1 class_of_point_ in_time (AE) 1 class_of_biological_matter class_of_temporal_ boundary class_of_event class_of_inanimate_material 1 class_of_state class_of_composite_material property class_of_compound class_of_inanimate_ status physical_object class_of_atom
class_of_feature class_of_organization class_of_sub_atomic_state
class_of_activity 1 phase class_of_arranged_state
class_of_information_state crystalline_structure
class_of_organism shape class_of_information_presentation
class_of_person class_of_information_representation
subtypes provide conventional data types (real, string etc.) and time.
Figure 28: Definition of
A.4.5 Taxonomy Taxonomy is considered here to be an expression of the breakdown of physical product structure as in
fluid moving device fan centrifugal fan forward curved bladed centrifugal fan
42 CWA 15141:2004 (E)
There is no taxonomy in ECM. It relies instead on the external development of Reference Data using the capabilities of the model.
A.4.6 Reference Data The fundamental key to using the ECM is through the development of reference data that is external to the model. Since there is no taxonomy within the model, practical usage is totally reliant on such reference data.
A.5 STEP
The Standard for the Exchange of Product Model Data (STEP) is a particular effort on the capture and specification of industrial data under the ISO Technical Committee 184. It is one of several standards under the ISO TC184 banner and delivers the various parts of the ISO 10303 standard.
Application Protocols
Application Application Resources Modules
Generic Resources
Implementation Methods
Figure 29: Simplified view of STEP standards architecture
STEP has many parts. Each of these is defined using particular implementation methods. Notably, all models are defined using the EXPRESS language specified in ISO 10303 part 11:1994
Models are grouped into 3 principal layers that increase in specificity moving upwards.
• At the lowest level are the generic resources. These provide reusable components that are used by, referenced by or specialised within more specific models. They are not implemented directly; application protocols may use, reference or are transformed by reference to entities within the generic resources. • Above this are the application resources. Again, these provide reusable components but are specific to a particular scope or requirement. They are not implemented directly; application protocols may use, reference or are transformed by reference to entities within the application resources. • At the top level are the application protocols that meet particular business requirements. Application protocols are interpreted according to generic and application resources so that they reuse entities already defined wherever possible. Business requirements that may have complex relationships to already defined concepts are mapped by interpretation to convert an ‘Application Reference Model’ to an ‘Application Interpreted Model’ or AIM. The normative standard for the application protocol is the AIM. A.5.1 Backbone Architecture STEP is published as a set of parts, each part containing one or more schemas that relate to the fundamental model resources (against which all other parts have to be interpreted) or to application domains. There is no published meta-schema for STEP. However, a backbone architecture can be determined1. This shown in the diagram below which is derived from the generic resource parts of the standard, each of which is designated in the series ISO 10303-4x.
1 Illustration from ‘Assessment of Harmonization of IFC with STEP Standards: Backbone Architectures of both specifications and comparison with AP225-AIM: Version 1.1’. Wolfgang R. Haas and Jochen Haenisch presented at the ISO TC184/SC4 meeting in Poitiers. October 2003
43 CWA 15141:2004 (E)
A key entity in the STEP meta-schema is property_definition_representation. This handles both the definition of a product and its representation. Definition is handled physically through the product_definition and geometrically through the shape_definition.
A product_definition specifies a ‘type’ of a product as opposed to an individually identifiable product. It can be decomposed through a product_definition_relationship so that whole/part relationships can be determined.
A product_definition has a product_definition_formation that defines the particular formation of a product. A product represents an individual, physical item that is characterised as a type of product through the product_category product_related_product_category entities.
A shape_definition can handle the complete shape of a product or of a particular identified aspect (or part) through shape_aspect.
Representations of a product are handled through the representation entity. A representation can contain any number of instances of representation_item that can be:
• geometric_representation_item (point, curve, surface, volume etc.), • topological_representation_item (edge, vertex, face, shell etc.), • mapped_item (symbols that are predefined, named, reusable groups of representation items), • descriptive_representation_item (text or annotation), • measure_representation_item (dimensions).
44 CWA 15141:2004 (E)
application application_protocol_definition application_context product_category
frame_of_reference
product_related_product_category application_context_element
products S[1:?]
frame_of_reference S[1:?] product_definition_context product_context product
frame_of_reference of_product related_product_definition formation product_definition_relationship product_definition product_definition_formation relating_product_definition
characterized_product_definition
shape_definition
characterized_definition
definition of_shape property_definition product_definition_shape shape_aspect
represented_definition
definition
property_definition_representation
used_representation
context_of_items representation_context representation shape_representation
items S[1:?]
representation_item
measure_representation_item mapped_item geometric__representation_item
descriptive_representation_item topological_representation_item
Figure 30: Overview of STEP backbone architecture
A.5.2 STEP in Building Construction For building construction, the most relevant standard within STEP is ISO 10303 part 225: Building Elements Using Explicit Shape Representation (AP225). This identifies a number of key elements that are relevant to building construction including items such as wall, beam etc. and provides for the specification of explicit shape (explicit shape being the complete shape description). This means that even the most complex sculpted shapes can be represented.
AP225 is interpreted according to the generic and application resources with specific capabilities for building construction added. Although adding building construction specific entities, there is not a complete product taxonomy within the model. Further specialisation can be carried out using the product_category.name attribute that enables the type of product to which an instance conforms to be named.
In addition to product naming, a lightweight classification facility forms part of the model. This enables traditional classification views of products to be specified through a classification string.
45 CWA 15141:2004 (E)
AP225 also incorporates the general property mechanism available from STEP, which enables additional properties to be attached to entities.
application name application_protocol_definition application_context STRING product_category
frame_of_reference
product_related_product_category application_context_element
products S[1:?]
frame_of_reference S[1:?] product_definition_context product_context product
frame_of_reference of_product
related_product_definition formation product_definition product_definition_formation product_definition_relationship relating_product_definition
building_element fixture_equipment_element service_element structure_enclosure_element
Figure 31: Representation of building elements in AP225 AIM
A.6 PLIB
ISO 13584: Industrial automation systems and integration - Parts Library, more commonly known by its short name PLIB, specifies the structure of a library system that provides an unambiguous representation and exchange of computer interpretable parts library information. The data held in the library are a description that enables the library system to generate various representations of the parts held in the library. The structure is independent of any particular computer system and is intended to permit any kind of digital representation of part representation. Different implementation technologies may be used for the storage, accessing, transference and archiving of parts library data.
PLIB is essentially a definition of information to be held within a supplier library. It does not provide for the specification of actual content; this is the responsibility of the supplier.
Parts Representation Representation Transmission Interface Interface to User Library External System System Library Systems Interrogation Interface Dialogue Flow
Library Data
Supplier Library
User Figure 32: Functional Areas of PLIB Library Usage
The library interrogation interface is not defined within ISO 13584 but is intended to include facilities to select parts from the library and to define the orientation, position and representation category of the part selected.
46 CWA 15141:2004 (E)
The representation transmission interface enables the library system to send parts representations to the user computer system. The representation transmission interface depends on the representation required by the user when a part is selected. Possible user requirements are modelled as representation categories that might include 2D symbolic representation, 2D side elevation, 3D solid representation etc.
A geometric programming interface with a FORTRAN language binding is specified in ISO 13584-31. This permits the exchange of parametric shapes that describe the implicit geometry of families of parts in the format of a parametric program.
A.7 bcXML
The Building and Construction eXtensible Mark-up Language (bcXML) represents an approach to handle the problems related to searching/finding precisely a given product/component when using marketplaces/portals devoted to building construction. Figure 34 shows the bcXML meta-schema.
Figure 33- The bcXML meta-schema bcXML enables the creation of "requirements messages" that can be interpreted by computer applications and then find suitable products and services that meet those requirements. To enable someone to find the required product quickly, a taxonomy is used where a taxonomy is defined as a clear, formal and agreed definition of the AEC objects, their properties and interrelationships. Such a taxonomy may be used by clients and suppliers to handle properly the match between requirements (clients’ side) and products/services (suppliers’ side). This taxonomy was defined based on the meta-schema part of bcXML called the eXtensible Taxonomy Definition (XTD). bcXML is primarily capable of supporting simple e-Commerce communication of products (materials, components, equipments, documents) and services inside or over the national borders. Users can specify the content of their messages (both supply and demand) in terms used in the building and construction industry. Simple, small and clear XML code is generated. Both B2C/C2B and B2B communication are provided. Though bcXML has started with simple e-Commerce-like communication, it will be possible to extend the usage of bcXML to more complex e-Business communication. Also the bridge between Product Data Technology and e-Commerce is realised. This goal was achieved through an internal dictionary, called bcDictionary, filled with interrelated
47 CWA 15141:2004 (E) objects and properties that play an important role in building construction. bcXML is also able to communicate with external taxonomies that add more complex structuring mechanisms like specialisation, decomposition, or views. The bcXML meta-schema was instantiated for the building construction industry sector. This instantiation was then promoted to a schema called the ‘bcBuildingDefinitions’ schema that can, in its turn, be instantiated for the actual goods and service specifications from a demand or supply viewpoint (i.e. requirements specifications and supplier catalogues respectively). This two-level modelling process potentially seems to integrate well in the similar multi-level ebXML modelling developments for transactions.
48 CWA 15141:2004 (E)
Appendix B Current manifestations
B.1 Glossaries of Terms
ISO 6707 is the current general standard for terminology for construction. This is published in multiple parts. A version of the British Standard BS6100: Glossary of building and civil engineering terms that references ISO 6707 is published in a single volume form. This is more useful and tends to be quoted and used far more widely.
There are many other standards that contain glossaries both at the international and national standards level, important amongst which are the IEC2 glossaries for electrical terminology.
These glossaries are vitally important components in schema and ontology definition since they provide good indication of high level content (by subject) and also the meaning of the terms used. However, in developing models according to the object-oriented paradigm (such as IFC), the extent of the content of these standards has been found to be limited covering only a small proportion of requirements.
B.2 Thesauri
An alternative to glossaries are thesauri. A thesaurus is a common way of presenting a controlled language index so that it may be effectively and efficiently used in information retrieval3.
There are many thesauri relating to building construction terms and these are generally well organised into hierarchical structures; there are also explicit translations between terms. These are potentially very valuable at the level of ontology (since they can prescribe the terminological content). A thesaurus term without a semantic definition is of limited use for schema development however.
Some key examples of English language thesauri for building construction include the Construction Industry Thesaurus4 covering general terms and the Building Services Thesaurus5 covering terms more specific to building services practice and use
B.3 Classifications
There are many different classification systems within building construction and their use differs according to geographical location, industry discipline and other factors. In considering a schema for classification, it is necessary to allow for the adoption of any rational classification system whether it is based on elements, work sections or any other classifiable division.
A schema for classification is either concerned with identifying the semantics of the concepts underlying the classification system (as is the case with ISO 12006 part 3), with the taxonomy of the classification system (as is the case with ISO 12006 part 2) or with the label that is used within the classification system (as is the case with the IFC classification model).
B.3.1 The IFC Classification Model The IFC classification model is able to represent classifications according to the most advanced current concepts based on ISO 12006-2 as well as more traditional classifications such as those in the various SfB forms used internationally, CAWS, Master format etc., or other national classification systems. It provides for:
The provision of one or more classification notations to an object.
2 International Electrotechnical Commission. 3 Cann J., Principles of Classification: Suggestions for a procedure to be used by ICIS in developing international classification tables for the construction industry, ICIS 1977 4 Roberts M.J., Construction Industry Thesaurus. 2nd ed. London: Property Services Agency, Department of the Environment, UK, 1976. 5 Beale G., Building Services Thesaurus, 5th ed. , Building Services Research and Information Association, UK, 1990
49 CWA 15141:2004 (E)
The inclusion of one or more facets to a classification notation. Referencing of facets of a classification notation from a described source (item or table) Exposure of the hierarchy of a classification structure. Identification of the source of the classification. The designation of a classification in terms of its source, edition and name. The provision of a means of semantically identifying the meaning of a classification notation.
IfcClassificationNotation
NotationFacets S[1:?]
IfcClassificationNotation NotationValue Facet
Notation
IfcClassificationItem Ti tle IFCMEASURERESOURCE .IfcLabel
ItemOf (INV) Contains S[0:?]
RelatingItem RelatedItems S[1:?] (INV) IsClassifyingItemIn S[0:1] (INV) IsClassifiedItemIn S[0:1]
IfcClassificationItemRelationship
Name
EditionDate Edition IFCDATETIMERESOURCE. IfcClassification IfcCalendarDate Source
Figure 34 : IFC Classification schema
Classifications are applied to objects through the IfcRelAssociatesClassification class. This applies either an IfcClassificationReference or IfcClassificationNotation to an object or a property definition. Each instance of IfcRelAssociatesClassification enables the association of one classification notation with one or many objects. An object may also have multiple classifications through the use of multiple instances of IfcRelAssociatesClassification, each instance pointing to a particular classification notation and to the objects that are classified by this notation.
RelatingClassification
L7533 IfcRelAsssociates (Uniclass classification Classification of HVAC fans for ductlines)
IfcRoot-->Objects RelatedObjects
Figure 35 : Example of attaching a classification to multiple instances
Any type of object can be classified regardless of whether it is a product, a process, a control or a resource. The IfcClassificationNotation class is used to define a classification. An IfcClassificationNotation is a notation used from published reference (which may be either publicly available from a classification society or is published locally for the purposes of an organisation, project or other purpose).
50 CWA 15141:2004 (E)
Modern classification systems (such as Uniclass, BSAB etc.) allow for multi-faceted classification. This is achieved the IfcClassificationNotationFacet class where each instance represents one facet of a classification notation. The classification notation itself is then made up of a set of notation facets.
A facet is a part of the actual notation but which has a specific meaning. For instance, it may be appropriate to classify an item by owning actor (represented by A=Architect) and by an entry from a classification table such as CI/SfB (represented by 210 for external wall). This gives a classification as A210.
An IfcClassificationItem is a class of classification notations used. For example, the classification item "L681" in Uniclass may be used to contain all subsequent notation facets within that class of classifications which has the title "Proofings, insulation"(e.g. L6811, L6812, L6813 etc.).
An IfcClassificationItemRelationship is a relationship class that enables the hierarchical structure of a classification system to be exposed through its ability to contain related classification items and to be contained by a relating classification item. IfcClassificationItem’s can be progressively decomposed using the IfcClassificationItemRelationship such that the relationship always captures the information about the parent level (relating) item and the child level (related) items of which there can be many. The following example shows how this could be achieved for the Uniclass system.
L IfcClassificationItem Uniclass Structure in the IFC Model RelatingItem
IfcClassificationItemRelationship
RelatedItems
L7 L8 IfcClassificationItem
RelatingItem
IfcClassificationItemRelationship
RelatedItems
L71 L72 L73 IfcClassificationItem
RelatingItem
IfcClassificationItemRelationship
RelatedItems
L711 L712 L713 L714 IfcClassificationItem
Figure 36 : Example of building a classification system in IFC2x
Each classification item belongs to an IfcClassification. This provides the means to identify the classification system being used. IfcClassification has attributes that define its source, edition and name.
51 CWA 15141:2004 (E)
Appendix C Interrelationships among schemas
C.1 Integration of ISO PAS 12006-3 and IFC
The development of property sets is likely to become a key factor in the successful deployment and use of the IFC model. In particular, the provision of catalogue data through property sets will be important.
It is recognised that property sets may be defined either generically to form part of a published IFC release or specifically to meet regional, local or even project based requirements. Regardless of how they are published, consistency in the naming and usage of properties is important. By applying the principle of a dictionary, it should be possible to ensure that properties are defined consistently, a particular named property always being used in the same way within the same context through its semantic definition and having consistently defined units.
There was a significant workload in recent IFC model releases simply in sorting out and coordinating all the properties within property sets so that they were consistent. This workload was with a fairly limited number of property sets/properties. If left uncontrolled, this task will grow in future releases and could place a huge load on the model integration process.
ISO PAS 12006-3 is a standard that can offer significant assistance in resolving the issue. There has been IAI input in the development of the conceptual model on which the standard is based, the conceptual model making use of a number of the constructs within the IFC 2x model.
IFC model developers and users could draw on an implementation of the standard so that the properties they define in property sets are defined consistently. It would certainly make model integration much simpler if the source of property terminology was known and trusted.
In 2002, a project was commenced jointly between the IAI, ISO TC59/SC13/WG6 and ICIS (the International Classification Information Society) to harmonise ISO PAS 12006-3 with the IFC model so that it is practically and directly usable in IFC development.
The scope of work of the project is to:
• define the approach and method by which the IFC model can be harmonised with dictionaries structured according to the ISO PAS 12006 part 3 framework so that IFC model development and use can draw on such dictionaries as a resource, • define an approach that enables IFC model development and use to contribute towards the extension of dictionaries, • provide an outline specification for an interface that enables property sets to be developed using populated dictionaries, • formulate requirements for output of property sets resulting from use of dictionaries according to the IFC property set mark-up language subset of ifcXML. Work on this project is ongoing.
C.1.1 bcXML/ ISO DIS 12006-3 With successful trials of the ISO PAS 12006-3 standard completed, further work has continued to develop to the more formal ‘Draft International Standard’ (DIS) level. This involved additional work on the meta-schema.
A significant input to the DIS development has been the bcXML meta-schema. This has enabled integration of the ISO DIS 12006 Part 3 and the eConstruct/bcXML XTD to be accomplished.
C.1.2 Integration of OWL with IFC and Catalogue Comparing functionalities of OWL with other Languages like ISO 12006-3 or bcXML shows that OWL is really a language that, in conjunction with RDF and RDFS (in which it is defined anyway) can be used to create models in much the same way as EXPRESS. Some concepts that are difficult to define within the language are omitted in
52 CWA 15141:2004 (E) the formal specification but these can be added in the form of reusable ontologies. Some of the concepts missing include:
• Kernel concepts such as objects, activities and resources (actors and equipment) and their interrelations, • Units (base, derived and currencies), • Decomposition, and • Complex values (especially quantitative enumerations and ranges). C.1.3 Core Ontology These extra concepts and others (taking into account the semantics provided by alternative approaches) can be modelled in a “core” ontology that uses OWL (which on its turn uses RDF and RDFS. Most of these additional concepts can be easily modelled e.g. the definition of an Xproperty (an extended property) is modelled as a subtype of the existing OWL “ObjectProperty” but now adding facets like unit, unit prefixes and context information. Additionally the use of name spaces facilitates the use of more open, extensible distributed data structures and associated data sets. The classes part of the core model is depicted below6.
Figure 37: OWL-based Core Ontology (core.owl)
With this core ontology construction-related ontologies can be developed by specialising the generic leaf classes and properties of the core. A good example is shown in the figure below. On the left, a cObject (construction object) is specialised in many subclasses. Here, the DoorLeaf is selected and on the right hand side, the Properties that are actually attached to this class can be seen. Furthermore, cardinality details can be specified (here there is always zero or one height for a DoorLeaf because the property is not multiple and optional).
6 The CASE tool used is Protégé from Stanford University with the OWL plug-in component which can be downloaded from http://protégé.stanford.edu
53 CWA 15141:2004 (E)
Figure 38: cObjects and their associated properties (cOntology.owl)
C.1.4 Catalogue Ontology With this ontology actual products and services can be specified. An example for the DoorLeaf is shown below. Within the catalogue (catalogue.owl) the item MyDoor is instantiated. This has a link with a supplier and has a height of 2 metres. The actual owl file in “RDF/XML Abbreviated” syntax is shown below.
54 CWA 15141:2004 (E)
Figure 39: A simple (type) specification example (catalogue.owl)
C.1.5 Comparison Existing agreed semantics (such as the IAI IFC 2x2 schema) can be transformed to the OWL-technologies and easily integrated with other ontologies (like the one above for definitions). Like ifcXML where the EXPRESS schemas are mapped to XSD schemas, EXPRESS schemas can be mapped to OWL (directly and/or optimised). From this, models such as that shown below can be obtained.
In the example below, a fragment of the process/task model in IFC is shown and comparable classes and properties shown for OWL7.
EXPRESS (IFC) OWL Example: Class showing subclass inheritance ENTITY IfcProcess
7 OWL specification created using the Protégé 2.0 software from the Stanford Knowledge Systems Laboratory.
55 CWA 15141:2004 (E)
OR ('IFCKERNEL.IFCPROPERTYDEFINITION' IN
Example: Enumeration in OWL IfcDocumentConfidentialityEnum = ENUMERATION
C.1.6 OWL Potential OWL is a language that may offer significant potential for the further expansion and ongoing development of information models for building construction. For instance, considering the IFC model, it offers the potential to combine an “ifcOWL” ontology with a cOntology (similar to that described above) that has extra classes and properties not yet modelled in IFC2x. The other way round these user-defined classes can be directly associated to standard explicit shape representations provided by IFC.
Similarly, data encoded in EXPRESS based structures could be mapped to and from OWL data (called Knowledge Bases i.e. sets of OWL individuals). So on the OWL-side the potential is to have exactly the same syntax for data structures and the actual instantiated data; namely RDF/XML files for both the IFC schema as the IFC models.
56 CWA 15141:2004 (E)
Appendix D Comparison
This section compares the structures of a number of schemas on a pairwise basis i.e. each section dealing with two models and considering how each handles particular schema development issues.
D.1 Comparison of the EPISTLE Core Model and IFC Entities
Process/offshore and building construction are related industries that fall under the more general heading of Architecture, Engineering and Construction (AEC) and therefore it is expected that there will be similarities in a number of the concepts developed between the EPISTLE Core Model (ECM) and the Industry Foundation Classes (IFC) model. This may be seen particularly in the fact that both models serve industry sectors that are project driven and that therefore have to deal with process data concepts as well as product data concepts.
Both EPISTLE Core Model (ECM) and Industry Foundation Classes (IFC) model trace their roots back to common work within ISO TC184/SC4. Since both models share a common industry super sector and are project related, it is to be expected that there will be similarities at some level of the models. This section provides an overview comparison based on the current ECM version 4 and IFC 2x Edition 2 published versions.
The comparison undertaken is at the entity level and is intended to provide an introduction to the similarities and differences that exist between these models.
Whilst note has been taken of the use of attributes within the two models, the differences in usage have not flavoured the analysis. Generally, it was found that differences in approach did not colour the development or potential usage of the models in a comparative sense. As an example, relationships in ECM are generally developed on a 1-to-1 basis whilst they are frequently developed on a 1-to-many basis in IFC. This only affects the number of instances of a relationship used; it does not affect how the relationship is applied.
Similarly, the different approaches to modelling have not been considered in great detail. Some caution must be exercised in this since modelling approach can affect the capabilities of entities and how they are used. For instance, IFC always uses exclusive subtypes. Whilst most subtyping in ECM is exclusive, there are cases of non exclusive (ANDOR) subtyping and these can be fundamental. For instance, in the case of class (see below), class_of_individual, class_of_relation and class_of_class are exclusive subtypes but may be ANDed with the role subtype.
D.1.1 High Level Concepts The top level structures of the models are shown together in figure 37. From this, it can be seen that the patterns of the models at this level is consistent. The question then is whether the concepts that are exposed are equivalent.
thing IfcRoot
1 1 individual IfcObject
relation IfcRelationship
class IfcPropertyDefinition
ECM Top Level IFC Top Level
Figure 41: Comparison of ECM and IFC top level model structures
57 CWA 15141:2004 (E) thing Root
The ‘thing’ entity in ECM and IfcRoot act as the entry point to the models and provide the common supertype to all entities (beside those defined in an IFC resource schema). The primary function of both is to provide an identification service to all other entities (by inheritance). The IfcRoot entity additionally provides naming, description and history services. These are functions that are dealt with more directly at lower levels of the model in ECM.
Individual Object
In ECM, existence is considered to handle identifiable items including physically existent objects, persons and organisations, a state, a point or a vector in space. It may be seen therefore to handle the idea of occurrences. This can be seen as directly comparable to the IfcObject.
ECM IFC actual_individual IfcProduct whole_individual IfcControl single_individual IfcResource plural_individual IfcGroup state IfcProcess temporal_boundary_of_state IfcActor IfcProject point_in_space vector_in_space
Table 3: Subtypes of individual and IfcObject
Actual, single and whole individuals in ECM represent broadly equivalent concepts to those of IfcProduct, IfcControl or IfcResource in that a product can be decomposed in whole part structures in the same way as an individual. There are subtle differences in that the parts as opposed to the whole can be identified within ECM whereas this is identified for instances of IfcElement at a lower level within IFC through an element composition enumeration.
The plural individual concept appears to be broadly equivalent to IfcGroup in cases where the collection of instances is arbitrary. However, it also seems to act as a target for an aggregation that could appear as an IfcProduct.
There is no equivalent concept of IfcProject in ECM. This would have to be dealt with as an ‘individual’ with the global context attributes defined as properties.
State in ECM appears to closely resemble the idea of IfcProcess (particularly for the activity subtype). Both have the idea of a duration that can be bounded by start and end (creation and destruction) times. These are modelled by explicit entities in ECM and via the IfcScheduleTimeControl and/or constraints in IFC.
Equally, both ECM and IFC contain the concept of sequence (temporal_sequence) as a relationship between processes although IFC is slightly richer in that it can also apply limited process logic (lead/lag concepts).
However, ‘state’ has a broader context in that it can also be applied to physical objects (that can exist at a particular state). This appears to have value for the notion that an object can exist in various states at different points in time; an important concept in a project based model. This does not directly exist in IFC although the recently added IfcPerformanceHistory concept can be seen as a move to adopting a similar approach. However, this is mostly dealt with via property sets and not by directly instantiated objects.
Relation Relationship
Both ECM and IFC make extensive use of relationship classes (objectified relationships). Practically, the approach is similar in that both models handle the relationship of one class as an attribute or member of another class via the intermediate use of a relationship class.
58 CWA 15141:2004 (E)
Both models refine the semantics of relationships through rich sets of more specific relationship classes.
Class Property Definition
Class is a critical concept in the ECM and its development occupies the largest proportion of the model. It is the means by which ideas in the real world can be developed and instantiated. It provides the fundamental capability for the development of Reference Data that is a crucial component of any usage of the model (such as the ISO 15926 standard.
Although occupying a much smaller proportion of the overall IFC model (largely because of the explicitly defined taxonomic classes), the property definition is also significant because of the role it plays in enabling externally defined data that is also a crucial component in using the model.
Therefore, at the most basic level, the ECM class and the IFC property definition fulfil and equivalent purpose.
D.1.2 Reference Data Property Sets The fundamental key to using the ECM appears to be the development of reference data that is external to the model8. Since there is no taxonomy within the model, practical usage is totally reliant on such reference data.
Practically, the same could be said of IFC property sets (although the availability of a thin taxonomy within the model does enable its direct use for a number of purposes including the current heavily implemented coordination view). There are already many property sets published in conjunction with the IFC model and an ability to generate property sets for local/regional use on an ‘as needed’ basis.
Whilst reference data templates and property sets differ in structure, the objective of their content is pretty much the same. At the level of individual properties, it is probable that they are exactly equivalent or could be made so.
D.1.3 Conclusions The ECM and IFC models can be said to overlap (see figure 38 in which IFC is shown larger simply based on the number of entities in the published model). That is, there are concepts that are common.
Perhaps the most crucial difference is that of usage of taxonomy. A key to understanding the intersection of the models would be to dispose of the schema in the IFC model that contain taxonomy (essentially the shared and domain level schema) together with some of the resource level schemas. The explicit STEP derived schemas for geometry, topology, measures (with some entity exceptions) and date/time should also be omitted from a detailed consideration.
ECM
Intersection
IFC
Figure 42: Intersection of the EPISTLE Core and IFC models
This would leave two models that were more or less of the same size in terms of the number of entities and level of taxonomy (the assumption being that all taxonomy detail would be handled externally as reference data/property sets). It is concluded that the meta-schema of the two models show substantial common concept coverage.
8 EPISTLE Reference Data Library version 2, European Process Industries STEP Technical Liaison Executive, available at www.epistle.ws/
59 CWA 15141:2004 (E)
D.2 Comparison of STEP and IFC Entities
As a result of the liaison relationship between ISO TC184/SC4 and the IAI, a comparison has been carried out between capabilities of relevant schemas within the STEP series of standards (ISO 10303) and IFC. This process has been extensively supported by the EU prodAEC project that is seeking harmonisation between ICT standards for building construction.
The comparison is primarily concerned here with high level structuring entities in the schemas and with how each deals with representation. In both cases, the comparison only covers a small part of the total model.
IFC entity STEP entity
There are no equivalent entities in application_protocol_definition IFC since the IFC model does not application_context use an application protocol like application_context_element separation. However some of the information such as life cycle stage subtypes is available. IfcProduct This entity is a kind of mix of the corresponding STEP entities product, Has an optional attribute product_definition_formation and product_definition. ObjectPlacement. In the STEP It has inverse attributes Decomposes (inverse of RelatingObject) and integrated resources placement IsDecomposedBy (inverse of RelatedObjects) for the Entity information is not available for IfcRelDecomposes. STEP offers similar capabilities between the product of product definition. entities product_definition and product_definition_relationship. Information for life cycle stages appears at product_definition in STEP but may be dealt with in various ways in IFC (including by declaration of a relationship with a life cycle stage process). IfcProductRepresentation Similar to the entity property_definition IfcProductDefinitionShape Counterpart of the entity product_definition_shape IfcShapeAspect Counterpart of the entity shape_aspect IfcRepresentation Counterpart of the entity representation. Differences in the EXPRESS include. • The inverse attribute IfcRepresentation.OfProductRepresentation is missing in the STEP entity. This is due to the fact, that in IFC the attribute Representation S[1:?] directly points to IfcRepresentation • Where rules of the STEP entity are omitted in IfcRepresentation IfcRepresentationContext Counterpart of the entity representation_context IfcShapeRepresentation Although the name indicates, that this IFC entity is a counterpart of the STEP entity shape representation there are substantial differences. This is described n the IFC documentation as follows. Definition from ISO/CD 10303-42:1992: The shape representation is a specific kind of representation that represents a shape. Definition from IAI: The IfcShapeRepresentation represents the concept of a particular geometric representation of a product or a product component within a special geometric representation context. Several representation types for shape representation are included as predefined types: GeometricSet points, curves, surfaces SurfaceModel face based surface model SolidModel including swept solid, Boolean results and Brep bodies. more specific types are: SweptSolid swept area solids, by extrusion and lti
60 CWA 15141:2004 (E)
IFC entity STEP entity
revolution Brep faceted brep's with and without voids CSG Boolean results of operations between solid models, half spaces and Boolean results additional types some additional representation types are given: BoundingBox simplistic 3D representation by a bounding box SectionedSpine cross section based representation of a spine curve and planar cross sections. It can represent a surface or a solid and the interpolations of the between the cross sections is not defined MappedRepresentation representation based on a mapped item, referring to a representation map. Note: it can be seen as an inserted block reference. The representation type is given as a string value at the inherited attribute 'RepresentationType'. The EXPRESS of both entities is different. • the IFC entity contains 11 where rules, which have no counterparts in the STEP entity. • the IFC entity has the inverse attribute OfShapeAspect, which is missing in the STEP entity. • the IFC this entity is not a subtype. In STEP, this entity is heavily subtyped to define specific types of shape representations by adding constraints. This is used in application protocols to constrain the representation of the shape of specific products. IfcRepresentationItem and Counterpart of the entity representation_item. subtypes IfcRepresentationItem is an ABSTRACT SUPERTYPE. In STEP all subtypes of the entity representation are implicitly “ANDOR”. The supertype constraint is a consequence of the constrained usage of EXPRESS in IFC. Only ONEOF is allowed in the IAI environment. This results in the creation of new subtypes, whenever an ANDOR situation is encountered. Subtypes of IfcRepresentationItem correspond to equivalent subtypes of corresponding STEP entity.
Table 4: Comparison of IFC and STEP entities
D.2.1 Comparison of STEP and IFC Property Mechanisms Both schemas include the concept of properties that can be applied to objects. They differ slightly in dealing with the type of a property and with an individual property. A type of property may be represented or exchanged independently of any association to a product, just as a property. The same type of property may be applied to many items.
An individual property can only be represented or exchanged together with at least one item that it is the characterisation of. The name of the property is then connected to this one instantiation only. Other instances of individual properties may use the same property name, but there is no correlation among their occurrences.
STEP has a dedicated concept that can only be used for individual properties. IFC2x bases all assignments of properties on relationships; the property representations may, therefore, be dealt with independently as long as no relationship is instantiated.
61 CWA 15141:2004 (E)
IFC entity STEP entity
IfcProperty general_property IfcPropertySet IfcTypeObject (various specific property sets like IfcDoorLiningProperties) IfcRelDefinesByProperty property_definition IfcRelDefinesByType
Table 5: Representation of type of property and individual property
IfcTypeObject may carry the semantics of being the set of properties for an entity data type, that is, for all instances of an entity data type. All instances of this type shall then have these properties. This semantic is not present in STEP.
Collections of properties
As a matter of fact, the same type of property shall only be assigned once to an individual item. There are no collections of individual properties of the same type. There may, however, be collections of types of properties. An item may have – in general or for just a certain purpose - a single type of property only. In other cases it is convenient to make the use of a property dependent on the use of other properties, that is, some properties shall always occur in collections of properties.
Data model Single property Collection of properties
STEP general_property group of general_property IFC IfcProperty IfcTypeObject; IfcPropertySet
Table 6: Representation of single property and collection of properties
In STEP, general_property describes a single property, as does IfcProperty. IfcPropertySet and IfcTypeObject describe collections of properties; however, these collections may consist of single elements only and may, thus, be used to represent individual properties. In STEP, collections of properties may be modelled by applying the entity data type group.
Assignment of properties
In both models properties are assigned to the objects that they characterise, instead of being referenced from the objects. Therefore, objects may exist without properties being defined. The set of properties of an object may grow over the lifetime of the object. Different property sets may be exchanged for different purposes, for example, dependent of the receiving type of software application.
IFC uses relationship entity data types to assign both types of properties and individual properties to something. STEP uses a relationship entity data type for types of properties and a direct attribute for individual properties. The type assignment uses the individual assignment. A coordination of general_property.name and property_definition.name is, therefore, required.
Targets for property assignments
Properties may be assigned to various objects. In IFC the target for any property assignment is IfcObject. IfcObject is located high in the type inheritance tree; the entity data types that are excluded from property assignments are IfcPropertyDefinition and IfcRelationship together with their subtypes.
STEP uses a complicated combination of select types to specify valid targets:
property_definition.definition -> characterized_definition = (shape_definition = (product_definition_shape) (shape_aspect) (shape_aspect_relationship))
62 CWA 15141:2004 (E)
(characterized_product_definition = (product_definition)(product_definition_relationship)) (characterized_object)
Whereas the shape_definition and product_definition related targets are specific and, thus, constraining valid choices, characterized_object allows anything to be given a property. To use characterized_object a new subtype shall be created that inherits from characterized_object and from the one or several entity data types that the property shall be assigned to. Such subtypes are typically created in application protocols.
D.2.2 ISO 10303 Part 225 and IFC Entities ISO 10303 part 225 (AP225) is concerned with the explicit shape representation of building structures and so is the part of the STEP series of standards that has the closest scope comparison to the IFC model. Although being primarily concerned with shape representation, AP225 does have the capability to define semantics of building objects through its inheritance of product structuring from STEP resources as identified in 6.2.1 above.
Building elements
In both IFC and AP225 the basic approach to entity definition is similar. Entities that represent building elements are subtypes of product definition like entities. Differences include.
Specific building elements such as walls, beams and columns are not subtyped in AP225. In IFC, taxonomy is more widely defined through the provision of more subtypes of IfcElement than on the corresponding subtypes of AP225 which uses more high level entities e.g. the service_element entity of AP225 has a functional type attribute indicating whether it is an electrical element, an HVAC element, a transportation element etc. Aggregations of building elements
This is one of the cases, where AP225 has more entities with building construction specific semantics as IFC as by subtyping. Some of the differences between corresponding entities will be discussed in the following sections.
IfcBuildingStorey: Corresponds to building_level in AP225. In IFC, building elements may be positioned in the coordinate space of an IfcBuildingStorey. In AP225 they are positioned in the coordinate space of a building_section.
IfcSite: Corresponds to site in AP225
IfcBuilding: Corresponds to building_complex, building and building_section in AP225. In IFC, the distinction between the three different meanings is provided by the inherited attribute IfcSpatialStructureElement.CompositionType
IfcSpace: Corresponds to space_element in AP225. The IFC entity enables differentiation between space groups, spaces and partial spaces. Similar capabilities are provided in AP225 by building_element_group.
AP225 provides the entities building_element_assembly and building_element_group. They provide mechanisms for assemblies and logical grouping for example as grouping of building elements that bound a fire zone. The building_element_assembly entity enables representation of assemblies of elements such as roofs, frames, elevator compartments etc. Subtypes of the IfcRelationship entity provide the equivalent mechanisms in IFC.
Relationships
AP225 has one particular relationship entity over and above the general STEP capabilities that is of interest. This is item_proximity_relationship which specifies the relationship between neighbouring building elements. It distinguishes between the three predefined types of relationships penetration, space to element and touch. IFC can handle penetration and space to element relationships via its rich relationship model. However, the concept of touch is not handled.
63