This article aims to clarify the differences and relationships between the IFC schema, IFC MVDs and IFC files. We will use similar concepts from the “books and library” domain to exemplify and compare to our AEC domain. If you are on either side of an “information exchange requirement” this distinction is important. We all need to understand this better and the concepts need to evolve (or be replaced) in our industry for the promise of “lifecycle BIM” to become real.
The post is written as a follow up to an blog article published by BIM Strategy last week called “the existential crisis of BIM”. After an having an “eureka” moment the author presents the analogy of libraries and books to describe the IFC schema, IFC MVDs and IFC files. I felt a bit puzzled by parts of the explanation and therefore will try here to offer an alternative/ supplemental explanation using the same domain. This is our take on using libraries and books as analogs to IFC Schema, IFC MVDs and IFC files.
The Schema
The schema is the conceptual model describing the “things” in your domain, how their characteristics are described and how those things are related to each other. For the “books and libraries” domain the “things” are books, chapters, paragraphs, authors, pages, editions etc. Relationship examples are “books are written by one or more authors ”, “libraries contain books” and “chapters belong to books”. Properties of a book are title, number of pages, author, category, isbn number etc.
For an example of a domain schema for books see image below.
You will see that the book have many common properties that is shared with the broader term creative work, but also some items specific to the book. Also many of the properties of the book are in fact entities (other things) of their own - an author is a person or an organisation and thus relationships are formed (image of the person schema below).
The schema itself do not concern itself with or mention specific books or libraries. They are just a model to understand and later describe this domain. The closest the schema is in being specific is in describing category values for some properties. E.g a book genre is a list of possible values. Broad distinctions - “fiction or nonfiction” or more specific categories like thrillers, romances, etc. If the categories become very detailed and are hosted outside the schema itself they are considered classification systems (like the dewey decimal classification system in use in public libraries to arrange books according to categories).
For this first part it should be easy to transfer the concepts into our domain. Instead of books with chapters and paragraphs we have buildings with floors and rooms. Instead of authors, number of pages and fiction categories we have load bearing capacity, finishing materials and rotations per minute. Instead of the dewey decimal system we have omniclass and uniclass.
The MVDs (Model View Definitions)
But how do we describe the model view definition? As the domain is different there is no 1:1 comparison.But we can find plenty of examples of model view definitions in this domain as well. Remember an MVD is a smart filter, a subset of the schema and an information exchange requirement.
Let's start with describing the need to standardize formats and contents. When multiple writers want to write a book together they need to agree on some common terms, contents and formats. They need to agree what parts to write and how to merge and unify their work. An editor that wants to see that they are on the right track need to merge their work along the way and give feedback on direction and progress. Using open formats the writers can use their editors of choice and save to the agreed format as shown in the image below.
This part of the “book” domain exemplifies the use of open standards as exchange requirements. However we have not covered the “smart filter” part of the MVD yet. Let's explore further.
When books are finished the data about the books will be used by a number of parties. Bookstores, online merchants and public libraries will use both the contents and the metadata of the book to promote, sell, locate and deliver it. To automate the process of updating their databases they will define different exchange requirements that will be subsets of the domain model. Libraries want isbn, title, category, summary etc. An online bookstore needs similar info. Some info may be overlapping with the libraries requirement, but some will also come in additionally, e.g pictures of the front and back cover of the book. For other use cases there are other requirements. E. g. when updating stock from sellers they only need to know the number of books (if new), the condition, & price (if used), the delivery time and a reference to the book already in the database (e.g. the isbn or sku number.)
Here is an example of an amazon.com spreadsheet template to load data about books for sale into the amazon online bookstore. In addition to this sheet to be filled out the workbook consists of instructions for use, data definitions and valid values for use in pick lists and validation. Looks very similar to COBie, right? One of the most capable cloud computing and transactional companies in the world are providing this “dumb” format to allow smaller vendors and private persons with limited resources and limited use a low threshold way to contribute. Amazon do of course also have alternative way for 3rd parties to update their registers using the same structure and content but using different formats (e.g. xml data transfers and restful APIs).
Above is another standard spreadsheet form from Amazon. When updating the stock supply there is no need to add much info about the book. Just use a unique pointer to an existing book and add the data to be added or changed.
The file
In the books and libraries domain the actual information that is exchanged between applications and databases are the exported word processing files, the audiobook sound-files or the filled-in book inventory templates. To be a proper Amazon Book Loader file the spreadsheet need to conform with the Amazon template, with valid information in all the required fields. The actual file is not just a spreadsheet file (conforming to the excel format specification) or just an Amazon spreadsheet file (using the Amazon data model).
These are comparable to our model exports that are not just generic spreadsheets/text files or files based on the IFC data model. They also conform to one of the IFC model view definitions, e.g “design transfer”, “reference view”, “structural analysis” or “COBie”
Summing up
We have covered just a couple examples of exchange requirements in this other domain. The main concept is that at different stages of the book project and for different actors different data are needed. A translator need the original text in the original language, An editor needs the drafts in a common format, a library need basic information about the book, an online seller needs a way to track inventory. If the book industry agrees on a shared format and shared interfaces the cost of writing and promoting books go down as it does for running and operating bookstores and libraries.
Similarly the use of the IFC schema let distributed teams work on distributed building models. Proper use of MVDs let the parties assemble (federate or merge) distributed models into unified models on demand. Similarly model parts can be “deconstructed” by other team members downstream for their specific needs, e.g energy analysis. Their needs are defined as exchange requirements based on other MVDs.
Our industry do have the platform for a common schema and a way to define exchange requirements. Some exchange requirements are implemented some are not. Some of the implemented ones are in use, some are not. If something fails upstream in the process it's hard or impossible to catch up later. If you do not get the proper information from design, product install and handover it is hard to do post-occupancy energy review or lifecycle cost modelling and maintenance planning. This will be a topic we will come back to, using the MVDs and their state of implementation and use to describe the gaps in lifecycle BIM.
Another follow up topic is how the MVD concept will need to evolve as the BIM world is moving towards level 3. Then the exchanges become more transactional upstream and query-based downstream. Are we ready for such a world?
If you are interested to follow this journey feel free to sign up for our newsletter and we will keep you posted on our progress.
If this post was unclear or you are of a different opinion, feel free to post comments here or on twitter and we will be happy to discuss and be open to different opinions and points of view
