Improving Applicability for Information Model of an IFC-Based Steel Bridge in the Design Phase Using Functional Meanings of Bridge Components

: The industry foundation classes (IFC) data model is the most important data schema in ensuring the interoperability of the information generated throughout the lifecycle of facilities. However, because the current IFC model is focused on buildings, there are limitations when this model is applied to bridge structures. This paper proposes a method that enables the information modeling of steel box girder bridges based on the current IFC. To select the required and core items, we classify the components of a steel box girder bridge by the design stage with reference to engineering documents. To generate functional meanings of each bridge component, we develop the rules of the unique identiﬁer and information reassignment, and then apply a semi-automated naming algorithm. The generated bridge information model was used to conﬁrm the functional semantic meanings of individual components, and it was checked whether additional external information, such as carbon emissions, could be linked for speciﬁc bridge components. It was observed that information retrieval and extraction for components is possible through a semantic-based query to the generated IFC-based bridge information model.


Introduction
In recent times, building information modeling (BIM) has been actively introduced in the construction industry to enhance productivity [1]. In projects involving buildings, the use of the BIM has the following advantages: (1) visibility owing to the use of a 3D model; (2) interoperability of the information owing to the use of a common data schema; and (3) persistence of the information owing to the use of a standard data schema.
The reason information interoperability should be treated as an important aspect can be explained by the problem of integration of various facilities or environmental information, or the improvement of applicability based on the information model. In the former case, the most representative case is the information linkage between BIM and the geographic information system (GIS). For example, it is essential to exchange information with the surrounding terrain of the tunnel structures. BIM does not deal with detailed information concerning the terrain or ground; it is indispensable to link it with the GIS to control the terrain information [2]. It is also essential to ensure interoperability between BIM and GIS for the construction of facilities, environmental impact assessment, resource distribution, safety analysis, or pipeline network plan [3,4]. However, as pointed out in [5], the integration of the two fields becomes compromised at the data, process, and application levels. Therefore, the authors

Related Works on Bridge Data Schemas
There have been studies on the development of an open bridge data schema at the research level since the 1990s, although such research for building structures began later. The most important consideration for the development of a data schema is that the data must be in a form that is accessible from any software package, while retaining a clear definition of the connections between the structure and the components. Representative examples of sophisticated data model description languages that satisfy this criterion include the EXPRESS language from Standard for the Exchange of Product model data (STEP) [21], and the Extensible Markup Language (XML) [22]; the development of bridge data schemas has been primarily based on EXPRESS or XML.

STEP AP 203-Based Bridge Data Schema
While the Generic AEC Reference Model (GARM) of Gielingh [23] focuses on buildings, it also contains some aspects related to civil works. However, this is merely a remark that civil works are one of the AEC product types. Actual development of bridge data model based on STEP was mainly implemented during the late 1990s. During that time, the emphasis was on the representation of the geometry of the bridge using the STEP Application Protocol (AP) 203, rather than on the development of data models solely for bridges [24,25]. Halfawy et al. [26] developed an entity for a bridge information model by proposing the bridge core model (BCM), and linked this with the CIMsteel integration standards (CIS/2) [27] to allow for the management of the information for structural analysis. Moreover, Lee and Jeong [28] developed an integrated framework for a steel bridge information model using STEP AP203 and AP209. However, the BCM added and defined the entities for the elements with low-level representations, without consideration of a classification system. The BCM and the model by Lee and Jeong [28] both exclude semantic consideration of the spatial arrangement of the bridge components. As such, spatial semantic information, such as which span the bridge belongs to, must be determined from the assigned location of the physical objects, which is a difficult interpretation task for a computer.

IFC-Based Bridge Data Schema
IFC is also defined in EXPRESS, a model description language of the ISO-STEP. Therefore, it inherits the object-oriented programming concept of EXPRESS. As such, the model can be made more delicate and specialized by adding low-level objects through subtypes [29]. Moreover, the IFC data schema provides a basic modular structure to the information model, and a framework for the sharing of information between various areas of the construction industry. Consequently, while IFC is being developed with an emphasis on buildings, it is possible to extend the entities for application to other structures, such as bridges. Therefore, even though IFC is a schema that was developed with a focus on buildings, it is highly efficient to re-use previous IFC resources for other structures, as long as the functional role regarding which component of the bridge model it will be used for is excluded. The data schema developed by adding the necessary elements for bridges to the previous IFC resources is generally referred to as an IFC-Bridge, of which the representative examples are the works of Arthaud and Lebegue [30] and Yabuki et al. [31], which are based on the IFC2X2 version While these two research teams initially worked independently of each other, they integrated their two data schemas after recognizing the similarity between their works. The integrated schema addresses both the physical and the spatial elements of a bridge, unlike the data schema discussed in Section 2.1.1. To represent the information about the physical function of the bridge components, IfcBridgePrismaticElement, IfcBridgeSegment, IfcBridgeElementComponent, and their subtypes are additionally defined as the subtypes of the existing IFC entity, IfcElement. To represent the spatial meaning of a bridge, IfcBridge and IfcBridgeStructureElement are added as subtypes of the existing IFC entity, IfcSpatialStructureElement. Horizontal alignment of the bridge is addressed by adding the entity IfcBridgeReferenceLine, which has the previous IfcCurve resource as an attribute.
Lee and Kim [20] proposed an IFC extension model for road structures, which includes bridges as a sublevel structure. Lee and Kim's [20] bridge model is characterized by the inclusion of items for the management of spatial arrangement information of the bridge members and the start/end point information of the horizontal road alignment, as compared with the previously mentioned IFC-Bridge schema. An element for the road space, IfcSpatialRoadElement, is additionally defined as a subtype of the existing entity, IfcSpatialElement, which also includes the subtypes of IfcBridge, IfcBridgeSpan, and IfcLane (common items used in road elements). The model allows for the identification of elements that are arranged in the parallel and vertical directions to the bridge span using these subtypes. The start/end point of the horizontal road alignment is managed as an attribute of the IfcGlobalPointReference (extended entity) type in IfcSpatialRoadElement. However, ultimately, additional entities and attributes must be developed, corresponding to the inclusion of all information about bridge structures. However, as noted by research of Lee et al. [32], the advantages of BIM from the sharing and re-use of information cannot be acquired at all, unless a modeling software package that supports the changed schema is developed and popularized.

Bridge Schema Elements in IFC
While the 2013 release of IFC4 contains the necessary entities for buildings only, it does include basic high-level elements for the enhancement of the support for other infrastructures in the future. These include IfcCivilElement and IfcCivilElementType, which were added as subtypes of IfcElement and IfcElementType, respectively. To develop the subtypes, attributes, and PSETs for these elements, buildingSMART International (bSI) founded the Infrastructure Room [33], which is now developing the standards for alignments [34,35], roads [36], and railways [37]. These will be included in IFC5 and it is known that the bridge schema is included in the Road and Railway Extension Project. However, as expressed by Cerovsek [19], even if a new schema were to be released, there would be a significant delay before its implementation in software: it was not until more than 10 years after the development of IFC that many BIM authoring software packages started to support IFC officially. Therefore, even if the elements pertinent to bridges were to be added to IFC, it is predicted that it would take a long time to generate information models, and to utilize them in actual applications effectively. This characteristic can be said to be an environment that cannot appropriately respond to the present demands of the user for the re-use of information and the efficiency enhancement of information management during a bridge lifecycle.

Bridge Data Schema in CityGML
CityGML is an open data schema suggested by the Open Geospatial Consortium (OGC) as a standard for the representation, storage, and exchange of city information. CityGML established the schema by adopting separate modules for each of the facilities that form a city [38]. While the initial version did not include bridges, version 2.0, released in 2012, includes a bridge module, which is a data schema for bridge structures [39].
Similar to IFC-Bridge, the bridge module of CityGML also distinguishes spatial and physical objects. Functional information can be assigned to a physical object using the BridgeConstructionElement or BridgeInstallation. While spatial objects are not explicitly instantiated in CityGML, spatial information can be represented using the BridgePart element. Moreover, the difference between CityGML and the previously mentioned STEP-based bridge schema is that the CityGML bridge module also comprises four stages of the level of detail (LoD), directly inheriting the characteristics of CityGML. While the representation of horizontal alignment is not included in CityGML as an explicit item, it can be implemented using the lod0Network, which is included in the transportation modules, and the CompositeCurve elements. However, as previously discussed, the bridge module of CityGML does not include the items needed for identification of the spatial arrangement of bridge components, and the application is difficult to use due to the lack of modeling software packages that directly support CityGML.

Bridge Data Schema in TransXML
TransXML is an open data schema developed by the NCHRP project of the US National Research Council for the exchange of transportation data of the public sector [40]. TransXML specifies and focuses on four business areas, including "highway bridge structures". The difference in the bridges in TransXML to those in the other already mentioned data schemas is that the TransXML version contains detailed elements for structural analysis and design, along with a general description of the bridge. (While this can be said to be similar to the Structural Analysis Domain and Structural Elements Domain of the "domain layer" in IFC, TransXML is specialized for highway bridges, unlike IFC.) However, the TransXML bridge does not consider explicit elements for the representation of the geometry of the model. While it provides elements for the geometry of the members of the entire bridge (Bridge > BeamShapes and its subelements), it is impossible to identify the meaning of the bridge components based on geometry. Therefore, the applications of TansXML adopt the geography markup language (GML) of OGC as a common framework. However, there are inevitable problems, since the TransXML bridge focused on engineering design while GML was developed for the geospatial domain.
Based on the previous discussion, the following criteria were adopted as important considerations for the selection of a bridge data schema for use in this study.

1.
Interoperable and accessible: The schema must be software-independent, and the model data should be accessible in any situation 2.
Three-dimensional: The schema must be able to manage the information of the constituent elements of the bridge based on 3D geometry 3.
Semantic: The schema must include functional semantic information of the bridge components, and be capable of spatially and physically distinguishing the components 4.
Software-based data manageable: The schema must allow information modeling on BIM authoring software As mentioned in Section 1, IFC is the ISO standard for BIM, satisfies all of the above criteria when applied to buildings, and is supported by an increasing number of BIM software packages. Moreover, there is a clear likelihood of extending IFC to structures other than buildings, similar to the aforementioned work of the Infrastructure Room. Accordingly, we state that the bridge information model in this study was created based on IFC4, which is the latest official version released, and explain its scope of application.

User-Defined Property Sets at a Glance
IFC contains various entities and PSETs for the exchange of information about a building during its lifecycle. However, it cannot satisfy all the requirements necessitated by structures such as buildings or bridges [41]. While this can be resolved, as mentioned above, by establishing a new data schema through the extension of entities, IFC also internally supports extension through PSETs [42]. IFC PSETs are generated as references to external data, unlike the addition of entities, and hence do not modify the IFC schema (see Figure 1). As such, the extended data schema can be directly utilized in all BIM authoring software packages that support IFC.
The most critical reason for the inability to properly utilize IFC as a bridge data schema is the difficulty in representing the functional meaning of the constituent elements of a bridge [20]. Therefore, in this study, we define the necessary additional elements for the management of the functional semantic information of bridge components using "IFC user-defined PSETs".
The user-defined PSETs of IFC can be represented using a container class, IfcPropertySet. To effectively represent the user-defined PSETs during this process, at the data schema level, IfcPropertySet only defines the types of dynamic metadata. Figure 2 shows the relationships between objects focused on IfcPropertySet, which can be used in applications through the following criteria.

1.
IfcObject is used as it is for the objects that represent the components themselves. During this process, IfcPropertySet and IfcObject can be linked by IfcRelDefinesByProperties, a subtype of IfcRelationship.

2.
The properties that form IfcPropertySet are represented using IfcProperty, an entity that implements "HasProperties", an explicit attribute of IfcPropertySet.

3.
The semantic meaning of a property is defined through the explicit "Name" attribute of IfcProperty.
released, and explain its scope of application.

User-Defined Property Sets at a Glance
IFC contains various entities and PSETs for the exchange of information about a building during its lifecycle. However, it cannot satisfy all the requirements necessitated by structures such as buildings or bridges [41]. While this can be resolved, as mentioned above, by establishing a new data schema through the extension of entities, IFC also internally supports extension through PSETs [42]. IFC PSETs are generated as references to external data, unlike the addition of entities, and hence do not modify the IFC schema (see Figure 1). As such, the extended data schema can be directly utilized in all BIM authoring software packages that support IFC. The most critical reason for the inability to properly utilize IFC as a bridge data schema is the difficulty in representing the functional meaning of the constituent elements of a bridge [20]. Therefore, in this study, we define the necessary additional elements for the management of the functional semantic information of bridge components using "IFC user-defined PSETs".

IfcPropertySet
Additional Properties (User-defined Properties) Associated with IFC objects The user-defined PSETs of IFC can be represented using a container class, IfcPropertySet. To effectively represent the user-defined PSETs during this process, at the data schema level, IfcPropertySet only defines the types of dynamic metadata. Figure 2 shows the relationships between objects focused on IfcPropertySet, which can be used in applications through the following criteria.
1. IfcObject is used as it is for the objects that represent the components themselves. During this process, IfcPropertySet and IfcObject can be linked by IfcRelDefinesByProperties, a subtype of IfcRelationship. 2. The properties that form IfcPropertySet are represented using IfcProperty, an entity that implements "HasProperties", an explicit attribute of IfcPropertySet. 3. The semantic meaning of a property is defined through the explicit "Name" attribute of IfcProperty. 4. A user-defined property is represented using IfcPropertyBoundedValue, IfcPropertyEnumeratedValue, IfcPropertyListValue, IfcPropertyReferenceValue, IfcPropertySingleValue, and IfcPropertyTableValue, all of which are subtypes of IfcProperty. In summary, the information, set by users in advance, is identified through IfcProperty, and appears as instances through the subtype of IfcProperty. Although this is an auxiliary method for creating a bridge model using the IFC4 shown in Table 1, there is an advantage in that it can be utilized to create and manage the functionalities of the elements used in the construction of the bridge.  In summary, the information, set by users in advance, is identified through IfcProperty, and appears as instances through the subtype of IfcProperty. Although this is an auxiliary method for creating a bridge model using the IFC4 shown in Table 1, there is an advantage in that it can be utilized to create and manage the functionalities of the elements used in the construction of the bridge.

Required Information for a Steel Bridge Data Schema
The classification of the structural elements of a steel box girder bridge is needed for the semantic and functional identification of each element. This is closely related to information generated during the bridge design phase. In particular, information modeling is the process of completing the model by adding relevant nongeometric information to the 3D geometry, and geometric representation can be said to be important for this process. Therefore, in this study, bridge components used for the design phase were analyzed, and the results were utilized as the basic elements for the development of the data model. Since the information generated during the design phase encompasses most of the information required during the bridge lifecycle, the element analysis in this study was restricted to the design phase. During the analysis, the design drafting standard for construction established by Ministry of Land, Transport and Maritime Affairs of Korea [43] was consulted for a list of the tasks completed during the design phase.
The primary task accomplished during the fundamental planning phase is selecting and specifying the optimal route. Therefore, the steel box girder bridge information model for the support of the fundamental planning phase is a conceptual representation of the route. During the fundamental design phase, the location and type of the bridge are determined. Consequently, to support the fundamental design phase, the modeling must be conducted to the extent of being able to identify the length of the model elements, and the bridge width, location, and direction.
The objective of the detailed design phase is to compile the drawings and specifications necessary for the actual construction, by concretizing the fundamental design. Therefore, all of the components from the fundamental design are included, and, in addition, each element must be represented in greater detail. "Guidelines for the Detailed Design of Steel Road Bridges" [44] and "Bridge Planning and Design" [45] were consulted for the classification of the specific components for each level of representation of the model, which were defined for each of the three phases of fundamental planning, fundamental design, and detailed design. The corresponding results used in this study are shown in Table 2. The breakdown of the structural items that comprise the steel bridge are listed in Table 2 and the table can be used to identify the function of each item.

IFC-Based Semantic Meanings for the Components of a Steel Box Girder Bridge
To ensure the compatibility of the elements of the information model between different software packages while including semantic information, measures for the management of semantic meaning at the data schema level must be established. In this study, functional semantic information of the bridge components was generated using IFC user-defined PSETs. Storage of the semantic information of the bridge components in PSETs, and how the PSETs are composed, are important considerations. In this study, the configuration of bridge entities was based on the work of Kim and Lee's research [46], according to which building and bridge models differ in terms of the spatial arrangement of the model, and the function of the elements that form the model. Therefore, the user-defined PSETs in this study were primarily composed of the following contents.

1.
Identification of the spatial arrangement of the structure: In building structures, space is extended vertically within the known range of the limited site. In contrast, in bridge structures, in addition to the vertical spatial arrangement of components with different functions, the arrangement of similar (or identical) elements in the spanwise direction is a highly important aspect. This affects not only the bridge structure, but also equally affects the road and tunnel structures that form the road system. Therefore, this study focused on enabling the identification of the spatial arrangement of each bridge component using its properties, rather than the alignment of the entire bridge. The advantage of this method is that the spatial identification method can be used unchanged, even if a new entity for alignment is added at a higher level of IFC.

2.
Identification of the structural components based on function and usage: Considering the aspect of structure, buildings and bridges can share most of the resources. IFC distinguishes such entities or types in the Resource Layer. The Resource Layer includes elements such as geometry and material, which do not have functional meaning. The physical aspect of the functional meaning of building components is handled by entities that belong to the IfcSharedBldgElements schema that are represented in the IFC physical file (IPF) through subtypes of the IfcBuildingElement entity. Therefore, for bridge information modeling, the function and usage must be represented similarly to those represented by the subtypes of the IfcBuildingElement.
The identification of the spatial arrangement of bridge components in this study relates to the location, region, and topology of the component. For buildings, a single story is considered as the largest unit object, and the space of the repeated stories of a building is managed by IfcBuildingStorey and its subtypes. However, as mentioned earlier, this only considers the direction vertical to the ground (while, indeed, the elements for the interior space of each floor are identified for buildings, these are low-level elements for the spatial identification of a floor, and are thus considered out of the scope of this paper). In contrast, for bridges, a spatial definition for three directions is required, even if the largest functional unit object is set as the reference (see Figure 3). largest unit object, and the space of the repeated stories of a building is managed by IfcBuildingStorey and its subtypes. However, as mentioned earlier, this only considers the direction vertical to the ground (while, indeed, the elements for the interior space of each floor are identified for buildings, these are low-level elements for the spatial identification of a floor, and are thus considered out of the scope of this paper). In contrast, for bridges, a spatial definition for three directions is required, even if the largest functional unit object is set as the reference (see Figure 3). In the Z-direction, the classification of the super/substructure of the bridge was assigned as the basic property. Although it is not considered in this study, a bridge pier can also be classified in terms of the Z-direction for spatial identification that includes the pier for bridge information modeling. The Y′-direction is the direction tangential to the spanwise direction of the bridge, and indicates the spanwise direction of the bridge. The X′-direction is the direction that is perpendicular to the Y′direction, in a plane that includes the Y′-direction. As such, in this study, the spaces corresponding to the Z-, Y′-, and X′-directions were identified using the Structural System, Span, and Girder properties, respectively (see Figure 4).
In this study, the physical semantic identification of bridge model elements is the determination of what function the element has, and what the usage of the element in the bridge is. For buildings, this is addressed by the IfcSharedBldgElements schema of IFC. IFC defines each entity with reference to ISO 6707-1 [47]. While some of these elements can be used directly for bridge structures, it is difficult for other elements to convey the function or usage in bridge models. For example, IfcDoor is defined as "a building element that is predominately used to provide controlled access for people and goods" in the IFC data schema. Here, if the higher-level object of "a building element" that contains IfcDoor is excluded, there is no functional difference even when IfcDoor is directly applied to bridge structures (e.g., the door inside a bridge for bridge maintenance). However, there are difficulties in directly applying IfcColumn to bridge piers, although both columns and piers are structural members that transmit the compressive forces applied to them to their bases. In the Z-direction, the classification of the super/substructure of the bridge was assigned as the basic property. Although it is not considered in this study, a bridge pier can also be classified in terms of the Z-direction for spatial identification that includes the pier for bridge information modeling. The Y -direction is the direction tangential to the spanwise direction of the bridge, and indicates the spanwise direction of the bridge. The X -direction is the direction that is perpendicular to the Y -direction, in a plane that includes the Y -direction. As such, in this study, the spaces corresponding to the Z-, Y -, and X -directions were identified using the Structural System, Span, and Girder properties, respectively (see Figure 4).
In this study, the physical semantic identification of bridge model elements is the determination of what function the element has, and what the usage of the element in the bridge is. For buildings, this is addressed by the IfcSharedBldgElements schema of IFC. IFC defines each entity with reference to ISO 6707-1 [47]. While some of these elements can be used directly for bridge structures, it is difficult for other elements to convey the function or usage in bridge models. For example, IfcDoor is defined as "a building element that is predominately used to provide controlled access for people and goods" in the IFC data schema. Here, if the higher-level object of "a building element" that contains IfcDoor is excluded, there is no functional difference even when IfcDoor is directly applied to bridge structures (e.g., the door inside a bridge for bridge maintenance). However, there are difficulties in directly applying IfcColumn to bridge piers, although both columns and piers are structural members that transmit the compressive forces applied to them to their bases.  1. In supporting dynamic loads, a pier is largely affected by the dynamic load in the direction vertical to the ground, while a column is affected by the dynamic load in the direction parallel to the ground. 2. In terms of general functional classification, a column is a necessary condition for a pier (i.e., pier

1.
In supporting dynamic loads, a pier is largely affected by the dynamic load in the direction vertical to the ground, while a column is affected by the dynamic load in the direction parallel to the ground.

2.
In terms of general functional classification, a column is a necessary condition for a pier (i.e., pier ⊂ column). 3.
In terms of usage, the column of a bridge substructure is termed separately from a pier.
Therefore, in this study, the physical elements were identified in a way that directly supports the entry of the classification of steel box girder bridge components. This allows classification of steel bridge components into parts and assembly, depending on the level. In this study, the physical components of a steel box girder bridge were also classified into Part, the single part property, and Assembly, the assembled product property, and assembled products were further classified into the combination of single parts (Parts Assembly) and the combination of assemblies (Assembled Assembly) (see Figure 5). Here, single parts refer to the components that are represented when a steel box girder bridge model is described in greatest detail. Moreover, the items for the smallest unit and combination were as shown in Table 2. In the case there are items that have not been included in Table 2, the model creator can create extra identification names, which would be applied in the IFC model as it is. 1. In supporting dynamic loads, a pier is largely affected by the dynamic load in the direction vertical to the ground, while a column is affected by the dynamic load in the direction parallel to the ground. 2. In terms of general functional classification, a column is a necessary condition for a pier (i.e., pier ⊂ column). 3. In terms of usage, the column of a bridge substructure is termed separately from a pier. Therefore, in this study, the physical elements were identified in a way that directly supports the entry of the classification of steel box girder bridge components. This allows classification of steel bridge components into parts and assembly, depending on the level. In this study, the physical components of a steel box girder bridge were also classified into Part, the single part property, and Assembly, the assembled product property, and assembled products were further classified into the combination of single parts (Parts Assembly) and the combination of assemblies (Assembled Assembly) (see Figure 5). Here, single parts refer to the components that are represented when a steel box girder bridge model is described in greatest detail. Moreover, the items for the smallest unit and combination were as shown in Table 2. In the case there are items that have not been included in Table 2, the model creator can create extra identification names, which would be applied in the IFC model as it is.  Table 3 shows the IFC user-defined PSETs proposed in this study for the abovementioned context. This consists of the attributes for the generation of spatial meaning, namely Structural System,  Table 3 shows the IFC user-defined PSETs proposed in this study for the abovementioned context. This consists of the attributes for the generation of spatial meaning, namely Structural System, Span, and Girder; the attributes for the generation of physical meaning, namely Assembled Assembly, Parts Assembly, and Part; and the attributes for the basic information of the model, namely Project Stage, Model Element Author, and Description. Table 3.
User-defined PSET for generating the semantic information of steel box girder bridge components.

Naming Process for Bridge Components
The most significant advantage of the application of the IFC user-defined PSETs proposed in this study is that it enables direct modeling of the IFC-based bridge information using the current BIM authoring software that supports IFC.
The generation of the semantic information of the components of an actual bridge consists of the following two stages. The first stage is the generation of the information regarding the usage and function of the component in question, among other components. The second stage is the assignment of a unique identifier between multiple instances of the same component. As such, two stages of the IFC-based bridge modeling process are proposed in this study.
The first stage is that in which the user generates the semantic identification information of the component with reference to Table 2 during bridge modeling. The second stage is the process of generating the identifiers for the identified components, in accordance with their relative locations. Pset_SteelBoxBridgeComponentsIdentification (see Section 3) applies the information generated through the above two processes. Figure 6 shows a conceptualization of bridge information modeling through current BIM authoring software. For bridge information modeling, the following processes were performed: (1) geometric modeling of the bridge structure; and (2) reassignment of the semantic information by modeler. The geometric model was built using the BIM authoring software that supports the IFC data schema. That means that the components of bridge structure were modeled through specific IFC entities of building structure-the subtypes of IfcBuildingElement. In this study, the geometric modeling was performed through IfcColumn of IFC entity in the case of the bridge pier model. The functional meanings, user's intentions for identifying the components of the bridge model are integrated with the subtypes of IfcBuildingElement using user-defined PSETs. Figure 7 shows the specific process for the IFC-based bridge information modeling using the BIM authoring software. Pre-information model in Figure 7 means a geometric model was built by BIM authoring software. Bridge component data in Figure 7 can refer to the component items in Table 2.

Basic Bridge Geometric Modeling and Information Reassigning
The identifiers of the model components of the bridge were generated through the user-defined PSETs defined in accordance with Section 3.2 and Table 3. We propose two methods to reassign the functional meanings of the bridge components to the existing bridge geometric model. The first method utilizes BIM authoring software, which builds a geometric model. In this study, we developed a user interface (UI) for managing the information using Autodesk Revit API (see Figure 8). To control the nullable type, the UI uses a checkbox to determine whether the information for Girder, Assembled Assembly, and Parts Assembly need to be entered. The IFC-based bridge information model intended in this study was built through the integration of geometric model and semantic identifiers. The IPF of the bridge model can be created by the IFC exporter of Revit software. entities of building structure-the subtypes of IfcBuildingElement. In this study, the geometric modeling was performed through IfcColumn of IFC entity in the case of the bridge pier model. The functional meanings, user's intentions for identifying the components of the bridge model are integrated with the subtypes of IfcBuildingElement using user-defined PSETs. Figure 6. Information reassigning concept for the bridge information modeling. Figure 7 shows the specific process for the IFC-based bridge information modeling using the BIM authoring software. Pre-information model in Figure 7 means a geometric model was built by BIM authoring software. Bridge component data in Figure 7 can refer to the component items in Table  2. The identifiers of the model components of the bridge were generated through the user-defined PSETs defined in accordance with Section 3.2 and Table 3. We propose two methods to reassign the functional meanings of the bridge components to the existing bridge geometric model. The first method utilizes BIM authoring software, which builds a geometric model. In this study, we developed a user interface (UI) for managing the information using Autodesk Revit API (see Figure  8). To control the nullable type, the UI uses a checkbox to determine whether the information for Girder, Assembled Assembly, and Parts Assembly need to be entered. The IFC-based bridge information model intended in this study was built through the integration of geometric model and semantic identifiers. The IPF of the bridge model can be created by the IFC exporter of Revit software.  The second way to reassign the functional meanings of bridge components is to input them directly into the generated IPF. This method, however, suffers from a disadvantage: the end-user cannot check the geometry of the object to reassign information simultaneously. However, it is software-independent, and the speed of information generation is fast. This speed is an important factor for facilities with many objects, such as bridge structures. The globally unique identifier (GUID) of the object, which is automatically generated in the IFC parsing step, and the data for reassignment, are both required. Algorithm 1 shows the process of adding newly defined user-defined PSET data to an object in the IPF generated in this study. The input data for Algorithm 1 are a list of the name and value data of the property to be added to the IPF, the GUID of the IFC entity, and the instance of the "Population" class, which has the same structure of the schema as the generated IPF. In this study, the "Population" of the generated IPF was compiled using ST-Developer from STEP Tools, Inc. To process multiple PSETs, a "DO" loop was applied (Line 2). The relatedObject (Line 3) is the same as "RelatedObjects" in Figure 2 and represents the object to which PSET is connected. The relatedObject can be retrieved through the inputted GUID. Lines 7-12 show the steps for creating entities and attributes of IfcPropertySet and create related information about IfcProperty using Lines 15-23. The generated data are linked with IfcPropertySet via Line 24. The connection between the object and the property shown in Figure 2 is implemented through the createRelationship function, which refers to the creation of a relationship entity (Line 30) and the connection of the object (Lines 32-35) through the assignment of its attributes. Figure 7. Basic framework for IFC-based bridge information modeling process. The second way to reassign the functional meanings of bridge components is to input them directly into the generated IPF. This method, however, suffers from a disadvantage: the end-user cannot check the geometry of the object to reassign information simultaneously. However, it is software-independent, and the speed of information generation is fast. This speed is an important factor for facilities with many objects, such as bridge structures. The globally unique identifier (GUID) of the object, which is automatically generated in the IFC parsing step, and the data for reassignment, are both required. Algorithm 1 shows the process of adding newly defined user-  Ifcpropertyset.setGlobalid(psetGuid) 11 Ifcpropertyset.setOwnerhistory(getIfcOwnerHistoryInPopulation(ref Population)) 12 Ifcpropertyset.setName(psetName) 13 SetIfcproperty: set of IfcProperty in Figure 2  14 NodeList properties: properties included in the pset 15 do (Node property : end of properties) 16 propertyName: getting a property name from the property 17 propertyValue: getting a property value from property 18 Ifcpropertyvalue that subtypes of IfcSimpleProperty in Figure 2: IfcPropertyValue class for inclusion in Population  19  //setting the IfcPropertyValue attributes to the Ifcpropertyvalue class  20 Ifcpropertyvalue.setName(propertyName) 21 Ifcpropertyvalue.setNominalvalue(propertyValue) 22 SetIfcProperty.add(Ifcpropertyvalue): adding the Ifcpropertyvalue to SetIfcProperty class 23 end do 24 Ifcpropertyset.setHasproperties(SetIfcProperty): setting the HasProperties attribute in Figure

Automated Naming Algorithm for the Identification of Bridge Components
We investigated the method of automatically generating the identifiers for the bridge components for which the semantic information of function and usage has been generated. In this study, the application of the automated identifier generation method was based on the assumption that the information for Girder and Span properties is already included, with regard to the Assembled Assembly and Parts Assembly in Figure 5. Here, the exclusion of the Structural System, Girder, and Span properties occur because it is likely that the introduction of an automated technique to problems with few elements, such as the classification of a bridge sub/superstructure or abutment/pier, will be inefficient compared with the manual operation. Since the feature-based semantic identification of components in greater detail than Parts Assembly is not within the scope of this study, it was also excluded.
The identification information of the bridge components was generated by forming feature sets, as shown in Equation (1).
where OF i denotes the feature set of object i. Gd(n) refers to the identifier of the nth girder and Sp(m) indicates the identifier of the mth span. Or L (S mn (i)) is the ordinal information of object i arranged along the axis of the bridge in the spanwise direction (Y -direction). S mn is defined as shown in Equation (2).
where S(Sp(m)) and S(Gd(n)) are for the ith object that belongs to Sp(m) and Gd(n). Figure 9 shows an example of OF i . Objects that are recurrently arranged, such as a section, are identified using the following rule. Rule: If objects i and j satisfy Equation (3), then it is defined that S mn (i) = S mn (j).
Here, p(i) and p(j) are the centroid (in the local coordinate system) of the objects i and j that are arranged along the axis of the spanwise bridge direction (Y -direction). ε is the tolerance that processes the exceptional case of modeling, in which an object is divided into two. Its value should be higher than zero, but, when it is smaller, it divides an object more strictly, which may vary depending on the target model. In this study, the authors used ε = 1 mm. c(i) β is the centroid coordinate values of the βth face of object i, and α is the nearer face, while β is the further face, with reference to the axis of the bridge spanwise direction. In other words, the rule is the identification of identical objects from among recurrently arranged objects, in terms of the semantic classification of the bridge. as shown in Equation (1). = [ ( ), ( ), ( ( ))] (1) where OFi denotes the feature set of object i. Gd(n) refers to the identifier of the nth girder and Sp(m) indicates the identifier of the mth span. OrL(Smn(i)) is the ordinal information of object i arranged along the axis of the bridge in the spanwise direction (Y′-direction). Smn is defined as shown in Equation (2).
( ) = { | ( ( )) ∩ ( ( ))} (2) where S(Sp(m)) and S(Gd(n)) are for the ith object that belongs to Sp(m) and Gd(n). Figure 9 shows an example of OFi. Here, p(i) and p(j) are the centroid (in the local coordinate system) of the objects i and j that are arranged along the axis of the spanwise bridge direction (Y′-direction). ε is the tolerance that processes the exceptional case of modeling, in which an object is divided into two. Its value should be higher than zero, but, when it is smaller, it divides an object more strictly, which may vary depending on the target model. In this study, the authors used ε = 1 mm. c(i) β is the centroid coordinate values of the βth face of object i, and α is the nearer face, while β is the further face, with reference to the axis of the bridge spanwise direction. In other words, the rule is the identification of identical objects from among recurrently arranged objects, in terms of the semantic classification of the bridge. The applicability of the developed algorithm was verified by the application to the sample bridge model shown in Figure 10. The sample bridge consists of two girder intervals and two span intervals, and the intervals used for the algorithm verification are the section interval (Assembled Assembly) and the diaphragm and crossbeam (Parts Assembly) inside the section. As mentioned earlier, the Girder and Span properties of each component have already been entered. The elements to be automatically identified were 18 sections, 14 diaphragms, and 12 crossbeams. Algorithms were first applied to the sections, and subsequently to the diaphragms and crossbeams. The results appeared in the form of Span_ID-Girder_ID-AssembledAssembly_ID-PartsAssembly_ID, using the elements of the set proposed in Equation (1). The 44 individual components all contained the identifiers in the correct format, as shown in the following example. During this process, for objects that extend over multiple elements, we adopted the expression of all included elements. This was true in the case of D, where the property Girder_1,Girder_2 was generated as the Girder property. As mentioned earlier, the Girder and Span properties of each component have already been entered. The elements to be automatically identified were 18 sections, 14 diaphragms, and 12 crossbeams. Algorithms were first applied to the sections, and subsequently to the diaphragms and crossbeams. The results appeared in the form of Span_ID-Girder_ID-AssembledAssembly_ID-PartsAssembly_ID, using the elements of the set proposed in Equation (1). The 44 individual components all contained the identifiers in the correct format, as shown in the following example. During this process, for objects that extend over multiple elements, we adopted the expression of all included elements. This was true in the case of D, where the property Girder_1,Girder_2 was generated as the Girder property.

Discussion
To verify the applicability of the bridge information model containing functional semantic information, we examined whether it can be applied to the basic quantity take-off of an actual bridge and information linkage with the external information, and whether it is possible to regenerate a model through an IPF-based semantic search. In an actual bridge design process, the result of the quantity take-off includes the as-built structure, the temporary facilities, and the components of the discarded part. However, this study aimed to examine whether the retrieval of the functional components can be used for quantity take-off. Therefore, only the as-built bridge model as appearing in the design document was used for the quantity take-off. Since the material quantity in the final product directly relates to the volume of the product, there is no room for problems, as long as the geometric information is correctly processed. However, for a more advanced form of decision-making support, such as the quantity take-off of bridge members with identical functions, or the quantity take-off of a specific member, the model must be able to provide information in various forms. This involves the critical requirement of accurate identification information for the bridge components, which can be said to be redundant geometries that represent the real world. For example, while a crossbeam and the main girder of the bridge can be identically represented as physical objects, these elements clearly have different functions, which require that the quantity take-off is considered separately for these two elements. Therefore, the process of applicability verification of the bridge information model in this study was as follows.
(1) The bridge information model was generated using BIM authoring software.
(2) The semantic information concerning the necessary bridge components was generated by the user, using Figure 8 or Algorithm 1. (3) Identifiers of the members were generated using the automated naming method. (4) The model applicability based on the bridge components and identifiers was examined. (5) Using the generated IPF, the semantics-based model regeneration of bridge components was examined.

IFC-Based Model Implementation of a Steel Box Girder Bridge Structure
To examine the applicability, some parts of the real steel box girder bridge were modeled using developed IFC and user-defined PSETs in this study. Figure 11 shows the standard cross section and current endpoint of the steel box interval of the target bridge that was modeled. The actual bridge consists of a total of 34 spans, and has a length of 1441 m. In this study, two span intervals were examined, with each span being 50 m. Figure 12 shows the result of the detailed design-level modeling based on the design drawings. As shown in the figure, each bridge component contains a corresponding identifier. Basically, the process of generating such information entails repetitive manual operations. In this study, we could reduce the information-generating time through multi-selection of objects as well as the use of applied object libraries (in the case of Autodesk-Revit families) that include the basic and shared data. Figure 13 is the IFC-based bridge information model generated through the integration of geometric model and semantic identifiers in accordance with a process of Figure 7. The model objects and properties have been checked via Solibri Model Checker. Additional information on identification could be found on the info tab with the name of the PSET. manual operations. In this study, we could reduce the information-generating time through multiselection of objects as well as the use of applied object libraries (in the case of Autodesk-Revit families) that include the basic and shared data. Figure 13 is the IFC-based bridge information model generated through the integration of geometric model and semantic identifiers in accordance with a process of Figure 7. The model objects and properties have been checked via Solibri Model Checker. Additional information on identification could be found on the info tab with the name of the PSET.

Quantity Take-Off Check Using the Bridge Data Model
The basic quantity take-off was derived using the steel box girder bridge information model, and the result was compared to the design drawings for that bridge. Table 4a shows part of quantities specified in the design drawings, while Table 4b shows the quantities corresponding to the Figure 13.
Steel box girder bridge information model based on the IFC with Pset_SteelBoxBridgeComponentsIdentification.

Quantity Take-Off Check Using the Bridge Data Model
The basic quantity take-off was derived using the steel box girder bridge information model, and the result was compared to the design drawings for that bridge. Table 4a shows part of quantities  specified in the design drawings, while Table 4b shows the quantities corresponding to the components in Table 4a, calculated using the information model. Functions provided by Revit were used for the quantity take-off based on the information model.
In terms of the quantities of each component, the results were identical. However, the quantity take-off results were provided in a faster and more detailed manner, as compared with the previous method of using the design drawings. The specific name of each component, as well as the corresponding quantity and quantity, can be provided in a specific form. For example, compared to "Horizontal stiffener" in Table 4a, "Horizontal stiffener" in Table 4b is separated into two elements. Nevertheless, while comparing the results, it was noted that the representation of components differed between the users, requiring additional manual tasks for adequately identifying the components.

Estimation of Carbon Emission Using IFC-Based Bridge Information Model
The United Nations Framework Convention on Climate Change (UNFCCC) has suggested that all nations should attempt to reduce greenhouse gas emissions. A large amount of carbon is emitted from civil engineering structures. However, the amount of carbon emitted has not been calculated perfectly because structural stability has received more emphasis and detailed assessment processes for such calculations do not exist at this time. Carbon emissions are calculated by employing a method that estimates an emissions source unit based on the embodied energy generated during the production of the material that is used over the whole life cycle of the facility. However, the proposed guidelines are based on material or equipment units according to the work process rather than the component unit of a facility. Therefore, from the viewpoint of the product, directly examining the effect of carbon emissions via components is disadvantageous. This study did not aim to accurately calculate the carbon emissions generated from bridge structures; rather, it attempted to verify whether the carbon emissions calculated for the structure and stored in the BIM data can be meaningfully reused. This study considered the following elements for carbon emissions calculations:

1.
Quantity: Utilization of the volume from the viewpoint of the product, based on the design phase.

2.
Identification: Utilization of the IFC and the IFC user-defined PSET proposed in previous sections.
Carbon emissions were estimated using a calculation method, in which each component in the structure is multiplied by a carbon emissions factor, as shown in Equation (4), by referring to "the carbon emissions calculation according to material input", as proposed by Ministry of Land, Infrastructure and Transport of Korea [48].
where i is an object identifier of object information OI equivalent to the total number of objects in the structure. In other words, the carbon emissions estimation was conducted for each individual component of the structure. A method of summing the emissions of individual components was used to calculate the total carbon emissions. EF CO2 is the carbon emissions factor. In this case, a carbon emissions factor of 430.87 kgCO 2 /m 3 (ready-mixed concrete No. 25-240-15) was used for concrete material. A unit weight of 7850 kg/m 3 and a carbon emissions factor of 0.4 kgCO 2 /kg were used for steel materials. The unit weight of asphalt concrete was 2340 kg/m 3 and its carbon emissions factor was 0.01 kgCO 2 /kg. The emissions factor and estimated carbon quantity of the component were saved so that the calculated result can be reused for other applications. This study additionally defined an IFC user-defined PSET to save the obtained information, as listed in Table 5. Table 3 is used to present the semantic information of components. The results were checked by applying the carbon emissions calculation process to the bridge information model. Table 6 shows a part of the carbon emissions for one span in a superstructure of the bridge model, and Figure 14 shows the IFC-based information model including carbon emissions-related information using PSET.
The estimated carbon emissions were calculated as 1068.65 tCO 2 for the bridge information model. It is difficult to say that the results have engineering implications. However, the results can be quickly reviewed for each of the detailed components. BIM model is advantageous for the management of new knowledge, such as carbon emissions, which is induced by digital models and external factors. In other words, BIM is effective at utilizing an external DB depending on the situation. In this study, however, the additional information was stored in the independent building information model to confirm that it is possible to extract or search for the needed result according to the specific component or detailed condition. Therefore, the estimation process has been simplified. It is worthwhile referring to the study of See et al. [49] when applying BIM's Information Delivery Manual (IDM) process, or the study of Choi et al. [50], which reflects LoD, to estimate the detailed quantity take-off or carbon emissions using BIM.

Extraction Test Based on Semantic Meaning of Steel Bridge Components
The IFC-based bridge information model proposed in this study has computer-understandable identification information within the model itself. Consequently, in this study, it was examined whether each object corresponding to the identification information of the components was extracted, using the generated IPF.
Mazairac and Beetz [51] proposed the Building Information Model Query Language (BimQL) to enable the extraction of certain values from a model in an IPFF format. However, this is currently at the research level, and supports the extraction of certain information only, with the combination of query results not being supported. Therefore, in this study, we developed an information extraction module based on the property value query from the IFC PSET, with reference to the grammar of the BimQL. The module developed in this study addresses the property values of the IfcPropertySet only, as the development of generalized BIM query terms was considered beyond the scope of this study. Algorithm 2 shows the underlying code for regenerating queried objects or retrieving the results based on PSET data. Input data are query sentence and the "Population" is the same as that of Algorithm 1. The query sentence was separated into the required words by string support Java library. The entry IFC entity is IfcPropertySet stored in the "Population" (Lines 1-3), and the search scope was reduced by comparison between the name of IfcPropertySet and the name of the input PSET (Lines 4 and 5). The objects to be extracted can be specified by comparing the attributes of the IfcProperty included in the IfcPropertySet and the identifier of the bridge component (Line 6-12). One of the subtypes of the IfcObjectDefinition connected with IfcPropertySet can be derived through a findRelatedObjects function (Line 13). Figure 15 shows the UI module developed according to Algorithm 2. Ifcpropertyset in Figure 2: IfcPropertySet class included in the Population 4 if (Ifcpropertyset.getName() == qs.EntityType) 5 SetIfcproperty: set of IfcProperty in Figure 2  6 checking (HasProperties) in Figure 2  7 while (SetIfcproperty.hasNext()) 8 Ifcproperty in Figure  The query format was fundamentally based on the items defined in Table 3, and the instances generated during the bridge information modeling. Query Sentence (1) shows the extraction of all objects(*) that include the identifier, "Diaphragm" from the target bridge model, of which the result is shown in Figure 16. In Query Sentence (1), Var1.ALL represents the calling of all entities that are connected to Var1. Moreover, the pier models in Figure 16 were deliberately added to determine the location of each diaphragm, and are irrelevant to Query Sentence (1). Figure 16 shows 44 diaphragms, which appear to be identical to those shown in Figure 11. The query format was fundamentally based on the items defined in Table 3, and the instances generated during the bridge information modeling. Query Sentence (1) shows the extraction of all objects(*) that include the identifier, "Diaphragm" from the target bridge model, of which the result is shown in Figure 16. In Query Sentence (1), Var1.ALL represents the calling of all entities that are connected to Var1. Moreover, the pier models in Figure 16 were deliberately added to determine the location of each diaphragm, and are irrelevant to Query Sentence (1). Figure 16 shows 44 diaphragms, which appear to be identical to those shown in Figure 11.
Query Sentence (1):  It was examined whether relevant objects can be extracted based on a specified instance only, regardless of the upper-and lower-levels of a specific element. Query Sentence (2) is a request for the extraction of objects containing the identifier, "Section_2" from the instances of Assembled Assembly. This is possible since only "Assembled Assembly" is selected as the object extraction criterion. Figure  17a shows the corresponding result. Four Section objects were extracted, with each object containing sub-level elements of Parts Assembly and Part.
Query Sentence (3):  SELECT $Var1.ALL WHERE $Var1.EntityType = IfcPropertySet AND $Var1.Name = "Pset_SteelBoxBridgeComponentIdentification"  SELECT $Var2 := $Var1.Attribute.HasProperties  SELECT $Var3 := $Var2.Attribute WHERE $Var3.Name = "Span" AND $Var3.NominalValue = "Span_1" It was examined whether relevant objects can be extracted based on a specified instance only, regardless of the upper-and lower-levels of a specific element. Query Sentence (2) is a request for the extraction of objects containing the identifier, "Section_2" from the instances of Assembled Assembly. This is possible since only "Assembled Assembly" is selected as the object extraction criterion. Figure 17a shows the corresponding result. Four Section objects were extracted, with each object containing sub-level elements of Parts Assembly and Part.
Query Sentence (2) Additional information, such as carbon emissions associated with the object, was reviewed. Query Sentence (4) retrieves the carbon emissions stored in the IPF by utilizing an identifier in the bridge component.
Query Sentence (4): Additional information, such as carbon emissions associated with the object, was reviewed. Query Sentence (4) retrieves the carbon emissions stored in the IPF by utilizing an identifier in the bridge component.
Query Sentence (4) The difference between Query Sentence (4) and Query Sentences (1)- (3) is that the former only retrieve information on the corresponding object because the "ALL" keyword is not used. Accordingly, the query response is 410.56, which is a result that verifies that the information of the corresponding object can be utilized according to the user's needs. Table 7 shows the results derived using such a method. These results imply that it is possible to semantically extract the model data or regenerate the information model depending on the user's need using the bridge information model, which contains identification information in a clear manner.

Conclusions
Currently, IFC has been firmly established as the standard data schema for BIM. Most BIM authoring software packages support the input and output of IFC format, and, as a result, BIM models generated in IFC format can be utilized with various application software. However, the current IFC addresses building structures only, and hence cannot be used for bridge structures, except for its geometrical information.
We propose a method that overcomes the limitation that the information modeling of a steel box girder bridge based on IFC cannot support the generation of semantic information for the components of bridge structures. For this purpose, the components of a steel box girder bridge were classified into those used during the fundamental planning, fundamental design, and detailed design phases, and the items necessary for the generation of semantic information were selected based on this classification.
The items necessary for the generation of functional semantic information were largely classified into spatial and physical aspects, to allow the simultaneous consideration of both the meaning from the location of the component, and the functional meaning from the properties of the component. To include the semantic information in the IFC-based steel bridge information model, we propose a method of identifying the constituent elements of the information model. Using the method described, it could be reflected in the IFC model through the user-defined PSETs of the framework of IFC. In addition, to verify the architectural validity of the IFC with the generated semantic identification information of the bridge components, an actual IPF was generated, and its internal data were examined. In this process, it was troublesome to generate the unique identifier through repetitive manual operation in the case of a component (e.g., a cross beam) including small elements and a plurality of elements. However, we could improve the speed using the object library with the unique identifier and applying the automated naming algorithm for the identification of bridge components. The generated bridge information model was used to confirm the functional semantic meanings of individual components, and it was checked whether additional external information such as carbon emissions could be linked for specific bridge components. It was observed that a semantic search for each bridge component is possible by generating a bridge information model in an IPF format. Through this process, we reviewed and discussed the applicability of bridge information model. The usefulness of the generated identification information of the bridge components was high. It was effective to obtain the information on the detailed components in cases of quantity take-off and carbon emissions estimation as well as object extraction and information retrieval by applying query language to the IPF.
While BIM based on an IFC data model is central to the interoperability of information, it is still insufficient for implementing true BIM models owing to the absence of support of IFC for bridge structures. Ultimately, a data model that supports bridge structures, or even all civil structures, must be developed, and relevant works are in progress. However, an appreciable amount of time is required for end-users to utilize the data models, since they must be continuously updated. Thus, specialized software that supports the updated model must be subsequently developed for its application. The information modeling of the steel bridge using IFC and user-defined PSETs proposed herein enables additional external data to be applied in the information model while maintaining the current IFC frame. It helps to reduce the constraints on the creation of an accompanied functional meaning when IFC-based information modeling is carried out on facilities such as civil infrastructures other than buildings in the current BIM environment. Moreover, the method for automated identification of components can be applied regardless of the data model type, which is thought to be a highly useful feature, considering that this can be applied to civil structures other than steel box girder bridges in the future.