COBie Data Structure – BIM Academy: Learning and Development

Now that we have an understanding of how COBie is structured and where it is used, we can explore what is inside COBie in more detail.

If we think a little bit more about it, the underlying challenge that COBie wants to address is a communication problem.

On projects where there is not a well-defined approach for structuring data, it is likely that some bits of information will be lost at each information exchange.

The people who invented COBie wanted to find out how we can best record information on maintainable assets for future reference.

The problem of recording information is not a new one.

One of the simplest ways to record information is in a list.

For example, let’s say we want to keep a record of the photos that were taken on every holiday moving forward.

How could we structure this list in an efficient way?

So, first, we could create a list of the photos from our last trips in a table.

We could then sort these photos out alphabetically, so that if we want to find the photo that shows the ‘Eiffel Tower’ we know that it is going to be near the top of the list.

But what if we want to see all the other photos taken in Paris?

It could take a long time to scan through a list with hundreds of photos, and we could miss one or two entries in the process.

So maybe, instead of creating a list that records only the names of the places shown in the pictures, we could also include the city and country where this photo has been taken.

Now, if want to find all the photos taken in France, we can easily filter the information in the table.

If we want to be more specific and see photos taken in Paris, this is also possible.

We could add more information to each photo.

What if we want to know when the photo was taken?

What if we want to know what people were in the photo?

Easy, we just need to add these attributes as a vertical column and record every new photo as a horizontal row.

We can see that if we record the information in this way, we have a lot of flexibility to filter the photos we want.

We can create many groups and subgroups.

We could for instance do a search for all the photos taken of Andrew in Spain, or also include the photos taken in Paris in this search.

However, we can see that in this table the same information is being stored many times.

This is inefficient, imagine if we could only use a limited number of characters to record all this information? What could we do in this case?

The best way to deal with this redundant information, in this case, is to break the table up into multiple tables.

Each table has its own specific information. For example, Table 1 has information about the photo, Table 2 has information about cities, Table 5 has information about people.

The information that links all these tables is the unique numeric codes that we use for each entry represented by the horizontal row.

Organising data in this way is flexible and efficient. What I have just shown you is called a ‘relational database’.

A relational database describes a collection of data items and the relationship between them.

You might be wondering why I just told you all that. I have told you all that because, in technical terms, COBie can be described as a relational database.

You will see that COBie follows this structure to record data about the maintainable assets in a building.

When we open COBie information that has been created in an excel file, we see a table with a number of tabs.

Each of these tabs directs us to different tables.

Remember, in a relational database different tables are used to record a specific type of information about something.

In the case of COBie, we want to record information about the maintainable assets of a building.