AEC Information Containers as Project APIs
AEC (still) suffers from poor data management
Seamless information exchange and data interoperability in AEC (Architecture, Engineering & Construction) is much discussed, long desired, but rarely achieved. And this is something to care about, as many of the industry’s stumbling blocks can be attributed to poor data management. This should definitely ring a bell when you think about superfluous costs, risk mishandling or insufficient insights.
In practice there are different attempts to offer a solution to this problem, which usually revolve around BIM workflows (Building Information Modelling) or more recently CDEs (Common Data Environment). So, is it only a matter of wider adoption of those technologies that will in turn increase efficiency?
As much as this can be true in certain cases, it remains only a partial solution to the problem, as important challenges remain unaddressed. Think of a simple query like “this wall in the BIM model is part of which task in the PMS (Project Management Software) and was created by which designer”. Now try to think of the last time that you were able to answer something similar on the spot… 🤔
Exactly.
So, here are some points to consider:
- AEC is a significantly document-driven industry. This means that a lot of valuable information is simply inaccessible or at best difficult to extract
- Most projects involve a variety of software that are not always very “friendly” to each other, resulting either in information loss or in lots of manual work configuring interconnections (…which are actually import-export workflows)
- BIM software are not able and not designed to ingest the complexity of all the information that is related to a contemporary AEC project
- Most commercial CDEs usually serve as a shared cloud storage for projects, with certain add-on functionalities. But this is arguably far from a really integrated project overview and coordination
A change of mindset is necessary
A common thread that connects the above dots is that AEC’s software culture is heavily based on monolithic applications that tie data, logic and interface into a single, usually opaque, package. This comes in contrast to a broader technological context (found in other domains) driven by ecosystems of apps that excel at certain things (instead of everything) and are effortlessly connected to each other, giving users the possibility to tailor their setup to their actual needs. Not to mention industries at the forefront of technology, that are highly dependent on open-source code and strong community collaboration. So, if AEC is still far from something like that, where should we start from?
Essentially, in a really interoperable and insightful AEC information environment, what is needed is:
- Unobstructed (yet regulated) access to the project data at any level of detail
- Scaleable information extraction from unstructured or semi-structured data sources
- Meaningful connections between interrelated information
- Ability to gain data-driven insights and decision assistance, by providing access to external algorithms
- Archiving the whole project in a future-proof way when needed
Project information containers and ICDD
But how to move from the current (soon to become legacy) style of work to one that abides by such requirements? As these things don’t change from one day to the other, a transition framework is into question. This is where we ‘re coming from when we engage with the topic of project information containers. More specifically, we ‘re especially interested in what is described in the ISO-21597 as “Information Containers for linked Document Delivery” (ICDD).
Here is an excerpt from its creators:
“[ICDD] defines an open and stable container format to exchange files of a heterogeneous nature to deliver, store and archive documents that describe an asset throughout its entire lifecycle. It is suitable for all parties dealing with information concerning the built environment, where there is a need to exchange multiple documents and their interrelationships, either as part of the process or as contracted deliverables. The format is intended to use resources either included in the container (such as documents) or referenced remotely (such as web resources).” source
Obviously, there might be (or will be) other similar initiatives too, but the conceptual vector of ICDD is already pointing to a fertile direction. Very briefly, using ICDD one can reference any document, any database or any legal entity involved in a project, along with their interrelations. Additionally, using identifiers, it is possible to point to any element in any file (proprietary or not), by providing the relevant directive (unique id, cell index, SQL query and more). This means that one can reference any data point in any level of detail and any relation between them. For example, if a window in the BIM model is also catalogued in a product information sheet and it is part of a task in the project schedule, or even has been laser-scanned during an as-built survey, one can make sure that these relations are formally registered in the container. One of the interesting things about ICDD is that it defines very generic concepts, which are flexible enough to accommodate different project management styles.
What’s inside an ICDD container
On the technical level, to apply ICDD to a project you need to take care of a couple of things:
- Use the predefined file structure and naming conventions
- Include the project files and the ISO resources under the respective folders
- Produce the index and linkset(s) RDF (Resource Description Framework) files
The first two requirements are trivial, but the last one can be quite cumbersome. After all, this is where all the important stuff resides. So, very briefly this is what it is about:
RDF is a data model which is based on the concept of the triple. A triple is a “statement” with three parts, namely a subject, a predicate and an object (eg. <person_01> <hasName> <John>). An RDF file is made of multiple triples, which combined together can compose a graph of connected entities.
The ICDD requires an index and one (or more) linkset RDF file. The index RDF should contain all the entities that are referenced in the project (documents, persons, organisations etc) expressed as RDF triples (eg <example.ifc> <type> <Document>). The linkset(s) RDF should include groups of links between different entities contained in the index. For example, one can create the linkset of “Floors” and add links like “Floor 1”, “Floor 2” etc, where each link is a connection of different link elements, like “these objects in the BIM model” and “this task in the project schedule” are linked to “Floor 2”.
Project API and Knowledge Graph
The end product is a complete project information container which includes all the files (local or web-sourced, proprietary or not), with all the information regarding elements and connections, expressed in an open, accessible file format, which can be represented as a graph. The latter can serve as the informational interface of the project (let’s call it project API), or as the infrastructure for advanced data analytics (let’s call it project knowledge graph).
To our minds this is quite pertinent to what is needed today in AEC. Surely, there are some challenges involved, mainly related to the process of producing the RDF files, but this is what we ‘d like to cover in the next part, by showing some real-life examples and by sketching a general framework of our approach.
The Amberg Digital Team
