## 2 Related Works on Bridge Data Schemas
### 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_.  
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.  
\begin{table}
\begin{tabular}{c c c c} \hline
**Bridge Data Model** & **Feature** & & **Limitations** \\ \hline \multirow{3}{*}{AP 203-based Models} & Initial bridge data model & - & Logically impossible to identify the spatial structure \\  & based on open data schema & - & Non-consideration of the classification system of the bridge structure \\ \hline \end{tabular}
\end{table}
Table 1: Bridge data model comparisons mentioned in this study. IFC: Industry foundation classes;  
Figure 1: Industry foundation classes (IFC) and sets of properties.  
Figure 2: Object, property, and relationship in IFC architecture focused on _IfcPropertySet_.