## 3 IFC-Based Bridge Information Modeling with Document Metadata
### Assistant Module for Integrated Management of Bridge Model and Document Information  
We developed a module to manage 3D model information, reflect the extended IFC-based bridge, and enable information retrieval for engineering documents related to bridge segments. The module was based on the Revit API provided by Autodesk [27], a representative BIM authoring tool. This enabled the integration of the extended IFC and engineering document retrieval in the Revit environment. We used the original functions provided by Revit to generate a 3D geometric model (Figure 7a). We modeled the components using general or building elements corresponding to bridge components referred by the concept of [PERSON] et al. 's [2] previous research for bridge components, such as bridge piers, that Revit cannot provide. As a note, to connect with the extended IFC entities for the bridge structure, each component should be created as one object. As a preliminary procedure, the user should directly generate spatial objects suitable for bridge and bridge components to apply IFC entities (see Figure 7b). This module suggests an appropriate IFC entity by parsing the EXPRESS files of the extended IFC schema for the spatial object, as depicted  
Figure 6: EXPRESS-G diagram to manage bridge model and document meta data; the shaded boxes denote extended entities for the bridge structure. in Figure 7c. All 3D physical objects of the bridge collected automatically through the Revit API can be mapped with an appropriate IFC entity using the interface shown in Figure 7d. The appropriate IFC entity can be suggested through the basic information included in the object, such as the object's family name and description. If the object information has a specific code or words included in the product breakdown structure (PBS) document developed in this study, then the physical object can be mapped precisely with the corresponding IFC entity using this PBS document. The PBS document comprises ab element code (_value_ attribute), name (_label_ attribute), IFC entity of the extended IFC-based bridge schema (_IfcEntityName_ attribute), the IFC4 entity (_Ifc4 EntityName_ attribute), and the description (_description_ attribute). Figure 8 shows a part of the PBS document developed in this study. In this module, the model object can be connected to not only the IFC schema entities developed for bridges, but also to the IFC4 entities, such that other commercial BIM authoring tools can utilize the IFC data generated through this module. Figure 9 shows a part of the iMapDoc containing essential information for the conversion to an extended IFC-based IPF, as well as for connecting a 3D object, IFC, and document fragments. We have designed the iMapDoc based on XML that can generate a relationship between bridge components, as well as connect attributes on the corresponding components. Various tested computer libraries related to the use of XML enable us to skip the verification process of the designed XML schema (iMapDoc). The _Project_ element in line 2 of Figure 9 stores the entire project-related information included in Revit, and is an element that is mapped with the _IfcProject_ entity and its attributes of the IFC schema. The child elements of the _StructuralElement_ in line 3 are mapped with the physical/spatial entities of the IFC. We used the _IfcSite_ entity as the topmost element of all of the spatial elements. The spatial objects generated by the user, shown in Figure 7b, are arranged as _IfcSite_'s sub-entities. The spatial element representing the entire bridge itself is mapped to _IfcBridge_ as an extended schema entity and _IfcBuildingStorey_ as an IFC4 entity (line 7 of Figure 9). In this case, the _IfcBuilding_ entity can be substituted for _IfcBuildingStorey_. Since no entities support bridge structures in IFC4, it is not essential to consider which entities of the IFC4 are used in this study. The entity just needs to be a spatial entity.