Blogpost moved to blog.bimsync.com
Blogpost moved to blog.bimsync.com
In 2010 I wrote the first version of this post in an attempt to explain what bSDD (at that time it was called IFD) was and why we need it. Now 4 years later many things have changed but the reason for bSDD remains and most of the points made then are still valid. Still there is a need to freshen up the “interview” a bit to use the right naming and to include the latest updates:
I’ve heard about this 4 letter acronym under the buildingSMART umbrella called bSDD. What is it and what is it good for?
bSDD stands for “buildingSMART Data Dictionary” as well “back stabbing designated driver(*)”. The choice of acronym was perhaps not the wisest but having buildingSMART in the name at least indicates that bSDD is part of international buildingSMART effort. But despite being named “Dictionary” , bSDD is not really a dictionary. Its a structure that enables mapping of ontologies, dictionaries and other content.
Eh, the last bit made me slightly confused. Could you please elaborate?
Sure. bSDD is not a dictionary. It is a framework where multiple dictionaries, ontologies or other structures can coexist. bSDD is a bit like a “international library” Its a place where you will send a copy of your book, ontology or dictionary so that it can be indexed, categoized and mapped to other books and dictionaries in multiple languages. But bSDD is also a core component of the buildingSMART technology stack.
But how? I’m familiar with the other standards of BuildingSMART like IFC, BCF and IDM/mvdXML. Where does this bSDD 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 heard that communication is working seamlessly over the “IFC line” in some projects today.
Well, that is true, but that only working because the people communicating in these projects has agreed about the terms to use in the project up front. Sometimes they have even got the software vendors to include the terms in the libraries they are using. A type “implementers agreement”. In other words, the participants in the given projects have agreed about terms and classifications used in the given project. 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 “Babel fish” 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, bSDD 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 bSDD is meant to solve… What bSDD 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 bSDD, 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 bSDD 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 bSDD 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 bSDD GUIDs to identify her product you could use a search engine 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, some search engines did pick up the GUID and indexed 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 bSDD.
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?
I believe no. While there are places with obvious overlaps in content bSDD is a tool that makes it really simple to map content regardless of origin and format and assure that that the mapping remains available for many years to come. While OWL URIs are unique they still have a sad tendency to disappear. A quick search for OWL libraries on google will quickly bring you to a closed down server of a PHD student that has left here space at the university and perhaps taken her OWL library elsewhere or simply let it die. If that student had provided a copy of her ontology to bSDD those data would still be alive today and by the status of bSDD as a core buldingSMART component, hopefully for many years to come. And bSDD did at some time have OWL versions of its content, as well as Topic Maps that by some was considered a better format. My point is that the format doesn’t matter. Copies of bSDD already exist on multiple formats due to it’s open REST API. Just download what you need and store it in a graph, sql, spreadsheet or whatever format you like. I’m sure we will see OWL exports of bSDD data as well as SPARQL endpoints to bSDD in near future. But again it’s not about technology. It’s the provision of GUIDs and how bSDD enables an easy two way mapping of all kind of content that is the key here.
But having one international library sounds like an utopia. Is’t the whole idea of RDF and OWL that there is no need for such a thing? All you need is to have open data freely available on the web and then people can reference and link as they like and build up their own OWL libraries?
Well. Firstly, not all data is freely available and will probably never be. bSDD had to implement a “hidden layer” of information before the technology became attractive for commercial actors. The hidden layer allows content owners to decide for themselves how much of the content that should be open for everyone and how much that should be available for a closed group of members. That said. Every concept in bSDD is always be visible for everyone and can never be deleted. It’s how that concept relates to other concepts that can be hidden. This fine balance between openness and commercial relevance is harder create with technologies like OWL because of their very nature. Nothing prevents you from providing an OWL version of some part of the bSDD content sitting on a server elsewhere. That is just what the Dutch CB-NL project decided to do.
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 bSDD 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. bSDD 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 bSDD overlap a lot with IFC as well?
No. I would say that bSDD 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 bSDD information. Its actually very easy. The official IFC documentation is also linked to bSDD and all PSETs are maintained within bSDD. bSDD is 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. Most of those objects and properties are now mapped to it’s corresponding concepts in bSDD.
This sound all fantastic. Where can I get some more information abut bSDD?
If you want to have your terms standardized when using openBIM then using bSDD is the recommended way to do it. But how do you actually go ahead and implement support for bSDD in your software? I then assume you already know the API and how to get information from bSDD itself. This documents covers how information from bSDD is incorporated into a IFC BIM. How to store and exchange the information. In Norway there is a technical specification explaining how this is done but It’s only covering IFC 2×3 and is also a bit outdated with regards to naming. I have therefore created a simple figure and some explanation for how this should be done for both IFC 4 and IFC 2×3. The listings is using names from IFC 4 but with additional information about changes from IFC 2×3 below in the explanation. If you have implemented or intend to implement support for bSDD in your software then please let us know.
Is used to represent the bSDD library in an Ifc file. There should be one and only one instance with Name “bSDD”.
|Source||IfcLabel||URL or name (1)|
|Edition||IfcLabel||Language id. (2)|
|EditionDate||IfcDate||Optional date for last update (3)|
|Description||IfcText||buildingSMART Data Dictionary|
|ReferenceTokens||IfcIdentifier(list)||Not used (6)|
The classification reference is where you store the actual classification. There should be one and only one classification reference for each classification used.
|Location||IfcURIReference||Url to concept (1)|
|Identification||IfcIdentifier||The bSDD GUID (2)|
|Name||IfcLabel||The concept name (3)|
|ReferencedSource||IfcClassification||Pointer back to the source (bSDD)|
|Description||IfcText||The concept description (4)|
|Sort||IfcIdentifier||Not used for bSDD (5)|
The inverse «HasReferences» attribute is used to rebuild the structure of a classification system inside a IFC model. It’s shown on the image but is not relevant for bSDD.
Used to create the actual relationship between the classification item and the objects being classified. In this case between a bSDD GUID (with language representation) and the objects in the BIM
|GlobalId||IfcGloballyUniqueId||The guid generated from the BIM tool|
|OwnerHistory||IfcOwnerHistory||Standard ifc owner history (1)|
|RelatedObjects||IfcRoot (Set)||Objects tagged (3)|
|RelatingClassification||IfcClassificationReference||The bSDD tag (4)|
The EU commission has financed a 3-year research project called DuraArk. Catenda is the Norwegian partner.
DuraArk — short for Durable Architecture — is about long term storage of architectural information. Architectual information can be a 3D point cloud of a building or a BIM (Building Information Model) of the building. In addition to the geometry we want to store other relevant information about the building using semantic technology (buildingSmart Data Dictionary; bsDD/IFD and semantic web). The target group is both those interested in preservation of building information and the construction industry. It is easier to plan a high quality restoration or repurposing of a building with this information available.
The consortium consists of a very interesting mix of organizations and competencies. There are people there with deep knowledge of 3D analysis, of long term archival, of semantic technologies, of Building Information Modeling, and of the current practice patterns of practitioners in the industry.
Catendas main role in the project is related to System specification and integration, Semantic metadata management and enrichment, and Data acquisition, evaluation and testing.
Read more about DuraArk here