Ifd:IFD in a Nutshell

From dev.ifd-library.org

By Lars Bjørkhaug and Håvard Bell - SINTEF Building and infrastructure

Introduction

This document is an introduction to IFD, the basic ideas behind it, what it is and what it isn't. The close relationship with Ifc and buildingSMART is also discussed.

What is IFD?

IFD stands for "International Framework for Dictionaries". The name is used both for the IFD library and for the organization running and maintaining it. While the two first words; "International and Framework" pretty well describes IFD, the last word "Dictionaries" is somehow misleading. Yes, IFD is a dictionary, or rather a lot of dictionaries, but it is also much more. International framework for Ontologies would be a better word, but as you will learn, IFD goes even further.

What IFD is not

Before explaining what IFD is, it might be a good idea to tell what IFD isn't. IFD is not:

One uniformed classification system. It can however store multiple classification system in its structure.
A meta ontology. IFD can hold several ontologies in it structure, but is in itself not an ontology.
An alternative to IFC. IFD is a supplement to IFC it cannot and is not trying to replace IFC.
An alternative to the EPISTLE standard. Although IFD and EPISTLE share much of the same ideas and have the same core structure, the initiatives are different. IFD only talks about types of things. EPISTLE will also store instances or individuals. To cover the same functionality as EPISTLE , IFD relies on the IFC standard.

.

The basics of IFD

The IFD standard (ISO 12006-3) is an EXPRESS model with a short explanation of its purpose and use. The model itself is pretty simple seen from a implementers view but it is proven to be very flexible and can therefore result in several different implementations. The two first implementations of the standard was the Norwegian BARBi library and the Dutch LexiCon from STABU. There was also other implementations done by e.g. EDIBATEC in France. The structure of IFD is given in ISO 12006-3 and is a result of many years of standardization work by the ISO TC59/SC 13/WG 6 work group. The standardization work started already in October 1999 and has slowly evolved into the official ISO 12006-3 standard that was formally published at April 14. 2007.

IFD as a dictionary

In its simplest form IFD is a mechanism that allows for creation of multilingual dictionaries or ontologies. There is noting in the ISO 12006-3 standard that limits it to building and construction, and the model as such can be used to describe most things.

Naming concepts

Ifd will capture what a dictionary normally don't.

IFD separates the names and languages from the concepts itself. It is not a mapping of words in one language to words in another language, but a mechanism where the concept itself is a separate thing, only connected to the words describing it through relationships.

E.g. the word “dør” in Norwegian is in a normal dictionary translated to “door” in English. By studying the concept we find that in Norwegian we refer to the door with its frame, while door in English only referrers to the door-leaf. The Norwegian dør should be transleted to door set. In Ifd this is achieve by separating the concepts itself from the names and descriptions used to name and describe it.

Synonyms, acronyms, definitions and lexemes

One concept have multiple names and each name might referrer to multiple concepts. Ifd captures this too.

Once concept often have multiple names event in the same language. Examples are beam and truss but also long and short form names as millimeter and mm. Ifd allows for multiple names, descriptions, short names (e.g. acronyms) and lexemes to be attached to the same concept. As is the case for descriptions, definitions and comments which also is supported in Ifd.

A beam is not just a beam.

A name is often used to describe more than one concept even in the same language. As the image shows a 'beam' is not just a 'beam' but a word used to describe multiple concepts. In any computer related exchange of information it is essential to capture the different concepts hidden behind all those different versrions of the word 'beam'.

Because of the internal relationships between concepts in Ifd it is possible to translate a specialized concept into a more generalized one. E.g. all of the fifteen different snow types in Greenlandic (East Inuit) might translate into only one word in Bantu. While each of the specialized concept for snow don't have any equivalently in Bantu they at least share the same super type being 'snow'. This will also be the case for more specialized building terms like e.g. fire-resistant classes in different countries.

The Global Unique Identifier (GUID or UUID)

Despite the problems arraising from one name having multiple meanings much of todays information exchange is still done using name tags as the only mean of identifying the information exchanged. Labels where users are meant to add self defined information are common in nearly any data model used for information exchange.

Ifd offers the GUID as an alternative to the 'label' or 'name-tag'. The GUID (Global Unique Identifier) or UUID (Universal Unique Identifier) is in reality performing the same task as as the personal identification number is doing for the tax authorities and governments. We are long past the days where identification of persons would rely on the name alone. If you change your name because you marry or because you've done something really stupid, chances are that your personal identification number will stay the same. It will not change even if you change your sex. It is simply too important for so many computer systems to function that anyone would allow it to change.

We believe that time has come to introduce the idea of a personal identification number for all the concepts used in the building industry as well. After all, all those tax people cannot possible be wrong?

So how does a GUID look like in real life? Taking the door-set as and example the corresponding GUID representing the door set concept looks like this:

3vHRQ8oT0Hsm00051Mm008

GUIDs are created using a standard algorithm assuring that there will never ever produced two identical GUIDs. The whole idea of a GUID is as for a personal identification number to be unique. The GUID identifier is a unique 128-bit number compressed down to a 22 character string. Typically, the identifier is generated using an algorithm such as that published by the Object Management Group which is based on the IP address of the computer that generates the identifier. An example of the algorithm is explained at http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt

The idea is that rather than exchanging words describing object e.g. in a building information model, you simply exhange the GUID. You will most likely also exchange a word communicating the meaning of the GUID for a user but that is not really required. After all the receiving user might want to see the names in a different language or have her own preferred names for the concepts. What you need is software that a) already have the words for the GUIDs implemented, or b) have access to the open available Ifd library on the internet.

IFC as an ontology

There are many definitions for what an ontology is and your may argue for or against using the word 'ontology' to describe Ifd. As earlier stated Ifd is not one ontology. It is a framework in which different ontologies can coexist.

In WikipediA the idea of an ontology is described from both from philosophy but also as ontology in computer science. In the latter there is a list stating that ontologies are used to describe:

- Individuals: the basic or "ground level" objects
- Classes: sets, collections, or types of objects
- Attributes: properties, features, characteristics, or parameters that objects can have and share
- Relations: ways that objects can be related to one another
- Events: the changing of attributes or relations

From this list Ifd covers everything with the exception of individuals. Individuals in Ifd is e.g. a door in a particular building project or a product in a product database. Ifd does not aim to hold such individuals. For that we rely on the Ifc standard. Ifd will on the other hand hold all classes or types of concepts that in it's turn can be used to instantiate individuals. In other words Ifd holds the templates while you will use Ifc (or in theory also other standards) to fill them in.

A concept in Ifd is defined not only by its names and descriptions but also with it's relationship to other concepts.

In Ifd a concept is described both by a set of names and definitions in multiple languages but also with relating a concept to other concepts.

As stated earlier Ifd can hold multiple ontologies in the same library. This is possible because of the support for contexts. A context in Ifd is a grouping of relationships that exists between concepts. There might be (or rather we know there are) multiple ways of viewing a concept. A door will be described different depending on the phase of the building project, the actor describing it or the standard used. Each of this views can be seen as a set of relationships between the concept being described and the other concepts describing it. Another name for such a view is a 'context'. The use of contexts in Ifd is described in detail here.

IFD as a mapping mechanism

There is no start and end on a Ifd library. Ifd is a web of concepts linked to eachother by the use of relationships. When contributing to or extracting information from the Ifd library you may start at any point in the structure. Another essential rule of Ifc is:

A concept can only exist once! There are no duplicates!

Even the measure concept 'millimeter' only exist once and any measure using millimeter is doing so by creating a relationship between the measure concept and the unit concept. Relationships are also two ways. Looking from 'millimeter' you will be able to see all measures using that unit.

A concept in Ifd is described independent of time and use and each relationship is of the type “can have”. Taking a window as example we will find that studying the concept of a window in different sources of information, each source will talk about a particular set of e.g. properties for that window.

The properties are here represented by colored boxes. Some properties are 'shared' between the different information sources where a window can appear, but some are different. A information source is often one particular 'view' of the concept for one particular use or in one particular phase. By going through different sources and adding each property to the generic concept of a window in Ifd, you will eventually end up with a concept having the sum of all properties for a window. By keeping the link back to the source where the information originated from, Ifd ultimately becomes a mapping structure as well.