1.1 연구의 배경

최근 스마트건설 확대 기조에 따라 건설 데이터 활용의 중요성이 높아지고 있다. 예컨대 유지관리 단계에서는 시설물 점검·진단, 성능 예측 등의 목적으로 시설물 정보, 시설물의 기하 정보, 계측 및 위치 정보, 유지관리 정보 등이 연계 활용된다. 최근 국내 항만 유지관리 분야에서 항만시설의 관리체계를 BIM(Building Information Modeling) 환경으로 구축하려는 시도가 있다. ^{Moon (2020)}은 항만 BIM 표준을 개발하여 항만시설의 설계 및 유지관리 정보를 BIM 표준 기반 디지털 정보로 체계화하였으며, BIM 플랫폼을 개발하여 시범 적용한 바 있다. 하지만 항만 사업 및 유지관리 정보는 개별 DB(Database)로 구축되어 사일로(Silo) 형태로 분산되기 때문에 이와 연관성 있는 데이터 간 연계와 활용이 제한적이다. 또한 IFC(Industry Foundation Classes) 등 BIM 데이터 스키마를 통한 정보 교환 및 연계 방식은 BIM과 웹상의 외부 자원과의 연결이 불가하다는 한계가 있다^{(Rasmussen et al., 2021)}. 즉, 항만시설 정보를 담고 있는 BIM 정보와 항만 사업 및 유지관리 정보의 관리체계가 다르고 정보의 단절로 인해 이들 정보의 연계 활용 및 통합 관리에 어려움이 존재한다.

한편 링크드데이터(Linked Data, 이하 LD)는 데이터 융합기술 중 하나로, 웹 데이터의 의미적 표현과 상호 연결을 통해 구조화된 데이터이다^{(Berners-Lee, 2006)}. 최근 건설 분야에서도 이기종 데이터 간 상호 연결성 확보, 데이터 공유 및 재사용 등을 목적으로 LD 구축 및 관련 온톨로지 개발 사례가 발표되었다^{(Erdene et al., 2020; Lee et al., 2016; Pauwels and Terkaj, 2016; Rasmussen et al., 2021)}. ifcOWL 온톨로지(ifcOWL은 BIM 표준 규격인 IFC(Industry Foundation Classes) 스키마를 OWL(Web Ontology Language)로 표현한 온톨로지이다. (출처: https://technical.buildingsmart.org/standards/ifc/ifc-formats/ifcowl/))^{(bSI, 2016)}는 BIM 표준 데이터(IFC)를 다양한 웹 데이터와 의미 기반으로 연계 활용할 수 있도록 하는 지식체계를 제공한다. 본 연구에서는 항만 BIM 표준인 항만 IFC(IfcHabour_K)에 포함된 형상과 속성이 갖는 정보를 의미론적으로 연결하여 네트워크 관점으로 시설 구성 요소의 관계를 추론하고 BIM 정보의 접근성을 높이기 위해 ifcOWL 온톨로지를 활용한다. 이를 토대로 국내 항만 유지관리 분야에서 운영되는 폐쇄적인 데이터 활용체계를 개선하고 BIM 데이터의 연결성과 미래에 축적되는 유지관리 데이터와의 연계 확장성을 높이기 위해 LD 기반으로 항만 BIM 데이터와 유지관리 데이터의 통합 및 활용방안을 제시하고자 한다.

1.2 연구의 목적 및 범위

본 연구는 선행연구^{(Moon, 2020)}에서 개발된 항만 BIM 플랫폼에 축적되는 BIM 정보와 사업 및 유지관리 정보를 이용하여 BIM 표준 기반 항만 유지관리 정보의 LD를 구축하는 것을 목적으로 한다. BIM 정보는 부산 신항 등 지방청 또는 항만공사에서 운영하는 항만시설을 BIM 모델로 구축하여 항만 IFC(IfcHarbour_K)로 변환된 데이터셋^{(Moon et al., 2020)}이다. 시설 및 사업정보는 항만 BIM 플랫폼을 구성하는 항만시설 유지관리 의사결정 시스템^{(Na et al., 2022)}의 유지 이력관리 정보와 항만 BIM 브라우저^{(Hyun and Ko, 2021)}의 항만 프로젝트 관련 정보이다.

본 연구의 수행 절차 및 산출물은 Fig. 1과 같다. 본 연구에서는 LD 구축 대상으로 BIM 시범사업인 부산 신항 2-1단계 3부두 시설의 BIM 정보와 사업·유지관리 정보를 선정하였다. LD 구축에 앞서 항만시설 데이터의 생성과 상호 연결을 체계화하기 위해 두 가지 온톨로지 모델을 설계하였다. 항만시설 데이터는 온톨로지의 지식 체계에 따라 RDF(Resource Description Framework) 구조로 변환 및 매핑되고, LD 발행 규칙에 따라 웹 상의 자원을 식별하기 위한 고유의 URI(Uniform Resource Identifier)가 부여된 데이터로 구축되었다. 마지막으로 구축된 LD의 활용성을 검증하기 위해 LD로 구축된 데이터에 질의를 수행하기 위한 표준 질의 언어인 SPARQL(SPARQL Protocol and RDF Query Language)을 활용하여 질의 테스트를 실시하고, LD 응용 및 데이터 서비스 프로토타입을 구현하여 기능성을 검토하였다.

Fig. 1. Research Scope and Procedures

2.1 BIM 기반 링크드데이터 구축 및 활용 연구

buildingSMART International(이하 bSI)의 BIM 표준(IFC)은 중립적이며 개방적인 교환 포맷으로 소프트웨어 간 상호 호환성을 제공한다^{(bSI, 2013)}. 하지만, IFC 스키마 명세언어의 한계로 인해 IFC는 지식 표현과 추론에 제한적이며, IFC 데이터는 웹 데이터와의 직접적인 연계가 어렵다. 이러한 문제를 해결하고자 ^{Pauwels and Terkaj(2016)}는 시맨틱 웹 기술을 바탕으로 IFC를 표현하는 웹 온톨로지인 ifcOWL 온톨로지를 고안하였다. ifcOWL 온톨로지는 IFC 데이터 타입별 변환 규칙을 정의하여 IFC 스키마와 유사한 형태로 설계되었다. 현재 bSI에서는 IFC2X3 버전부터 IFC4.1 버전까지 다양한 버전의 ifcOWL 온톨로지를 구축하였다^{(bSI, 2016)}. 하지만, ifcOWL은 IFC 스키마가 방대하고 복잡하다는 근본적인 한계점을 그대로 수용하고 있어서 새로운 접근의 필요성이 제기되었다^{(Rasmussen et al., 2021)}.

W3C LBD CG(Linked Building Data Community Group)는 ifcOWL의 한계점을 극복하기 위해 단순하고 모듈화된 온톨로지를 제안하고 개발하고 있다. ifcOWL 등 기존 온톨로지와의 연계를 고려하여 건물 전 생애주기에서의 LD 활용 유즈케이스 및 요구사항을 정의하고 건물-건물요소 및 부품-부품속성을 설명하는 온톨로지 모델인 BOT(Building Topology Ontology)을 발표하였다^{(Rasmussen et al., 2021)}. BOT 온톨로지의 경우 bot:Building, bot:Element, bot:Space 등 7개 클래스가 정의되었고, 관계 속성인 Object Property(bot:adjacentElement, bot:containsElement 등 14개)와 데이터타입 속성인 DatatypeProperty(bot:hasSimple3D Model)로 구성되었다.

^{Lee et al.(2016)}은 건설 하자정보의 공유와 활용 체계를 개선하기 위해 LD와 BIM을 융합한 시스템 프레임워크를 제안하였다. 이는 하자정보의 생성, 저장, 검색, 공유 및 활용 모듈로 구성되었다. 하자정보의 제반 과정을 체계화하고 시스템으로 연계하기 위해 하자정보 온톨로지를 개발하고, 온톨로지에 따라 개별 하자 사례에 포함된 문서 정보와 관련 BIM 작업상황 정보를 자동 추출하여 RDF 포맷으로 변환하는 도구를 개발하였다. 이를 통해 기존에 분산되어 있던 하자 정보가 BIM 정보와 의미적으로 연결되어 통합적인 활용이 가능함을 보여주었다. ^{Zhou et al.(2023)}은 이기종의 댐 안전 모니터링 지식 정보(Dam Safety Monitoring System, 이하 DSMS)의 통합적 관리를 위해 BIM 기반 DSMS 도메인 온톨로지인 OntoDSMS 온톨로지를 제안하였다. Onto DSMS 온톨로지는 기존 센서 모니터링을 위해 정의된 SSN(Semantic Sensor Network)와 SOSA(Sensor, Observation, Sample, and Actuator) 온톨로지를 기반으로 확장되었다. DSMS 관련 DB 데이터와 BIM 데이터는 제안된 온톨로지로 매핑된 후 RDF 구조로 변환되어 SPARQL 질의, 지식 추론 등에 활용되는 체계로 구축되었다. ^{Farghaly et al.(2022)}는 예방적 안전관리를 위한 설계 안정성 검토(Design for Safety, DfS) 측면에서 요구되는 건설 안전관리 정보 모델인 Safety and Health Exchange(SHE) 온톨로지를 개발하였다. 또한, IFC 정보와의 상호운용성을 고려하여 SHE 온톨로지와 ifcOWL 온톨로지 간 매핑을 제안하였으며, BIM 협업 솔루션인 3D Repo 플랫폼을 기반으로 SPARQL 질의를 통해 온톨로지 및 매핑의 의미적 일관성을 평가하였다. ^{Li et al.(2022)}는 시맨틱 웹 기술을 활용한 BIM 기반 철도 공사 안전 점검 자동화를 목적으로 철도 공사 안전 점검 온톨로지(Subway Construction safety checking Ontology, SCO)를 개발하고 SPARQL 기반의 안전리스크 룰 체킹 프레임워크를 제안하였다. 제안된 온톨로지는 공사 절차, 안전 규정, 엔지니어링 정보, 안전리스크 요인 관련 4가지 하위 도메인 온톨로지로 구성되며, 이를 의미적 관계로 연결하여 개발되었다. 본 프레임워크에 따라 BIM과 센싱데이터로부터 추출된 안전리스크 요인 데이터는 SCO 온톨로지의 논리구조에 따라 RDF 형식으로 변환되며, 텍스트로된 안전리스크 규정은 자연어 처리 기술을 활용하여 SPARQL 기반의 룰로 자동 생성되었다.

건설 분야에서 BIM기반 링크드데이터 기술 응용연구는 다양한 건설 데이터와 BIM 데이터의 융합을 통한 지식 정보 체계화를 위해 활용 목적별로 특화된 온톨로지를 개발하거나, BIM기반 응용 기술 개발을 위한 BIM 데이터 추출 및 RDF 구축을 중심으로 수행되었다. 특히 bSI의 ifcOWL 온톨로지는 현재 다양한 건설 분야와 단계에 시험적으로 적용되어 IFC 데이터를 웹 데이터와 연계하고 공유하기 위한 정보체계로 활용되고 있다. 본 연구에서는 항만 BIM 데이터를 RDF 구조로 변환하는 기준으로 bSI의 ifcOWL 변환 규칙을 적용하였다.

2.2 항만분야 BIM 표준 개발 연구

항만시설은 국가보안시설로, 다른 인프라 시설에 비하여 관리 시스템과 데이터가 폐쇄적인 특성을 가진다. 데이터가 표준화되지 않고 데이터 공유 환경이 부족한 상황을 극복하기 위해서는 시스템 간 데이터 상호 운용성의 확보가 필요하다. ^{Moon et al.(2020)}는 국내 항만분야에 BIM을 도입하여 BIM 표준 환경으로 전환하기 위한 기초 연구로, IFC를 기반으로 항만 BIM 표준을 개발 및 검증하였다. 당시 ISO16739(2013) 표준인 IFC 4를 기반으로 개발 중이었던 도로 표준안(IFC4X3 RC1)을 토대로 항만 스키마(IfcHarbour_K)를 구축하였다. 이를 위해 관련 데이터 모델과 설계 기준, 작업분류체계 등 기준을 분석하여 항만시설의 요소를 도출하였다. 항만시설의 요소는 IFC 구조에 따라 항만 공간(Ifc Facility, IfcFacilityPart 등)과 시설(IfcHarbourPart, IfcHarbour FacilityPart) 및 부재(IfcElementComponent 등)와 관련된 엔티티와 관계(IfcRelContainedInSpatialStructure, IfcRelDefinesBy Properties) 및 속성으로 정의되었다. 이때, 기존 IFC 스키마에 정의된 엔티티(Entity) 및 타입(Type)을 공통으로 활용하거나, 신규 엔티티 및 타입을 구성하였다. Ifc4X3 RC1을 기준으로 IfcHarbour_K 스키마에 신규 정의된 엔티티는 25개, 타입은 Enumeration data type 16개이며, 대부분은 기존 엔티티의 사전정의유형(PredefinedType)의 값으로 추가 정의되었다. 예를 들어, 항만시설의 공간 구조를 표현하기 위해 IfcFacility 하위에 IfcWaterway_K(하천), IfcEnvironment_K(환경), IfcLand scape_K(조경) 등 엔티티를 추가하였다. 해당 시설의 세부 유형은 IfcFacilityPart의 사전정의유형인 IfcWaterwayTypeEnum_K, IfcEnvironmentTypeEnum_K, IfcLandscapeTypeEnum_K으로 정의하였다. 항만시설을 구성하는 구조물 및 부재를 표현하는 경우도 마찬가지 방식으로 정의되었다. 예컨대 방파제, 안벽 등은 기존 IFC에 정의되어 있는 IfcMarineFacility(항만&해양) 엔티티를 그대로 활용하되 IfcMarineFacilityTypeEnum 값인 BREAKWATER_K(방파제), QUAYWALL_K(안벽) 등이 새롭게 정의되었다.

2.3 항만 IFC 기반의 ifcOWL 개발 접근 방법

BIM 표준에 기반한 온톨로지와 데이터와의 관계는 스키마와 인스턴스 관점으로 설명될 수 있다. 온톨로지는 스키마 관점에서 건설 도메인을 구성하는 개념과 속성을 EXPRESS 또는 OWL을 활용하여 정의한 명세이다. ifcOWL은 Table 1과 같이 IFC 스키마의 entity, type 및 속성 등을 OWL의 클래스와 속성으로 변환 설계된 온톨로지이다^{(Pauwels and Terkaj, 2016)}. 데이터는 온톨로지와 스키마에 정의된 개념에 따라 표현된 인스턴스로, bSI에서는 BIM 데이터를 RDF 형식으로 유통하기 위해 IFC 인스턴스 파일을 ifcOWL 온톨로지 체계에 따라 RDF 파일로 변환하는 방식을 적용하고 있다.

본 연구에서는 항만 BIM 데이터를 활용하여 LD를 구축하기 위해 IfcHarbour_K를 두 가지 접근 방법을 적용하였다(Fig. 2). 첫 번째는 항만 BIM 기반 온톨로지 설계를 위한 접근 방법으로, IfcHarbour_K 스키마를 Table 1의 변환 규칙에 따라 변환하여 기존 ifcOWL를 수정하였다. 두 번째는 LD 구축 대상인 원천 데이터 생성을 위한 접근 방법으로, BIM 모델로 구축된 항만시설을 IfcHarbour_K 표준에 따라 IFC 데이터로 변환하였다. IFC 데이터는 추후 ifcOWL 온톨로지에 따라 RDF 데이터 구조로 변환된다.

Fig. 2. ifcOWL Development Approach Based on IfcHarbor_K

3.1 항만 유지관리 정보체계 및 온톨로지 설계 방법론

항만 온톨로지 모델은 BIM 기반 항만 유지관리 정보의 논리적 표현을 위한 지식 체계로, 크게 세 가지 방법론이 제안될 수 있다. 첫 번째는 항만 BIM 표준(IfcHarbour_K)에 따라 기존 ifcOWL을 보완하고 이를 단독으로 사용하는 방법이다. 이 경우 항만시설의 사업정보와 유지관리 정보를 BIM 모델에 입력해야 하는 추가 작업이 요구되며, 모델에 담지 못하는 정보는 RDF로 생성될 수 없다. 두 번째는 항만 BIM 표준을 반영한 ifcOWL과 항만시설의 사업정보와 유지관리 정보의 표현을 위한 신규 온톨로지 모델을 구축하여 함께 사용하는 방법이다. 이 방법론은 ifcOWL을 기반으로 생성된 RDF와 신규 온톨로지 모델을 기반으로 생성된 RDF와의 인스턴스 매칭을 통해 연결 관계를 설정해야 하는 후작업이 요구된다. 세 번째는 ifcOWL 온톨로지를 확장하는 것으로, 항만 BIM 표준이 반영된 ifcOWL를 기반으로 항만시설의 사업정보와 유지관리 정보를 표현하는 방법이다. 이 방법론은 확장된 ifcOWL의 복잡도가 증가하고, ifcOWL의 본질이 훼손될 수 있다는 문제가 있다. 항만시설 정보의 의미적 체계를 통합하기 위해서는 세 번째 방법론인 ifcOWL을 확장하여 하나의 온톨로지로 설계하는 것이 이상적이다. 하지만 BIM 정보와 유지관리 정보의 관리 체계와 거버넌스가 다르기 때문에 온톨로지를 모듈화하여 분할하는 것이 합리적이다^{(Allenmang et al., 2021)}. 이에 본 연구에서는 두 번째 방법론인 항만시설물의 사업 및 유지관리에 관한 신규 온톨로지 모델(이하, 항만시설 유지관리 온톨로지)과 항만 표준 기반 ifcOWL(이하, 항만 ifcOWL 온톨로지)과 함께 활용하는 방법을 채택하였다.

3.2 항만시설 유지관리 온톨리지 설계

항만시설 유지관리 온톨로지를 위한 정보 표현 대상의 범위는 항만 BIM 플랫폼의 항만 프로젝트 정보 DB와 항만시설 유지 이력관리 정보 DB로 설정하였다. 대상 DB에 포함된 항만, 시설, 프로젝트와 유지관리 정보 및 성과품 정보를 종합적으로 분석한 결과, 시설 관점에서 하나의 항만시설은 특정 항만에 속하고 여러 프로젝트 정보와 유지관리 정보를 가진다는 개념과 논리적 관계를 도출하였다. 이와 같은 논리적 개념에 따라 온톨로지 설계를 위해 항만시설과 의미 연결이 가능한 데이터를 추출하였다. 항만 프로젝트 정보 DB의 경우, 프로젝트 정보, 프로젝트 성과품, 프로젝트 성과품 파일 DB 테이블 3개와 항만시설 유지 이력관리 정보 DB의 경우, 항만시설 데이터, 항만시설별 점검 이력 데이터, 시설물 보수보강 데이터, 시설 영향인자 데이터, LCC(Life Cycle Cost) 비용 데이터, LCC비용 시나리오 DB 테이블 등 8개가 해당되었다.

대상 시스템의 관리정보와 항만법 등을 참고하여 도메인 용어를 도출하고 해역, 항만, 관리기관 등 항만 정보와 항만시설 형식의 분류체계를 정립하였다. 이로부터 집합의 개념으로 표현할 수 있는 용어를 선정하고 그들 간 관계를 식별하여 클래스, 계층 구조(Subclass 관계 등) 및 속성을 구성하였다. 그 결과 항만시설 유지관리 온톨로지는 class 50개와 ObjectProperty 17개 및 DatatypeProperty 52개로 정의되었다. Fig. 3은 항만시설 클래스를 중심으로 관계가 설정된 해역과 항만, 프로젝트, 관리 기관, 점검진단 이력정보, 보강 이력정보 등과 상하위 시설 클래스 계층구조를 표현한 온톨로지 클래스와 속성의 일부를 나타낸다. 예를 들어, ‘HarborFacility(항만시설)은 Harbor(항만)에 위치하며(beLocatedIn), foaf:Organization(기관)이 소유한다(hasIntendance).’, ‘HarborFacility(항만시설)은 MooringFacility (계류시설), OuterWallFacility(외곽시설), PortTrafficFacility(임항교통시설) 등 세부유형으로 구성되며, DiagnosisRecord(점검이력) 정보를 가진다(hasDiagnosisRecords).’ 등으로 정의된다. 이때 FacilityClass, HarborType, InspectionType, Structure Grade, StructureForm 클래스는 skos:Concept의 하위 클래스로 정의하고 hasIntendance 속성의 range를 foaf:Organization으로 정의하여 FOAF(Friend of Friend)(FOAF는 사람에 대한 정보, 사람이 지닌 속성 및 사람 간 관계를 기술하는 온톨로지이다(출처: https://dbpedia.org/page/FOAF)) 온톨로지와 SKOS(Simple Knowledge Organization System)(SKOS는 지식 어휘 체계를 표현하기 위한 데이터 모델이다(출처: https://www.w3.org/TR/skos-reference/))와의 상호운용성을 확보하였다.

Fig. 3. Parts of the Classes and Properties of the Port Facility Maintenance Ontology

3.3 항만 ifcOWL 온톨로지 설계

항만시설 BIM 데이터의 LD 구축을 위해 본 연구에서는 IFC to ifcOWL 변환 메커니즘을 적용하여 항만 IFC 스키마를 OWL 온톨로지로 변환 설계(항만 ifcOWL 온톨로지)하였다. 항만 ifcOWL 온톨로지를 모델링하기 위해 IFC to OWL 프로그램^{(Pauwels and McGibbney, 2017)}을 기반으로 변환 프로그램을 개발하였다. 변환 결과, 항만 IfcOWL 온톨로지는 Class 1,521개, Object Property 1,751개, Data property 5개, Individual 1,678개로 구성되었다.

Fig. 4의 예시 (1)은 IFC 스키마의 IfcWaterway_K 엔티티에 대한 OWL 온톨로지를 나타내며, IfcWaterway_K 엔티티는 owl:Class와 Ifc:IfcFacility의 subClass로 정의되었다. 또한, Ifc Waterway_K와 같은 위계에 존재하는 엔티티인 ifc:IfcLandscape _K, ifc:IfcBridge, ifc:IfcTunnel_K, ifc:IfcRoad, ifc:IfcEnviron ment_K, ifc:IfcRailway, ifc:IfcBuilding, ifc:IfcMarineFacility은 owl:disjointWith를 통해 관계가 표현되었다. 또한, IfcWater way_K의 사전정의유형과 데이터 타입 및 Cardinality 등 제한 조건이 함께 정의된 것을 확인할 수 있다. 예시 (2)는 IfcWaterway_ K의 사전정의유형(Ifc:predefinedType_IfcWaterway_K)의 표현으로, 해당 속성은 domain 및 range가 각각 ifcWaterway_K, ifcWaterwayTypeEnum_K로 설정된 owl:FunctionalProperty로 정의되었다. 상기 두 가지 온톨로지 모델은 추후 원천 데이터인 IFC 포맷의 데이터와 DBMS(Database Management System) 포맷의 데이터를 RDF 데이터로 변환하는 과정에서 참조된다. 즉, 단절되어 있는 BIM 데이터와 사업 및 유지관리 이력 데이터는 온톨로지 체계에 따라 연계 가능한 트리플 구조로 변환될 수 있다.

Fig. 4. Example of Port ifcOWL Ontology

4.1 온톨로지 기반 데이터 변환 및 매핑 규칙 정의

본 연구에서는 원천 데이터셋을 확보하기 위해 부산항만공사에서 운영하는 부산 신항 2-1단계 3부두를 대상으로 BIM 모델과 해당 시설에 대한 가상의 사업 및 유지관리 이력데이터 셋을 구축하였다. BIM 모델은 지형, 우수공, 오수공 등 상부구조물과 안벽공 및 호안공을 포함한 하부구조물 및 철근 배근 구간으로 구성되었다. 대상 시설의 원천 데이터를 RDF 형식의 데이터로 변환하기 위해서는 변환 규칙이 필요하며, 트리플 변환기를 통해 해당 변환 규칙을 적용해야 한다. 본 연구에서는 IFC 및 DBMS 데이터를 RDF로 변환하기 위해 오픈소스 기반 프로그램인 ifcOWL 기반 RDF 변환기(https://github.com/pipauwel/IFCtoRDF)와 R2RML(RDB to RDF Mapping Language)을 지원하는 상용 프로그램인 OntoTrans 2.0(http://li-st.com/ontoTrans)을 사용하였다.

BIM 기반 항만 유지관리 온톨로지 모델을 활용한 LD의 구축은 분산된 웹 자원 간 연결을 통해 데이터의 융합된 활용을 지원하기 위함이다. 트리플 형태의 데이터 연결은 관계 연결, 개체 연결, 용어 연결 유형으로 구분될 수 있다^{(Heath and Bizer, 2011)}. 본 연구에서 다루는 항만시설 정보는 항만 프로젝트, 항만시설, 시설의 유지관리와 관련된 개체 및 속성으로, IFC 관점에서 정의하는 방식과 유지관리 사업 관점에서의 정의 방식이 상이하기 때문에 서로 다른 데이터셋에 정의된 개체와 용어 간 연결이 필요하다. 이를 위해 IFC와 DB 데이터셋에 정의된 항만 프로젝트와 시설물 명칭 및 시설물 유형에 대하여 다음의 의미적 관계를 고려하여 매핑 규칙을 설정하였다(Table 2). 1) IFC 데이터의 IfcProject Name 속성값과 DB 데이터의 prj_title 필드 속성값이 같은 경우 동일한 프로젝트이다. 2) IFC 데이터의 IfcMarineFacilityType Enum 값과 DB 데이터의 facilitytype 필드 속성값이 같고 Ifc MarineFacility Name 속성값과 DB 데이터의 name 필드 속성값이 같은 경우(시설물 유형과 시설물 명칭이 동일한 경우) 동일한 시설물이다.

두 온톨로지 모델을 기반으로 생성된 RDF 데이터는 상기 매핑 규칙에 따라 ‘owl:sameAs’ 속성을 통해 연결되었다(Fig. 5). 매핑 규칙 1에 따라 프로젝트를 의미하는 <http://kict.rdf.kr/resource/ project_BS030103>는 IFC 데이터로 정의된 <http://linkedbuild ingdata.net/ifc/resources20220216_214729/IfcProject_4123520> 등과 동일한 프로젝트로 인식된다. 또한 매핑 규칙 2에 따라 항만시설을 의미하는 <http://kict.rdf.kr/resource/facility_ 92>는 IFC 데이터로 정의된 시설 중 시설물 명칭과 항만시설의 유형이 동일한 <http://linkedbuildingdata.net/ifc/resources 20220216_214729/IfcFacility_839794>, <http://linkedbuilding data.net/ifc/resources20220216_214729/IfcMarineFacility_ 839795>, <http://linkedbuildingdata.net/ifc/resources20220215_213500/IfcMarineFacility_2144949> 등과 동일한 시설로 인식된다.

Fig. 5. RDF Data Linking Results Applying Mapping Rules

4.2 항만 BIM 시범사업 대상 링크드데이터 구축 및 활용 테스트

본 연구에서는 RDF 변환과 매핑 규칙을 바탕으로 원천 데이터셋을 트리플로 변환하여 저장 및 발행하기 위한 개발 환경으로 상용 소프트웨어인 ontoTrans 2.0(트리플 변환기)과 ontoBase 3.0(트리플 저장소), Apache Tomcat 등을 사용하였다. 데이터 발행을 위한 URI 규칙은 리소스 유형별로 http://kict.rdf.kr/onto logy/[class] (Class 타입), http://kict.rdf.kr/ontology/[property] (Property 타입), http://kict.rdf.kr/resource/[instance] (인스턴스 타입)으로 정의하였으며, 해당 규칙에 따라 데이터의 URI를 생성하였다. 발행된 항만시설 데이터는 각각의 고유한 URI를 가지며, URI를 통해 데이터의 접근이 가능해진다.

본 연구에서는 스키마 레벨에서 IFC 스키마와 DB 스키마를 각각 항만 ifcOWL 온톨로지 및 항만시설 유지관리 온톨로지로 변환하는 과정과 인스턴스 레벨에서 IFC SPF(STEP Physical File)와 DB 데이터를 RDF 데이터로 변환하는 과정을 수행하였다. 스키마 및 인스턴스 수준에서 변환된 결과물은 그 유효성에 대한 검증이 요구된다. 스키마 레벨에서의 검증은 온톨로지의 검증으로, OWL/RDF 검증 도구를 통해 온톨로지의 구조 오류를 검토할 수 있다. 인스턴스 레벨에서의 검증은 RDF 데이터 변환에 대한 검증과 활용성에 대한 검증이 가능하다. IFC to RDF 데이터 활용성에 대한 검증은 생성 및 발행된 RDF 데이터를 기반으로 SPARQL 질의언어를 통해 데이터 활용 시나리오를 적용하는 과정으로 수행된다. 이는 RDF 데이터의 품질이 확보되었다는 전제가 있어야 한다. 본 연구에서는 SPARQL 질의를 통해 BIM 기반 항만 유지관리 LD의 활용성 검증을 수행하였다. Fig. 6 예시는 ‘“계류시설의 유형 중 부산항 신항 3부두(2-1단계)”라는 시설명을 가진 항만시설과 매핑되는 IfcMarineFacility 객체는?’을 의미하는 쿼리와 쿼리 결과를 나타낸다. 또한, 질의를 통해 sameAs 관계에 있는 항만시설과 항만시설의 상위 관계에 있는 시설을 조회하여 특정 시설물과 sameAs 관계 및 상위 또는 하위 관계의 시설물을 파악할 수 있었다. 이처럼 사용자는 활용 목적에 맞게 데이터 질의를 수행하여 BIM 정보와 연계한 항만시설 유지관리 정보의 의미적 검색이 가능하며, 나아가 객체 단위에서의 항만시설 정보의 탐색 등 고도화된 정보의 활용이 가능하다.

Fig. 6. Example of SPARQL Query and Result Using BIM-Based Port Facility Linked Data

4.3 BIM 기반 항만 유지관리 링크드데이터 활용 서비스 프로토타입 구현

발행된 LD는 SPARQL Endpoint를 통해 내외부 접근의 접점이 만들어지며, 서로 다른 LD와의 융복합을 통해 다양한 응용 서비스가 구현될 수 있다. Fig. 7은 BIM 기반 항만 시설물 LD의 구축과 응용 환경을 제공하기 위한 시스템 프레임워크이다. 본 시스템 프레임워크는 1) BIM 데이터, DB 데이터 등 원천데이터 레이어, 2) BIM 기반 항만 유지관리 온톨로지에 따라 원천데이터를 RDF로 변환 및 매핑하기 위한 온톨로지 및 트리플 레이어, 3) RDF 데이터를 저장 및 발행하여 LD 구축하기 위한 LD 레이어, 4) LD를 활용한 서비스 레이어와 5) 이를 사용자에게 제공하기 위한 클라이언트 레이어로 구성된다. 이는 앞서 제시된 원천 데이터 수집부터 온톨로지 기반 LD 생성, 저장과 활용까지 일련의 단계가 적용되며, 정보관리 프로세스 관점에서 자동화된 시스템으로 개발될 수 있다.

본 연구에서는 LD 활용성을 테스트하기 위한 목적으로 항만 시설물 LD의 브라우징 기능, 항만 시설물 검색 및 통계 기능, SPARQL Endpoint 기능 프로토타입을 구현하였다(Fig. 8). LD 브라우징 기능은 구축된 LD를 온톨로지 체계에 따라 계층적 구조로 나타내어 시설물 데이터를 구조적으로 탐색할 수 있도록 하며, 리소스 명칭과 URI 정보를 제공한다. 또한 시설물 명칭 등 키워드 기반 검색 기능을 통해 생성된 약 150만여개 트리플 데이터를 기반으로 시설물 유형, 명칭, 소유자, 해역 등 시설물의 기본정보와 해당 시설물의 사업 및 유지관리 이력 정보, IFC 인스턴스 명칭, 타입, URI 등 BIM 객체 정보를 확인할 수 있다. 이외에도 트리플로 정의된 항만시설 44개에 대한 세부 유형 및 BIM 객체별 개수 현황 등 통계정보를 생성할 수 있다. SPARQL Endpoint는 시스템에서 제공하는 고정된 관점이 아닌 사용자가 원하는 관점으로 데이터 수준에서 질의할 수 있는 기능을 제공하였다. Fig. 8의 SPARQL Endpoint 예시는 ‘“부산신항 북컨테이너 축조공사” 프로젝트의 시설(IfcFacility)에 포함된 IfcMarineFacility 객체 인스턴스와 인스턴스의 타입을 추출’하기 위한 질의문과 질의 결과를 보여준다. 이처럼 본 프레임워크를 통해 구축 및 공유되는 유지관리 데이터는 BIM 객체와 직접 연계되어 시설물뿐만 아니라 부위-부재 단위의 손상 및 성능 정보를 생성하고 추론을 가능하게 한다. BIM 뷰어와 연동된 LD 시스템이 구현된다면, 제안된 프레임워크는 3차원 모델 기반 항만시설물 종합성능평가 및 예측 등 운영 및 자산관리 분야로 확장될 수 있을 것이다.

Fig. 7. Application System Framework of Linked Data for BIM-Based Port Facility

Fig. 8. Application Service Prototype Using Linked Data for BIM-Based Port Facility