In many earlier articles I mentioned the distinction between IFC as a file and IFC as a schema. When I did this is always rendered to the STEP physical file format (SPF) with the “.ifc” file extension.
While this is the most common one there are several other ways to save your building information. Let’s have a short look into these.
.ifczip
It looks like a special file format but actually it is just a regular zip-file. As you have probably noticed when opening an IFC file in a text editor there are many parts that are repeated over and over again (you might have the term “IFCWALL” or “IFCPROPERTYSET” a few hundred times). This is something that the ZIP algorithm is very good at compressing. In an amateurish simplification it replaces repeating string pattern by a short unique “key”, saves the pattern with the key in a separate “table” and reconstructs this during the unzipping process. Depending on your file this can reduce your model by up to 90%. Many people don’t want to agree on this but most part of a building are just repetitive elements with slight deviations. So zipping works fine here. In fact, however, this is just a SPF file.
.ifcXML
A STEP file requires the parser (the “reader” of the file, either human or an algorithm) to know the order and meaning of attributes of specific IFC-classes. While this is efficient in terms of data storage it makes it harder to “make sense” of the data. You always have to look things up in the schema or use special libraries. An ifcXML file solves this problem by wrapping all the data into its “meaning”. Therefore you explicitly see what your GlobalId, Description or NominalValue is. The downside is that this adds a lot of overhead to your file (as you always have opening and closing tags for classes and attributes). So there’s more to ready but it’s easier to understand.
.ifcJson
Json files work similar to XML files. The difference is that there are no wrapping tags but “keys” that tell the meaning of an attribute. There is always a key/value pair, like “‘Description’: ‘Wall_Concrete_200′”. References to other entities are given by their GlobalId. Everything that is not a class derived from IfcRoot (and therefore has not GlobalId) is nested into this key/value structure. Json is a file format well understood by many programmers and bit more efficient than XML in terms of data storage. However ist shares the same “problem”: in an SPF you can reuse non-rooted entities (like geometries or properties), in XML or Json you can not. In an IFC file – theoretically – you have to define the property “IsLoadBearing: true” only in one line and could reuse is for all your load bearing elements, even in different property sets. In Json or XML you cannot use this “trick”.
.rdf
If you look at the IFC schema you will recognize that there are mainly two types of classes – “stuff” and “relationships between stuff”. You could also say that some classes are like nouns and some are like verbs. E.g. a wall has a property set, or a window sits in an opening. In these examples wall, property set, window and opening are “nodes”; “has a” and “sits in” are connections. This kind of data triples can be represented in an rdf (Resource Description Framework) file. Not quite efficiently though as it consumes about 8 times the storage of your SPF IFC models (and those can get large pretty fast).
Other formats
There are some other, less known ways to store model data, for example .hdf (Hierarchical Data Format), a relational database (see IfcSql), or new initiatives unrelated to buildingSmart like .bim or .bimjson. One of the important aspects of openBIM however is an open and easy to read file format, which basically means a text file. SPF, ifcXML, ifcJson and RDF are actually structured text file; HDF or SQL are not. The ZIP algorithm is pretty much universal, but who knows, maybe we will forget how to decompress those at one point in the future. A text file is guaranteed to be supported by computer / operating systems for decades to come.
The choice is yours – so choose wisely (at the point if writing, SPF and ifczip will probably make up for more than 99% of the exchanged models).