IFD Library White Paper 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),
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 ‘name’ (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 organization as a Group reporting to the International Council. The IFD Library Group Charter IFD Library White Paper 2008-04-10 2 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.