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 [1]. Similarly to the U.S. National BIM Standard, there has been a significant push in the US to define a national BIM for bridges standard since the early 2000's. Many research projects have been funded to investigate the development, utilization, and implementation of BIM into state transportation agencies. A few schemas to promote the exchange of transportation data have been developed, including TransXML, LandXML, and OpenBrIM, but have not obtained industry wide adoption. Since each of the 50 states oversee and govern their own transportation infrastructure, it has been difficult to implement one national standard. Recently, the U.S. transportation industry, under the American Association of State Highway and Transportation Officials (AASHTO), has adopted the industry foundation classes (IFC) as the standard data schema for the exchange of electronic engineering data [2] and has developed a BIM National Strategic Work Plan [3]. This is significant because it shows that the state transportation agencies are progressing toward BIM as the successor to the standard plan set for transportation infrastructure. As part of the progression and adoption, there have been significant U.S. national projects aimed at integrating BIM and IFC into transportation workflows, namely the TPF-5(372) "BIM for Bridges and Structures" 1 and the recent TPF-5(480) "BIM for Infrastructure" 2 .
Since inception, IFC has been mainly defined for the traditional building design. The success of IFC has led to addition efforts to expand to other infrastructure, including bridges, roads, rail, and tunnels. Even with these expansion efforts, 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 [4]. Thus, the utilization of ontological and linked data approaches, due to modularity and flexibility, have been on the rise.
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 difficult 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 [5]. Thus presents the gap between true industry knowledge and its encoding. Methods to obtain industry knowledge do exists in the forms of information delivery manuals (IDM) [5], Information Delivery Specification (IDS) [6], and Collaborative Ontology Engineering [7], which are all driven by the client or industry.
The aim of this research is to create a bridge and infrastructure data dictionary to support the current efforts 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 [8]. Although there are existing ontologies for bridges [9,10,11,12], these do not contain the level of detail needed for full bridge information exchange needed for the multiple stakeholders at the various stages of the bridge life cycle. This research currently utilizes an Excel (.xlsx) spreadsheet of bridge software terms called the BrDD Data Dictionary (BrDD). The purpose of the BrDD is to serve as the source of truth for the various transportation projects in the U.S. to maintain alignment. Furthermore, the BrDD Excel has been the basis in the creation of a formal bridge and infrastructure data 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, [13] is expanding IFC to include finite element analysis (FEA) of bridge substructures and soil-structure interactions. [14] proposes a three-dimensional (3D) alignment expansion for railways. Still, these expansions do not really model the full properties of a bridge an infrastructure domain. Thus, to help expand digital exchange to domains and classifications not described in IFC, the buildingSMART Data Dictionary (bSDD) 5 provides the ability for users to define and host their own classifications and properties. This open-source service enables the ability to define custom properties as well as reference to the current IFC 4.3 schema. Although the bSDD provides needed flexibility and expansion, there is no oversight for data quality and control (outside of guidelines and best practices), which ultimately places this responsibility on the data owners and managers.
Semantic and ontological approaches for infrastructure have also been on the rise [15,16]. Specifically relating to bridges, [9] propose the bridge maintenance ontology, BrMontology. Based on the "Code for Technical Condition Evaluation of Highway Bridge", BrMontolgy covers bridge evaluation standards, maintenance code, required materials, cost, and the selection of supplier. The ontology is structured monolithically and without the bridge components structured in superclasses, in which [4] note that this can cause complications with extensions and querying. Thus, [4] propose the Bridge Topology Ontology (BROT), which is is core ontology for bridge representations modeled after the SIB-Bauwerke data. BROT extends Building Topology Ontology (BOT) [17] and contains the following extensions: Bridge Components Ontology (BRCOMP), Building Material Ontology (BMAT), Bridge Structure Ontology (BRSTR), and Bridge Classification Ontology (BRIDGE). [4] also includes alignments to ifcOWL, although the IfcBuilding and IfcBuildingElement mappings no not correlate with the IFC 4.3 ifcBridge extension, which would be ifcBridge and IfcBridgePart, respectively. Nevertheless, BROT provides a good starting point of a bridge and infrastructure ontology, especially since the modularity aspect of BROT makes extension more efficient. An ontology for bridge inspection (ASB-ING Ontology) [18] has been created based on the German road and bridge data model Anweisung Straßeninformationsbank -Teilsystem Bauwerksdaten (ASB-ING) [19]. The ASB-ING Ontology contains 120 classes, 80 datatype definitions, and 500 properties. This work has been further enhanced by an automatic conversion process of converting the SIB-Bauwerke datasets into RDF graphs [18] and automatic transformation of the existing inspection data from SIB-Bauwerke into an object-oriented structure [20]. The authors propose that the next step for the ASB-ING Ontology will be to map to other relevant ontologies and structures, including BOT, BROT, and ifcOWL.
This research stemmed from the lineage of BIM for transportation efforts 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 [8,22]. Thus, information exchange development was no longer limited to building structures. In addition, a significant aspect of this method is that it could enabled direct industry involvement since it didn't require software or coding knowledge (most efforts at that time required significant computing and IFC knowledge). The development of process maps and the the organization of the domain knowledge into a taxonomy [16] also made the process user friendly.
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 Although not fully complete, the BrDD was the basis of the first developments of information delivery manuals (IDMs) for steel bridge erection [8] and steel bridge design to fabrication [21]. A BIM task group, TG15, was established in the AASHTO/NSBA Steel Bridge Collaboration 6 , which is a collaboration between AASHTO and the National Steel Bridge Alliance (NSBA). The aim of TG15 was to facilitate the development of bridge industry consensus standards for data description, modeling, and interoperability for integrated design, construction, and life cycle. This task group was composed of domain experts that provided the industry knowledge. The first case study focused on the development of standardization process for information exchanges for steel bridge erection engineering. Since this was the first industry group to utilize the NBIMS for transportation, the goal was to serve as a pilot study for future IDM development and resulted in the "IDM for Steel Bridge Engineering". In addition to being a taxonomy of the data properties and relationships, the BrDD was expanded to identify the exchange requirements by adding more terms. Additionally, this group also established a model and best practices for the process of creating bridge IDMs. Several lessons learned were identified, including the need for detailed assumption and standardized formats, which enabled future work to be completed more quickly and purposefully. Another lesson learned was that the domain experts did not have software knowledge, outside of certain BIM products, so understanding the IDM process, developing the BrDD, and using non-BIM software were challenges. A significant deliverable was the creation of a bridge life cycle process map with the identification of critical model exchanges 7 .
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 delivery 8 . TG15 continued to supply the data requirements needed for the development of the for Bridge Design 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 products 9 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 efficient 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 difficult 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 different 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 efforts 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 efforts. 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 efficient 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 [4], one of the goals of the ontology is to ensure modularity. Additionally, since the end goal of both TPF projects is to utilize the bSDD, IFC 4.3 will be reviewed to identify any current classes and properties that are already defined (any inconsistencies or omissions will be document in collaboration with the IFC 4.3 development). Finally, in the creation of a knowledge graph of functional relationships, current bridge software will be reviewed and compared with the current structure of the BrDD. Throughout this methodology, the ontology, data dictionary, and knowledge graph will be continually updated by creating links and maps between them. Methodologies and techniques for automated mapping will be explored.
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 difficult 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 efficiency 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 fields). 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 different 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 efforts. In the BrDD, the exchange requirements were captured directly in the sheets as new columns. This is fine 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 efficient 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 efforts, 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 efficiently 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 efficient 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 efficient.
Various challenges have been discovered that currently prevent an efficient 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 efforts. 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 efforts in this research, including Joseph Brenner, David Dexter, and Jeffrey Ouellette.