## 4 Experimental Verification via Retrieval of Document Fragments Related to the 3D Model Object
### Connection Review of the Retrieved Document Fragments and the 3D Model Objects  
Figure 13 shows a part of the data of the retrieved structured engineering document related to the _Concrete_Pier_ object under _Pier_2_4. These data are presented in Figure 7e, where the results are shown in a list view (1) of Figure 14). _Pier_2-4_, as well as its parent and children elements, can be used to retrieve _Concrete_Pier_-related elements and information because the object selected in Figure 7b is synchronized with iMapDoc (see line 19 of Figure 9 and 2 of Figure 14). The _Dictionary for synonyms_ database was also used to retrieve the related content. The results selected by the user among the retrieved document contents are integrated with the IPF. The connection information between the 3D object and document content is stored in the _Doc_ element in iMapDoc, as shown in line 23 of Figure 9 (3 of Figure 14). The connection information indicates the location of the related document content translated into XML format according to the method described in Section 2 using XPath; line 23 of Figure 9 represents. _/ pier_design(@header = 9.]_. The _Doc_ element can be added to all children elements of _StructureElements_ of iMapDoc. The selected object from the 3D model or iMapDoc can be connected to the IFC entity mutually through the element name and the _GlobalId_ attribute of the iMapDoc. Figure 15 shows a part of the IPF generated using a developed converting module including the _Pier_2_4 object. The _Pier_2_4 object was implemented as the _IfcBridgeSpacePart_ entity, and its attributes are consistent with the attributes of _GlobalId_ and _Data_ in line 17 of Figure 9. _Concrete_Pier_ was implemented as the _IfcBridgePier_ entity, as shown in #2976952 in Figure 15, corresponding to line 19 of Figure 9 (4 of Figure 14). The elements of iMapDoc and the entities of IPF share the entity name and global ID; the IFC and Revit are connected through the information of _OidInSWDB_ and _PBSCode_ stored in iMapDoc. The _Representation_ attribute representing the shape information of the _IfcBridgePier_ entity uses a subtype of the _IfcProductRepresentation_ attribute. The _Price_ attribute is represented by the _Price_ attribute. entity, and the _IfcProductDefinitionShape_ entity is used for the representation, as shown in #1273678. The actual data are implemented using the _IfcShapeRepresentation_ entity (#1274058), which utilizes the information in line 24 of Figure 9 (S) of Figure 14). The _IfcBridgeSpacePart_ (#2971755) and _IfcBridgePier_ (#2976952) were connected through the _IfcRelContainedInSpatialStructure_ entity (#1268533) since they are spatial and physical entities defined by the extended IFC, respectively. The _pier_design_-related information (line 23 of Figure 9) of the engineering document connected to the object of _Concrete_Pier_ (line 19 of Figure 9) represents the _IfcDocumentInformation_ entity (shown in #4852759 in Figure 15). Among the 17 attributes of the _IfcDocumentInformation_ entity in the IFC4 schema, we generated values for attributes _Identification_, _Name_, _Description_, _Location_, _ElectronicFormat_, and _Status_ automatically based on iMapDoc. The _Identification_ attribute is used to identify documents, and the value data (_pier_design_-_p5 MyBLhGB06 HLAvQv7x8 RA_) combined with the name (_pier_design_) of the connected document fragment and the _GlobalId_ attribute data (_p5 MyBLhGB06 HLAvQv7x8 RA_) of the parent element (_Concrete_Pier_) are used (S) of Figure 14). The document fragment name (_pier_design_) is used for the _Name_ attribute, and the file name of the XML-formatted construction document (_Jaenechon_.xml_) is represented in the _Description_ attribute. The _Location_ attribute specifies the location of the document in the form of a uniform resource identifier (URI); it (_Jaenechon_/_pier_design_(_@header_ = 9.))