During the years I’ve been working with IFD and buildingSMART related matters I’ve given lots of presentations on the subject. The challenge when talking about IFD is that it’s rather technical and abstract and need to be put in some kind of familiar context to be understood. Finding a generic way of introducing IFD has turned out to be really hard. As a regular reader of the excellent magazine; Linux Format I’ve noticed the “What on earth.. ” series where the authors introduce rather complex issues using a technique of schizophrenic monologues. So I’m giving it another try. To introduce the wonders of IFD, I’ve set myself up for an interview with my evil twin. Here we go:
I’ve heard about this 3 letter acronym under the buildingSMART umbrella called IFD. What is it and what is it good for?
IFD stands for International Framework for Dictionaries. That is a description that more or less exactly fails to explain what it is.
Eh, that wasn’t particularly helpful. Could you please elaborate?
Sure. IFD is a framework and a data-model, and it can be used for mapping dictionaries in multiple languages. But IFD is so much more than that…
Like what? I’m familiar with the other standards of BuildingSMART like IFC and IDM. Where does this IFD thing fit in?
Let me use an analogy. Image the IFC standard as being the GSM standard of the building industry. IFC allows different applications communicate by defining a way of storing and exchanging BIM data. It has good commercial backing so there already exist lots of “phones” out there that communicate using IFC. But enabling people to communicate doesn’t really solve the communication problem, does it? For example; what if these people talk using different languages or if they have different understanding of the meaning of a particular word? The words get trough from one phone to the other but but the receiver will not get the meaning, unless both speaks the same language…
Well, I accidentally ended on a non English speaking switchboard in Finland when calling a colleague last week so I can understand the problem. On the other hand this doesn’t seem to be a problem for IFC. I’ve seen lots of examples of communication working seamlessly over the “IFC line” on various “seeing is believing” sessions at BuildingSMART conferences…
Well, that is true, but that is simply because the people communicating in this sessions has agreed about the language to use in this sessions up front. A kind of “implementers agreement”. In other words, the makers of IFC compatible software have agreed about the meaning of each word used in the applications. But that is not enough. You also got to agree about the language for each project where you use IFC in order to have a fully working scenario like you’ve seen on “seeing is believing.” Without such agreements it would simply not work.
I see your point, but honestly, the only way to fully resolve this is to have a “bablefish” stuck in the ear or network cable of every computer…
So you’ve read “the Hitchikers Guide to the Galaxy”? Good, that makes everything easier. Well you see, IFD is the Babel fish of buildinSMART..
Yes, sure… Come on, I’ll love the idea of having something translate concepts automatically, but we are no where near inventing the Babel fish for the building industry… or are we?
Well, perhaps not as sophisticated as a multilingual fish feeding on brainwaves, but the idea of having something there that can automatically translate the idea of a concept in one context or language to another is exactly what the IFD library is meant to solve… What IFD has done is to replace the words as carriers of information, with globally unique identifiers, (GUID) and connected, the word to the GUID instead. As a bonus we’re also linking the concepts (GUIDs) to each other by all kind of relationships to other concepts in the library. Those relationships eventually allows for a loot of cool side effects of using IFD, but the main idea is still to have one GUID for each type concept in the building world.
But I don’t get this. Why don’t simply use unique words as they are, why do we need a stupid 32 character random string instead….
Well you partly gave the answer yourself. Firstly words are NOT unique. One word can mean several things and a thing can have several names (words) even in the same language. The IFD GUID will help buildingSMART in the same way as a personal ID number help tax authorities. A modern society would simply not work if people would be identified by their name. You can change name, sex, whatever, but your ID number will never change. Secondly computer programs love these unique numbers, and IFD on the technical level is a tool for computer programs not humans.
I think I’m getting the message, but could you give me another example, and please don’t include the tax people this time…
OK. Take this silly example; you have been given the task to find your old high school classmates for a 20 year reunion party. The only restriction is that you can only search for them using the Internet phone book and you’re not allowed to ask anyone for help. Well guess what? Lots of the girls from school are married and many have changed their names. You will waste a lot of time and money calling the wrong person and your party will lack many people. Wouldn’t it be much better if you knew their personal number and you could use that to search them up in the phone book?
he idea sounds nice, but I can see a flaw. What if some of the girls moved abroad? I’m sure that the phone book in the other country wouldn’t understand the personal ID from here? The other country would probably have given her another personal number too…
Yes, exactly. And that’s why we use Globally unique Id’s. They’re supposed to be completely unique, at least on this planet.. By the way, the example you gave is just the same for product catalogs. Every catalog invents a “unique” number for the products within. But these number are rarely comparable with numbers used in other catalogs. Even if the product is identical. So you can’t search in one catalog using the number from another.
But hold on.. does this mean that if a producer uses IFD GUIDs to identify her product you could use Google to search it up rather than having to look it up in various product catalogs all over the world?
Well, yes in theory. We have already tested it and it works, the search engines did pick up the GUID and some did index it. But finding an “aluminum window” by its GUID is usually not enough. The ideal would be if the search engines would understand the semantic and allow us to search not only for the object but for a particular property for that object too. You see, properties have GUIDs just like the object itself. Even a unit like “mm” has a GUID in IFD.
Well now you sad the magic word; semantic. Isn’t there a huge overlap in what you do and what’s being done e.g. in the work around semantic web and OWL?
Not really. You see, the real work being done in IFD is the work of populating the library. Its the IFD library content that gives the value not the IFD “machine”. OWL is just another “machine” or mechanism for representing the structure. And beside that, as you know IFD is all about the GUIDs, and to my knowledge there are no OWL based initiatives out there that gives the idea of a GUID a similar role as it has in IFD. The initiatives I’ve seen has all been around the idea words and their meaning. But that sad, the content from IFD can be represented on OWL format. If someone sees the need to do just that, and are willing to do the work, their initiative will be welcomed..
But what about other industries. Isn’t there a similar initiative in the oil industry. EPISTLE or ISO 15926 or something?
Funny you mentioned EPISTLE or ISO 15926. The whole IFD initiative has always been inspired by the work being done in EPISTLE and Posc/Caesar in particular. Still there are differences. ISO 15926 is a standard not only for types of objects but also for the actual instances like the platforms being built. It has a bit of a “one standard fits all” approach. IFD and the organizations behind had a focus on the terms used to define types of concepts. After all the IFC standard was already taking care of the virtual representation of the actual building project (BIM). In the attempts of implementing parts of ISO 15926 it also became clear that the standard had a communication problem itself. At one point the ISO 15926 standard contained crazy ideas like “class_of_cause_of_beginning_of_class_of_individual”, where the individual itself is a “possible_individual” being ” ‘things that exists in space and time’. That, some political issues, and the overlap with IFC eventually led to the creation of ISO 12006-3 as a separate standard with a more limited scope. ISO 15926 is also lacking the idea of a GUID and are using local Ids and unique names instead, and the language support is mostly limited to English.
Talking about IFC. Does’t IFD overlap a lot with IFC as well?
No. I would say that IFD could be seen as a dynamic extension of IFC allowing users of IFC compliant software to standardize all of the information in a BIM, allowing us to overcome limitations in IFC on type definitions, properties and naming of elements and objects. IFC already supports ways of fully integrating and exchanging IFD information. Its actually very easy. IFD will come handy everywhere when the information exchange from a BIM relies on the naming of objects. This is the case for everything from internal object libraries to naming of rooms, wall-types and layers. “All” that needs to be done is to map those namings to it’s corresponding objects and properties in IFD. Today lots of meaningless names and properties are dumped to the IFC file resulting in “spamming” that is confusing more than helping the process.
A friend of mine once made an excellent piece of plug-in to a CAD software. In his boredom he decided to name all objects in the object library after bier brands he had been drinking. This first seemed like a brilliant idea as he would have to visit pubs regularly to complete the object library. He never though his data ever would be exchanged. Now he’s busy explaining authors of programs later in the food-chain if the environmental impact is stored on Heiniken or Delirium. Does this mean he can return to the pub if he only did the work of mapping those objects and their properties to IFD?
To your friends comfort he’s not alone. After studying various IFC files in projects I can confirm there are lots of really really odd things in there. And to your question; yes he can. I would also guess your friend is the only person able to do a correct mapping. For the receiving application the work would simply involve looking for a particular IFD id in the file. The really neat thing is that those Ids didn’t have to match 100% as IFD also know where things are specialization or generalizations of other things. If you don’t find exactly what you’re looking for you can always use IFD to get the search ids for the more generic or specialized object. In other words. You don’t need to know all fifteen ways of naming snow in Greenland. Sometimes the generic idea of snow is enough. On the other hand, when its crucial to difference between these fifteen types of snow, then its good to know you can do it even if your language limits you to name them all “snow”.
This sound all fantastic. Where can I get some more information abut IFD?
You can get lots of information on the official site at www.ifd-library.org and http://buildingsmart.com/. For technical information head for dev.ifd-library.org. And if you’re looking for help to implement IFD in your software, product library or object database, then Catenda is a safe place to start