ict standards for construction projects - vttcic.vtt.fi/projects/icci/deliverables/icci_d221.pdf ·...

Reza BEHESHTI Edwin DADO Saban OZSARIYLDIZ 18 July 2003 of 1

Classification: Restricted to ICCI Consortium Partners

ICT Standards for Construction Projects

Author(s): Reza BEHESHTI (TUDelft)

Edwin DADO (TUDelft) Saban OZSARIYILDIZ (TUDelft)

Issue Date 18 July 2003 Version V3 Deliverable Number D221 Task Number T2 Status Issue

ICT Standards for Construction Projects ICCI: IST-2001-33022WP2/D221

Reza BEHESHTI Edwin DADO Saban ÖZSARIYLDIZ 18 July 2003 of 2

Summary The European Building and Construction (BC) industry is to a great extent dominated by small and medium size enterprises (SMEs). The fragmented nature of this industry necessitates the implementation and use of well-thought-of standards. However, the development of these standards is often characterised by a slow progress due to the fragmentation of developments and the lack of general agreements. This is mainly caused by the presence of actors who are not dominant enough because of the aforementioned fragmentation. Although industry–wide standards are largely lacking, some developments have been quite successful. For example the standards developed by individual software companies such as DXF, PDF etc., referred to as de facto standards, have been widely adopted by the BC SMEs. Another source of successful standards, are those emerged from EU projects or other research projects elsewhere in the world.

This deliverable is a document presenting the results of the analysis, which has been carried out during the ICCI project as a part of the Work Package WP2, Task number T22. The major focus of this document is introducing ICT standards, which are specifically relevant for the European BC industry. The word ‘standard’ here is used as the implicit definition rather than the explicit one. This broader definition refers to either widely recognised or employed as a model of authority or excellence, which can be referred to as the de facto standard.

This document presents an analysis and synthesis of the ICT standards that are developed or adopted specifically by ICCI partner projects or emerged from these projects, considering that the scope of these projects is limited to the European BC industry.

In order to classify standards and to structure this document three abstraction levels are introduced, respectively data, information, and knowledge. Although this categorisation is relevant for most ICT standards, sometimes a particular standard may fall into two categories at the same time. The descriptive properties of the standards covered in this document and in the comparison tables are Version, Creator, Complexity, Status, Format, Open Source/Standard/Propriety, Target User (i.e. Purpose/Functionality) and BC Industry.



Document Revision Sheet

Revision Status Page Nos. Amendment Date By

0.5 Draft 51 Initial release. 29 August 2002

TUDelft

0.7 Draft 73 Revised. 30 September 2002

TUDelft

0.8a Draft 73 Revised. 16 October 2002

TNO

0.8b Draft 73 Commented By Dr. Alain Zarli 10 October 2002

CSTB

0.9 Draft 73 Revised. 1 November 2002

TUDelft

1.0 Issue 73 Revised 30 November 2002

TUDelft

1.4 Draft 69 Revised (restructured) 30 March 2003

TUDelft

1.5 Draft 67 Commented By Dr. Thomas Liebich

1 June 2003 AEC3

1.6 Issue 72 Submitted for review to prof. Fried Augenbroe (Gtech) and Jeff Stevens (Taylor Woodrow)

5 June 2003 TUDelft

2.0 Issue 75 Revised 15 June 2003 TUDelft

2.3 Issue 74 Revised pre-final 30 June 2003 TUDelft

2.5 Issue 74 Commented By Dr. Alain Zarli 11 July 2003 CSTB

3 Issue 74 Final 18 July 2003 TUDelft



Contents SUMMARY............................................................................................................................. 2

ABBREVIATIONS ................................................................................................................ 8

1 INTRODUCTION........................................................................................................ 13 1.1 ORGANISATION OF WORK PACKAGE 2 ........................................................................ 13

1.1.1 Objectives ...................................................................................................................... 14 1.1.2 Description of the work ................................................................................................. 14 1.1.3 Deliverables...................................................................................................................15 1.1.4 Milestones and expected results .................................................................................... 15

1.2 OBJECTIVES AND EXPECTED OUTCOME OF DELIVERABLE D221.................................. 15 1.2.1 Objective of D221.......................................................................................................... 16 1.2.2 The rationale of D221.................................................................................................... 16

1.3 CONCLUSIONS ............................................................................................................. 18

2 DATA AND INFORMATION STANDARDS........................................................... 19 2.1 DATA STANDARDS ...................................................................................................... 19

2.1.1 Structured Query Language (SQL)................................................................................ 19 2.1.2 Virtual Reality Mark-up Language (VRML).................................................................. 20 2.1.3 Scaleable Vector Graphics (SVG) ................................................................................. 21 2.1.4 Portable Document Format (PDF) ............................................................................... 23 2.1.5 PLT, DXF, and IGES..................................................................................................... 23 2.1.6 Wireless Application Protocol (WAP) ........................................................................... 24

2.2 INFORMATION EXCHANGE AND PRODUCT DATA STANDARDS..................................... 27 2.2.1 STEP-Application protocols for the BC industry .......................................................... 28

2.2.1.1 AP225.....................................................................................................................................29 2.2.1.2 AP228.....................................................................................................................................29 2.2.1.3 AP230.....................................................................................................................................30 2.2.1.4 BCCM ....................................................................................................................................31

2.2.2 Industrial manufacturing management data (MANDATE) ........................................... 31 2.2.3 IIDEAS........................................................................................................................... 31 2.2.4 IAI Industry Foundation Classes (IAI-IFC) .................................................................. 32

2.2.4.1 IFC Release History and Planning..........................................................................................33 2.2.4.2 Parts Library (PLIB)...............................................................................................................39

2.2.5 XML-based standards.................................................................................................... 42 2.2.5.1 bcXML ...................................................................................................................................42 2.2.5.2 aecXML..................................................................................................................................43 2.2.5.3 ebXML ...................................................................................................................................44 2.2.5.4 ifcXML...................................................................................................................................44 2.2.5.5 WML ......................................................................................................................................45 2.2.5.6 Extensible 3D (X3D)..............................................................................................................45

2.2.6 EDI-based standards ..................................................................................................... 47 2.2.6.1 EDI for Administration Commerce and Transport (UN/EDIFACT)......................................48 2.2.6.2 American National Standards Institute X12 (ANSI X12) ......................................................48 2.2.6.3 TRADACOMS.......................................................................................................................49 2.2.6.4 ODETTE ................................................................................................................................49

2.3 CONCLUSIONS ............................................................................................................. 49



3 INFORMATION COMMUNICATION & REMOTE ACCESS STANDARDS... 51 3.1 PROTOCOL STANDARDS............................................................................................... 51

3.1.1 The Component Object Model (COM)/Distributed COM (DCOM).............................. 51 3.1.2 ActiveX........................................................................................................................... 52 3.1.3 Common Object Request Broker Architecture (CORBA) .............................................. 53 3.1.4 Simple Object Access Protocol (SOAP) ........................................................................ 53

3.2 SERVICE STANDARDS .................................................................................................. 54 3.2.1 Universal Description, Discovery and Integration (UDDI).......................................... 55 3.2.2 Web Services Description Language (WSDL)............................................................... 56

3.3 ARCHITECTURAL STANDARDS..................................................................................... 56 3.3.1 Java Platform ................................................................................................................ 56 3.3.2 .Net Platform ................................................................................................................. 58

3.4 CONCLUSIONS ............................................................................................................. 59

4 KNOWLEDGE STANDARDS ................................................................................... 62 4.1 KNOWLEDGE INTERCHANGE FORMAT (KIF) ............................................................... 62 4.2 DARPA AGENT MARKUP LANGUAGE / ONTOLOGY INTERCHANGE LANGUAGE (DAML/OIL)...................................................................................................................... 63 4.3 KNOWLEDGE QUERY AND MANIPULATION LANGUAGE (KQML) ............................... 64 4.4 FIPA AGENT COMMUNICATION LANGUAGE (FIPA-ACL).......................................... 65 4.5 RESOURCE DESCRIPTION FRAMEWORK (RDF)............................................................ 66 4.6 RULE MARK-UP LANGUAGE (RULEML) ..................................................................... 67 4.7 CONCLUSIONS ............................................................................................................. 68

5 CONCLUSIONS........................................................................................................... 70

ACKNOWLEDGEMENTS................................................................................................. 72

REFERENCES..................................................................................................................... 73



Figures

FIGURE 1 AN ABSTRACT MODEL FOR DATA PRESENTATION AND ....................................................................... 21 FIGURE 2 A SVG BEAM EXAMPLE [FLEUREN, 2001]......................................................................................... 22 FIGURE 3 WAP PROGRAMMING MODEL (WAP FORUM, 2002)......................................................................... 24 FIGURE 4 STANDARDS UNDER ISO TC184/SC4 ................................................................................................ 28 FIGURE 5 IFC DEVELOPMENT TIMELINE. ........................................................................................................... 33 FIGURE 6 SCOPE OF IFC RELEASE 2.0 ............................................................................................................... 35 FIGURE 7 IFC RELEASE 2X EDITION 2 (PREVIOUSLY NAMED 3.0)....................................................................... 38 FIGURE 8 PLIB INFORMATION MODEL............................................................................................................... 39 FIGURE 9 BCXML META-MODEL FOR TRANSLATION SERVICES. ........................................................................ 42 FIGURE 10 AN X3D BROWSER............................................................................................................................. 46 FIGURE 11 MOVING FROM API INTEGRATION TOWARDS THE FILE INTEGRATION. .............................................. 47 FIGURE 12 DCOM: THE CENTRAL COMMUNICATION CORE ................................................................................. 52 FIGURE 13 THE MAIN COMPONENTS AND FEATURES OF THE .NET PLATFORM. ................................................... 59 FIGURE 14 THE DAML/OIL BASIC ELEMENTS AND THEIR RELATIONSHIPS. ........................................................ 63 FIGURE 15 KQML: AN EXCHANGE PROTOCOL AGENTS AND/OR APPLICATIONS................................................... 64



Tables

TABLE 1 THE STANDARDS ARE GROUPED INTO THREE ABSTRACTION LEVELS. ................................................ 17 TABLE 2 COMPARISON OF THE IMPROVEMENTS OF VRML 1.0 AND VRML97................................................. 20 TABLE 3 WAP ENVIRONMENT AND WIRELESS PROTOCOLS............................................................................. 25 TABLE 4 DATA STANDARDS ............................................................................................................................. 26 TABLE 5 IMPLEMENTATIONS OF IFC1.5.1 ........................................................................................................ 35 TABLE 6 IMPLEMENTATIONS OF IFC2.0 ........................................................................................................... 36 TABLE 7 IMPLEMENTATIONS OF IFC2X ............................................................................................................ 37 TABLE 8 PRODUCT DATA AND INFORMATION STANDARDS ............................................................................. 41 TABLE 9 DATA AND INFORMATION STANDARDS BASED ON XML ................................................................... 50 TABLE 10 INFORMATION COMMUNICATION STANDARDS................................................................................... 61 TABLE 11 KQML PERFORMATIVES ORGANISED INTO SEVEN BASIC CATEGORIES............................................... 65 TABLE 12 KNOWLEDGE EXHANGE STANDARDS................................................................................................. 69



Abbreviations A2A Application-to-Application

A2H Application-to-Human

ACL Agent Communication Language

AEC Architecture, Engineering and Construction

AIML Artificial Intelligence Mark-up Language

ANSI American National Standardisation Organisation

AP Application Protocol

API Application Programming Interface

ASP Active Server Pages

B2B Business-to-Business

B2C Business-to-Consumer

BC Building and Construction (industry sector)

BCCM Building Construction Core Model

BC Ontology Building and Construction Ontology

BCS The British Computer Society

BC Taxonomy Building and Construction Taxonomy

bcXML Building and Construction Mark-up Language

CAD Computer-Aided Design

CIM Computer Integrated Manufacturing

CIS CIMSteel Integration Standards

COM Component Object Model

CORBA Common Object Request Broker Architecture [developed by OMG]

CSCW Computer Support for Co-operative Work



CLR Common Runtime Library (from MS .Net platform)

DCOM Distributed Component Object Model

DIVERCITY DIstributed Virtual Workspace for Enhancing Communication within the Construction Industry [ICCI partner project]

DOM Document Object Model

DP Data Processing

DTD Document Type Definition

DW Data Warehouse

DXF AutoCAD Drawing eXchange Format

EAI Enterprise Applications Integration

EDI Electronic Data Interchange

eBusiness Commercial or non-commercial; B2B or B2C; A2A or A2H

e-COGNOS Methodology, tools and architectures for electronic COnsistent knowledGe maNagement across prOjects and between enterpriSes in the construction domain [ICCI partner project]

eCommerce Involving goods/services Supply-Chains: commercial buying & selling off-the-shelf goods/services

eConstruct Electronic Business in the Building and Construction Industry: Preparing for the new Internet [ICCI partner project]

Project for eBuilding (esp. eCommerce) over NGI addressing European aspects (country-specific languages & taxonomies)

EDI Electronic Data Interchange (trade/commercial data)

EDMS Electronic Document Management System

eLEGAL Specifying Legal Terms of Contract in ICT Environment [ICCI partner project]

ERP Enterprise Recourse Planning

EU European Union

Exchange Transfer or sharing (of data/information/knowledge)

FIPA Foundation for Intelligent Physical Agents



GLOBEMEN Global Engineering and Manufacturing in Enterprise Networks [ICCI partner project]

HTML Hyper Text Mark-up Language

HTTP Hyper Text Transfer Protocol

HVAC Heating, Ventilation, Air-Conditioning

IAI International Alliance for Interoperability

ICCI Innovation co-ordination, transfer and deployment through networked Co-operation in the Construction Industry

ICCI Inter-Connecting Construction Industry

ICT Information and Communication Technology

ICKT Information Communication and Knowledge Technology

IFC Industry Foundation Classes [developed by the IAI]

Internet Interconnected Networks (The Internet, Intranet, Extranet and other web services)

ISO International Organisation for Standardisation

IST User-friendly Information Society Programme [EU 5th Framework]

ISTforCE Intelligent Services and Tools for Concurrent Engineering [ICCI partner project]

IT Information Technology

J2EE Java 2 Platform, Enterprise Edition

JDBC Java Database Connectivity

JNDI Java Naming and Directory Interface

JMS Java Message Service

JSP Java Server Pages

KM Knowledge Management

KIF Knowledge Interchange Format

KQML Knowledge Query and Manipulation Language



LAN Local Area Network

LexiCON Lexicon for Construction

LSE Large Scale Engineering

MANDATE Industrial manufacturing management data

NGI Next Generation Internet (XML-based) [W3C]

OMG Object Management Group that develops the CORBA standard

OS Operating System

OSMOS Open System for Inter-enterprise Information Management in Dynamic Virtual EnvirOnmentS

PC Personal Computer

PDA Personal Digital Assistant

PDF Portable Document Format

PDI Product Data Interchange (technical data)

PDT Product Data Technology

P-LIB ISO/STEP Parts library

PoP Point of Presence

R&D Research and Development

RPC Remote Procedure Call

RDF Resource Description Framework

RuleML Rule Mark-up Language

SGML Standard Generalised Mark-up Language

SME Small and Medium size Enterprise

SOAP Simple Object Access Protocol

SQL Structured Query Language

STEP Standard for The Exchange of Product model data

SVG Scaleable Vector Graphics



SWOT Strength Weakness Opportunity Threat

TCP/IP Transmission Control Protocol/Internet Protocol

UBR UDDI Business Registry

UDDI Universal Description, Discovery and Integration service protocol

UML Unified Modelling Language [OMG]

URI Uniform Resource Identifier

URL Uniform Resource Locator

VE Virtual Enterprise

VRML Virtual Reality Mark-up Language

W3C World-Wide-Web Consortium (http://www.w3.org/)

WAN Wide Area Network

WAP Wireless Application Protocol

WDP Wireless Datagram Protocol

WML Wireless Mark-up Language

WP Work Package [ICCI]

WSDL Web Services Description Language

WSP Wireless Session Protocol

WTLS Wireless Transport Layer Security

WTP Wireless Transaction Protocol

WWW World Wide Web

X3D eXtensible 3D

XML eXtensible Mark-up Language [developed by W3C]

XSD XML Schema Definition

Reza BEHESHTI Edwin DADO Saban OZSARIYLDIZ 30 June 2003 of 13

1 Introduction This deliverable is a document presenting the results of the analysis and synthesis of ICT standards, which has been carried out during the ICCI project as a part of Task 22 as described in Work Package 2. The major focus of this document is introducing ICT standards, which are specifically relevant for the European BC industry. The word ‘standard’ here is used as the implicit definition rather than the explicit one. This broader definition refers to either widely recognised or employed as a model of authority or excellence, which can be referred to as the de facto standard.

The ICCI1 partner projects have provided the necessary information about the current ICT standards that are relevant for the European BC industry. Furthermore, this information covers the entire life cycle of BC projects. This investigation is based on the assumption that these ICT standards fall into the following three main categories:

• Data (e.g. VRML, PDF, SQL, etc.) • Information (e.g. ISO STEP, XML, CORBA, UDDI, etc.) • Knowledge (e.g. KIF, KQML, DAML/OIL, RuleML, etc.)

The following chapters give some detailed descriptions of the above mentioned categories in the context of the different properties of individual standards such as Version, Creator, Complexity, Status, Format, Open Source/Standard/Propriety, Target User (i.e. Purpose/ Functionality) and BC Industry. The categories in some cases may contain outdated standards in order to show the evolutionary path of the current standards. In addition, some emerging and future ICT standards are studied that are not mentioned in the ICCI partner projects.

Based on these observations, a clear picture is drawn for the use of the ICT standards relevant to the BC industry today but specifically relevant for the future. The latter can also point to relevant future research topics for the BC industry.

1.1 Organisation of Work Package 2

This document entitled ‘State-of-the-art in ICT standards & standardisation efforts’ (D221) is part of Task 22 ‘State-of-the-art in ICT markets, standards and R&D’ (T22) as described in Work Package 2 ‘ICT Infrastructures for Construction Projects’ (WP2). Some aspects covered in this document overlaps with the deliverable D222 ‘Market Watch’ and D23 ‘Synthesis of Projects ICT Infrastructures’. Before embarking on a detailed description of this deliverable, it is necessary to give a brief description of the organisation of WP2.

In this section the WP2 objectives, description of the work, deliverables, milestones and expected results are introduced.

1 ICCI is a cluster project consisting of the following projects: OSMOS, eConstruct, Divercity, ISTforCE, eLEGAL, GLOBEMEN.



1.1.1 Objectives

The main objective of this report is to identify and structure all the RTD themes that are shared by the ICCI partner projects to develop and set-up a multilingual dictionary of related terms:

• Creating an ontological base of the fields of ICT in construction

• Providing an up-to-date synthesis of: o Market watch studies

o Existing standards and standardisation efforts

o RTD advances in the various fields targeted by the ICCI partner projects.

• Realising a synthesis of innovative research paths pursued by the ICCI partner projects as well as complementary expected results (e.g. models, APIs) and potential synergy

• Realising a synthesis of the ICCI partner projects’ ICT infrastructures

• Organising technical workshops and meetings amongst projects under the ICCI umbrella, as well as other projects identified in the course of ICCI (and of potential interest for ICCI)

An additional objective is to investigate the promising standards required for future developments of tools and services for the BC industry, e.g. the ‘ICCI IT Services Platform’.

1.1.2 Description of the work

WP2 is structured into the following four tasks:

Task T21: ICCI ontology framework, glossary and classification for ICT

This task aims firstly at identifying and structuring all the RTD themes that are shared by ICCI partner projects. Secondly, this task aims at the development and setting-up a multilingual dictionary of terms related to the fields covered by ICCI. A classification of topics will also be defined thus effectively creating an ontological base of the field of ICT in construction. Such a terminology will be used throughout the ICCI project and in particular in the documentation produced in each IST project. It will be refined until the ICCI completion. The objective is to constitute a common reference of the terms used, along with their definitions. It will also be used to provide a controlled vocabulary for information retrieval and structure of ICT knowledge bases.

Task T22: State-of-the-art in ICT markets, standards and R&D

This task will provide an up-to-date synthesis of (1) market watch studies, (2) existing standards and standardisation efforts (the subject of this deliverable) and (3) RTD technical advances in the various fields targeted by ICCI, along with the assessment of potential risks regarding the construction industry acceptance and take-up of the identified IT and communication technologies.



Task T23: synthesis of projects ICT infrastructures

For each identified RDT theme, this task will identify innovative research paths pursued by the IST projects under ICCI as well as complementary expected results (e.g. models, APIs) and potential synergy. This task will organise technical workshops and meetings amongst projects under the ICCI umbrella, as well as other projects identified in the course of ICCI, the work of which could be of potential interest for ICCI.

Task T24: delivery of tools and services to the construction industry

Relying on the outputs from the previous tasks and especially Task T23, this task will investigate ways to optimise future delivery of tools and services to construction companies and SMEs, e.g. the ‘ICCI IT Services Platform’, which can be implemented as the lowest common denominator of similar platforms developed in the ICCI projects. The task will encompass transversal integration of various technologies in order to lead to demonstrators preparing the emergence of new services and/or new infrastructures.

1.1.3 Deliverables

WP2 has the following six deliverables:

• D211: ICT common glossary • D212: ICT ontological framework and classification • D221: State-of-the-art in ICT standards & standardisation efforts (this document) • D222: Market watch • D223: RTD advances and migration risks • D23: Synthesis of projects ICT infrastructures • D24: Guide for tools/services delivery

1.1.4 Milestones and expected results

• Milestone: M2

• Expected Results: delivery of D211, D212, D221, D222, D223, D23 and D24

1.2 Objectives and expected outcome of Deliverable D221

The European Building and Construction (BC) industry is to a great extent dominated by small and medium size enterprises (SMEs). The fragmented nature of this industry necessitates the implementation and use of well-thought-of standards. However, the development of these standards is often characterised by a slow progress due to the fragmentation of developments and the lack of general agreements. This is mainly caused by the presence of actors who are not dominant enough because of the aforementioned fragmentation. Although industry–wide standards are largely lacking, some developments have been quite successful. For example the standards developed by individual software companies such as DXF, PDF etc., referred to as de facto standards, have been widely



adopted by the BC SMEs. Another source of successful standards, are those emerged from EU projects or other research projects elsewhere in the world.

1.2.1 Objective of D221

The objective of this deliverable is to provide an up-to-date analysis and synthesis of the existing ICT standards and standardisation efforts regarding the BC industry. In order to achieve this objective, the use of standards within the ICCI partner projects has been analysed. In addition, whenever appropriate, this analysis is extended with a brief study of other relevant standards. Also this deliverable may help BC actors with a wider acceptance and take-up of the identified IT and communication standards.

1.2.2 The rationale of D221

In order to classify standards, three abstraction levels are introduced, respectively data (e.g. VRML, PDF, SQL, etc.), information (e.g. IFC, XML, CORBA, UDDI, etc.), and knowledge (e.g. KIF, KQML, DAML/OIL, RuleML, etc.). In Human-to-Human communication there is no need to make distinction between data, information and knowledge levels. However, Human-to-Computer communication and vice versa requires clear distinction between these three abstraction levels. By definition at the data level, the information is stored in computers or is exchanged by computers. At data level, information is not yet interpreted by either humans or computers. In this regard, the information level concerns the ‘structured’ data that does not need any further interpretation or processing. At the knowledge level computers have the capability of processing data and information for a particular purpose such as represented in ontologies, taxonomies and intelligent agents.

Noticeably, the added value of the adoption, implementation and use of ICT standards by the BC industry is driven by the increasing use of ICT in order to achieve the following:

• Improving cooperation and communication at both project and company level

• Increasing efficiency of BC SMEs and organisations

• Enhancing business performance (e.g. B2B, B2C, etc.) In order to gain the maximum benefit from ICT developments and to secure ICT investments for the future, these developments should be based on existing or emerging standards. These standards should conform to one or more of the following functionalities described in terms of interoperability, sharing, communication, automation:

Interoperability is the smooth exchange of electronic data, information and knowledge. In BC where every project has several actors, the most efficient approach is to use a shared project model and a single common language. It enables a co-ordinated approach to project delivery and facilities management. Interoperability in BC often refers to the use of neutral formats for the exchange of data, information, and knowledge. Amongst others interoperability can be described by the following characteristics:



• Language independency refers to the exchange of data, information and knowledge between software platforms regardless of the requested or implemented language.

• Application independency refers to the exchange of data, information and knowledge regardless of the software application and the vendor.

• Platform independency refers to the use of data, information and knowledge regardless of the hardware and the Operating System.

As mentioned before, multi-actor BC projects require a shared model for the communication amongst actors, which is preferably based on a neutral format for the data exchange. Data sharing is about how data, information and knowledge are shared by actors assuming that these are available in a (centralised or distributed) project repository. From this definition, data sharing is also involved with the reusability of data, information and knowledge as stored in Web-based libraries and catalogues of all actors, especially those related to the supply chain. Sharing data, information and knowledge also requires the availability of communication protocols and standards in addition to data exchange standards. Data exchange, sharing and communication (including messaging) requires an ICT infrastructure (including hardware and software) that itself requires additional protocols and standards for the transportation and integration data, information and knowledge. The above-mentioned arguments are summarised in table 1 that also provides some examples of related standards at each abstraction level. Detailed explanations are given in the following chapters.

Abstraction Level

Purpose (Functionality)

Example Standards

Sharing neutral data formats and Representation of data

PDF, SQL, DXF, VRML, SVG, VoiceML, etc.

Data

Service and platform for data sharing and representation

WSDL, UDDI, JAVA, .NET, etc.

Information exchange EPISTLE, BCXML, IFCXML, ect.

Information representation/sharing and Object sharing

X3D, SOAP, CORBA, DCOM, ActiveX, etc.

Information

Communication protocols and Meaningful libraries and catalogues

PLIB, IFC, bcXML, etc.

Knowledge Knowledge Reuse, Automation DAML/OIL, RDF, etc.

Table 1 The standards are grouped into three abstraction levels: (1) data, (2) information and

(3) knowledge. Examples are given in the context of usage, purpose and functionality.

In order to improve their efficiency and to enhance business performance, BC SMEs and organisations adopted ICT related tools for automation (including related standards and protocols) as found in other industries. The latter involves repetitive tasks that can be automated. However the characteristic of the BC industry is that it involves one-of-a-kind products and processes. In this regard BC is to employ other complementary measures to accommodate these BC-specific characteristics. This leads to the necessity of BC-specific



standards and protocols that are either emerged from the existing ones or are developed from scratch.

1.3 Conclusions

The investigation shows the widespread and fragmented use of many standards in the BC industry. However these standards are not all customised for the needs of the BC industry or not developed at a level that makes them commercially feasible. Although the latter are the prime examples of the very promising developments that need further investigation and application throughout the BC industry. Therefore, steps have to be taken to recognise and develop BC-specific standards and protocols (tools and infrastructures). This requires a great industry-wide effort. But the fragmented nature and the lack of dominant actors in the BC industry is a major bottleneck in this process. To improve this situation, next to the improving industry-wide acceptance and use of these developments, it is also necessary to make and implement policies at the EU level to encourage and facilitate such developments.


2 Data and Information Standards This chapter focuses on the standards for the data and information abstraction levels as discussed in chapter 1, namely, data standards and information exchange and product modelling standards.

2.1 Data Standards

Data standards discussed in this section are: SQL, VRML, SVG, PDF, DXF, PLT, IGES and WAP, further analysed.

2.1.1 Structured Query Language (SQL)

The Structured Query Language (SQL) is a database query language that was adopted as an industry standard in 1986. Since then SQL has been transformed from a simple database query language into a complete language for the definition and management of persistent complex objects. The new version of SQL, includes generalisation and specialisation hierarchies, multiple inheritance, user defined data types, triggers and assertions, support for knowledge-based systems, recursive query expressions, and additional specifications for data administration tools. These functional specifications are related to the definition of abstract data types (ADT) including features such as object identifiers, methods, inheritance, polymorphism, encapsulation, and all of the other functionalities normally associated with object data management.

In 1993, the ANSI and ISO development committees decided to split future SQL3 developments into a multi-part standard. These parts are:

• Part 1: Framework: A non-technical description of how the SQL specifications document is structured

• Part 2: Foundation: The core specification, including all of the new ADT features

• Part 3: SQL/CLI: The Call Level Interface

• Part 4: SQL/PSM: The stored procedures specification, including computational completeness

• Part 5: SQL/Bindings: The Dynamic SQL and Embedded SQL bindings taken from SQL-92

• Part 6: SQL/XA: An SQL specialisation of the popular XA Interface developed by X/Open

• Part 7: SQL/Temporal: Adds time related capabilities to the SQL standards In the fall of 1996, several parts of SQL3 went through an ISO CD ballot. Those parts were SQL/Framework, SQL/Foundation, and SQL/Bindings but those ballots failed with more than 900 comments. Although the latter has the capability of sophisticated object management (containing semantic information stored in objects that could be also considered as information standard as described in section 2.3), it is still used as a simple database query language.



The SQL is widely accepted all over the world as the data exchange and modelling standard. There are actually a number of SQL standards’ committees engaged in standardisation efforts. There is also an international SQL standards group as a part of ISO. A number of countries have committees that focus on SQL. These countries (usually) send representatives to ISO/IEC JTC1/SC 21/WG3 DBL meetings. The countries that actively participate in the ISO SQL standards are: Australia, Brazil, Canada, France, Germany, Japan, Korea, The Netherlands, the UK and the USA.

The acceptance and use of SQL as a standard by the BC industry is limited to the company and individual levels. The widely used CAD systems support this standard. An additional functionality of SQL is to store product catalogues or libraries as well as managing administrative works that are stored in databases that are based on SQL. However, due to the fact that the BC is a fragmented industry, the use of SQL for integration or data exchange, does not occur on a large-scale.

2.1.2 Virtual Reality Mark-up Language (VRML)

The Virtual Reality Mark-up Language (VRML) emerged during the first generation of the World Wide Web when HTML acted as a paper or as a page in the real life. The VRML at that time, aimed at simulating the reality in a virtual 3D space making it available on the Internet. The VRML is a mark-up language like HTML. VRML is developed by ISO WEB3D Consortium as an open standard. Later on VRML was accepted as an international standard (ISO/IEC-14772-1, 1997) by the International Organization for Standardization (ISO) and the International Electro-technical Commission (IEC) in December 1997 [VRML, 2000]. Table 2 shows the latest improvements of VRML that are later evolved to X3D (section 2.2.5.6).

Table 2 One of the improvements of VRML 1.0 is that VRML97 adds more interactive objects.

Recently, VRML is widely accepted by various industries and people. Many software vendors provide free and commercial tools that are using the VRML standard specification. For instance, VRML is used a communication protocol between a CAD system and an Animation tool. In addition, the industries such as the Building and Construction or Goods Industries are presenting their products on the Internet by using VRML. An alternative use of VRML is for creating cyber cities, virtual markets, or virtual museums, allowing people to meet and interact. There are added-values to the use of VRML in the BC by for instance providing better communication with the client in order to satisfy the client’s demand or to communicate with the authorities regarding to the escape routes for fire safety, etc.

VRML 1.0 VRML 97 Shape objects (cube, sphere, cone, cylinder, text), Arbitrary objects (surfaces, line set, point set), Browsing objects, Lights object, Camera object (viewpoints), Textures objects, Link object, Define and reuse object

Animated object, Switches object, Sensors object, Script object (Java or JavaScript) for behaviours, Interpolators (colour, position, orientation, etc.), Background Colour and Texture object, Sound (.wav and MIDI), Animated Texture object, Extrusion object, Event object, Route object



Two major bottlenecks have slowed down the adoption of VRML in the BC industry. The first one is the technological bottleneck. This regards the speed of the Internet and computers, which either they cannot handle the complex shapes or they are too slow. The second one is the semantic bottleneck. This relates to the fact that it is not possible to link any additional information to the shape, or it is too difficult for end users (they are not programmers) to create such information. However, the Next Generation Internet (NGI) and the arrival of fast computers will probably solve the above mentioned bottlenecks. This is how the X3D was born.

2.1.3 Scaleable Vector Graphics (SVG)

Scaleable Vector Graphics (SVG) is a new 2D graphics file format and web development language based on XML. SVG is developed as an open standard by W3C group. SVG enables web developers and designers to create dynamically generated, high quality graphics from real-time data with precise structural and visual control. With this powerful new technology, it is possible to create new generation of web applications based on the data-driven, interactive, and personalised graphics [Adobe, 2001].

Using SVG allows for data-driven 2D graphics, because it is entirely written in XML. Therefore the content can be linked to back-end business processes, such as eCommerce, shared databases (product database) and other data rich sources (XML-based) of real time information. SVG also supports other extensible style sheet languages, so that graphics can be easily customised.

Data Presentation Representation

Persistent Transient

Data Logic GUI Logic

Interaction GUI

Semantic Syntactic

Figure 1 An abstract model for data presentation and representation by using XML-based SVG.

Many benefits can be gained by using data-driven graphics. Firstly, it reduces the maintenance costs, development time, scaleable solutions, and it can be easily updated. Changing images, by eliminating the pictures, can reduce the maintenance costs. As an example, a product picture can be replaced by SVG definitions, which may also contain colour, shape, text, and size properties. Because SVG is text based, it is possible to utilise new definitions and track changes or link it to a product database. Secondly, it reduces the development time of products. In traditional web work flow, data, presentation, and application logic are developed sequentially (Figure 1). In this regard, the entire graphics



must be re-created when a change is made to the content after a project is completed. SVG helps to separate these tasks, in order to work more efficiently and if required to change the graphics. Finally, SVG is scalable which refers to the fact that it is possible to use one shape definition for different platforms such as PDA’s, cellular phones, etc. In addition, the shape information is changed without a developer, and hence new designs can be inserted at any time.

Interactive 2D Graphics with SVG is possible by combining the existing web technologies like HTML, JavaScript, DOM, Java, or Visual Basic in order to create extremely rich interactive graphics. Any SVG graphic element or object can modify or control any other SVG or HTML element or object. For instance, the movements of the mouse over a list of part numbers in a HTML table can highlight an illusion of that part in an accompanying SVG assembly diagram. Alternatively, specifications of a beam can pop-up and then resize the beam shape properties. It can also generate the drawing of a building element by dynamically translating the dimensions and geometric properties of the building element into a visual representation, with reference to all dimensions of the drawing (Figure 2).

Personalised 2D Graphics in SVG can easily be customised because it is text based. For instance a SVG graphic which contains English text can easily be translated into another language if needed for localisation purposes. In this regard the end-user can reuse the localised SVG graphic.

Figure 2 A SVG beam example [Fleuren, 2001].



SVG has promising capabilities for the BC industry, because it can bridge the gap between the paper-based world of the past and the electronic world of the future [eConstruct, 2002]. Paper as a means of communication will exist for many decades in the BC industry. This is a fact that cannot be ignored. An interesting point is that the application of SVG as an electronic paper format that can be steered by the same XSLT style-sheet that also produces HTML and X3D. In other words it is one source with several targets. The added value here is the chance to maintain one version of the data and produce various printable outputs on demand.

2.1.4 Portable Document Format (PDF)

The Portable Document Format (PDF) is a de facto standard for electronic document distribution worldwide which is the propriety of Adobe. PDF is a universal final2 ePaper document format that preserves all the fonts, formatting, graphics, and colour of any source document, regardless of the application and platform used to create it. PDF files are compact and can be shared, viewed, navigated, and printed exactly as intended by anyone using the PDF reader software [ADOBE, 2002]. The current version of PDF (version 1.3) has the following features and abilities for the creators/users of PDF files such as file protection, to print exactly on any device, to preserve the document’s visual integrity, to save PDF files as Rich Text Format. Furthermore, PDF files contain meta-information about the content and structure of the PDF file which make them accessible.

In addition, the new version of PDF will also support XML-based content that are stored as XObjects. In the future this may facilitate embedding XML-based content such as bcXML or ifcXML into a PDF document. A potential application for this feature in the BC industry is for example building specification linked to design drawings. These two documents become living documents in such a way that when the design changes, the specification will also change.

2.1.5 PLT, DXF, and IGES

The results of case studies done during several EU projects in the past (e.g. eConstruct, eCognos, etc) showed that the BC is not yet intensively using standards for information exchange. Plans, contracts, reports and many other documents are all created electronically, but they are rarely exchanged electronically despite the available communication infrastructures. A reason for this inefficiency is the variety of the software systems used within the construction industry bringing in a variety of data formats.

Usually the exchange of drawing data takes place, if at all, via the de facto standards3 such as PDF, DXF, PLT, etc. The quality of the transfer is often not satisfying and a further handling

2 In the sense that a document stored as PDF file cannot be modified or changed. 3 Although the dwg, dgn, doc, xls, etc. file formats are also changed, they are application specific formats, and hence they

are excluded.



of the drawing is difficult. A substantial potential for optimisation can be particularly gained by using standard formats.

The widely used standard DXF is the propriety of Autodesk. The AutoCAD DXF (Drawing eXchange Format) and AutoCAD DXB (Drawing eXhange Binary) formats are the native vector file formats of Autodesk's CAD application. [AUTOCAD, 2002] DXF is probably one of the most widely supported vector formats in the world today. DXF is rich in features, including: support for 3D objects, curves, text, associative dimensioning, and is an easy format to parse. The DXB format is a binary representation of a DXF file and they are usually smaller and faster to load than the equivalent DXF file.

The creation of all CAD documents in a standard format is recommendable – also with regard to archiving. In order to ease and guarantee tasks over several years and later modifications, the archiving in a permanent, producer-independent format is preferable. Currently electronic archives of drawings and documents in construction are using the TIF format (Tagged Image File) and PDF format from Adobe. As both formats are bitmap formats (this is also the case for embedded TIFF, JPG or bitmaps in PDF documents), the ‘background’ information for future re-use of the original documents is lost. Nevertheless, the experience of the past ten years has shown that a long-term archive of documents in native, product dependent data formats requires an intensive maintenance of these documents – a task for which construction companies usually are not paid for.

2.1.6 Wireless Application Protocol (WAP)

Wireless devices such as mobile phones, personal digital assistants, etc. are constrained in terms of limited CPU, memory, battery life, and a small and simple user interface. At the same time, the wireless networks through which they communicate are constrained by low bandwidth, high latency, and unpredictable availability and stability [WAP Forum, 2002]. These problems are addressed through the Wireless Application Protocol specification, which attempts to enable industry participants to develop air interface independent, device independent and fully interoperable solutions for wireless devices (Figure 3). Delivered through WAP-enabled wireless devices, WAP services are tuned to provide timely information access and delivery where and when a full screen environment is not required or is not available.

Figure 3 WAP Programming Model (WAP Forum, 2002)



The Wireless Application Protocol (WAP), published by the WAP Forum (founded in 1997 by Ericsson, Motorola, Nokia and Unwired Planet) is an open application communication protocol used to access services and information through wireless devices such as mobile phones, personal digital assistants, etc. WAP is an open standard protocol designed for ‘micro browsers’ that enables the creation of web applications for mobile devices. It is based on existing Internet standards such as HTML, XML, TCP/IP, etc. WAP specifies a Wireless Application Environment and Wireless Protocols (Table 3):

Wireless Application Environment Wireless Protocols

WML Microbrowser Wireless Session Protocol (WSP)

WMLScript Virtual Machine Wireless Transport Layer Security (WTLS)

WMLScript Standard Library Wireless Transaction Protocol (WTP)

Wireless Telephony Application Interface Wireless Datagram Protocol (WDP)

WAP Content Types Wireless network interface definitions

Table 3 WAP Environment and Wireless Protocols

Known limitations other than support for colour and graphics are due to the limited capacities of client devices. While some WAP devices support deck sizes of up to 3000 bytes, others are limited to 1074 bytes, thereby making it difficult to serve content without consideration of the client device. In terms of images, only WBNP (wireless bitmap images) are currently supported. Their dimensions are again constrained, based on the display size of the client device. Furthermore, since a WBNP forms a part of the deck, care must be exercised to ensure that the size of the deck is controlled. Limitations are now being resolved as more bandwidth becomes available and the second generation of WAP-enabled devices become available. It is inevitable that mobile communication is part of our daily life, and in the near future we can expect that the businesses such as the BC industry will benefit from the developments regarding mobile communications. In this regard, the BC industry should have a close watch on the developments of mobile communication standards and protocols.



Table 4 Data Standards

Model Creator Version Format Status Open Source/

Standard

Purpose (functionality)

BC Industry Complexity

DXF Autodesk 14

2000- 4

Neutral Format Final Owned by Autodesk

CAD data exchange Widely used +

IGES American National Standard (ANS)

5.3 Neutral Format Final US Standard CAD data exchange Widely used +

PDF Adobe 1.3 Portable Final Owned by Adobe

ePaper document exchange

Widely used ++

PLT Cal comp 2.0 Neutral Format Final Owned by Cal comp

CAD plot file exchange

Widely used +

SQL ANSI/ISO 3.0 Neutral Format Decision Stage Standard Structured data exchange

Used +

SVG W3C 1.0 Neutral Format Recommendation Standard 2d vector graphics exchange

Used +

VRML ISO 2.0 Neutral Format Final Standard Web enabled 3D Shape data exchange

Widely Used +

WAP W3C 0.2 Neutral Format Conformance Release

Open Standard

Wireless applications communication

Used +



2.2 Information Exchange and Product Data Standards

Product Data Technology is essentially the application of IT specialised for industrial application. The aim of PDT is to design and apply common information models that use the same notions as the human practitioners. The idea is that in the future information and knowledge only can flow freely if humans and computer applications share a simplified version of the same technical vocabulary (syntax and semantics).

The most important product modelling effort, taking all industry sectors into account, is undoubtedly ISO-STEP [STEP, 1983]. STEP is an open ISO-standard (ISO 10303) that includes a large number of partial models and, in theory, supports meaningful information exchange between different industries. Taken the facts that some participants in a construction project also work in different industries (like Electrical and Mechanical Engineering), the broad scope of STEP is potentially attractive. In this section we also make some references to historical issues regarding the developments of STEP because these developments can shed light on the direction taken by current standards.

More important, the ISO-STEP standard is a series of standards, which include the basic foundations for product data exchange, namely the EXPRESS data definition language (ISO 10303-11), various implementation methods, like the STEP physical file (ISO 10303-21) or the Standard Data Access Interface (ISO 10303-22), next to the actual data models for information exchange. The structure is described in STEP part 1 ‘Overview and fundamental principles (ISO 10303-1)’ as:

• Description methods Parts 11 to 19 • Implementation methods Parts 21 to 29 • Conformance testing methodology and framework Parts 31 to 39 • Integrated resources: Generic resources Parts 41 to 99 • Integrated resources: Application resources Parts 101 to 199 • Application protocols Parts 201 to 1199 • Abstract test suites Parts 1201 to 2199

This series of ISO 10303 standards is developed and decided upon within the ISO committee TC184 (Industrial automation systems and integration) SC4 (Industrial data), however ISO TC184/SC4 is also the umbrella of other related standards, such as MANDATE, IIDEAS, POSC/CEASAR and others.

Figure 4 shows all standards that are developed under the umbrella of ISO TC184/SC4. In addition to standards directly developed inside ISO, a new policy is adapted by TC184/SC4 that allows accepting externally developed and verified standards through a so-called ‘harvesting process’. The first standard that was added under this new procedure is the IFC2x platform, developed by the IAI under the designation ISO/PAS 16739.



ISO TC184/SC4

ISO 10303STEP

ISO 13584PLIB

ISO 15531MANDATE

ISO 15926Oil/Gas

ISO 18629PSL

ISO 18876IIDEAS

ISO/PAS 16739IFC

Figure 4 Standards under ISO TC184/SC4

2.2.1 STEP-Application protocols for the BC industry

Internationally, the developments of the STEP standard for the exchange of product definition data, by the ISO, define the path for future integration of information technologies. Although the STEP project started in 1984, its objectives are currently still being discussed. Due to its dynamic nature the focus of the STEP has shifted from data exchange to information sharing. Along with the conceptual developments, implementation aspects have also become increasingly closer to the scope of the project. In a view of STEP, Wilson mentions two objectives of the STEP developments [Wilson, 1993]:

• To specify a standard method of representing the information necessary to define a product from its conception to its time of retirement.

• To specify standard methods for electronically exchanging the data representing this information.

In this introduction we discuss some of the important Application Protocols (APs) for the BC industry that have emerged from the STEP developments.



2.2.1.1 AP225

The first STEP application protocol for the description of the building model (or parts of it) has been AP225 ‘Building elements using explicit shape representation’. The STEP AP225 standardises components, their attributes and the 3D geometry in a building model. This building model is a valid international standard since the year 1999. At present, there are no implementations that support the latest version of this standard. Alternative, older implementations, based on the non-standard ARM (application reference model) model of the DIS version of AP225 are available, e.g., through the products of the Nemetschek company.

The BC industry contributed to the development of the building model but unfortunately, it did not find sufficient acceptance of the CAD suppliers. The reason probably lies in the fact that AP225 only supports 3D geometry of the building. Only exchanging data about the 3D geometry is insufficient. This assessment led, amongst other things, to a parallel initiative, which aims at its own standardisation by the establishment of the IAI. The IAI develops its own product data models that are available as IFCs (Industry Foundations Classes).

The main difference between STEP AP225 and IFC resides in the approach to the geometry. The IFC describes, in particular, the characteristics of the objects, such as the material it is made of, its construction type (like the layering of a wall), the parameters that determine its shape, and the relationships to other objects, etc, whereas the focus of AP225 is mainly the explicit 3D shape.

At present, AP225 is available as an international ISO standard but is not used in practise due to the lack of commercial software implementations.

2.2.1.2 AP228

AP228 is defined within the framework prepared under the auspices of the Building Construction Application Protocol Planning Project (BCAPP) published in document N315 (May 1994). In accordance with that framework, it was anticipated that the currently proposed ‘HVAC’ will sit alongside other future technical system APs (electrical, piping etc.) in the Building Services family. Such building technical systems will relate directly to similar systems in other sectors in the BC industry, and a specific effort will be made to reuse (and to contribute) models.

The AP228 was planned to be applicable to houses, commercial, industrial and recreational buildings, transportation facilities and other users of HVAC services. It addresses the systems that provide heating, ventilation and cooling to the spaces of the buildings. HVAC systems are considered as products in their own right with the function of providing the environment (fresh air, thermal conditions etc.) required for supporting the activities that take place within buildings in accordance to the applicable regulations. The AP228 should address the whole project life-cycle, although initially emphasising the inception, design and construction stages. The scope of AP288 covers the information needed in these stages including the topology of the HVAC system, the energy analysis, the detailed design of the system networks, the detailing of the HVAC sections including their connections, tendering, planning and some of the information preparatory for the commissioning and operation stages.



Due to a lack of resources and missing industry participation the process of developing AP228 had to be stopped. According to the ISO rules, that any standard development process has to be cancelled if no progress is made after a certain period, the AP228 had been dropped from the list of STEP APs.

2.2.1.3 AP230

This part of ISO 10303 specifies the use of integrated resources to satisfy requirements for the exchange of computer-interpretable information relating to structural steel building frames, which are considered purely from the standpoint of a structural engineer. The product model underlying AP230 is based closely on the product model underlying the CIMsteel Integration Standards (CIS), which were the main deliverable of the Eureka 130 CIMsteel project. The CIMsteel project was aimed at improving the efficiency and effectiveness of the European Constructional Steelwork industry through the introduction of computer integrated manufacture (CIM). The CIS are ISO-aligned and it is envisaged that the ‘twin track’ approach will provide a clear migration route from CIS to ISO-based technology.

The products addressed by AP230 are employed in low, medium and high-rise construction in domestic, commercial and industrial applications. AP230 is applicable to a variety of structures ranging from simple, single-storey portal frame industrial buildings to multi-storey office blocks. The main structural steelwork is covered, as is secondary steelwork, such as purloins, side-rails, cleats and cladding. The frames considered may be braced or not. Connections can be pinned, rigid, or semi-rigid (rigid and semi-rigid being full or partial strength). The data model underlying AP230 views frames as being fabricated from manufacturing assemblies, and views manufacturing assemblies as being made up of parts and joint systems. Parts may be prismatic, prismatic-derived or two-dimensional.

AP230 includes support for rolled, welded, cast, or cold-formed parts (although only limited information is held on cast and cold-formed parts). Welded and bolted joint systems are covered, and bolted joint systems may involve ordinary and pre-loaded bolts. In general terms, the data supported by AP230 include:

! Geometrical and geographical data, data relating to physical and material characteristics

! Data relating to structural behaviour, data relating to unique identification, logical grouping data, and temporal data

Whereas the CIMsteel Integration Standard version 2 (CIS-2) has gained acceptance (mainly in the Anglo-American market), which led to commercial implementations, the plan to bring it as AP230 into ISO-STEP had to be stopped due to a lack of resources. Today AP230 is dropped from the list of STEP APs.



2.2.1.4 BCCM

The Building Construction Core Model (BCCM) has been developed within the BCAPP initiative. Main objective of this initiative was to define a framework for development of APs and to determine the priority areas for initial AP development. The WG3 recognised that the BC industry is made up of a number of disciplines each having their own application requirements. It was also recognised that there is a set of common information to be exchanged between these disciplines. This set of information is less detailed as required for an AP. This kind of information is referred to as core data and from this the concept the BBCM has been developed. The BCCM does not include fully elaborated objects, but provides only a set of objects from which application-specific objects can be specialised. The BCCM had become part of the STEP standard (part 106). This standard is not widely accepted by software vendors; however it leads to development of IFCs, which is explained in next sections.

Since the development team moved to develop the IFC standard under the auspice of the IAI, the further development of BCCM had been stopped. Presently the BCCM (part 106) is dropped from the list of STEP parts.

2.2.2 Industrial manufacturing management data (MANDATE)

In addition to STEP, SC4 is also responsible for two other closely related standards: ISO 3584 (Standard for Part Libraries, P-LIB) and MANDATE (Standard for Manufacturing Management Data). Both are meant to support the standardisation of data, to describe the way information should be exchanged or shared - in particular in industrial manufacturing plants projects.

The MANDATE initiative comprises three main developments:

• To develop an international standard dealing with model, form and attributes of data exchanged between an industrial manufacturing company and its environment of manufacturing management activities

• To develop an international standard dealing with model, form and attributes of data able to reside in an industrial manufacturing company's resources database

• To develop an international standard dealing with model, form and attributes of data controlling and monitoring the flow of materials within an industrial manufacturing company

In the future, manufacturing industries, particularly those in the BC industry, can apply these initiatives for data and information sharing, such as prefabricated building elements etc.

2.2.3 IIDEAS

ISO 18876 ‘IIDEAS’ is an international standard that is being developed within ISO TC184, SC4 Industrial data, WG10 Technical architecture defining the overall architecture for the development of standards for data representation and exchange, product libraries, data



management and life-cycle integration within different industries. The architecture supports the following standardisation efforts:

• ISO 10303 Product data representation and exchange (STEP)

• ISO 13584 Parts library (PLIB)

• ISO 15531 Manufacturing management data (MANDATE)

• ISO 15926 Integration of life-cycle data for oil & gas production facilities The current status of ISO 18876 is that two parts have been approved as New Work Items in May 2000:

• Part 1: Architecture overview and description

• Part 2: Mapping and integration methodology This standard is widely accepted by oil & gas production industries but it is not accepted by the BC industries.

2.2.4 IAI Industry Foundation Classes (IAI-IFC)

The International Alliance for Interoperability (IAI) is an interesting standardisation project. The IAI, an organisation of IT-vendors and end-users, is developing the Industry Foundation Classes [IFC, 2002]. In general IT companies, frustrated with the current fractured information systems of the BC industry, are working together to make this happen. The IAI includes industry leaders from all aspects of the international BC community. This group is uniquely qualified to develop the specifications for the IFC. It works with software companies that serve the AEC/FM industry to promote the IFC specifications and to enable them to create a new generation of software applications that apply the potential of the computer in the BC industry.

The intention of the IAI is to specify how ‘things’ that could occur in a constructed facility (including real things such as doors, walls, fans, etc. and abstract concepts such as space, organisation, process etc.) should be represented electronically. These specifications represent a data structure supporting an electronic project model useful in sharing data across applications. The economical drive behind the IFC development ensures that the first IFC compatible products are already available on the market. For the coming years, the IFCs will be the default product modelling standard for the BC industry. The classes defined by the IAI are termed ‘Industry Foundation Classes’ or IFCs. The reasons for this are:

! IFCs are defined by the BC industry

! They provide a foundation for the shared project model

! They specify classes of things in an agreed manner that enables the development of a common language for construction

IFC-based objects allow BC professionals to share a project model, yet allow each profession to define its own view of the objects contained in that model. IFCs enable interoperability



among BC software applications. Software developers can use IFCs to create applications that use universal BC-objects that are based on the IFC specification.

Up to the year 2000, once a year, new versions of the classes were made available. This methodology did not work satisfactorily, because it did not ensure continuity for the implementation. Starting from the year 2000, it was decided that all further versions within a timeframe of minimum 5 years would be available as editions based upon the IFC2x platform. This change to the platform-based delivery provides basic upward compatibility and enables the reuse of software components and end-user project data.

2.2.4.1 IFC Release History and Planning

The IFC model specifies classes of things in an agreed manner that enables the development of a common language for the BC industry. IFCs are the standard specifications that enable interoperability and form the basis of shared project models. They are information-rich and allow a wealth of detail (comprising physical and other attributes) to be shared through the supply chain. The IFC model contains objects that allow each sector in the BC industry to define its own view of the project model. The IAI is continuously improving the IFCs and in its short history, many IFC versions have been released. Figure 4 shows the IFC development timeline (AEC3, 2003).

Figure 5 IFC development timeline.

IFC Release 1.0

The initial release of IFC has been a further development of ISO/BCCM standard and included also the outcomes of European R&D projects at this time, mainly the ATLAS, COMBI and VEGA projects. Release 1.0 of the IFC Specifications began the incremental definition of a shared project model used throughout a BC project life-cycle. This initial release included models supporting some processes in architectural design, HVAC



engineering design, facilities management, and cost estimating. The resulting integrated model represented only a fraction of the scope that will define a complete shared project model. However, these were identified as critical to the first incremental release of the IFC Specifications. The IFC Release 1.0 Specifications limited its scope to a set of achievable milestones:

! A ‘core’ model plus plug-in extensions software architecture was established to ensure structured extension of the IFC model with minimal disruption between releases

! Four AEC/FM domains were addressed: architecture, HVAC engineering, construction management, facilities management. Only a small set of the processes used in these domains were supported

The first prototypes developed for standard CAD systems have been demonstrated during the ACS show in Frankfurt 1996. The results had shown that the approach is feasible but that there are still many shortcomings in the IFC1.0, mainly in the area of complex geometry. This led to the consolidated development of IFC1.5 and to postponing the commercial software releases to IFC1.5.1.

IFC Release 1.5 (1.5.1)

Release 1.5 of the IFC Specifications did not extend the domain coverage beyond that which was developed for Release 1.0. However, building upon the implementation experience of Release 1.0, the IFC Technical Architecture was improved and the Core of the IFC Object Model extended and stabilised to provide a platform for commercial software developments. Initially, Release 1.0 of the IFC Specifications included models supporting a small set of the processes in the following areas:

• Architectural design • HVAC engineering design • Facilities management • Cost estimating

Resulting from improvements and trials of Release 1.0 and the Release 1.5 model, the first IFC release, namely Release 1.5.1 reached the level of stability acceptable for commercial implementation. Currently, there are six software vendors, whose products have passed certification for IFC R1.5.1 CAD view (Table 5).



Software company Software product Type Autodesk Architectural Desktop 2.0 und 3.0 architectural CAD Graphisoft ArchiCAD 6.0 und 6.5 architectural CAD Nemetschek AG ALLPLAN 16 architectural CAD Olof Granlund Oy RIUSKA, BSPro Server building service CAD Data Design System HousePartner building service CAD Messerli AG EliteNT architectural CAD IDEYAPI ideCAD architectural CAD,

structural design Table 5 Implementations of IFC1.5.1

IFC Release 2.0

Release 2.0 extends the domain coverage of the IFC Object Model and includes domain processes identified below. Key parts of the Core and Resource models remain unchanged although some additional features are added to support new domain processes. IFC Release 2.0 in 1999 expanded the scope of the model considerably. New concepts were introduced in the following areas (Figure 6):

• Architecture: Core, Shell, Roof, Restroom, Space planning, Fire compartments • Building Services: Duct design, Co-ordination, Thermal loads calculation,

performance metrics • Facility management: Move planning, Workstation design, Workstation layout • Estimating/Construction management: Cost items, Task modelling, Scheduling • Codes: Energy, Disabled access, Escape routes • Materials performance • Visualization

Figure 6 Scope of IFC Release 2.0

Several commercial implementations are supporting IFC Release 2.0. Two certification workshops took place in May 2001 and in October 2002 resulting in fifteen software vendors



getting the certification (Table 6). These vendors support one or several views of the IFC model, relating to various exchange scenarios:

• Architectural design - Quantities take off / cost estimating • HVAC system design - Quantities take off / cost estimating • Architectural design - Thermal load calculations / HVAC system design • Client brief / space layout - Architectural design

Software company Software product Type Graphisoft ArchiCAD architectural CAD Fujitsu Limited Personal BLD architectural CAD IAI France Claire Viewer neutral viewer KAJIMA Arc DB-CAD, MED DB-CAD,

StrDB-CAD Architecture, QT, Structural

Lawrence Berkeley Nat. Lab BSClient for EnergyPlus thermal simulation Microsoft VISIO Professional business design tool NEC Corporation NcadArc, WEBCMN architectural CAD,

internet service Olof Granlund Oy RIUSKA, BSPro building service CAD Pacific Northwest Nat. Lab COMcheck-EZ, MECcheck energy code checker Skanska Facets cost estimation Solibri Solibri Model Checker model verification Sumitomo Estimate-Core estimation Timberline Software Precision Estimation cost estimation K Line Systems IFC to VRML VRML converter YIT COVE cost estimation

Table 6 Implementations of IFC2.0

IFC Release 2x

The last IFC Release, IFC2x from October 2000, does not expand the scope of the model, but it marks the change in the way that IFCs are developed and released. It created a platform containing classes that provide the framework for the integration of models developed by projects and that provide for the sharing of information between domain areas. Projects will develop extension models, using the platform and will issue models independently as work is completed.

The IFC Release 2x also intends to consolidate the previous developments, it creates a stable core (or platform), which includes the proven and implemented parts of the IFC model. This is frozen for a minimum of 5 years after the release of IFC2x. The stable platform now enables (for the first time in IFC history) upward compatibility for implementations and end-user project files.

Another major milestone has been achieved with IFC2x. Its stable platform has been forwarded to ISO TC184/SC4 for acceptance as a formal international standard. Under the ‘harvesting procedure’, initiated by ISO TC184/SC4 for the transposition of externally



developed specifications into ISO deliverables, the IFC2x platform model has been accepted as an ISO Publicly Available Specification, ISO/PAS 16739.

In addition to projects aiming to expand the scope of IFC model, there is on-going effort for providing a standardised XML encoding, called ifcXML (briefly introduced in the section 2.2.5.4).

Another major achievement has been the last and most current implementations of IFC, based on the co-ordination view of IFC2x. Meanwhile eleven companies participated in the IFC2x certification process, which also has been considerably improved compared with earlier IFC releases (Table 7). For the first time a two-stage certification process is used. The first stage is the traditional testing against artificial test cases. The second stage involves an end-user testing, where actual project models of invited end-users are the basis for the import and export testing of the participating software applications.

Software company Software product Type Bentley Triforma CAD for Architects DDS ElectroPartner/ HVACPartner CAD for Electrical and

HVAC Engineers G.E.M. Team Solutions IFC2x-Interface for Autodesk ADT IFC-Interface for CAD for

Architects Graphisoft ArchiCAD CAD for Architects Nemetschek Allplan 2003, (Allplan, Allplot,

Allready, AllFEM, Allfa) CAD for Architects, Structural-, Civil- and HVAC- Engineers, Contractors and Facility Managers

BCA Singapore / novaSPRINT

e-Plan Checking Submission checking and control tool

Olof Granlund BSPro/RIUSKA IFC middleware and energy simulation

Solibri Model Checker Design Spell Checking Vizelia Facility on line, VRML & CAD IFC-customized VRML

viewer and CAD for facility managers

YIT Cove Cost estimation ACTIVe3D IFC-Tree & Viewer Visualisation

Table 7 Implementations of IFC2x

Release 2x Edition 2 (formerly IFC Release 3.0)

The latest IFC Release, IFC2x Edition 2, significantly extends the domain coverage of the IFC Object Model. The second edition uses the platform developed by IFC2x and has been issued on completion in May 2003.

The extension projects, that led to the significant extension in scope had been previously designated as release 3.0 projects, with the change to the platform based development during the time-frame of IFC2x, it has been re-assigned to IFC projects.



In addition to more domain specific content, also the general model capabilities are extended by including 2D design and presentation capabilities. Extension models included into the IFC2x Edition 2 are:

• Architecture o Architectural code compliance checking

• Building services: o HVAC Performance monitoring & validation, o HVAC modelling and simulation, o HVAC code compliance checking, o Electrical design

• Facility management: o Assets, Costs Accounts and Financial Elements, o Engineering maintenance, o Project specifications

• Structural engineering: o Steel frame design, o Reinforced concrete design and Foundation design, o Structural analysis

Figure 7 IFC release 2x edition 2 (previously named 3.0)

To conclude, looking at the semantics of the IFC core model and the interoperability layer, it is clear that the model focuses on global design, though extensions in several areas like Facility Management have been added. Applying a layered-approach solves the semantics versus size problem in the IFC model architecture and by handling most semantics in enumeration types and in extensible property sets being attachable to all IFC classes. This approach is acceptable for information sharing and exchange. For expressing more detailed knowledge it is has to be accompanied by an accepted dictionary of construction-specific product and property characteristics.



2.2.4.2 Parts Library (PLIB)

The Parts Library (PLIB) standardisation initiative was launched at the ISO level (ISO 13584) in 1990. The initial goal of PLIB was to develop a computer-interpretable representation of parts library data to enable a full digital information exchange between component suppliers and users, covering many industries. Since 1990, ISO 13584 has evolved and is characterised by the following:

• An object-oriented approach as the more efficient way for capturing data, information and knowledge about components

• An information model (Figure 6) formally specified in EXPRESS to ensure portability on different platforms and software systems (both data management and CAxx systems)

• An exchangeable data dictionary mechanism to support the integration of multi-supplier libraries and the progressive standardisation of the data element types that describe the various kinds of components (e.g., screw, door, capacitor etc.) and the various technical properties of components (e.g., threaded diameter of a screw, maximum working temperature of a pump, capacity of an electric capacitor etc.)

• Separation of components definitions (carried by one particular class hierarchy: the general model classes hierarchy), and components representations (carried by functional model classes) to support multi-representation (e.g., geometry, schematics, simulation models etc.) of the various components

Figure 6 shows the basic modelling constructs of PLIB.

FuctionalModelClass FunctionalViewClass

created_view

ComponentClass

is_view_ofis_case_of

class

is_part_of is_a

Supplier

Figure 8 PLIB information model.

The PLIB information model contains at the lowest level physical Objects-Of-Interest (OOI) that can be grouped into libraries, for instance for construction products. By the inheritance mechanism these OOIs are subclasses of the ComponentClass. Grouping objects together will



result in libraries. From this, a digital library can be developed. This approach follows the information system perspective.

In addition, PLIB has some abstracted mechanisms (not shown in figure) that support the end-user perspective. These abstracted mechanisms provide additional functionalities usually missing in other information models. While PLIB is focussing on the development of digital product libraries, it does not support process-related objects as seen in other developments. Furthermore PLIB is not an information model in the traditional way (supporting objects and relationships forming sentences), but only support the ‘words’ upon which other initiatives can be based (e.g., BCCM, IFC, etc.). Consequently, PLIB can play an important role in the development of BC electronic libraries of construction products and to extend the information models with additional product libraries.



Table 8 Product Data And Information Standards

Model Creator Version Format Status Open Source/Standard


BC Industry

Complexity

AP225 ISO/STEP 1.0 Neutral Format

Approved Standard AEC geometry information exchange

Leeds to new Standards

++

AP228 ISO/STEP 0.2 Neutral Format

Cancelled Standard Electrical, piping, building services engineering info. exchange

Not used +++

AP230 ISO/STEP CIS 2.0 Neutral Format

Cancelled Standard Steel construction information exchange

Not used +++

BCCM ISO/STEP 1.0 Neutral Format

Cancelled Standard BC information exchange Leeds to new Standards

++

MANDATE ISO 1.0 Neutral Format

Committee Draft

Standard Manufacturing data exchange

Not used ++

IIDEAS ISO 2.0 Neutral Format

Working Draft

Standard Manufacturing information exchange

Not Used +

IAI-IFC IAI 2.0x and 2x2

Neutral Format

Final Open Standard BC, Arch, Eng, HVAC, FM information exchange

Widely Accepted

+++

EDIFACT OASIS 1.0 XML Format

Committee Draft

Open Standard Electronic Business information exchange

Accepted ++

PLIB ISO/STEP 1.0 Neutral Format

Committee Draft

Standard Component suppliers and user information exchange

Not Used ++



2.2.5 XML-based standards

The Next Generation Internet (NGI) will be based on XML (eXtensible Mark-up Language). XML is the new technology replacing the current Internet language HTML. The most important advantages of XML are: (1) its separation of definition (content) and representation (mark-up), and (2) its ability to support the development and use of domain specific XML vocabularies.

In the next section the following XML-based standards will be discussed: bcXML, aecXML, ifcXML, ebXML, WML and X3D.

2.2.5.1 bcXML

The IST project eConstruct developed an XML vocabulary for the European BC industry, called bcXML [eConstruct, 2001]. bcXML is a XML vocabulary of BC semantics. These semantics describe the current practice information needs for communication and electronic business between BC stakeholders (e.g., construction products, resources, work methods, regulations, etc.). These semantics include also language translations, developed in a separate part that acts as a ‘neutral’ electronic taxonomy4 (Figure 7) providing neutral BC object identifications called LexiCON [LexiCON, 2001]. This component helps to solve one of the biggest obstacles the European BC industry is facing, i.e. the fact that the Information Systems (all the information and knowledge related to the BC industry) of all the European countries are different. These differences do not only result from differences in the national languages but also manifested in differences in the national ontologies5 or classification systems.

bcXMLid : ID

Specifi cati onid : ID

0..1+s pec if icat ion 0..1

Translation

id : ID

Dictionaryid : ID

0..1+dictionary 0..1

Taxon omyid : ID

0..1

+taxonomy

0..1

Specif ica tionItem

id : ID1..*

+specif icationItem

1..*

Supplierid : ID

0..1

+suppl ier

0..1

Spe ci ali sat io nid : ID

DictionaryItemid : ID

1..*

+translation

1..*1.. *

+dictionary Item

1..*

TaxonomyItemid : ID

1..*

+taxonomy Item

1..*

0..1+taxonomy Item 0..1

0..*

+suppl ier

0..*

0..*

+specialisation

0..*1

+t ax onomy I tem

1

1+dictionary Item 1

Figure 9 bcXML meta-model for translation services.

4 A classification for the identification of objects with similar characteristics, structured according to a specialisation hierarchy.

5 A set of terms, associated with definitions in natural language and, if possible, using formal relations and constraints, about some domain of interest, used in their work by humans, databases and computer programs.[Green, 2002]



Within the eConstruct project a tool has been developed that is able to support both language and classification conversion. This tool is used for communication based on bcXML as well as providing for electronic business between stakeholders in a European setting.

The eConstruct consortium co-operates with other organisations that develop XML vocabularies for electronic business for the BC industry, i.e. the aecXML working group initiated by Bentley Systems in the USA and the ebXML organisation initiated by UN/CEFACT and AOSIS. All these vocabularies are open standards and can be combined with each other and with more general XML components and vocabularies like XSLT and X3D.

2.2.5.2 aecXML

The aecXML is a US-oriented project that has been proposed by Bentley Systems in 1999 and is currently closely aligned with IAI. The aecXML vocabulary is developed and used to represent and communicate information across the AEC industry. The development of aecXML is intended to enable:

• AEC project information to be entered only once and be made available for reuse by all project participants, and each of their respective software applications, throughout the project life-cycle

• To access, search and interrogate all relevant AEC information over the Internet

• On-line access to regulatory and statutory rules, requirements and guidelines

• An ‘operator’s manual’ for the life-cycle of a facility to be generated directly from the operating, maintenance and safety information (contained within the body of the design and construction information of a project)

To achieve the above mentioned objectives, a large variety of information types need to be incorporated into aecXML, including documents (e.g., drawings, specifications, change orders, contracts, building codes, purchase orders, etc.), building components (e.g., items from a catalogue, custom manufactured items, assemblies, materials, etc.), projects (e.g., design, construction, decommissioning, operations, maintenance, facility management, etc.), professional services and resources (e.g., engineers, architects, contractors, suppliers, specialities, etc.), organisations (e.g., standards bodies, government agencies, etc.), software (e.g., CAD, planning software, etc.) and provide support for activities such as scheduling, project and document management, etc. The most recent version of aecXML, version 1.0, has been released in 2000. Currently, the aecXML initiative operates under the IAI umbrella (section 2.2.4). After the initial high public awareness of aecXML most of the developments had been stopped (or at least delayed) following the dot com crisis. Some XML based models, that were intended to form part of aecXML, had been successfully introduced independently. Examples are landXML and gbXML, however the aecXML framework did not succeed. A finally accepted version 1.0 has not been produced so far.



2.2.5.3 ebXML

ebXML is a global electronic business standard that is sponsored by UN/CEFACT (United Nations Centre For Trade Facilitation And Electronic Business) and OASIS (Organization for the Advancement of Structural Information Standards). ebXML defines a framework for global eBusiness, allowing businesses to find each other and to conduct business based on XML messages within the context of a standardised business process. ebXML provides for mutually-negotiated partner agreement, which includes the Messaging Service, Registry, Collaboration Protocol Profile and Agreement specifications. ebXML is currently widely accepted by for eBussiness and therefore worth serious consideration for the BC industry (e.g. eConstruct and bcXML). Version 2.0 of the core ebXML Registry specification was approved in January 2002 [ebXML, 2002].

2.2.5.4 ifcXML

The XML-based technology has become the mainstream commercial activity for many software and Internet companies. XML is also increasingly used for data exchange purposes (as pursued by aecXML and bcXML initiatives). This has led to IAI taking steps towards XML-based exchange by starting a project for defining an ifcXML schema. IAI-IFCs are discussed in section 2.2.4 in details. The goal of the ifcXML is internationally agreed content and structure of the IFC2x specification (or any valid subset) to the XML community. The XML schema language binding of EXPRESS developed for ifcXML is used for an automatic translation of the whole IFC2x model (or as a minimum for the IFC2x platform model). The result is the availability of the IFC2x model in XML schema notation. Two potential usages have been identified:

• Exchange of IFC data files alternatively as XML instance documents

• Reuse of IFC content and structure within XML-based initiatives for data exchange and sharing in the BC industry

To facilitate the above, a two-stage translation procedure is envisaged:

• Stage 1. The automatic translation of the IFC2x EXPRESS model into an XML schema notation to facilitate the exchange of IFC data in XML format, as an alternative to the current way to exchange the IFC data in STEP physical file format. The translation preserves the exact syntax of the original EXPRESS model

• Stage 2. The optimised translation of the IFC2x EXPRESS model to serve as an XML object repository, which can be used to build XML exchange standards on top of it. The optimisation executes a Stage 2 translation based on the results of the Stage 1 translation. In order to allow for optimised results, the Stage 2 translation process needs to be configurable. The configuration, subject to human interpretation of the underlying EXPRESS model, will be the basis for the most appropriate XML definitions. The optimisation preserves the semantics of the original EXPRESS model, but may change the syntax to more appropriate XML structures. Currently, ifcXML



language binding of EXPRESS exists as a draft document (public launch at IAI-XML summit 25.04.2001).

A parallel development is the work on Part 28 edition 2 of the ISO-STEP standard ISO10303. Part 28, the ‘Implementation methods: XML Schema governed representation of EXPRESS schema governed data’, aims at defining a standardised translation of any EXPRESS-based model into an equivalent XML schema structure. The ifcXML language binding has been one contributor to the Part 28 development, and it is the final goal, that ifcXML will be compliant to ISO 10303-28 after its final acceptance.

2.2.5.5 WML

WML (Wireless Mark-up Language) is the web language for accessing sites on mobile phones. The WML is the XML version of the WAP standard discussed in section 2.1.6. The official WML specification is developed and maintained by the WAP Forum, an industry-wide consortium founded by Nokia, Phone.com, Motorola, and Ericsson. This specification defines the syntax, variables, and elements used in a valid WML file. The actual WML 1.1 Document Type Definition (DTD) is available since 2001 [WML, 2001].

The use of mobile telephony for verbal communication in the BC industry is indispensable and will inevitably lead to a demand for additional Internet services via mobile telephone devices in the future. In this sense, WML is probably an important standard for the BC industry.

2.2.5.6 Extensible 3D (X3D)

At present, under the ISO/Web3D Consortium umbrella, the X3D Graphics Working Group is designing and implementing a next generation Extensible 3D (X3D) graphics specification. This specification is defining the capabilities of VRML regarding geometry and the behaviour of VRML object using XML. Besides the X3D Graphics Working Group, another group is currently working on the implementation. This ‘Browser Working Group’ has adapted much of the specification defined by the X3D Graphics Working Group. The Browser Working Group released an open source browser, which could be used by other developers and eventual commercial implementations.

The ISO/Web3D Consortium has clearly defined the following set of goals for X3D technology which has led to tangible results in development of this technology by the working groups:

1. Compatibility of the file syntax with the emerging World Wide Web Consortium's XML specification

2. Backward compatibility with older version of VRML

3. Extendibility of the lightweight Core Profile in order to provide additional functionalities



X3D is designed to enable a new generation of XML-compliant 3D standards for the web. The X3D graphics specification extends the capabilities of VRML 97 as shown in Figure 8. The reason for using X3D is because the XML technology is the basis of an extensible architecture. This means that the processing of documents and 3D elements for display can take place under various ‘profiles’ (software components) depending on the required level and domain of functionality. The major impact of using such a technology will break the barriers, in order to lead to new opportunities for semantic shape definition. The simple integration problems at the file level can be solved by combining the Product Data Technology (Section 2.2) and the shape definitions such as X3D. This has resulted in using web browsers with the appropriate plug-ins, available at no cost (Figure 8). This is in contrast to the past where a huge investment was needed for writing advanced and complex applications.

X3D files, streams X3D events

X3D nodes Scripting

Scene Graph Data Structure Event Graph

3D Rendering Service User Interactions

Figure 10 An X3D browser, where simplified File, Application and User interaction are shown.

In addition to X3D developments, there are also a lot of small companies engaged in pushing their own 3D technologies. Common to all these companies is:

• Each company provides an excellent solution for only one part of the problem

• Each company requires a large infusion of cash from investors for their idea These points to the necessity for integrated efforts required for 3D developments. Currently X3D is the only interchangeable file format for the Internet and therefore an important development for the BC industry (Figure 9). Another benefit is that all the information can be published via the Next Generation Internet, which is accessible worldwide. X3D is an extensible and an open-ended architecture, which allows parallel developments to occur next to each other.



X3D XPDT

Open API Shape API

PDT API

Data File

GUI GUI

Figure 11 Moving from API integration towards the File Integration by using Open APIs.

As a matter of fact, X3D is just file syntax written in XML. VRML 97 is one encoding for representing 3D. The following example shows the difference between the VRML 97 and XML syntaxes, which usually are stored in a plain text file:

VRML 97: DEF HelloView viewpoint { position 0 0 0 }

XML: <viewpoint DEF='HelloView' position='0 0 0' >

The interesting thing about X3D is, that it has a great potential in the inception support of the design process. Clients can see their products’ requirements and virtually experience, how it will look like when the actual building is finished. In addition, by walking through the building, they can check specifications of the internal details, etc. In this regard, X3D offers feasible, but powerful solutions for the client support.

2.2.6 EDI-based standards

Electronic Data Interchange (EDI) is the transmission of information in a standard and computer-readable format. It includes electronic order placement, electronic shipping notification, electronic invoicing, and many other business transactions. An EDI message contains a string of data elements each representing a singular fact, such as the price, the product number, etc. separated by delimiters. The entire string is called a data segment.

One or more data segments framed by a header and a trailer form a transaction set, is the EDI unit of transmission (equivalent to a message). A transaction set often consists of what would usually be contained in a typical business document or form. The parties who exchange EDI transmissions are referred to as trading partners. The following are provided by EDI:

• Logging and Archiving

• Acknowledgements

• Application APIs

• Transaction Expertise

• Message Standards

• Well tried Business Languages



• Well known Business Practices

• Trading Partner Profiles

XML and EDI are going to merge into a common standard framework called XML/EDI, providing a standard framework for exchanging different types of data. The information, in a transaction, exchanged via an API, database portal, catalogue, a workflow document or message, can be searched, decoded, manipulated, and displayed consistently and correctly by first implementing EDI dictionaries. Furthermore the latter can be extended by adding available vocabulary via on-line repositories to include business language, rules and objects. Thus by combining XML and EDI a new powerful paradigm, different from XML or EDI, is created. EDI incorporates standard layouts for all business documents. Amongst others the following four EDI standards are available. The BC industry related standards should closely follow these developments because the extent of the use of these well-established and widely recognised standards in other industries:

• UN/EDIFACT - the main standard supported by the UN

• ANSI X12 - common in USA, Canada and Australia

• TRADACOMS - predominantly used in the UK

• ODETTE - developed in the UK for the motor industry

2.2.6.1 EDI for Administration Commerce and Transport (UN/EDIFACT)

The EDIFACT standard (EDI for Administration Commerce and Transport) is the only EDI standard that is truly accepted worldwide. EDIFACT provides standard formats for business documents and incorporates features that meet international requirements.

Whilst EDIFACT messages are designed for business data transactions, they are complex in their structure. It is accepted that national/industry conventions will determine which parts of the total message requirements to use. As a result, the message will be reduced down to size to only contain the information required by that industry. The two different subsets of EDIFACT format, interesting for BC are EdiBuild and EdiCon.

2.2.6.2 American National Standards Institute X12 (ANSI X12)

US standards under the control of ANSI (American National Standards Institute) is developed separately from Europe. The ANSI X12 committee specified standards for transaction sets, a data element dictionary, and transmission control. Direct comparisons can be found with standards developed in Europe, but the American standards are used differently. The ANSI X12 standard is used in the USA, Canada and to a degree in Australia. The X12 transaction sets cover a wide range of industry sectors, including administration, education, finance and government.



2.2.6.3 TRADACOMS

TRADACOMS is developed by the ANA (Article Numbering Association) in 1982 for the UK retail industry. It is currently the most widely used standard in the UK within this market. It defines standards for 30+ trading documents. Due to the more specific nature of TRADACOMS messages, the standard is not generally broken down into subsets.

2.2.6.4 ODETTE

The ODETTE standard consists of over thirty messages for deployment in the automotive industry and reflects the industry's use of JIT (‘Just in Time’) methods. The messages can use either EDIFACT or TRADACOMS service segments. ODETTE International currently has 8 European members including ODETTE UK, which is managed in association with SMMT (Society of Motor Manufacturers and Traders).

2.3 Conclusions

This section discussed both Data Standards and Information Standards. The Data Standards, for instance SQL and VRML, are widely accepted and used by the BC industry where most CAD systems and databases support these standards. However, it is clear that Data Standards are not a viable solution for the integration of the BC industry. However, increasing awareness about Information Standards within the BC industry will increase the need for more BC-specific Information standards. Among Information Standards, the IAI-IFC is a promising one because it particularly targets the BC industry. In addition, XML-based standards will pave the way towards integrated BC-specific solutions (e.g., bcXML, aecXML etc.).





BC Industry

Complexity

BCXML IST 1.0 XML Format

Committee Draft

Open Standard BC information exchange

Accepted +

AECXML Bentley 0.87 XML Format

Working Draft Open Standard AEC information exchange

Partially Accepted

++

IFCXML IAI 2x XML Format

Working Draft Open Standard BC information exchange

Accepted +++

EBXML OASIS 2.0 XML Format

Approved Standard Electronic Business data exchange

Used ++

WML W3C 1.1 XML Format

Working Draft Standard Mobile Phones communication

Accepted +

X3D ISO/Web3d 1.0 XML Format

Committee Draft

Standard Web based Virtual reality data exchange

Widely Accepted

+

Table 9 Data And Information Standards Based On Xml



3 Information Communication and Remote Access Standards This chapter discusses the standards for the communication of data, information and knowledge. It covers the protocol, service and architecture standards. The protocol, (web) service and architecture standards are not, in comparison with the standards discussed in the previous chapters, especially targeting end-users but application developers (mostly from outside the BC industry). Nevertheless, applications based on the communication standards have inevitably a profound effect on the improved performance of the BC industry.

3.1 Protocol standards

The term ‘Protocol’ is the collective term for the rules that governs communication at given layers in network architectures. They are important because in each layer, in any communication system, a set of rules must be agreed to and followed in order for communication to be successful. The four protocol standards are considered, namely, Component Object Model, ActiveX, CORBA and SOAP.

3.1.1 The Component Object Model (COM)/Distributed COM (DCOM)

Microsoft's protocol standard Component Object Model (COM) was introduced in 1993, as the foundation for the development of component-based applications. From its original application on a single machine, COM has been developed to allow access to components on other systems (DCOM).

Distributed COM, introduced in 1996, makes it possible to create networked applications built from components in various systems. DCOM is a protocol that enables software components to communicate directly over a network in a reliable, secure, and efficient manner. Previously called ‘Network OLE,’ DCOM is designed for use across multiple network transports, including Internet protocols such as HTTP. DCOM is based on the Open Software Foundation's DCE-RPC specifications and operates with both Java applets and ActiveX components through its use of the COM (Figure 10).



Figure 12 DCOM is the central communication core for the component-based development of applications (it provides the glue that ties things together).

3.1.2 ActiveX

ActiveX is a protocol standard developed by Microsoft using COM technologies to provide interoperability with other types of COM components and services. ActiveX controls are the third version of OLE (Object Linking and Embedding) controls (OCX), providing a number of enhancements specifically designed to facilitate distribution of components over high-latency networks and to provide integration of controls into Web browsers. These enhancements include features such as incremental rendering and code signing, to allow users to identify the authors of controls before allowing them to be executed.

Reuse is a central goal in object-oriented software design. Reusing instead of rewriting code saves development efforts. ActiveX controls are reusable software components that can quickly add specialised functionality to Web sites, desktop applications, and development tools. ActiveX controls have become the primary architecture for developing programmable software components for use in a variety of different containers, ranging from software development tools to user productivity tools.

The importance of ActiveX is increased with the arrival of the Internet. This lies in the fact that ActiveX controls are required to support only one interface and two API functions (DllRegisterServer and DllUnregisterServer). These two API functions ensure that ActiveX controls are self–registering, i.e. they can add and remove the necessary information for their use in the registry of the target system. An ActiveX control does not have to support the standard set of interfaces required for an OLE control, a container application must have specific knowledge about the interface for an ActiveX control in order to use it. However, ActiveX controls are small, fast, lightweight, and resource efficient, hence making them ideal for use on the Internet and for handheld devices.



3.1.3 Common Object Request Broker Architecture (CORBA)

When developing distributed applications most developers are trying to provide or acquire many of the same underlying services, including security, event notification, persistence, and transactions. These services are critical for giving a long-term value for a distributed application. The question that arises is: how can these services be packaged so that they are easy to use, easy to learn and easy to distribute?

The CORBA Component Model (CCM) was developed by the Object Management Group (OMG) to address the above-mentioned issues. The CCM is a server-side component model for building and deploying CORBA applications. It is very similar to Enterprise Java Beans (EJBs) because it uses accepted design patterns and facilitates their usage, enabling large amounts of code to be generated. This also allows for system services to be implemented by a container (the execution framework) provider rather than an application developer. The benefit and need for these types of containers can be observed through the growth of Application Server software. The CCM extends the CORBA object model (also part of the CORBA specifications) by defining features and services in a standard environment that enable application developers to implement, manage, configure and deploy components that integrate with commonly used CORBA Services. These server-side services include transactions, security, persistence and events.

In order to support all the above features, the CCM extends the CORBA Implementation Definition Language (CIDL) to a point that it introduces a new declaration language. CIDL relieves developers from having to provide much of the ‘plumbing’ needed to include components within a container.

One important part of the CCM specification is a CORBA container for hosting EJBs. This provides the mechanisms for a two-way interoperability between EJBs written in Java and CCM components in any CORBA programming language.

The CCM specification introduces the concept of components and the definition of a comprehensive set of interfaces and techniques for specifying implementation, packaging and deployment of components.

The current version is 3.0 and is managed by the OMG. The first version of CORBA was released in 1991. Formally, CORBA 2 and CORBA 3 refer to complete releases of the entire CORBA specification. The OMG increments the major release numbers when a significant addition to the architecture is made. In this regard, CORBA 2 sometimes refers to CORBA interoperability and the Internet Inter-ORB Protocol (IIOP). On the other hand CORBA 3 sometimes refers to the CORBA Component Model.

3.1.4 Simple Object Access Protocol (SOAP)

W3C’s Simple Object Access Protocol (SOAP) is a lightweight protocol for enabling heterogeneous applications to exchange information in a distributed environment. SOAP can be considered as a firewall friendly protocol as well as a platform and programming language technology. The SOAP native domain is the Internet and, as such, SOAP relies on



heavyweight Internet standards such as XML and HTTP/SMTP. SOAP uses XML to represent the data to be exchanged and the SOAP messaging protocol uses HTTP to carry the messages.

Furthermore, SOAP is an extensible protocol can evolve over time and it is very simple to implement or use. The client sends a request to a server to invoke an object, and the server sends back the results. SOAP works with existing Internet infrastructure, which means that it is not necessary to make any special accommodations on routers, firewalls, or proxy servers to use SOAP.

SOAP also provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a distributed environment (by using XML). SOAP, by itself, does not define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems (applications, servers, etc.) by using messaging or Remote Procedure Call (RPC). An RPC can be developed and invoked remotely in a synchronous way. This means, the input parameters passed to a SOAP service does not have to be written in XML, although the result produced by the SOAP service will always be a XML stream.

The development of SOAP started in early 1998. At that time there was no schema language or type system for XML. In the earlier versions of the SOAP specifications was focussing on defining a type system. The original type system of SOAP (and XML-RPC) had a handful of primitive types, composites that are accessed by name and composites accessed by position. The current version of SOAP, version 1.2, consists of the following main parts:

• The SOAP envelope construct defines an overall framework for expressing what is in a message, which should be dealt with, and whether it is optional or mandatory

• The SOAP encoding rules defines a serialisation mechanism that can be used to exchange instances of application-defined data types

• The SOAP RPC representation defines a convention that can be used to represent remote procedure calls and responses

Although these parts are described together, they are functionally orthogonal. In particular, the envelope and the encoding rules are defined in different namespaces6 in order to promote simplicity through modularity.

3.2 Service standards

A Web service is a self-describing, self-contained, modular unit of application logic that provides some business functionality to other applications through an Internet connection.

6 In the computing disciplines, the term ‘namespace’ conventionally refers to a set of names, i.e. a collection containing no duplicates. An XML namespace is a collection of names, identified by a URI reference (W3C 1999).



Applications access web services via communication protocols (section 3.1) and data formats in XML (section 2.2.5), independent from how a web service is implemented.

As communications protocols and data formats are currently standardised in the W3C community, it is inevitable to specify standards for the implementation of (structured) web services. The two Web Service standards are considered, namely, UDDI and WSDL.

3.2.1 Universal Description, Discovery and Integration (UDDI)

The Universal Description, Discovery and Integration (UDDI), which developed by W3C, is a specification that defines the way in which businesses can publish and discover information about ‘Web services’. The UDDI standard enables companies to:

• Describe their business and their services

• Discover other companies that offer desired services

• Interoperate with other companies The main approach adopted by UDDI organisation (UDDI.ORG) is to develop a distributed registry of businesses and related services, implemented in a common XML-format. The UDDI Business Registry (UBR) is the core element of the infrastructure that supports Web services. It provides a place for a company to register its business and the related services that it offers. People or companies that need a service can use this registry to find a company that provides the service. An Operator's Council sets policy and quality of the service guidelines for the operators. A ‘node operator’ is a company that runs an instance of the public UBR. The operators replicate the registrations across all nodes on a regular basis thus resulting in a complete set of registered records available to all. The operators support a common set of APIs that will ensure the integrity and availability of the information provided. This information is organised in UDDI as follows:

• Business Entity. A business entity represents information about a business. Each Business Entity contains a unique identifier, the business name, a short description of the business, some basic contact information, a list of categories and identifiers that describe the business, and a URL pointing to more information about the business

• Business Service. Associated with the Business Entity is a list of Business Services offered by the Business Entity. Each Business Service entry contains a business description of the service, a list of categories that describe the service, and a list of pointers to references and information related to the service

• Specification Pointers. There is a list of binding templates associated with each Business Service entry that point to specifications and other technical information about the service

• Service Types. A Service Type is defined by a tModel . Multiple businesses can offer the same type of services. The tModel defines these multiple businesses and specifies information such as the name of the organisation that published the tModel, a list of categories that described the service type, and pointers to technical specifications for



the service types such as interface definitions, message formats, message protocols, and security protocols

The W3C provides information about the most recent version of UDDI (version 3), which includes both information about the UDDI specification and a list of operators for the UDDI Business Registry. Because it’s a new standard, the BC businesses are not yet actively registered, but in the future we can see more BC industry registry.

3.2.2 Web Services Description Language (WSDL)

The Web Services Description Language (WSDL) is developed by W3C and provides a way for service providers to describe the basic format of web service requests over different protocols or encoding. WSDL is used to describe what a web service can do, where it resides, and how it is invoked. While the claim of SOAP/HTTP independence is made in various specifications, WSDL makes the most sense if it assumes SOAP/HTTP/MIME as the remote object invocation mechanism. UDDI registries describe numerous aspects of web services, including the binding details of the service. WSDL fits into the subset of a UDDI service description.

WSDL defines services as collections of network endpoints or ports. In WSDL the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions of messages, which are abstract descriptions of the data being exchanged, and port types, which are abstract collections of operations. The actual protocol and data format specifications for a particular port type constitute a reusable binding. A port is defined by associating a network address with a reusable binding, i.e. a collection of ports that define a service.

The W3C provides the information about the most recent version of WSDL (version 1.1) that includes both information about the WSDL and a template that describes how services should be specified and bounded by clients.

3.3 Architectural Standards

This section on architecture standards mainly discusses the Java Platform (provided by SUN Microsystems) and .NET platform (provided by Microsoft).

3.3.1 Java Platform

This section discusses the architectural support, which is a platform independent ICT standard, provided by the Java Platform suite of APIs, components and libraries.

The Java 2 Platform, Enterprise Edition (J2EE), defines the standard for developing multi-tier enterprise applications, such as ERP systems (Enterprise Resource Planning), horizontal software components such as CMSs (Content Management Systems), or ASP (Active Server Page) services. J2EE simplifies enterprise applications based on standardised and modular components, as well as providing a complete set of services for these components. It is a



platform for building Web-based enterprise applications. The following is a list of the main J2EE components:

• WebLogic. J2EE services operate in the middle tier, between the end-user's browser, the enterprise databases and legacy information systems. J2EE comprises a specification, reference implementation (provided by Sun Microsystems, see also java.sun.com) and a set of testing suites. Its core components are:

o Enterprise JavaBeans Architecture. The Enterprise JavaBeans specification defines an API that makes it easy for developers to create, deploy and manage cross-platform, component-based enterprise applications that work within the framework of the systems currently in use

o JavaServer Pages (JSP). The Java Server Pages (JSP) technology provides a simple and easy to use functionality to create dynamic web content. JSP technology enables rapid development of web-based applications that are server and platform independent

o Java Servlet. The Java Servlet API provides web application developers with a simple and consistent mechanism for extending the functionality of a web server by back-end application logic (e.g., catalogues, collaboration functions, etc.)

• J2EE Connector. The J2EE Connector architecture defines a standard architecture for connecting the J2EE platform to heterogeneous Enterprise Information Systems (i.e., for Web-based ERP integration between two businesses)

• Java Naming and Directory Interface (JNDI). JNDI provides a uniform, industry-standard and seamless connectivity from the Java platform to business information assets, thus allowing developers to deliver Java applications with unified access to multiple naming and directory services across the enterprise

• Java Interface Definition Language (IDL). IDL provides interoperability together with CORBA (Section 3.1.3), as an industry standard for heterogeneous computing. Java IDL includes an IDL-to-Java compiler and a lightweight Object Request Broker (ORB) that supports Internet Inter ORB Protocol (IIOP)

• Java Database Connectivity (JDBC). JDBC provides programmers with a uniform SQL (Section 2.1.1) interface to a wide range of relational databases, upon which higher-level tools and interfaces can be built

• Java Message Service (JMS). JMS provides developers with a standard Java API for enterprise messaging services, such as reliable queuing, publish and subscribe communication and various aspects of push/pull technologies

• Java Transaction API (JTA). JTA defines a high-level transaction management specification intended for resource managers and transactional applications in distributed transaction systems

• Java Transaction Service (JTS). JTS technology ensures interoperability with sophisticated transaction resources such as transactional application programs, resource managers, transaction processing monitors and transaction managers. JTS



provides open standard access to these transaction resources because these components are implemented by different vendors

• JavaMail. The JavaMail API provides a set of abstract classes that model a mail system. The API is meant to provide a platform independent and protocol independent framework to build Java-based mail and messaging applications

• Remote Method Invocation (RMI-IIOP). RMI-IIOP provides developers with an implementation of the Java RMI API over the OMG industry-standard Internet Inter-Orb Protocol (IIOP), allowing developers to write remote interfaces between clients and servers

The machine and OS independent architecture of Java Platform provide the architecture for the interoperability of applications. This functionality profoundly enhances the current and future developments as well as the effectiveness and efficiency of the BC industry. Therefore, the BC industry has to closely monitor all developments of this technology.

3.3.2 .Net Platform

The .NET Platform is a new computing framework developed by Microsoft, in 2002, to simplify writing codes for the development of applications in the highly distributed environment of the Internet. The .NET Platform is designed to provide a code-execution environment for:

• object-oriented programming (local, remote and distributed)

• Windows-based and Web-based applications

• communication protocol standards

• software deployment and versioning conflicts The .NET Platform has two main components for code execution: 1) the Common Language Runtime (CLR) and 2) the .NET Platform class library. The CLR is the foundation of the .NET Platform. The CLR is an agent that manages code at execution time, providing core services such as memory management, thread management and remote management. In fact, the concept of code management is a fundamental principle of the CLR. The class library, the other main component of the .NET Platform, is a comprehensive, object-oriented collection of reusable types that can be used to develop applications ranging from traditional command-line or graphical user interface (GUI) applications to applications based on the latest functionalities provided by ASP.NET, such as Web Forms and XML Web services. ASP.NET hosts the CLR to provide a scalable, server-side environment for the managed code. Figure 11 shows the main components and features of the .NET Platform.



Figure 13 The main components and features of the .NET Platform.

Mainly, the .NET Platform provides language and device independency. However, it is operating system dependent (current versions of the .NET Platform are only available for Microsoft OSs). Moreover, it does not solve the vendor dependency problem because some functionalities of the .NET Platform are integrated with typical Microsoft products such as MS Internet Explorer. The .NET Platform only targets developers rather than end-users. In addition, the cost of learning and buying the .NET Platform development packages are high comparing to the alternatives such as J2EE, which is for free.

Similar to the JAVA Platform, the device and language independent architecture of .NET Platform can provide the interoperability for applications despite the above mentioned limitations. Nevertheless, the .NET platform functionalities can profoundly enhance the current and future developments as well as the effectiveness and efficiency of the BC industry. Therefore, the BC industry needs to closely monitor all developments of this promising technology alongside the JAVA developments in order to be able to choose and employ the most appropriate technology for the industry.

3.4 Conclusions

This chapter discussed the standards for the communication of data, information and knowledge. It covers the protocol, service and architecture standards. The protocol, (web) service and architecture standards are not, in comparison with the standards discussed in the previous chapters, especially targeting end-users, but application developers (mostly from outside the BC industry). Therefore these standards may have significant influence on future ICT developments, which will indirectly affect the BC industry. For instance SOAP as a



lightweight protocol that enables heterogeneous applications to exchange information in a distributed environment, or WSDL that defines the way in which businesses can publish and discover information about ‘Web services’, enables new business opportunities for the BC industry. In addition, the two architectural standards J2EE and .NET provide new infrastructures for enhanced business processes.





BC Industry

Complexity

COM/DCOM Microsoft 1.0 Binary Format

Final Owned By Microsoft Distributed/Object Sharing API

Accepted +

ACTIVEX Microsoft 1.0 Binary Format

Final Owned By Microsoft Dynamic Component Model API

Widely Accepted

++

CORBA OMG 3.0 Binary Format

Final Standard Distributed Object Sharing API

Widely Accepted

+++

SOAP W3C 2.0 XML Format

Working Draft

Standard Object Access Protocol

Widely Used

++

UDDI W3C 3.0 XML Format

Specification Standard Universal description, Discovery and Integration

Widely Accepted

+

WSDL ISO/W3C 1.2 XML Format

Working Draft

Standard Web Services description

Accepted +

Java SUN 2.0 Platform Independent

Final Owned By Sun Platform independent software environment

Widely Accepted

+++

.NET Microsoft 1.0 Windows OS

Final Owned By Microsoft Software Integration Platform via Internet

Accepted ++++

Table 10 Information Communication Standards


ICCI: IST-2001-33022WP2/D221


4 Knowledge standards This chapter discusses the standards for knowledge modelling and exchange. The five protocol standards considered are KIF, DAML/OIL, KQML, ACL-FIPA, RDF and RuleML.

4.1 Knowledge Interchange Format (KIF)

The Knowledge Interchange Format (KIF) has been developed for software agents that use KIF to describe objects (or things) in the real world. The description could be expressed in neutral languages, such as English, Dutch, etc., which are capable of describing a wide variety of things and situations. However, the meaning of a natural language statement is often subject to different interpretations.

Symbolic logic is a general mathematical tool for describing things. Simple logics (subset of symbolic logic) have been found to be capable of describing almost anything of interest or utility to people and other intelligent agents. These things include simple concrete facts, definitions, abstractions, interference rules, constraints, and even meta-knowledge.

KIF, a particular logic language that has been proposed as a standard for describing things within expert systems, databases, intelligent agents, etc. It is both readable by computer and human. Moreover, it was especially designed to serve as an inter-lingua, or mediator in the translation of other languages. For example, a translation program can map an EXPRESS (modelling language within ISO STEP developments) expression about products into equivalent KIF expression and vice versa. Consequently, KIF can be used for mapping between different languages.

KIF is a prefix version of first order predicate calculus with extensions to support non-monotonic reasoning and definitions. The language description includes specifications for both semantics and syntax. The semantics of the KIF core (without rules and definitions) is similar to that of first order logic. There is an extension to handle non-standard operators, and there is a restriction that the model must satisfy various axiom schemata (i.e. the semantics of the words expressed in KIF are restricted by these schemata). Despite these extensions and restrictions, the core language retains the fundamental characteristics of the first order logic. Also, KIF can be used to express simple data, for example information that is stored in a personal database. Information that is more complicated can be expressed by more complex terms in KIF. Furthermore, KIF includes a variety of logical operators to assist the encoding of logical information, such assertion, disjunction, rules, and quantified formulas. The KIF uses a LISP like syntax, which makes embedding of knowledge in applications difficult. Therefore KIF has evolved to XML based models such as DAML/OIL as explained in the next section.

The initial version of KIF has been proposed as a US standard by ANSI X3H7 in 1992. In March 2002 it was agreed that KIF should be merged with the work on Conceptual Graphs (CGs). In a meeting in July 2002 a New Work Item was proposed for ISO/IEC JTC1/SC32 WG2 for development of a standard based on Common Logic, CG and KIF. The current version is 3.0 and is managed by Computer Science Department Stanford University Stanford. As the KIF standard will probably merged with other standards, the influence of the core KIF



standard on the BC industry can be considered less significant. However, merged with other standards, KIF may prove to become a significant development for the BC industry.

4.2 DARPA Agent Markup Language / Ontology Interchange Language (DAML/OIL)

The DARPA Agent Markup Language / Ontology Interchange Language (DAML/OIL) is a semantic mark-up language for Web resources. It builds on earlier developments of both DAML7 (US-led initiative) and OIL8 (EU-led initiative) and is based upon earlier W3C standards such as RDF and RDF Schema. DAML/OIL extends these languages with richer modelling primitives. DAML/OIL provides modelling primitives commonly found in frame-based languages. The language has clear and well-defined semantics based on description logics. Figure 12 shows the basic elements and their relationships of DAML/OIL, including class, enumeration and property elements as well as property restrictions, Boolean combination of class expressions and axiom.

subClassOf

TransitivePropertylabel

UniquePropertyID

ClassIDComment

PropertyID

MinCardinality MaxCardinality

Restriction

Cardinalitycardinality

maxcardinalityQ

mincardinalityQ

cardinalityPropertyObject samePropertyAs

inverseOf

subPropertyOf

onProperty

Collection

ClassObject

1..n1..n

disjointWith

toClass

1..n1..noneOf

sameAsClass

complementOf

intersectionOf

range

1..n

collects

Disjoint

1..n1..ndisjoint

disjointUnionOf

1..n

Figure 14 The DAML/OIL basic elements and their relationships.

With the arrival of the Semantic Web, DAML/OIL has become the de facto ontology language. However, at present, most of the native DAML/OIL processing tools are built by

7 The original purpose of DAML was to provide a markup language for software agents, which provides a basic infrastructure allowing machines to make the same sorts of simple inferences that human beings do.

8 The original purpose of OIL was to enable sharing and exchange of ontologies.



knowledge research specialists. As a result they do not attempt to hide the details of an ontology building task from the user. It is conceivable that an integrated development environment (IDE) to handle DAML/OIL ontology building details (such as creating, locating, reusing, merging and validating) will add to the appeal of the Semantic Web. The DAML/OIL is a so-called ‘upper ontology model’, which is simple to master and powerful enough to make explicit knowledge models. The DAML/OIL model does not make distinction between instances and classes. What is missing is the capability of modelling procedural knowledge. DAML/OIL is only capable of modelling frame-based knowledge in other words descriptive knowledge. DAML/OIL formed a basis for the development of the W3C standard OWL9, which probably will integrate with emerging industry standards in business process modelling. Therefore, the BC industry needs to closely monitor all developments of this promising standard.

4.3 Knowledge Query and Manipulation Language (KQML)

The Knowledge Query and Manipulation Language (KQML) is a protocol for the query, manipulation and the exchange of knowledge between agents and/or applications. The KQML is part of a broader research and development effort for a methodology for the distribution of information and knowledge among different systems [KQML, 1992]. A KQML message contains the information about the language, ontology, content and performative. This is an elegant feature, which gives the message the capability of understanding itself (Figure 13).

ApplicationAgentB

KQML

<<communicate>>

AgentA

KQML<<communicate>>

KQML

Figure 15 KQML is an exchange protocol agents and/or applications.

The syntax of KQML is similar to LISP, but the arguments maybe given in any order. The semantics of the KQML performatives (Table 8) are domain independent, while the semantics of the message is defined by the fields related to the content (the message itself), the language (the language in which it is expressed) and the ontology (the vocabulary of the words in the message). KQML requires an infrastructure (that is not part of the KQML) for allowing agents to locate each other.

As a middle-tier protocol between the infrastructure and the content language (e.g., bcXML, ifcXML, etc.), the KQML is a versatile technology for the BC industry, because KQML is

9 The Web Ontology Language (OWL) is a semantic markup language for publishing and sharing ontologies on the Internet.



language, ontology and content independent. Therefore, the fragmented BC industry can greatly benefit from this technology.

Category Performative

Basic query Evaluate, ask-one, ask-all, etc.

Multi response Stream-in, stream-all, etc.

Response Reply, sorry, etc.

Generic informational Tell, achieve, cancel, etc.

Generator Standby, ready, next, rest, etc.

Capability definition Advertise, subscribe, monitor etc.

Networking Register, forward, broadcast, etc.

Table 11 KQML performatives organised into seven basic categories.

4.4 FIPA Agent Communication Language (FIPA-ACL)

The Foundation for Intelligent Physical Agents (FIPA) is an international organisation that is dedicated to promoting the industry of intelligent agents by openly developing specifications supporting interoperability among agents and agent-based applications. This occurs through open collaboration among its member organisations, which are companies and universities that are active in the field of agent technology.

The most important output of FIPA today is its Agent Communication Language (ACL). The intention of FIPA-ACL is to provide conversational logic to agents, thus raising the semantic level of agent communication to a higher level than existing technologies, e.g. event-based communication. In order to achieve this, each of the FIPA-ACL communication primitives, called ‘Communicative Acts’, is given a precise semantics by providing pre- and post conditions expressed in a first order modal logic. With this semantics, the agent is able to express its attitude (e.g., uncertainty, choice, intention, etc.) towards its achieved knowledge rather than the semantics of the knowledge itself. Based on the underlying semantic model, the agent can compile sensible options for its next action. It also provides a conversation envelope based on ACL messages, consisting of a header, the ‘Communicative Act’, followed by the subject of this act, referred to as the ‘content’. In addition to this, a set of predefined agent interaction protocols is defined, such as protocols required for negotiation. Each ACL message representation specification contains precise syntax descriptions for ACL message encoding based on XML, text strings and several other schemes. The following terms are used to define the ontology and the abstract syntax of the FIPA-ACL message structure containing frame, ontology, element, description and reserved values.

The latest release of ACL as a standard (version E) is issued in December 2002 by FIPA. Arguably, this standardisation alone is not sufficient to achieve interoperability because there is also a need for the standardisation of vocabularies, ontologies and the content language (the same arguments are also valid for KQML discussed in Section 4.3).

The interoperability of agents provided by ACL is a functionality that can profoundly enhance the current and future developments of knowledge for the effective and efficient performance



of the BC industry. Therefore, FIPA-ACL can be seen as important platform for the BC industry as an enabler for eBusiness, eCommerce and eMarket.

4.5 Resource Description Framework (RDF)

The Resource Description Framework (RDF) is the W3C recommendation for modelling metadata about Web resources. RDF provides interoperability between applications that exchange information and knowledge on the Internet.

RDF uses XML to exchange descriptions of Web resources but the resources being described can be of any type, including XML and non-XML resources. RDF emphasises facilities to enable automated processing of Web resources. RDF can be used in a variety of application areas, such as in resource discovery to provide better search engine capabilities, in cataloguing for describing the content and content relationships available at a particular Web site, digital library etc. RDF can also be used by intelligent software agents to facilitate knowledge sharing and exchange.

The broad goal of RDF is to define a mechanism for describing resources that make no assumption about a particular application domain and the related semantics. The definition of the mechanism should be domain neutral, yet the mechanism should be suitable for describing information about any domain.

Another goal of RDF is to make it possible to specify semantics for data that is based on XML in a standardised, interoperable manner. RDF and XML are complementary, i.e. RDF is a model of metadata and only addresses by referencing many of the encoding issues that transportation and file storage require. For these issues, RDF relies on the support of XML. It is also important to understand that the XML syntax is only one of the possible syntaxes for RDF.

The RDF data model defines a simple model for describing interrelationships among Web resources in terms of named properties and values. The RDF Data Model is composed of Web Resources, Properties and Statements:

• Web Resources represent the key entities being described by RDF expressions. These can be an entire Web page, a part of a Web page, a whole collection of Web pages, or even an object that is not directly accessible via the Web. Web Resources are always named by URIs plus optional anchor IDs

• Properties are specific aspects, characteristics, attributes, or relations used to describe Web Resources. Each property has a specific meaning that defines its permitted values, the types of Web Resources it can describe, and its relationship with other properties

• Statements are specific Web Resources together with named Properties plus the values of those Properties for Web Resources. These three individual parts of a statement are called, respectively, the subject, the predicate, and the object



The RDF Schema (RDFS) provides mechanisms for declaring Properties and for defining the relationships between Properties and other Web Resources. The RDFS is a simple ontology language able to define basic vocabularies, covering parts of a knowledge model (classes, properties, domain and range restrictions, instance-of, subclass-of and subproperty-of relationships).

The interoperability of applications that exchange information and knowledge on the Internet, provided by RDF, is a functionality that can profoundly enhance the current and future developments of Web resources for the BC industry. Therefore, RDF can be seen as important platform for the BC industry as an enabler for eWork and eCollaboration.

4.6 Rule Mark-up Language (RuleML)

Following the success of rule-based reasoning in the AI field, inferencing and rules have also become a mainstream topic for the Internet. This requires an approach where rule-based reasoning is integrated with Web Resources and the languages describing them. This led to the development of a Rule Mark-up language. The Rule Mark-up initiative (formed by industries and academia), took initial steps towards defining a shared Rule Mark-up Language (RuleML), permitting both forward (bottom-up) and backward (top-down) rules in XML for deduction, rewriting, and further inferential-transformational tasks. The RuleML was launched on the Internet in 2000. Besides the previous XML-only RuleML and the current on XML and RDF based RuleML, there is also an approach towards an only RDF RuleML. Complementary efforts consist of the development of Java-based rule engines such as Mandarax RuleML and XSB-RDF RuleML.

The goal of the Rule Markup Initiative is to develop RuleML as the canonical Web language for rules using XML Markup, formal semantics, and efficient implementations. The Initiative develops a modular RuleML specification and transformations from and to other rule standards. Moreover, it coordinates the development of tools to elicit, maintain, and execute RuleML rules. RuleML can thus specify queries and inferences in Web ontologies, mappings between Web ontologies, and dynamic Web behaviours of workflows, services, and agents.

The current RuleML (2002, version 0.8) encompasses a hierarchy of rules, from reaction rules (event-condition-action rules), via integrity-constraint rules (consistency-maintenance rules) and derivation rules (implicational-inference rules), to facts (premiseless-derivation rules). The RuleML hierarchy of rules constitutes a partial order rooted in reaction rules. Its second main layer consists of, next to each other, integrity-constraint rules and derivation rules. The third layer just specialises derivation rules to facts.

RuleML is a highly reusable technology and easy to integrate with a broad spectrum of Internet applications. As the BC industry is moving towards an extensive use of Internet-based data, information and knowledge exchange and sharing, we can assume that RuleML will play an important role in the future developments of eWork initiatives in the BC industry.



4.7 Conclusions

This chapter discussed the standards for knowledge modelling and exchange. The five protocol standards considered are KIF, DAML/OIL, KQML, ACL-FIPA, RDF and RuleML. The DAML/OIL is promising standard which can serve as a framework for modelling BC industry knowledge. This standard is currently a W3C standard called OWL. The interoperability of agents provided by ACL is a functionality that can profoundly enhance the current and future developments of knowledge for the effective and efficient performance of the BC industry. The RuleML provides mechanisms to express knowledge for eCommerce and eBussines. In the future the information and communications standards will help the acceptance of knowledge exchange.





BC Industry

Complexity

KIF Stanford 3.0 Neutral Format

Final Open Standard Knowledge sharing

Not Common

+++

DAMN/OIL W3C 1.6 XML Format

Final Standard Upper Ontology Model

Accepted ++

KQML Darpa 1.5 Neutral Format

Working Draft Standard Knowledge sharing

Not Common

+++

ACL FIPA 1.0 Neutral Format

Working Draft Open Standard Agent Communication

Not Common

++

RDF W3C 1.0 XML Format

Final Standard Web Resources Definition

Accepted +

RuleML ISO 0.8 XML Format

Working Draft Standard E-Business E- Commerce rule sharing

Accepted +

Table 12 Knowledge Exhange Standards


ICCI: IST-2001-33022WP2/D221


5 Conclusions This deliverable regards, an investigation carried out during ICCI project and as a part of the work package WP2 task number T22. The analysis relies on the categorisation and description of standards, which may be currently used, has a potential for future use and those used or developed in ICCI partner projects. In addition, the scope of standards is limited to their relevance for the BC Industry.

In order to classify standards, three abstraction levels are introduced, respectively data (e.g. VRML, PDF, SQL, etc.), information (e.g. IFC, XML, CORBA, UDDI, etc.), and knowledge (e.g. KIF, KQML, DAML/OIL, RuleML, etc.). In Human-to-Human communication there is no need to make distinction between data, information and knowledge levels. However, Human-to-Computer communication and vice versa requires clear distinction between these three abstraction levels. By definition at the data level, the information is stored in computers or is exchanged by computers. At data level, information is not yet interpreted by either humans or computers. In this regard, the information level concerns the ‘structured’ data that does not need any further interpretation or processing. At the knowledge level, computers have the capability of processing data and information for a particular purpose such as represented in ontologies, taxonomies and intelligent agents.

Currently, Data Standards and Information Standards are applicable to the BC industry. The Data Standards for instance SQL and VRML are widely accepted and used by the BC industry where most CAD systems and databases support these standards. However, it is clear that Data Standards are not a viable solution for the integration of the BC industry. Alternatively, the more people are aware of Information Standards, the more it becomes feasible and accepted by the BC industry. By the arrival of the Next Generation Internet, the use of XML-based information standards is growing. From this a number of BC-specificv standardisation efforts have emerged. For instance ifcXML is a promising standard that is specifically developed for the BC industry. It is also recommended that EU projects look at the ISO-PAS and eConstruction CEN developments. Also other EC projects such as eLegal and eConstruct are examples of such BC-specific developments.

The standards particularly for the communication of data, information and knowledge include the protocol, service and architecture standards. The protocol, (web) service and architecture standards do not specifically targeting end-users, but they are for application developers (mostly from outside the BC industry). Therefore, these standards will have significant influence on future ICT developments, which will indirectly affect the BC industry. For instance, SOAP as a lightweight protocol, which enables heterogeneous applications to exchange information in a distributed environment, or WSDL specification that defines the way in which businesses can publish and discover information about ‘Web services’, enables new opportunities for the BC industry integration. In addition, the two architectural standards J2EE and .NET provides new infrastructures for business processes.

The advancement in data and information standards facilitates the knowledge development processes. The knowledge development requires a group effort. The fragmented nature of the BC industry is a major bottleneck in this process. However, the knowledge exchange and infrastructure will help to improve the automation in the BC industry.



Developing standards is essential for the BC industry. Also, the BC industry is lacking dominant-stakeholders and is an extremely fragmented industry. As a result the BC industry itself is not able to take the necessary steps in solving this problem. Consequently, policies have to be made for drastic measures at the EU and national levels to stimulate RTD efforts for the BC industry. Therefore, the EU and the national governments in Europe should play a significant role in providing possibilities and support for all RTD efforts required for ICT standardisation which will inevitably enhance the effectiveness and efficiency of the BC industry as a whole.



Acknowledgements The ICCI Consortium would like to acknowledge the financial support of the European Commission under the IST programme. Furthermore we like to thank Dr. Thomas Liebich from AEC3 for his extensive contribution to chapter 2 of this deliverable (mainly STEP and IFC).



References

DIVERCITY 2001 , EU DIVERCITY project IST project No: IST-1999-13365 at http://www.e-divercity.com/

ECognos 2000, Deliverable D1.3: Construction common software applications analysis, eCognos Methodology, tools and architectures for electronic COnsistent knowledge maNagement across prOjects and between enterpriSes in the construction domain

eLEGAL, 2001. Deliverable D11: State-of-the-art Assessment, eLEGAL: Specifying Legal Terms of Contract in ICT Environment, IST-1999-20570.

OSMOS, 1999. Specification of the OSMOS compliant extensions to common construction applications, IST-1999-10491

eConstruct, 2000. Deliverable D103 Final edition of the bcXML Specification, IST-1999 10303

GLOBEMEN, 2001. GLOBEMEN (Global Engineering and Manufacturing in Enterprise Networks)

OSMOS, OSMOS (2000), Open System for Inter-enterprise Information Management in Dynamic Virtual Enterprises (http://osmos.vtt.fi)

W3C 1999, REC-xml-names-19990114, Document available at http://www.w3.org/TR/REC-xml-names/.

SOAP 1999, Specification of SOAP on W3C web site available at http://www.w3.org/2000/xp/.

Universal Description, Discovery and Integration http://www.uddi.org/

XML, XML Schema by W3C at http://www.w3.org/XML/Schema.

DAML, DARPA Agent Markup language at http://www.daml.org/.

RDF2002, Web Resources Description Framework at http://www.w3.org/RDF/

RuleML 2002, Rule mark-up language at http://www.dfki.uni-kl.de/ruleml/

WSDL 2002, Web service description Language at http://www.w3.org/TR/wsdl

http://www.e-divercity.com/

http://osmos.vtt.fi/

http://www.w3.org/TR/REC-xml-names/

http://www.w3.org/TR/REC-xml-names/

http://www.w3.org/2000/xp/

http://www.uddi.org/

http://www.w3.org/XML/Schema

http://www.daml.org/

http://www.w3.org/RDF/

http://www.dfki.uni-kl.de/ruleml/

http://www.w3.org/TR/wsdl



NET 2002, Microsoft .NET paltform at http://www.microsoft.com

JAVA 2002, Sun Java platform at http://www.java.sun.com

AIML 2002, Artificial Intelligence Markup language at http://www.alicebot.org

KIF 2000, Knowledge Interchange Format at Http://logic.stanford.edu/kif/kif.html

Autocad 2002, CAD vendor Autodesk at Http://www.Autodesk.com

WAP2000, WAP forum at http://wapforum.org

SVG 2001, W3C Simple vector graphics API at http://www.w3.org/TR/SVG/

VRML1997, W3C /Web 3D consortium at http://www.web3d.org/

IAI-IFC 2002, IAI web site at http://www.iai-international.org/iai_international/

EbXML, Enterprise Beans at www.ebXML.org

WML, WAP Markup language at http://www.wapforum.org/DTD/wml_1.1.xml

FIBA, Foundation for Intelligent Physical Agents at http://www.fipa.org/

IETF, http://www.ietf.org/internet-drafts/draft-fielding-uri-syntax-04.txt

[Green 2002] Green, R. The semantics of relationships, Kluwer Publishers, USA, 2002

http://www.microsoft.com/

http://www.java.sun.com/

http://www.alicebot.org/

http://www.autodesk.com/

http://wapforum.org/

http://www.w3.org/TR/SVG/

http://www.web3d.org/

http://www.iai-international.org/iai_international/

http://www.wapforum.org/DTD/wml_1.1.xml

http://www.fipa.org/

http://www.ietf.org/internet-drafts/draft-fielding-uri-syntax-04.txt

ict standards for construction projects - vttcic.vtt.fi/projects/icci/deliverables/icci_d221.pdf ·...

Documents