IFD (International Framework for Dictionaries)

发布时间:2009-12-25 16:14:26 来源:建筑信息模型BIM网
摘要:

【ChinaBIM.com注】由于BIM信息在各个软件之间的转换还存在很多问题,比如用ArchiCAD或者revit建模导出的IFC文件进入能量模拟软件比如Riuska时,模型的各种信息并不能很好的和Riuska本身的library进行mapping,而IF

【ChinaBIM.com 注】由于BIM信息在各个软件之间的转换还存在很多问题,比如用ArchiCAD或者revit建模导出的IFC文件进入能量模拟软件比如Riuska时,模型的各种信息并不能很好的和Riuska本身的library进行mapping,而IFD(International Framework for Dictionaries)就是针对这一问题产生的。


IFD Library

Introduction
The construction industry will increasingly apply building information modeling methods in
developing design, procurement, construction and operation/ maintenance of facilities. Building
information model (BIM) programs internally apply schema that define the templates for the
information that they can process. Schemas also define the way in which different BIM software
applications communicate with each other.
A schema requires a consistent set of entity names of items which make up the model and
names of things that are modeled to be able to work. Entity names could refer to a material,
property set, property etc. Names of things being modeled can refer to a particular construction
(e.g. wall type 1), system (e.g. low voltage electrical supply), etc. Each of these names should
have a controlled definition that describes what it means and the units in which it may be
expressed. Having a controlled vocabulary of construction terminology is essential to support
data exchange.
Perhaps even more importantly, 'names' of things may be used more widely to support
knowledge application and management in connection with BIM. For instance, building codes
also refer to items by name (both in terms of a concept and attributes or properties that a concept
may possess). An application of a controlled construction vocabulary is being developed with the
International Code Council.
A dictionary defines concepts behind names. A data dictionary will then define the use of a
particular 憂ame?(type, property etc.) in a consistent manner whoever is using the schema and
wherever it is used. Properties used in different places need to be expressed in the language of
choice for that place. To be useful in the increasingly globalized construction industry, a dictionary
needs to be able to handle multiple languages.
Background
At ISO meetings in Vancouver in 1999, a variety of organizations developing IT standards for the
building industry (leading to what we are today calling BIM) agreed that some sort of standardized
global terminology was necessary and that its structure must be useful for computers to reliably
exchange data irrespective of language. As a result, the ISO committee TC59/SC13/WG6 was
tapped to develop the standard now known as ISO 12006-3 ?Framework for Object-oriented
Information Exchange.
Once ISO 12006-3 was published, STABU LexiCon in Holland and BARBi in Norway each
focused their development of the object library databases to be compatible with the standard. In
January 2006, the organizations signed an agreement that they would combine their separate
efforts into the International Framework for Dictionaries (IFD) Library to produce a single
object library / ontology that they would share between themselves for mutual benefit.
Following the IAI buildingSMART conference held September 2006 in Lisbon, Portugal that
included a two day workshop on IFD, the Construction Specifications Institute, Construction
Specifications Canada, buildingSMART Norway, and the STABU Foundation (the Netherlands)
signed a Letter of Intent to share unified object libraries, developed under ISO 12006-3, as a
structure for a controlled dictionary of construction terminology.
Following on the goals of the Letter of Intent and a subsequent Partnership Agreement signed in
April 2009, the signers applied for and received recognition by the buildingSMART International
IFD Library White Paper
2008-04-10 2
organization as a Group reporting to the International Council. The IFD Library Group Charter
defines how the Group will operate within buildingSMART International setting out the following
objectives:
.. To manage and develop an open, international and multilingual IFD Library based on the
principles of ISO 12006-3, 2007.
.. To establish and operate IFD Library as financially nonprofit but also self supporting
component of buildingSMART technology as a group under IAI International1.
.. Provide support for implementation of buildingSmart technology in the global building and
construction industry through extension of IFC and integration of IFC with IDM.
The Charter with further details on how the group will operate is available at www.ifd-library.org.
Relevance to Users
In order for a real free flow of information to occur, three factors need to be in place:
1) The format for information exchange,
2) A specification of which information to exchange and when to exchange the
information, and
3) A standardized understanding of what the information you exchange actually is.
Figure 1: Interoperability through Standards, courtesy Janne Aas-Jakobsen, Jotne EPM Technology AS
Having these three fundamental items in place allows for a true computerized interoperability
between two or more information parties. This approach has been used with success in other
industries, most notably the oil and gas industry, to support application and data interoperability.
In the building industry, material suppliers, specification writers, cost engineers and many others
recognize the formats, terminology, and concepts included within the classification system of
OmniClass. As a result, these tables are already being used in many cases to store, retrieve, and
analyze facility and material information. Use of all of the OmniClass tables is anticipated to grow
with the demand for structured access to and reports based on BIM information. Being a
framework for dictionaries and ontologies IFD library allows concepts within widely used
classification systems like OmniClass to be mapped to corresponding concepts in other
standards like IFD while preserving the internal classification structures of both standards.
Relevance to the National BIM Standard
Design of the National Building Information Model Standard (NBIMS) relies on terminology and
classification agreement (through OmniClass) to support model interoperation. Entries in the
OmniClass tables can be explicitly defined in the IFD Library once, and reused widely enabling
reliable automated communications between applications ?a primary goal of NBIMS.
1 IFD Library Outline Business Plan, 09.10.07
IFD Library White Paper
2008-04-10 3
Relationship between IFC, IFD, IDM and MVD
The open international IFC (Industry Foundation Class) standard defines an exchange format for
information related to a building and its surroundings. The upcoming (September 2008) release of
version 2x4 of the IFC standard will include facilities (currently available for preview in the 2x3g
Preview Release) to exchange GIS data, (e.g. where the building is located and information about
surrounding buildings) and facilities to tag all information with a globally unique ID (GUID) from an
internationally agreed ontology. With this added functionality the IFC will provide a computer
understandable format in which all relevant building information can be exchanged between two
parties. The IFC allows various data to be exchanged in various ways. If a receiver of information
wants to be sure they can utilize the information received, the sender and receiver need to agree
on exactly which information to exchange.
The aim of the supporting IDM (Information Delivery Manual) and MVD (Model View Definition)
processes is to specify exactly which information is to be exchanged in each exchange scenario
and how to relate it to the IFC model. For example an architect designing a building needs to be
sure that they receive information from the structural engineer about which walls and columns are
load bearing and which are not. At the same time the structural engineer needs to know the
function of each of the spaces in the building in order to calculate the right design loads for the
structure. IDM along with MVD explains the exchange scenario in plain text for human readability
and in a technical way to enable implementation of automatic checks and validations in
applications. Continuing the example above, the engineer can run a quick test through a
computer based on the requirements established in the IDM/MVD to verify that the architect has
sent enough information to get started on the work.
In order to automatically verify the information in an exchange process (as described above) the
information needs to be detailed further than the general level of the IFC standard. For example,
if an architect wanted to supply information about the type of materials in the beams and columns
this would be done in IFC using a plain text string. Even if all of words are spelled correctly there
is no guarantee that the receiving application will understand exactly what this text string means.
And if a different language, dialect or form of the word is used there is no reliable way to achieve
verification. Ideally the computer should be able to understand even this type of information in
the IFC formatted information received. This is typically the scenario addressed in semantic
searches on the web but in order to automatically interpret the semantic, the semantic needs to
be described first. The IFD (International Framework for Dictionaries) (ISO 12006-3) together with
the upcoming version of the IFC standard, 2x4, provides a means to make this possible. IFD is a
supplement to IFC; it cannot and is not trying to replace IFC.
IFD Library is an open library, where concepts and terms are defined, semantically described and
given a unique identification number. In order to make the information exchanged through IFC
understandable, this information should rely on concepts as defined in IFD. This allows all the
information in the IFC format to be tagged with a Globally Unique ID (GUID). The architect can
then provide the materials in, say Chinese, while the receiver can understand it in Norwegian.
Likewise, a synonym or plural form of a name of a material can be correctly understood by the
receiving application, as long as the correct GUID is given. While strings like names and
descriptions are exchanged in textual form and used by humans, the underlying GUID is used by
the computers. Currently, IFC uses its own definitions, stored in the model and in property sets.
These definitions will be mapped to the corresponding definitions within IFD.
IFD Library White Paper
2008-04-10 4
IFD Library and International Standards
IFD, the International Framework for Dictionaries, is, in simple terms, a standard for terminology
libraries or ontologies. The concept for the IFD Library is derived from internationally-accepted
standards that have been developed by the International Organization for Standardization (ISO)
and the International Construction Information Society (ICIS) subcommittees and workgroups
from the early-1990s to the present.
ISO 12006-2
The related standard, OmniClass follows the international framework set out in International
Organization for Standardization (ISO) Technical Report 14177 - Classification of information in
the construction industry, July 1994. This document was later established as a standard in
ISO 12006-2: Organization of Information about Construction Works - Part 2: Framework for
Classification of Information.
ISO 12006-3 and ICIS
In much the same way that ISO 12006-2 has been implemented in the UK in Uniclass and in
North America in OmniClass, the object-oriented framework standardized by ISO/PAS 12006-3
has been adopted by ICIS members in the Netherlands with LexiCon and in Norway with the
BARBi programs.
Following these ISO standards will promote the ability to map between localized classification
systems developed worldwide and the object-oriented framework of 12006-3, implemented
alongside and in concert with 12006-2-based standards, will multiply the degree of control
available over construction information.
ISO 12006-3 and ISO 15926 (EPISTLE)
EPISTLE is a dictionary development used in the oil and gas industry that has a similar top level
structure to ISO 12006-3. While IFD and EPISTLE share much of the same concepts and have
the same core structure, the initiatives are different. IFD only defines types of things. EPISTLE
will also store instances or individuals. To cover the same functionality as EPISTLE, IFD relies on
the IFC standard. Entries in IFD would be for example types of doors while an instance of a door
in a particular building project would be established using IFC. IFD does not aim to hold such
individual records. For that we rely on the IFC standard. IFD will on the other hand hold all
classes or types of concepts that in turn can be used to instantiate individuals. In other words IFD
holds the templates while IFC (or also other standards and conforming databases) are used to fill
them in.
IFD Library Development
Development of the IFD Library is in two primary areas - content and technology. To date the
Norwegian and Dutch efforts have independently focused on developing on both fronts. With the
creation of the IFD Partners and the release of the IFD API by the Norwegians, all technology
development is being focused on this platform which is now in limited release. Efforts are also
underway to harmonize all of the content developed to date into the common core context within
the IFD.
IFD Library Status - Content
Content within IFD are of two basic types:
IFD Library White Paper
2008-04-10 5
1. Concepts (Labeled through Terms) 杝omething that can be distinguished from other
things and that can be recognized as such. One concept can have many labels in
different languages or in the same language, still remaining the same concept. On the
other hand a name might be used as a label for several concepts. Names and concepts
have their own Ids, and are linked through a naming relationship.
2. Characteristics (Properties) - concepts that cannot be defined using other concepts; their
meaning is provided through a description.
Subjects are concepts being defined, Characteristics are concepts that define.
Characteristics contain values when instantiated in a relationship with a Subject.
Characteristics can be distinguished into the following types (in alphabetic order):
Behavior, Environmental influence, Function, Measure, Property and Unit. (The list of
Characteristics is not extensive. Measure and Unit are used to scale Properties.)
Concepts are related to other concepts through objectified relationships. Relationships are
collected into contexts based on how they came into the library and where they came from.
Concepts can relate to other concepts in multiple contexts. For example, the concept Door might
have the following relationships to other concepts depending on the context in which it is being
viewed. A context can typically be the relationship structure of one given classification system like
OmniClass.
Figure 2: Concepts and Relationships: courtesy Lars Bj鴕khaug and H鍁ard Bell, IFD in a Nutshell, IFD Developers
wiki, www.ifd-library.org
All concepts are assigned a Global Unique Identifier (GUID) by the IFD to allow them to be readily
identified and reused by applications. A goal for entering terms into the IFD Library is to resolve
duplicates and synonyms so that multiple entries with the same or similar meaning are not
created. The processes and procedures for achieving the common use of terms across multiple
contexts are still being refined to help those using the IFD efficiently search for similar terms
already in the library.
The following graphic illustrates how a concept (window) can be described by a set of
characteristics in IFD. The relationship between a concept and its characteristic can also be
captured in a context allowing the relationship between the particular use of a concept and its
properties in that use to be captured within a given context.
IFD Library White Paper
2008-04-10 6
Figure 2: IFD as a Mapping Mechanism: courtesy Lars Bj鴕khaug and H鍁ard Bell, IFD in a Nutshell, IFD Developers
wiki, www.ifd-library.org
Currently both the Norwegians and Dutch have created objects in the IFD Library. The Dutch are
leading a project to harmonize the existing terms in the Dutch and Norwegian contexts. As new
projects are initiated the goal will be to make use of terms already in the IFD to the greatest
extent possible so that a shared global and multilingual dictionary can be created. The partners
have agreed that any terms entered into the IFD must be accompanied by an international
English translation to facilitate connection to equivalent concepts in other languages.
In North America, CSI/CSC are planning to organize an access structure (context) into the IFD
Library based on the OmniClass schema. The goal is to identify where concepts fit into
OmniClass as they are brought into IFD Library. This will allow us to identify and relate concepts
that have been assigned a persistent definition to the classification systems commonly used to
structure documents and applications. Currently CSI is working with the ICC to bring the terms
used in the codes into IFD in this way. This project is serving as a pilot to help define the
requirements for tools to support term identification and input and to further validate the concept
of using the IFD to enrich the concepts and property sets of the IFC model.
IFD Library Status - Technology
The core of the system is an object oriented database, based on the EXPRESS standard hosted
on EPM Technology抯 EDM Server? Although proprietary as a product, all data are stored and
manipulated using the ISO originated EXPRESS standard. The database resides on one physical
server in a well guarded and maintained datacenter.
A Standard Web Service based approach is utilized to communicate with the library independent
of the actual technology chosen for the database in a way more suited for application developers.
A set of objects and a set of methods that use the objects to pass information back and forth are
defined. These objects and methods fit into a normal object oriented programming setting and
can thus be easily utilized from within an application. The API is clearly versioned through its
access point, so newer versions of the API can be provided in parallel with the old.
An offline option will also be available where the entire library will be located on the local disk of
the application. The data will be accessible through the same objects and methods as for the
IFD Library White Paper
2008-04-10 7
Web Service. In addition, it will be possible for the application, when online, to download the
latest version of the library, and thus stay up to date as often as needed.
The Web Service API and offline API will enable any application to access the library. The set of
objects and methods defined in the API, greatly simplify accessibility to the library. The Web
Service API is in its initial release and will be accessible at www.ifd-libray.org. Several
applications to use the API, an input tools and browsers, are now being developed.
One input tool called Propertylizer will allow for selecting or entering concepts and associating
them with definitions, synonyms, classifications and properties. buildingSmart Norway has
developed the Propertylizer input tool and is utilizing it for projects in Norway. CSI is working with
the developer to adapt the current version to support projects in North America and is aiming to
have something available early in 2008. The Propertylizer will support the content authoring
process by providing access to existing concepts and properties through an interface that can be
used to prepare them for input to the IFD. New concepts and properties can also be entered
through the Propertylizer. An early version of the application illustrating these functions follows:
Figure 3: Propertylizer User Interface, courtesy Aleksander Bjaaland, Holte Byggsafe
Another class of tools being developed for the IFD is browsers to enable access and review of
terms in the IFD. The Dutch have developed the IFDLibrarian for internal content access and
management. A public access web version of IFDLibrarian and the IfdBrowser developed by
SINTEF building and infrastructure in Norway as well as several other browser tools are currently
under development and will be released soon to provide on-line access to look up and make use
of content in the IFD..
IFD Library White Paper
2008-04-10 8
IFD Library Status - Projects
The IFD Library partners have a number of projects underway that are starting to address
working with the IFD and integrating it with the IFC model to support interoperability. Here in
North America, we are currently pursuing the following projects:
1. ICC Smart Codes - the primary project CSI is pursuing as an initial test case is supporting
the International Code Council (ICC) SmartCodes project. ICC has identified terms from
the energy code and identified their relevant properties. We are using this work captured
in spreadsheets to develop the input tool and access to the API. With the energy code
complete, we will move on to support other parts of the International Building Code.
2. NBIMS ?Once the toolset and procedures are established, CSI plans to make them
available to support all projects looking to achieve interoperability through using the IFC
model and IDM process definitions. Initial work with the development committee on the
Product Property Sets for Specifiers project is expected to utilize the IFD to establish the
requirements for specifications by project phase.
Organizations wishing to use the IFD will be invited to file a Project Plan and join the IFD Partners
as an Observer organization. Details will be available soon at the IFD Library web site.
BIM Applications
OmniClass, MasterFormat, and UniFormat are all currently used to index, organize and retrieve a
variety of different information types throughout a project life cycle. The consistent use of
standard classifications from any of these, applied to objects, will enhance the ability of users to
sort data, roll up or drill down through data based on the hierarchy that all of these classifications
are built upon. A standard implementation of any of these classifications within a BIM model will
allow for this same information sorting and retrieval across multiple platforms and by all users at
any stage in the facility life cycle.
In conjunction with the IFDLibray, the structure of the classification systems can be explicitly
applied to the information used in model-based design, analysis and management systems. A
more consistent naming system for objects captured in a BIM has the potential to support the
goal of buildingSmart to improve interoperability of systems and processes.