I’m Artur Tomczak, and I represent buildingSMART International, a worldwide organisation developing and promoting open international standards and solutions for the built environment. Today, I would like to encourage you to pay closer attention to the meaning and consistency of the data being exchanged and how our service - bSDD - can help you with it.

The Problem: Lack of Alignment in AEC Projects

When designers communicate, they often send each other data in the form of geometry and parameters. Solutions like Rhino Inside and Speckle make data exchange easy, giving control and flexibility over the data. Thanks to many integrations called Connectors, Speckle is a very useful interoperability tool for designers. Support for IFC files makes Speckle useful on projects following openBIM.

There is one thing apart from the technical layer that is often a challenge on projects - that is the meaning of the data. Everything works great as long as designers understand each other and can easily recognise the objects being exchanged. However, sometimes the objects are not self-explanatory and, unless labelled properly, require designers to ask for more information. On more complex projects, such interactions are not efficient.

Let’s look at an example. We start modelling geometry in Rhino and Grasshopper using BRep geometry. Then, we transfer it to Revit, where it is represented with Generic Model elements, which would be exported to IFC as proxy elements. These don't convey much meaning, and they all use different names.

How can we keep track of their meaning?

One way would be to use, for example, Revit categories and call it Mechanical Equipment instead and apply the IfcPump name to it. That is one way, but still, we are talking about the same object but with different meanings and a different context. Sometimes, we need to add even more names and properties. I often see the challenge of adding classifications to models, which results in more and more names to describe the same objects, making it even more confusing.

The Solution: Data Dictionaries

Data dictionaries are a collection of name definitions and properties that help define the meaning and guide others on how to capture and interpret the data. This concept is not new and is popular in other industries. For example, laboratories have data dictionaries to show others how to interpret results, and NASA has a planetary system data dictionary.

bSDD is a buildingSMART solution for data dictionaries and can be considered a reference library to enrich your data with standardised terms and definitions. A great advantage of using data dictionaries is that they are reusable, as you don't need to reinvent the term each time.

bSDD Data Dictionaries

Use Cases and Benefits

Different users might get value out of bSDD:

You can watch a practical example directly from the SpeckleCon recording here:

Status and Integrations

Although the idea is not new, the bSDD is quite a new service. To date, more than 75 organisations are publishing their data dictionaries, with the most popular ones being IFC, CCI, ETIM, Uniclass, and country-specific classification systems. We also went through many pilot projects and tested bSDD in the field, as was presented at our buildingSMART conferences.

Various software integrates with bSDD, such as:

How does bSDD Fit Into the OpenBIM Landscape?

Among openBIM standards, the most known is, of course, the IFC schema, which doesn’t require much introduction. But there is more than that. Recently, we have published the IDS standards for defining information requirements that, in my opinion, already revolutionise how we ensure the quality of the BIM data. If you encounter any issues, you can report this through BCF, our standard for communication. You can also share your data through our standard openCDE API, the API protocol for communication between different software. Check out our website to find out more about openBIM solutions.

How does bSDD extend the IFC?

You might be curious why you can find the IFC dictionary in the bSDD as well. IFC, as the name implies, are foundation classes, upon which the complete dataset can be built. IFC contains more than 1000 classes and twice as many properties, but it is far from covering the full spectrum of AEC needs. Popular Uniclass has more than 15,000 classes, and ETIM has more than 16,000 properties. This doesn’t mean you need all of them to create a model, but I’m sure there was a time when you couldn’t find the term you were looking for.

The IFC schema allows users to create data from building blocks called entities and supplement those with properties either defined by the IFC standard itself, another classification standard, or the users themselves. The more standardised terms we use, the easier it is to reach true data interoperability and convey the meaning. bSDD helps you to find the definitions easily and register new terms if needed.

Final Words

Data standards are important, and here’s three reasons why:

  1. Consistent interpretation: we’re all on the same page; when relying on standard names, we reduce the chances of making errors.
  2. Automatic processing: when data agreements are standardised, computers can automatically process them.
  3. Comparison and learning: analysing data over multiple projects enables learning, discovering new patterns and improving workflows.

To wrap up, bSDD and Speckle are working together to shape a future where data isn't just exchanged—it's understood.

Join us on this transformative journey!

Subscribe to our newsletter for more content like this: