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
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.