## 2 Related Works on Bridge Data Schemas
### Bridge Data Schemas Using EXPRESS
#### 2.1.2 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 [PERSON] and [PERSON] [30] and [PERSON] 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.  
[PERSON] and [PERSON] [20] proposed an IFC extension model for road structures, which includes bridges as a sublevel structure. [PERSON] and [PERSON]'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 [PERSON] et al. [PERSON] et al. (2018), 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.