=Paper=
{{Paper
|id=Vol-3633/paper6
|storemode=property
|title=Towards a U.S. national bridge and infrastructure data dictionary: an introduction
|pdfUrl=https://ceur-ws.org/Vol-3633/paper6.pdf
|volume=Vol-3633
|authors=Aaron Costin,Marina Muller
|dblpUrl=https://dblp.org/rec/conf/ldac/CostinM23
}}
==Towards a U.S. national bridge and infrastructure data dictionary: an introduction
==
https://ceur-ws.org/Vol-3633/paper6.pdf
Towards a U.S. National Bridge and Infrastructure
Data Dictionary: An Introduction
Aaron Costin1,∗ , Marina Muller2
1
M. E. Rinker, Sr. School of Construction Management, University of Florida, 323 Rinker Hall, P.O. Box 115703,
Gainesville, FL 32611 USA
2
Stock Development Department of Construction Management, Florida Gulf Coast University, 10501 FGCU Blvd, Fort
Myers, FL 33965 USA
Abstract
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 efforts 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 effort to
ensure that it can be extended to include other transportation structures.
Keywords
IFC, Bridge, Infrastructure, Data Dictionary
1. Introduction
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
Proceedings LDAC2023 - 11th Linked Data in Architecture and Construction , 15 - 16 June 2023, Matera, Italy.
∗
Corresponding author.
Envelope-Open aaron.costin@ufl.edu (A. Costin); mfigueiredomuller@fgcu.edu (M. Muller)
Orcid 0000-0003-4263-8101 (A. Costin)
© 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
71
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
1
https://www.pooledfund.org/Details/Study/624
2
https://www.pooledfund.org/Details/Study/707
72
dictionary.
2. Related Work
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
3
https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/
4
https://www.csiresources.org/standards/overview
5
https://www.buildingsmart.org/users/services/buildingsmart-data-dictionary/
73
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 ontol-
ogy 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 ex-
tension, 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.
3. Early Bridge and Infrastructure Data Dictionary
Development
This research stemmed from the lineage of BIM for transportation efforts investigating digital
delivery of bridge projects[21]. Previous methodologies enabling BIM-based information ex-
changes, 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 methodol-
ogy 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 stan-
dard 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
74
Figure 1: Snapshot of the BrDD with Data Requirements from Steel Bridge Design to Fabrication
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[8] and steel bridge design to fabrication[21].
A BIM task group, TG15, was established in the AASHTO/NSBA Steel Bridge Collaboration6 ,
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
exchanges7 .
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
6
https://www.aisc.org/nsba/design-and-estimation-resources/aashto-nsba-collaboration/
7
The scope was steel bridges, but these exchanges were also reviewed for concrete bridge types
8
https://bimforbridgesus.com/
75
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.
4. Current Bridge and Infrastructure Data Dictionary
Development
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 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
9
https://www.buildingsmart.org/standards/bsi-standards/
76
Figure 2: OntoGraph of BrDD Showing Illogical Hierarchy
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.”
5. BrDD Development Methodology
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
77
Figure 3: Hierarchy Based on Functionality
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
78
Figure 4: BrDD Development Methodology
Figure 5: Process to insert the Excel data into Protégé
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
79
Figure 6: Example Connections between Classes, Data Properties, and Ranges
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.
6. Discussion and Open Challenges
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
80
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
81
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 bi-
directional 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.
7. Conclusion and Future Work
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.
8. Acknowledgements
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.
10
https://www.buildingsmart.org/standards/bsi-standards/information-delivery-specifications-ids/
82
References
[1] A. Costin, A. Adibfar, H. Hu, S. S. Chen, Building information modeling (bim) for trans-
portation infrastructure–literature review, applications, challenges, and recommendations,
Automation in construction 94 (2018) 257–281.
[2] AASHTO Board of Directors, Adoption of Industry Foundation Classes (IFC) Schema as the
Standard Data Schema for the Exchange of Electronic Engineering Data, Administrative
Resolution AR-1-19, AASHTO, 2019.
[3] J. Mallela, A. Bhargava, et al., Advancing BIM for Infrastructure: National Strategic
Roadmap, Technical Report, United States. Federal Highway Administration, 2021.
[4] A.-H. Hamdan, R. J. Scherer, Integration of bim-related bridge information in an ontological
knowledgebase, in: Proceedings of the 8th Linked Data in Architecture and Construction
Workshop-(LDAC), 2020, pp. 77–90.
[5] A. Costin, H. Hu, R. Medlock, BIM for Bridges and Structures Case Study: Outcomes and
Lessons Learned from the Steel Bridge Industry, Technical Report, 2021.
[6] L. van Berlo, P. Willems, P. Pauwels, Creating information delivery specifications using
linked data, in: 36th CIB W78 2019 Conference, 2019, pp. 647–660.
[7] D. Spoladore, E. Pessot, Collaborative ontology engineering methodologies for the
development of decision support systems: Case studies in the healthcare domain,
Electronics 10 (2021). URL: https://www.mdpi.com/2079-9292/10/9/1060. doi:1 0 . 3 3 9 0 /
electronics10091060.
[8] A. Costin, A new methodology for interoperability of heterogeneous bridge information
models, Ph.D. thesis, Georgia Institute of Technology, 2016.
[9] G. Ren, R. Ding, H. Li, Building an ontological knowledgebase for bridge maintenance,
Advances in Engineering Software 130 (2019) 24–40.
[10] K. Banujan, S. Vasanthapriyan, Bridge ontology architecture for knowledge management
in bridge maintenance, in: 2020 Moratuwa Engineering Research Conference (MERCon),
2020, pp. 1–6. doi:1 0 . 1 1 0 9 / M E R C o n 5 0 0 8 4 . 2 0 2 0 . 9 1 8 5 3 3 5 .
[11] A. Hamdan, T. Dresden, T. Kozak, Krebs + Kiefer, Bridge topology ontology,
https://wisib.de/ontologie/brot/. URL: http://website-url.com, accessed on February 10,
2023.
[12] Y. Zhang, Y. Liu, G. Lei, S. Liu, P. Liang, An enhanced information retrieval method based
on ontology for bridge inspection, Applied Sciences 12 (2022) 10599.
[13] A. S. Shishlov, A. M. Costin, M. T. Davidson, Integration of building information modeling
interoperability into nonlinear finite element analysis of bridge substructures, Transporta-
tion Research Record (2023) 03611981231160172.
[14] T. H. Kwon, S. I. Park, Y.-H. Jang, S.-H. Lee, Design of railway track model with three-
dimensional alignment based on extended industry foundation classes, Applied Sciences
10 (2020). URL: https://www.mdpi.com/2076-3417/10/10/3649. doi:1 0 . 3 3 9 0 / a p p 1 0 1 0 3 6 4 9 .
[15] P. Pauwels, S. Zhang, Y.-C. Lee, Semantic web technologies in aec industry: A literature
overview, Automation in construction 73 (2017) 145–165.
[16] A. M. Costin, C. Eastman, R. R. Issa, The need for taxonomies in the ontological approach
for interoperability of heterogeneous information models, in: International Workshop on
Computing in Civil Engineering, ASCE, 2017, pp. 9–17.
83
[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ßenin-
formationsbank 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. Office of Infrastructure, 2013.
[24] A. A. of State Highway, T. O. (AASHTO), Manual for bridge element inspection, American
Association of State Highway and Transportation Officials (AASHTO, 2019.
84