Building Information Modeling (BIM) has been gaining more acceptance outside of the traditional built environment. The U.S. transportation industry has recently adopted IFC as the standard data schema for the exchange of electronic engineering data. This is significant because the transportation agencies are progressing toward BIM as the successor to the standard plan set for highway infrastructure. Unfortunately, as previous studies indicate, IFC is currently limited in modeling the full capacity of bridges and infrastructure data exchange. Utilizing IFC P-Sets and ontology models have been the current workaround to enable the full information exchange. The challenge with properly modeling such ontologies is that the breadth of knowledge needing to be captured, from all the stakeholder perspectives and all bridge and infrastructure elements, is a large undertaking without the direct support from the industry. Additionally, each state agency has their own processes, terminology, and culture that further complicate the challenge. To mitigate these challenges, research has been ongoing to create a national data dictionary to support current US national eforts and promote alignment across the various state agencies. This paper presents an overview of the research and the methodology in creating a bridge and infrastructure data dictionary. Current limitations and open challenges are presented. As this work is still ongoing, the goal is to continue the development of the data dictionary in a collaborative efort to ensure that it can be extended to include other transportation structures.
Building Information Modeling (BIM) has been gaining more acceptance outside of the traditional
vertical building environment and has been on the rise in the transportation industry [
ceur-ws.org
ISSN1613-0073
industry wide adoption. Since each of the 50 states oversee and govern their own transportation
infrastructure, it has been dificult to implement one national standard. Recently, the U.S.
transportation industry, under the American Association of State Highway and Transportation
Oficials (AASHTO), has adopted the industry foundation classes (IFC) as the standard data
schema for the exchange of electronic engineering data [
Since inception, IFC has been mainly defined for the traditional building design. The success
of IFC has led to addition eforts to expand to other infrastructure, including bridges, roads,
rail, and tunnels. Even with these expansion eforts, there are still challenges and limitations to
contain every aspect of each of these structure types. For example, IFC 4.3 only has the following
bridge parts: ABUTMENT, DECK, DECK_SEGMENT, FOUNDATION, PIER, PIER_SEGMENT,
PYLON, SUBSTRUCTURE, SUPERSTRUCTURE, and SURFACESTRUCTURE. There are many
more parts of the bridge that need to be defined. IFC also has limited property sets to fully
support the bridge descriptions, and these mainly focus on bridge design. It is infeasible to
model every property into the IFC schema, so the utilization of property sets (P-Sets) have
been the way to exchange these data. Furthermore, since IFC is inflexible for representing
unsupported domains and has a slow approval process for extensions, using IFC as the sole
model for bridge representations will remain impractical [
Regardless of the method of data exchange, the real-world knowledge must first be defined
in order to model it. Unfortunately, this proves to be dificult since those who are experts in
software development do not often have the full breadth of knowledge of the industry; likewise,
those with the breadth of knowledge of the industry (i.e., industry experts) do not typically
possess the skills to encode their knowledge [
The aim of this research is to create a bridge and infrastructure data dictionary to support
the current eforts integrating BIM and IFC into U.S. state transportation agencies. The method
utilizes a modified IDM approach that enables industry to directly input their knowledge into a
data dictionary, which could them be implemented into an ontology [
dictionary.
Expanding IFC to include other structure types has been in the works for a few years. The upcoming release of IFC 4.33 includes multiple civil infrastructure updates such as IfcRoad, IfcRail, IfcTrack, IfcGeotechnicalElement, and IfcEarthworksElement, to name a few. IfcCivilElement has been depreciated due to the inclusion of specific subtypes added under IfcBuiltElement, IfcEarthworksElement, IfcFacility, and IfcGeotechnicalElement. IfcBuildingElement has been renamed to IfcBuiltElement to be more inclusive of other structure types included in the updated release. One major issue with the current IFC 4.3 bridge extension is the defining of the spatial relationships of the bridge components, and how best to describe these in IFC is an ongoing debate. For example, bridge superstructure and substructure can be defined as the spatial container ContainsElements since it is a classification of how a bridge is decomposed, but it is not an element in and of itself (this can be synonymous to a building storey). However, superstructure and substructure are listed as enumerations of IfcBridgePartTypeEnum. Another case is a bridge pier (or bent), which is also listed as a bridge IfcBridgePartTypeEnum. Functionally, a pier can be viewed as a single element that is used to support the bridge deck, but in reality, a pier is composed of one or more columns, a pier cap, and foundation, which are each engineered and modeled as a separate element. Thus, a pier can be either treated as a spatial container or an assembly, but not as a part or element. One reason behind the challenge of organizing bridge component relationships in a consistent fashion is the lack of a national classification system, such as Onmiclass, MasterFormat, and UniFormat4 that provide the standards in the building industry. What amplifies the bridge classification issue is that each of the 50 US State transportation agencies have their own bridge classification system. Thus, the need for a single classification system is a major motivation of this research.
Outside of the IFC standard development, there is other research that are proposed expansions
to the IFC schema. For example, [
Semantic and ontological approaches for infrastructure have also been on the rise [
This research stemmed from the lineage of BIM for transportation eforts investigating digital
delivery of bridge projects[21]. Previous methodologies enabling BIM-based information
exchanges, namely the U.S. National BIM Standard (NBIMS), focused solely on IFC as the final
output. Since IFC could not support non-building structures at that time, a new
methodology for industry-defined information exchanges was developed that enabled the output to be
ontological based, meaning the industry knowledge captured could then be mapped to any
schema[
The BrDD was first developed by the preliminary work seeking information exchange standard for bridges[23]. The BrDD was a collection of bridge terms needed for design, construction, and operation. The process of developing the data dictionary started with examining an early bridge design and load rating software called Opis/Virtis. A gap analysis identified the lack of important data dictionary items related to roadway alignment, erection analysis and concrete detailing. The data dictionary was later expanded by adding missing data items by thoroughly examining contract drawings, the NYSDOT bridge design manual, and other existing data schemas for buildings.
Although not fully complete, the BrDD was the basis of the first developments of information
delivery manuals (IDMs) for steel bridge erection[
The work conducted by TG15 was used in transportation pooled fund study TPF-5(372) “BIM for Bridges and Structures” which was established to implement, test, and demonstrate the use of IFC for bridge information exchange to facilitate highway bridge project delivery8. TG15 continued to supply the data requirements needed for the development of the for Bridge Design 6https://www.aisc.org/nsba/design-and-estimation-resources/aashto-nsba-collaboration/ 7The scope was steel bridges, but these exchanges were also reviewed for concrete bridge types 8https://bimforbridgesus.com/ to Fabrication model view definition (MVD). The purpose of this MVD was to contain the subset if IFC entities needed for all bridge types, and TG15 supplied the data required by the fabricator and detailer to complete their scope of work to fabricate the structural steel. This project was broken down into two major phases. Phase 1 was to produce the “IDM for Steel Bridge Detailing and Fabrication” that contains all the exchange requirements in the BrDD, as shown in Figure 1 (M=Mandatory, O=Optional, N=Not Needed). Phase 2 (which is currently ongoing) involved the mapping of the BrDD requirements into IFC. Throughout these developments, the BrDD content has been continually updated and modified (e.g., adding or removing terms). However, the organization of the hierarchy structure remained the same.
Needless to say, the BrDD has been serving as the source of truth for various US developments and will be the basis in the TPF-5(480) “BIM for Infrastructure” project. In addition to IFC, other buildingSMART products9 are being explored including buildingSMART Data Dictionary (bSDD), Information Delivery Specification (IDS), and the BIM Collaboration Format (BCF). The BrDD uses Excel (.xlsx) for convenience since it is well known and easy to use by the industry domain experts. However, Excel has technical limitations in creating a formal data dictionary. First, the BrDD is limited to only 4 columns to represent the hierarchical relationships (Information Groups, Information Items, Attribute Sets, Attribute). This is by design since it captured the functionality of BIM software; however, this causes issues since some relationships needed more than 4 columns to fully map the hierarchical relationships. Second, the organization of the data is based on project timeline and not in a logical fashion for an ontology development. This causes issues such as data duplication, missing relationships, and the mixture of data types (classes, properties, attributes, etc.). Third, there is no easy or eficient way to reorganize the data (e.g., a row needs to be added/deleted to move a property). Manual manipulation takes much needed time and has resulted in errors that were later found and corrected. Fourth, there is no method of linking terms and common property sets (i.e. no modularity). This causes confusion since related items were in various locations, which has resulted in the addition of duplicate data and annotations of linkages. Additionally, with the same property set located in various locations, each will simultaneously need to be changed if any changes are required. Fifth, the sheer size of the data (nearly 3000 lines) makes it dificult to navigate and comprehend. Other non-technical issues include the lack of definitions, the use of acronyms instead of the full words, and elements that could be better placed elsewhere.
Because of these challenges, it has been determined that the BrDD needs to be represented in a diferent format. Since the TPF projects are main drivers, the end goal is to populate the bSDD to enhance the IFC MVDs being developed, as well as support other US national eforts related to BIM for infrastructure. Before this can happen, the current BrDD must be reorganized. Since the BrDD was intended to identify exchange requirements, it was never intended to be structured as an ontology. Figure 2 is a subset of data modeled directly from the BrDD. As
can be seen, the organization and nomenclature are not proper organization for ontologies or spatial relationships. The organization incorrectly shows that “Element_Details”, “Contract”, and “Approach_Substructure” are all subclasses of “Bridge.”
The BrDD needs to be reorganized in order to provide functionality and usability for the ongoing US National eforts. Two main structures of organization will be created based on spatial relationships and functionality. The first structure will be an ontology in .owl to map the spatial relationships, which is the typical method of creating a parent-child hierarchy. An ontology also allows for better organizing and managing the data. The second structure will be a knowledge graph in UML that will provide functionally for the end users. Figure 4 displays a bridge design software that has components ordered in a functional way to enable eficient design. Since there is no national bridge classification system, this knowledge graph will enable consistency in the industry. Both structures will be supported by a formal data dictionary developed in the bSDD.
The methodology of organizing the BrDD is shown in figure 4. The first task is to identify the
classification of each term in order to classify it as a class (e.g., modeled element) or a property.
This is important to provide the basis of the bridge component relationships. The second task
is to review the current US Bridge Standards in order to 1) create the spatial classifications
needed for the ontology, 2) aggregate definitions and metadata needed to classify each term
and usage, and 3) create the functional relationships needed for the knowledge graph. In the
ontology development, the existing ontologies previously described (e.g., ASB-ING Ontology,
BROT) will be reviewed and utilized. As mentioned by [
A preliminary ontology has been developed in Protégé to begin the organization of the spatial components of the BrDD. The first step of the procedure is to adjust the BrDD spreadsheets so that the structure could be easily inserted into the system. Then a set of transformation rules using the .json format (JavaScript Object Notation) have been developed to convert the data from the spreadsheet to Protégé, as shown in Figure 5.
Developing an ontology directly from the BrDD is dificult and overwhelming due to sheer number of elements. Thus, the .owl file is first focusing on the major structural items and will continue to be expanded with the additional items and relationships. The current scope is the super structure and sub structure of a bridge. Is important to get the main structural entities defined so we can establish the entity relationships of the properties.
The data on the spreadsheets collected from the specialists was structured in: Information Group, Entity, Property, and Property set. So, the information groups and entities were defined as classes and subclasses, respectively. For example, BridgeSubstructure has the subclasses PierWall, Pile, Footing, Pedestal, PierColumn, etc. The properties and property sets were defined as data properties and sub properties. Therefore, a property such as HasFootingDepth will be a sub property of the group HasDimensions. The domain of HasFootingDepth will be the class Footing, which by itself is a subclass of BridgeSubstructure. As for the range, HasFootingDepth will have the range Real. In other words, this means that a bridge substructure will have Footing, and Footing element will have dimensions, of which one of them is its depth, and it can be expressed as a real number.
In some cases, some elements in the BrDD had multiple names or synonyms (for example Crash Wall and Pier Wall both represent the same element), so they were asserted as equivalent. This is quite important since some professionals will know them by either of those names, but not necessarily by both.
There are a few challenges in the current BrDD spreadsheet that were able to be remediated through the use of the ontology, namely the eficiency of the organization, ability to only define properties once and then link, and not being constrain to 4 levels of hierarchy. However, a few more were revealed during the ontology development that are discussed below.
The first challenge is how best to organize the data. The current structure of the BrDD is ordered in the timeline of the bridge life cycle. For example, the first information groups relate to the bridge project, then roadway design, bridge planning, design, structure, construction etc. This makes reviewing the data and assigning exchange requirements by industry simple and straight forward. However, this presents a logical challenge. Should it be based on the current IFC schema? Should it be based on the geometric elements (girders, columns, deck, etc.)? Should it be based on how it will be used? For example, the AASHTO Manual for Bridge Element Inspection bases its organization on bridge inspection [24]. The organization is still in process, but the BrDD is focusing on the structural elements first. The use of two structures, the ontology for spatial and knowledge graph for functionality, will help solve this challenge. It is envisioned that once the ontology, data dictionary, and knowledge graph are fully mapped, additional converters will enable the reorganization of information to suit a specific need for the final usage (although this may provide additional burdens).
The second challenge is determining when various information groups should be formed as a separate data set instead of being listed multiple times (e.g., modularity). The BrDD has multiple duplicates and redundancies. For example, all structural components (girder, deck, column) contain common connection details (plates, welds, bolt assemblies, etc.), and each component currently has some degree of these connection details (meaning that there are duplicate data ifelds). The current BrDD also has an element detail information group, which contains all the information regarding connection details. Should connection details be their own property set, or should they stay under the current structural components? To further complicate the challenge, there are many similar items that have similar property sets. For example, in the element details group, there are many types of plates, including bent plates, fill plates, gusset plates, splice plates, and cover plates. Each plate has similar properties (e.g, bolt holes, material, layout, etc.), but have completely diferent functions in the field. Should they be groups as “plates” or should they be grouped based on the functionality? In the current ontology development, one assumption is that if there are any identical property sets under names, the groups will be combined with an added field that chooses between the two. For example, a girder can have a top and bottom flange. Since the flange has the same properties regardless of if it is a top or bottom, the groups were combined into a “flange” property set and a new field was created that enabled the selection of “top or bottom”. Reviewing current existing ontologies and developing the ontology in modules will alleviate this challenge.
The third challenge involves the storing of the data requirements. Although this is not a technical challenge directly related to ontologies, it still is relevant in the creation of information exchanges needed to support the current BIM for bridges and infrastructure eforts. In the BrDD, the exchange requirements were captured directly in the sheets as new columns. This is ifne for one use case, but since there are many use cases throughout the bridge life cycle, it will be infeasible to contain all of these in the same workbook. Currently, multiple workbooks have been created which is a major issue since they need to be continuously consolidated to ensure that all of the data properties are the same when changes are made. Neither Protégé nor the bSDD have an eficient way to capture each exchange requirements. Other methods will be investigated, such as the Information Delivery Specifications (IDS) 10.
The fourth challenge is the automaton of adding the classes as the domain for the properties in Protégé. It currently is done manually for some properties to test the concept, since Protégé does not allow for that sort of automation. Furthermore, the Excel to Protégé export only works one way, so there is still a need to export the ontology back to the Excel so, if for example, any changes are made in Protégé, the user could re-export that data back to a spreadsheet format. Since the current BrDD Excel is a requirement of the current US eforts, it is important that this still be used as the source of truth. Until the entire BrDD is mapped into a new format, the BrDD in Excel will continue being used. Protégé allows for export to .csv (Comma Separate Values) format, but in the process the data is unstructured, and a lot of information could be lost. A separate software program is currently being developed to enable the bidirectional exchange. The software enables an import/export function, a drag and drop function to eficiently reorganize the data, as well as the ability to add new data, delete data, and add comments.
The development of a bridge and infrastructure data dictionary is essential to serve as the source of truth for the current and upcoming U.S. National research projects implementing BIM and IFC for Bridges and infrastructure. Currently, not every data requirement can (or will need) to be mapped into IFC, so a data dictionary is needed to capture other classifications and properties. Currently, there is a spreadsheet of bridge terms, the Bridge Data Dictionary (BrDD), that contains most of the bridge related terminology and property relationships. Due to the limitation of Excel, various methods are being explored to determine which could be the most eficient to model the ontology, including the web ontology language (OWL) and the buildingSMART Data Dictionary (bSDD). A preliminary ontology has been developed in Protégé, but also contains limitations. A software editor is being developed to make the development and management of the ontology, data dictionary, and knowledge graph more eficient.
Various challenges have been discovered that currently prevent an eficient way to fully map the BrDD Excel into an ontology to better manage and manipulate the data. These open challenges are needing to be solved to automate the current manual eforts. This research is still in the infancy regarding the data dictionary and ontology development, so additional representations and methods will be explored. The buildingSMART USA chapter will oversee the bSDD development as part of the current transportation pooled fund (TPF) projects. Finally, the current BrDD only contains bridge terms and there is a need for more collaboration to include other infrastructure.
The authors would like to thank the buildingSMART USA chapter Data Dictionary Working Group for their eforts in this research, including Joseph Brenner, David Dexter, and Jefrey Ouellette. 10https://www.buildingsmart.org/standards/bsi-standards/information-delivery-specifications-ids/ [17] M. H. Rasmussen, M. Lefrançois, G. F. Schneider, P. Pauwels, Bot: The building topology ontology of the w3c linked building data group, Semantic Web 12 (2021) 143–161. [18] A. Göbels, J. Beetz, Conversion of legacy domain models into ontologies for infrastructure maintenance, in: Proceedings of the 9th Linked Data in Architecture and Construction Workshop-LDAC, volume 3081, 2021, p. 12. [19] A. S. Bundesministerium für Verkehr, Bau-und Stadtentwicklung, Anweisung straßeninformationsbank segment bauwerksdaten–asb-ing, 2013. [20] A. Göbels, Enabling object-based documentation of existing bridge inspection data using linked data, in: Proceedings of 33. Forum Bauinformatik, 2022. [21] A. Costin, H. Hu, R. Medlock, Building information modeling for bridges and structures: Outcomes and lessons learned from the steel bridge industry, Transportation Research Record 2675 (2021) 576–586. [22] A. M. Costin, C. Eastman, Requirements for ontology development in the aeco industry, in: Lean and Computing in Construction Congress (LC3): Volume I Ð Proceedings of the Joint Conference on Computing in Construction (JC3), 2017, pp. 533–54. [23] S. S. Chen, H. Hu, N. Ali, R. Srikonda, Bridge Data File Protocols for Interoperability and Life Cycle Management-Volume II: Information Delivery Manual Elements for Highway Bridge Interoperable Data Protocols, Technical Report, United States. Federal Highway Administration. Ofice of Infrastructure, 2013. [24] A. A. of State Highway, T. O. (AASHTO), Manual for bridge element inspection, American Association of State Highway and Transportation Oficials (AASHTO, 2019.