For the past few months, there has been discussion within the bSI technical community to look forward at the architecture of IFC. As part of this discussion, it is important to understand that there are different components, such as:
- Description Method - including the Definition Language (UML vs. EXPRESS, etc.) and Data Formats (STEP, XML, JSON, etc.)
- Specification - including the structure and content of the schema and possible extensions like Taxonomy and Data Dictionary
- Implementation Methods - including File-based (P21-STEP, XML), Database (Relational-SQL or Triplestore-SPARQL) and even Web-based (openAPI or GraphQL).
I think to make any headway on many of the discussions recently launched in this Forum, it also helps to have everyone step back and take a broader view before launching into “…well I can make it better if you all just do it this way instead…”, especially when jumping into implementations/executions before understanding many other points of view.
There are many requirements that must be fulfilled in any case of moving the development forward. This includes, but is not limited to:
- Legacy compatibility (versioning, STEP/XML, file-based workflows, etc.) which is VERY important to existing and long time users with existing IFC files;
- Posterity, where any long-term vision (25-50-75+ years?) of development and deployment must be viable and accessible;
- Ease of use, not necessarily for everyday BIM end users, but considering modern and best practice methods for development now and debugging by completely new actors in the future, some large, some small, some less sophisticated than others;
- Flexibility, enabling schema content to expand and/or contract based on needs that have been evaluated at critical times. This may include “modularization” which helps specific stakeholders create tailored semantics, context, and content for specific market needs while still having a valid overall relationship to the general scope, semantic structure, and transactional capability of the data;
- Industry-specific, the data that the building and infrastructure domains generate is much different than much of general manufacturing, commerce, and services. There are complex relationships and many attributes that are important to capture and enable many types of transactions;
So, I ask that everyone take a deep breath and maybe step back for a moment and look at this from a higher-level before diving too deep into the debates that appear to be heating up.