IFC R2.0 Implementers agreements

Traditionally implementers agreements have been made whenever the IFC model is too ambiguous. These agreements don't usually change the IFC model itself, they only clarify the use of the model. The IFCs have for example a very generic geometry model and often implementers agreements are needed to give some semantics to the generic geometry objects.

Another field for implementers agreements is the scope of implementations, the model views and concept blocks. Programs that are on either the sending or receiving end of a use case (e.g. Arch. Design -> Quantity takeoff) have to support the same subset of the model. If a quantity takeoff application relies on the construction type of walls to make the takeoff and the arch. design application is not able to provide this information, then the data exchange is obviously not working. There is need to come to an agreement about the subset of the model that is used in each supported real life exchange scenario.

In the BLIS -project we combine the definition of these two types of agreements in the concept block documentation. The views and concept blocks define the scope of the implementation, and the concept blocks documentation also contains the implementation details - which is roughly equivalent to the traditional implementers agreements.

The concept block documentation has these parts

1. The data structure lists the supported attributes and related concepts. This is a 'filter' that is put on top of the full IFC model and it shows only the parts of the IFC model that need to be supported. This section contains links back to the full IFC model.
2. The semantic definition of the concept block explains the concept and tells how it should be used.
3. Implementation diagrams can show a larger area of the model than a single concept (e.g. the project, site, building and building storey relationships), instructions about how to use the geometry or other relevant information.
4. Additional documents contain in depth analysis of parts of the model and give the background for decisions made regarding the views and concepts.

With all this documentation that is relevant to the implementations it is difficult to make one 'flat' list of implementers agreements. In fact, the structure of the current documentation comes from the realization, that the format used for the IFC R1.5.1 agreements was inadequate for the task. We will attempt to make a list of the most important agreements, but the concept block documentation will remain the most comprehensive source of implementation information. The list of agreements will be more like a 'report' from this main documentation.