KR101064684B1

KR101064684B1 - 온톨로지에서 인스턴스 업데이트 방법

Info

Publication number: KR101064684B1
Application number: KR1020090098919A
Authority: KR
Inventors: 신사임; 임태범; 장세진; 이석필
Original assignee: 전자부품연구원
Priority date: 2009-10-16
Filing date: 2009-10-16
Publication date: 2011-09-14
Also published as: KR20110041894A

Abstract

본 발명은 온톨로지를 구성하고 있는 인스턴스의 변경된 정보를 업데이트하는 방안에 간한 것으로서, 더욱 상세하게는 인스턴스를 관리하는 관리자는 인스턴스를 실질적으로 관리할 수 있는 방안에 관한 것이다.

이를 위해 본 발명은 온톨로지를 구성하고 있는 인스턴스를 관리하는 인스턴스 시스템에 있어서, 인스턴스의 생성, 삭제 및 수정 중 어느 하나가 요청되면, 요청된 인스턴스의 생성, 삭제 및 수정을 수행하는 파일을 생성하는 단계; 생성한 상기 파일의 위치가 포함된 URL 함수를 생성하는 단계; 생성한 상기 URL 함수를 상기 온톨로지를 관리하는 온톨로지 시스템으로 전달하는 단계;를 포함함을 특징으로 하는 인스턴스 관리 방법을 제안한다.

온톨로지, 클래스, 인스턴스, 업데이트, 메카니즘, 인스턴스 추가, 인스턴스 삭제, 인스턴스 수정

Description

온톨로지에서 인스턴스 업데이트 방법{Method for Instance update In Ontology}

MPEG-7은 가장 대중적인 이미지 메타데이터 표준 형식 중 하나이다. MPEG 표준안은 이미지를 비롯한 동영상 및 다양한 멀티미디어 데이터의 형식, 전달 및 압축 방식 고차원적인 멀티미디어 기반 의미검색 등 멀티미디어 데이터 및 그의 응용에 대한 다양한 분야에 대한 표준화를 수립하였고, 현재도 활발하게 진행되고 있다.

그러나 MPEG-7은 멀티미디어 메타 데이터들 사이에 호환성에 대한 고려가 없이 다른 형식의 메타데이터 혹은 시스템들 간의 호환 및 접근에 대한 지원을 허용하고 있지 않다는 한계를 가진다. 즉, MPEG 기반 메타데이터 어플리케이션들은 그 메타데이터가 국제표준인 XML로 서술되어 있다 하더라도 각각의 독립적인 이미지 파일 및 메타데이터를 취급해야 하는 가정 하에 운영되는 한계를 가지고 있다.

즉, MPEG-7은 유연하고 다양한 기능을 포함하며 확장성 있는 멀티미디어 메타데이터 표준안이지만, 원칙적으로 다른 멀티미디어 표준안과의 호환을 인정하지 않기 때문에 대용량 및 다양한 형식의 메타데이터 표준안을 망라하는 대용량 멀티미디어 기반 추출 시스템의 관리와 동기화가 어렵다.

영상 압축 표준 중의 하나의 JPEG은 칼라 정지 영상의 부호화 표준을 목표로 ISO/CCITT에서 1988년 ADCT(Adaptive Discrete Cosine Transformation)를 기초로 하는 알고리즘을 선택, 이 부호화 방식을 JPEG이라 명명하였으며 최종적으로 1992년 국제 표준으로 JPEG(Joint Photographic Expert Group) 알고리즘이 확정되었다. JPEG은 기본적으로 화상의 크기, 칼라 시스템 및 칼라 성분에 대한 제한을 갖지 않으며, 압축 모드로는 순차적 부호화, 점진적 부호화, 계층적 부호화, 무손실 부호화가 있다. JPEG의 기본 개념은 여러 가지 응용 목적에 맞게 부호화 방식을 선택해서 필요한 부분을 선택적으로 적용할 수 있도록 툴 키트(tool kit) 개념을 바탕으로 한다.

JPEG 표준안 안에서 이미지 검색을 위한 관련표준들을 제정하고 있는 JPSearch는 JPEG의 이러한 호환성 원칙 안에서 필요하다면 이미지 파일 형식을 자유롭게 변화시킬 수 있다. JPSearch는 이미지 헤더 안에 파일 형식을 기재하는 표준안을 포함하고 있기 때문에, 사용하는 이미지 파일의 압축 형식을 자유롭고 다양하게 적용할 수 있다. JPSearch의 이러한 호환성은 MPEG-7 기반 이미지 추출 시스템과 비교하여 이미지 추출 어플리케이션들을 개발 및 운용하는데 손쉽게 해 준다는 장점이 있다.

JPSearch에서 정의하는 메타데이터는 저차원 특성과 관리를 위한 정보부터 의미적 수준의 명시를 모두 포함하는 다양한 수준의 이미지 콘텐츠에 대한 정보를 포함하는 데이터이다. 예를 들어, 이미지는 하나의 데이터 아이템이다. 이미지에 대한 메타데이터는 이미지의 사이트, 압축방식, 생성에 관련된 데이터 정보들이 포함된다.

메타데이터를 위한 데이터(또한 데이터베이스 모델)는 어떻게 데이터를 표현하고 접근하는지(예를 들어 관계형 모델, XML Infoset, RDF)를 설명하는 추상적 모델이다. 이 모델은 예를 들어 W3C의 XML과 같은 메타데이터의 적합성을 결정하는 규칙을 정의하는 구문을 최소 하나 이상 가진다. 메타데이터 스키마, 혹은 메타데이터 형식은 데이터 모델의 다른 표현으로 특정 문제 분야의 논리 모델을 말한다. 메타데이터 스키마의 부분집합은 개념들 사이의 의미적 관계들을 모델링한다. 어떤 XML 기반 메타데이터 형식이 사용되었는지에 상관없이, JPSearch에서 제안하는 메타데이터 모델은 참조 메타데이터 스키마 (RMS: Reference Metadata Schema)를 제공한다. 참조 데이터 스키마는 이미지 추출 프레임워크에서 이미지를 설명하기 위한 메타데이터 스키마이다. JPSearch에서는 이를 수집자(aggregator)라고 정의하고 있다. JPSearch 기반 멀티미디어 추출 시스템에서 입력 질의는 RMS에 있는 용어와 메타데이터 경로 정보들을 참조할 것이다. 만약 메타데이터 형식이 RMS와 다르게 사용되는 외부 스키마라면, JPSearch 표준안에서는 규칙을 기반으로 이들 사이의 변환을 지원하고 있고, 이를 위한 표준안 지정이 진행 중이다.

온톨로지 표현을 위한 표준안들이 진행되고 있지만, 그 내용과 형식이 복잡 하고 전문적이기 때문에 온톨로지 관리 시스템들의 유지 및 관리가 복잡하고 전문적이다. 이러한 한계는 논리적이고 체계적으로 데이터 및 지식을 구축하여 관리하는 온톨로지, 즉 시멘틱웹 기반 시스템들의 확장의 장애물로 작용하고 있다. 또한, 온톨로지에 대량의 데이터는 한꺼번에 업데이트하는 메카니즘에 대한 부분이 없다.

본 발명은 온톨로지를 다수의 서비스에서 공유하며 관리할 경우 일관성있고, 체계적인 온톨로지 업데이트 모델을 제안한다.

본 발명은 온톨로지 통합 시스템에서 세부 시스템 관리자들이 추가, 삭제, 수정이 가능한 온톨로지 관리 시스템을 제안한다.

본 발명은 통합 시스템의 확장 및 통합을 용이하게 함으로서 효율적으로 온톨로지를 관리할 수 있는 방안을 제안한다.

상술한 문제점을 해결하기 위해 온톨로지를 구성하고 있는 인스턴스를 관리하는 인스턴스 시스템에 있어서, 인스턴스의 생성, 삭제 및 수정 중 어느 하나가 요청되면, 요청된 인스턴스의 생성, 삭제 및 수정을 수행하는 파일을 생성하는 단계; 생성한 상기 파일의 위치가 포함된 URL 함수를 생성하는 단계; 생성한 상기 URL 함수를 상기 온톨로지를 관리하는 온톨로지 시스템으로 전달하는 단계;를 포함함을 특징으로 하는 인스턴스 관리 방법을 제안한다.

상술한 문제점을 해결하기 위해 본 발명은 적어도 하나의 인스턴스를 포함하 는 온톨로지 시스템에서 인스턴스를 관리하는 방법에 있어서, 인스턴스의 변경을 수행하는 파일의 위치가 포함된 URL 함수를 수신하는 단계; 수신한 상기 URL함수를 이용하여 상기 인스턴스를 업데이트 하는 단계;를 포함함을 특징으로 하는 인스턴스 관리 방법을 제안한다.

상술한 문제점을 해결하기 위해 본 발명은 인스턴스의 생성, 삭제 및 수정 중 어느 하나가 요청되면, 요청된 인스턴스의 생성, 삭제 및 수정을 수행하는 파일을 생성하고, 생성한 상기 파일의 위치가 포함된 URL 함수를 생성하고, 생성한 상기 URL 함수를 전달하는 인스턴스 시스템; 상기 인스턴스 시스템으로부터 전달받은 URL함수를 이용하여 상기 인스턴스를 업데이트 하는 온톨로지 시스템을 포함하는 서비스 시스템을 제안한다.

상술한 문제점을 해결하기 위해 본 발명은 인스턴스의 생성, 삭제 및 수정 중 어느 하나가 요청되면, 요청된 인스턴스의 생성, 삭제 및 수정을 수행하는 파일을 생성하고, 생성한 상기 파일의 위치가 포함된 URL 함수를 생성하는 생성부; 생성한 상기 URL 함수를 전달하는 전달부;를 포함하는 인스턴스 시스템을 제안한다.

본 발명은 온톨로지를 다수의 서비스에서 공유하며 관리할 경우 일관성있고, 체계적으로 관리할 수 있게 되며, 온톨로지를 관리하는 각자가 등록한 지식 내용을 각자 세부 시스템 관리자들이 추가, 삭제, 수정이 가능하게 된다.

또한, 본 발명은 통합 시스템의 확장 및 통합을 용이하게 함으로서 효율적으로 온톨로지를 관리할 수 있게 된다.

전술한, 그리고 추가적인 본 발명의 양상들은 첨부된 도면을 참조하여 설명되는 바람직한 실시 예들을 통하여 더욱 명백해질 것이다. 이하에서는 본 발명의 이러한 실시 예를 통해 당업자가 용이하게 이해하고 재현할 수 있도록 상세히 설명하기로 한다.

온톨로지란 어휘나 개념의 정의 또는 명세서로서 정보시스템 분야에서는 시스템이 다루는 내용에 해당하는 구성요소를 의미한다. 온톨로지는 의료ㅇ기계제조ㅇ부동산ㅇ금융 등 특정 응용영역에 대해 만들어지는데, 그 분야의 기본 개념에 대한 정의와 그들 상호간의 관계에 대한 명세서로 이루어진다. 가장 단순한 형태로는 어휘사전이나 용어모음을 생각할 수 있지만 일반적으로 온톨로지는 컴퓨터가 처리할 수 있을 만큼의 구조성과 구체성을 갖춰야한다. 온톨로지의 기본은 해당 영역에 존재하는 개념들이다. 예를 들어 책ㅇ컴퓨터ㅇ책상ㅇ의자ㅇ구매ㅇ입찰 등이다. 각 개념은 다시 그 개념을 설명하는 속성들을 갖게 되는데, 예를 들어 책은 저자ㅇ출판사ㅇ쪽ㅇ가격 등의 속성을 갖고 입찰은 대상ㅇ날짜ㅇ방식ㅇ조건 등의 속성을 가질 수 있을 것이다. 또 개념들은 서로 관계를 가질 수 있는데, 가장 기본적인 관계는 상하포함관계다. 예를 들어 동화책은 책에 포함되는 하위개념이 된다.

발전된 온톨로지에서는 속성의 특성, 좀 더 복잡한 형식의 관계 등을 정의함으로써 풍부한 내용을 담을 수 있게 된다. 온톨로지를 독립적인 하나의 중심 구성요소로 보고 이를 개발과 운영의 중심에 놓는 것이 온톨로지 기반의 시스템(ontology-driven system) 또는 시스템 개발인데, 이는 몇 가지 측면에서 장점을 갖는다. 대표적인 장점으로는 정보 콘텐츠의 구조에 대한 명세서로서의 역할, 해당 영역의 지식 공유와 재사용, 해당 영역의 제약과 가정에 대한 명시, 지식 (정보)과 프로세스의 분리, 요구사항 분석의 기본 단계 등이다.

온톨로지는 정보검색, 의료정보와 바이오정보, 인공지능 및 에이전트, 전자상거래, 지능형 인터넷 등 다양한 기술 분야에 적용되며, 이미 분야별로 이에 대한 연구가 활발히 진행되고 있다.

다음은 온톨로지의 구성에 필요한 기본적인 구성요소의 개념과 그 정의를 설명하고 있다.

- 글래스(Class): 클래스는 유사한 특성으로 온톨로지의 요소들을 묶기 위한 추상화 메카니즘을 말한다. 즉, 같은 의미정보를 공유하는 요소들의 그룹이라고 할 수 있다.

- 인스턴스(instance): 인스턴스는 각각의 명제(axiom) 혹은 사실(fact)을 정의하는 요소로 다음의 두 가지 형태로 구성될 수 있다.

(1) 각각의 하위 클래스요소와 속성 (property) 값들을 포함하는 사실값.

(2) 각각의 사실 그 자체가 가장 작은 하위 요소인 사실값.

- 개체 속성(object property): 개체 속성은 클래스 구성 요소와 인스턴스의 속성에 관한 의미적 관계를 규정하는 사실값을 의미한다. 개체 속성의 구성 요소는 다음의 두 가지로 구성될 수 있다.

(1) 도메인 속성(domain property): 개체 속성의 온톨로지 구문에서 이러한 속성값의 주체가 되는 속성값.

(2) 범위 속성 (range property): 개체 속성의 온톨로지 구문에서 이러한 속성값의 값이 되는 속성값.

- 데이터 속성(data property): 인스턴스를 구체화하는 데이터 자체를 포함하는 사실값.

본 발명에서 제안하는 온톨로지 관리를 위한 프레임은 다수의 다양한 서비스에서 공유 및 참조하고 있는 온톨로지의 관리 방법을 제안한다. 온톨로지는 초기에 높은 비용을 들여 연동하는 서비스에 적합하도록 구축된다. 그러나 변화하는 서비스 환경에 적응하거나 최신의 지식 서비스의 제공을 목적으로 하는 서비스에서는 지속적으로 연동하는 온톨로지의 지식을 업데이트해야 할 필요가 있다. 본 발명은 다수의 서비스를 공유하는 온톨로지를 각각의 서비스 관리자가 업데이트를 수행할 수 있도록 하는 메카니즘을 소개한다. 본 발명은 온톨로지 적용 시의 복잡한 충돌 및 동기화 문제를 고려하여 온톨로지의 클래스를 업데이트하는 권한은 세부 시스템 관리자들에게 부여하지 않는다. 즉, 온톨로지의 인스턴스로 구성되는 데이터만을 개별 서비스 관리자들이 등록 및 수정할 수 있도록 허용하고 있다. 본 발명에서는 다수의 세부 서비스들 및 서비스 관리자들이 공유하는 온톨로지의 인스턴스를 "추가", "삭제" 및 "수정"할 수 있는 방법론 및 표준화된 방법을 제안한다.

온톨로지를 표현하는 다양한 언어들을 지원하는 라이브러리들이 온톨로지 인스턴스를 위한 방법 혹은 함수들을 지원하고 있지만, 이는 개별 인스턴스를 대상으로 하는 개발 수준의 라이브러리들이다. 본 발명에서는 대용량 지식기반 시스템들에도 복잡하지 않은 형태로 대량의 인스턴스들을 처리할 수 있는 과정을 제안하고 있다. 또한, 온톨로지 작성에 적용하는 언어의 종류에 상관없이 적용 가능한 호환성 높은 온톨로지 관리 모델을 추구하고 있다.

도 1은 본 발명의 일 실시예에 따른 온톨로지를 도시하고 있다. 도 1에 의하면 온톨로지는 JPLO클래스와 JPLO클래스의 하위 클래스인 제1 클래스와 제2 클래스를 도시하고 있다. 또한 제 1클래스는 하위 클래스로 서비스 클래스와 스키마 클래스를 포함하며, 제2 클래스 역시 하위 클래스로 서비스 클래스와 스키마 클래스를 포함하고 있다. 제1 클래스 및 제 2 클래스의 하위 클래스를 구성하는 클래스는 스키마 클래스 또는 서비스 클래스가 아닌 다른 클래스가 포함될 수 있다.

서비스 클래스는 서비스1 내지 서비스n으로 구성되는 인스턴스를 포함하며, 스키마 클래스는 스키마1 내지 스키마n으로 구성되는 인스턴스를 포함하고 있다. 이하 인스턴스를 추가하는 과정에 대해 알아보기로 한다.

인스턴스의 추가

제안하는 모델은 온톨로지 기반 지식체계를 공유하는 서비스 관리자들이 온톨로지에 새롭게 등록해야 하는 인스턴스의 추가를 허용한다. 각 온톨로지에 적합한 온톨로지 표현 언어로 기술된 새롭게 온톨로지에 등록할 인스턴스들을 기술하고 있는 파일은 온톨로지에 추가하는 방식으로 온톨로지를 확장한다. 이 방법은 온톨로지에 추가될 인스턴스들을 포함하고 있는 파일의 위치를 가리키는 'addInstanceFilePath'라는 URL 함수를 가진다.

이 름	타 입	의 미
addInstanceFilePath	URI	추가될 인스턴스 파일의 위치를 지정.
schemaID	URI	추가될 인스턴스 파일이 등록될 스키마, 혹은 온톨로지를 지정. schemaID는 모든 스키마들 사이에 중복 없이 유일한 ID여야 한다.
serviceID	URI	본 인스턴스들과 온톨로지를 등록하고 사용하는 서비스 ID를 지정. 모든 가능한 서비스들 사이에 중복 없이 유일한 ID여야 한다.

즉, 인스턴스의 추가 방법은 전체 온톨로지에 해당 파일의 위치 혹은 그 내용을 등록하는 역할을 수행한다.

도 2는 본 발명의 일 실시예에 따른 인스턴스를 추가하는 예를 도시하고 있다. 도 1의 제1 클래스를 구성하고 있는 서비스 클래스에 인스턴스를 추가하는 경우를 가정한다. 일예로 도 2는 서비스3이라는 인스턴스를 추가하는 경우에 대해 알아보기로 한다.

S200단계에서 서비스3을 관리하는 서비스 관리자가 제1 클래스를 구성하고 있는 서비스 클래스에 서비스3이라는 인스턴스를 추가한다.

S202단계에서 서비스 관리자(서비스 관리부)는 추가한 인스턴스를 포함하고 있는 파일 위치를 가르키는 URL 함수를 생성한다. S204단계에서 서비스 관리자는 생성한 URL 함수를 메인 관리부로 전달한다. S206단계에서 메인 관리부는 전달받은 URL 함수를 이용하여 전체 온톨로지를 업데이트한다. 메인 관리부의 업데이트는 생성한 인스턴스를 포함하고 있는 파일 위치를 가르키는 URL 함수를 추가하는 것으로서 수행된다.

인스턴스들의 삭제

제안하는 모델은 온톨로지 기반 지식체계를 공유하는 서비스 관리자들이 온톨로지에 더 이상 사용되지 않거나, 사용해서는 안되는 인스턴스의 삭제를 허용한다. 각 온톨로지에 적합한 온톨로지 표현 언어로 기술된 온톨로지에서 삭제할 인스턴스들을 기술하고 있는 파일은 기존에 온톨로지에 등록한 파일 단위로 온톨로지에서 해당 인스턴스 파일은 삭제하는 방식으로 온톨로지를 수정한다. 이 방법은 온톨로지에서 삭제할 인스턴스들을 포함하고 있는 파일의 위치를 가리키는 'deleteInstanceFilePath'라는 URL 함수를 가진다.

이 름	타 입	의 미
deleteInstanceFilePath	URI	삭제할 인스턴스 파일의 위치를 지정.
schemaID	URI	삭제할 인스턴스 파일이 등록되어 있었던 스키마, 혹은 온톨로지를 지정. schemaID는 모든 스키마들 사이에 중복 없이 유일한 ID여야 한다.
serviceID	URI	본 인스턴스들과 온톨로지를 등록하고 사용하는 서비스 ID를 지정. 모든 가능한 서비스들 사이에 중복 없이 유일한 ID여야 한다.

인스턴스의 삭제 방법은 전체 온톨로지에 해당 파일의 위치 혹은 그 내용을 삭제하는 역할을 수행한다.

인스턴스의 삭제는 도 2에 도시되어 있는 인스턴스의 생성과 동일한 방식으로 수행된다. 다만, 인스턴스의 삭제는 도 2의 인스턴스의 생성이라는 점에서 차이가 있다.

기존에 존재하는 인스턴스들의 수정

제안하는 모델은 온톨로지 기반 지식체계를 공유하는 서비스 관리자들이 온톨로지에 이미 존재하는 인스턴스들의 수정을 허용한다. 각 온톨로지에 적합한 온톨로지 표현 언어로 기술된 새롭게 온톨로지에서 수정될 인스턴스를 포함하고 있는 파일은 새롭게 수정한 인스턴스들을 포함한 수정된 파일을 새롭게 등록하고 기존의 파일을 삭제하는 방식으로 온톨로지를 수정한다. 이 방법은 온톨로지에서 원래 수정되기 전의 인스턴스를 포함하고 있는 파일의 위치를 가리키는 'originnstanceFilePath'와 새로 수정된 인스턴스를 포함하고 있는 파일이 위치를 가리키는 'updatenstanceFilePath'라는 두 개의 URL 함수를 가진다.

이 름	타 입	의 미
originalInstanceFilePath	URI	수정할 인스턴스가 포함된 파일의 위치를 지정.
updatedInstanceFilePath	URI	수정한 인스턴스가 포함된 파일의 위치를 지정.
schemaID	URI	수정할 인스턴스 파일이 등록되어 있었던 스키마, 혹은 온톨로지를 지정. schemaID는 모든 스키마들 사이에 중복 없이 유일한 ID여야 한다.
serviceID	URI	본 인스턴스들과 온톨로지를 등록하고 사용하는 서비스 ID를 지정. 모든 가능한 서비스들 사이에 중복 없이 유일한 ID여야 한다.

제안하는 메써드의 아규먼트들 중 'originalInstanceFilePath'는 수정되기 전에 수정 대상인 인스턴스가 포함되어 있는 인스턴스 파일의 URL을 가리킨다. 또한, 'updateInstanceFilePath'는 수정 대상인 인스턴스들이 새롭게 수정되어 포함된 새로운 인스턴스 파일의 URL를 가리킨다. 이 방법은 온톨로지의 'oraginalInstanceFilePath'를 'updateInstanceFilePath'로 변경하는 방식으로 기존의 인스턴스의 내용을 수정할 수 있도록 개발되어야 한다.

도 3은 인스턴스를 수정하는 과정을 도시하고 있다. 이하 도 3을 이용하여 인스턴스를 수정하는 과정에 대해 알아보기로 한다.

300단계에서 서비스 관리자가 제1 클래스를 구성하고 있는 서비스 클래스에 서비스3이라는 인스턴스를 수정한다.

S302단계에서 서비스 관리자(서비스 관리부)는 수정전 인스턴스를 포함하고 있는 파일 위치를 가르키는 URL 함수와 수정한 인스턴스를 포함하고 있는 파일 위치를 가르키는 URL 함수를 생성한다. S304단계에서 서비스 관리자는 생성한 URL 함수를 메인 관리부로 전달한다. S306단계에서 메인 관리부는 전달받은 URL 함수를 이용하여 전체 온톨로지를 업데이트한다. 메인 관리부의 업데이트는 수정 전 인스턴스를 포함하고 있는 파일 위치를 가르키는 URL 함수를 수정한 인스턴스를 포함하고 있는 파일 위치를 가르키는 URL 함수로 변경하는 것으로 수행된다.

위에 제안한 세 개의 방법을 통하여 대량의 데이터들을 하나의 온톨로지를 공유하는 여러 서비스 관리자들이 간단하고 빠르게 업데이트할 수 있다.

이하에서는 대표적인 온톨로지 표현 언어인 OWL을 기반으로 하여 앞서 제안한 방법들의 수행하는 예에 대해 설명하기로 한다.

먼저 인스턴스를 추가하는 예에 대해 알아보기로 한다. 다음의 온톨로지는 다수 개의 owl 파일들과 네임스페이스를 포함하고 있다

원래의 온톨로지는 표 4와 같이 'jprmo_main.owl'을 중심으로 'jprmo_main.owl'과 'jprmo_mpeg7.owl'의 두 개의 owl 파일을 온톨로지에 더 포함하고 있다.

<!- jprmo_main.owl -!>
<?xml version="1.0"?>
<rdf:RDF
xmlns:inst="file:/C:/ontology/sample_ontology/jprmo_instances.owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns="file:/C:/ontology/sample_ontology/jprmo_main.owl#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:mpeg7="file:/C:/ontology/sample_ontology/jprmo_mpeg7.owl#"
xml:base="file:/C:/ontology/sample_ontology/jprmo_main.owl">
<owl:Ontology rdf:about="file:/C:/ontology/sample_ontology/jprmo_main.owl">
<owl:imports rdf:resource="file:/C:/ontology/sample_ontology/jprmo_mpeg7.owl"/>
</owl:Ontology>
</rdf:RDF>

인스턴스 추가 방법은 기존의 온톨로지를 새로운 인스턴스 파일을 포함하여 확장한다. 인스턴스 추가를 다음과 같이 수행한다.

addInstances ("file:/C:/ontology/sample_ontology/jprmo_instances.owl", "JPSearch_Schema1", "JPSearch_Service1")

인스턴스 추가 방법을 수행하면, 아래 표 5와 같이 온톨로지는 'jprmo_main.owl' 뿐만 아니라 'jprmo_instances.owl'도 포함하는 형태로 확장된다.

<!- jprmo_main.owl -!>
<?xml version="1.0"?>
<rdf:RDF
xmlns:inst="file:/C:/ontology/sample_ontology/jprmo_instances.owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns="file:/C:/ontology/sample_ontology/jprmo_main.owl#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:mpeg7="file:/C:/ontology/sample_ontology/jprmo_mpeg7.owl#"
xml:base="file:/C:/ontology/sample_ontology/jprmo_main.owl">
<owl:Ontology rdf:about="file:/C:/ontology/sample_ontology/jprmo_main.owl">
<owl:imports rdf:resource="file:/C:/ontology/sample_ontology/jprmo_instances.owl"/>
<owl:imports rdf:resource="file:/C:/ontology/sample_ontology/jprmo_mpeg7.owl"/>
</owl:Ontology>
</rdf:RDF>

다음은 온톨로지에서 인스턴스를 삭제하는 과정을 설명하기로 한다. "deleteInstances"는 jprom_instances.owl를 포함하는 표 5의 온톨로지에서 해당 함수를 삭제한다. 인스턴스 삭제는 다음과 같이 수행한다.

deleteInstances ("file:/C:/ontology/sample_ontology/jprmo_instances.owl", "JPSearch_Schema1", "JPSearch_Service1")

인스턴스 삭제 방법을 사용하면 아래 표 6에 표시된 것과 같이 'jprmo_instances.owl' 파일은 온톨로지에서 더 이상 존재하지 않는다.

이하에서는 인스턴스 수정하는 방안에 대해 알아보기로 한다. 다음의 예는 OWL로 표현된 온톨로지의 예를 보여준다. 다음의 표 7의 온톨로지는 몇 개의 네임스페이스와 owl 파일들을 포함하고 있다. OWL 파일은 'jprmo_main.owl', 'jprmo_mpeg7.owl'과 'jprmo_instances.owl'를 포함한다.

<!- jprmo_main.owl -!>
<?xml version="1.0"?>
<rdf:RDF
xmlns:inst="file:/C:/ontology/sample_ontology/jprmo_instances.owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns="file:/C:/ontology/sample_ontology/jprmo_main.owl#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:mpeg7="file:/C:/ontology/sample_ontology/jprmo_mpeg7.owl#"
xml:base="file:/C:/ontology/sample_ontology/jprmo_main.owl">
<owl:Ontology rdf:about="file:/C:/ontology/sample_ontology/jprmo_main.owl">
<owl:imports rdf:resource="file:/C:/ontology/sample_ontology/jprmo_mpeg7.owl"/>
<owl:imports rdf:resource="file:/C:/ontology/sample_ontology/jprmo_instances.owl"/>
</owl:Ontology>
</rdf:RDF>

인스턴스 수정 방법은 첫 번째 함수의 온톨로지 안의 파일은 두 번째 함수에 있는 새로운 인스턴스 파일로 교체한다. 일예로 아래와 같이 인스턴스 수정을 수행한다.

updateInstances ("file:/C:/ontology/sample_ontology/jprmo_instances.owl", "file:/C:/ontology/sample_ontology/jprmo_new_instances.owl" , "JPSearch_Schema1", "JPSearch_Sercice1")

상술한 인스턴스를 수행하면, 표 8에서와 같이 온톨로지는 더 이상 'jprmo_instances.owl' 파일을 포함하지 않고, 'jprmo_new_instances.owl' 파일을 포함하는 것을 알 수 있다.

<!- jprmo_main.owl -!>
<?xml version="1.0"?>
<rdf:RDF
xmlns:inst="file:/C:/ontology/sample_ontology/jprmo_instances.owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns="file:/C:/ontology/sample_ontology/jprmo_main.owl#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:mpeg7="file:/C:/ontology/sample_ontology/jprmo_mpeg7.owl#"
xml:base="file:/C:/ontology/sample_ontology/jprmo_main.owl">
<owl:Ontology rdf:about="file:/C:/ontology/sample_ontology/jprmo_main.owl">
<owl:imports rdf:resource="file:/C:/ontology/sample_ontology/jprmo_mpeg7.owl"/>
<owl: imports rdf:resource = "file:/C:/ontology/sample_ontology/jprmo_new_instances.owl"/>
</owl:Ontology>
</rdf:RDF>

본 발명은 도면에 도시된 일실시 예를 참고로 설명되었으나, 이는 예시적인 것에 불과하며, 본 기술 분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시예가 가능하다는 점을 이해할 것이다.

도 1은 본 발명의 일 실시예에 따른 온톨로지를 도시한 도면이며,

도 2는 본 발명의 일 실시예에 따른 온톨로지를 추가하는 과정을 도시한 도면이며,

도 3은 본 발명의 일 실시예에 따른 온톨로지를 수정하는 과정을 도시한 도면이다.

Claims

온톨로지를 구성하고 있는 인스턴스를 관리하는 인스턴스 시스템에 있어서,

인스턴스의 생성, 삭제 및 수정 중 어느 하나가 요청되면, 요청된 인스턴스의 생성, 삭제 및 수정을 수행하는 파일을 생성하는 단계;

생성한 상기 파일의 위치가 포함된 URL 함수를 생성하는 단계;

생성한 상기 URL 함수를 상기 온톨로지를 관리하는 온톨로지 시스템으로 전달하는 단계;를 포함함을 특징으로 하는 인스턴스 관리 방법.
제 1항에 있어서, 상기 인스턴스의 수정이 요청되면,

상기 수정 전 인스턴스 파일의 위치가 포함된 URL 함수와 수정한 인스턴스 파일의 위치가 포함된 URL 함수를 생성함을 특징으로 하는 인스턴스 관리 방법.
제 2항에 있어서, 상기 인스턴스의 추가는,

추가될 인스턴스의 고유 스키마 식별자와 고유 서비스 식별자를 지정함을 특징으로 하는 인스턴스 관리 방법.
제 1항에 있어서, 상기 인스턴스의 추가는,

추가될 인스턴스의 고유 스키마 식별자와 고유 서비스 식별자를 지정함을 특징으로 하는 인스턴스 관리 방법.
적어도 하나의 인스턴스를 포함하는 온톨로지 시스템에서 인스턴스를 관리하는 방법에 있어서,

인스턴스의 변경을 수행하는 파일의 위치가 포함된 URL 함수를 수신하는 단계;

수신한 상기 URL 함수를 이용하여 상기 인스턴스를 업데이트 하는 단계;를 포함함을 특징으로 하는 인스턴스 관리 방법.
제 5항에 있어서, 상기 인스턴스의 변경은 인스턴스의 추가, 인스턴스의 삭제, 인스턴스의 수정 중 어느 하나임을 특징으로 하는 인스턴스 관리 방법.
제 6항에 있어서, 상기 인스턴스의 수정은,

수정 전 인스턴스 파일의 위치가 포함된 URL 함수와 수정한 인스턴스 파일의 위치가 포함된 URL 함수를 수신함을 특징으로 하는 인스턴스 관리 방법.
제 7항에 있어서, 상기 인스턴스의 수정은 수정 전 인스턴스 파일의 위치가 포함된 URL 함수를 삭제하고, 수정한 인스턴스 파일의 위치가 포함된 URL 함수를 추가함을 특징으로 하는 인스턴스 관리 방법.
인스턴스의 생성, 삭제 및 수정 중 어느 하나가 요청되면, 요청된 인스턴스의 생성, 삭제 및 수정을 수행하는 파일을 생성하고, 생성한 상기 파일의 위치가 포함된 URL 함수를 생성하고, 생성한 상기 URL 함수를 전달하는 인스턴스 시스템;

상기 인스턴스 시스템으로부터 전달받은 URL함수를 이용하여 상기 인스턴스를 업데이트 하는 온톨로지 시스템을 포함하는 서비스 시스템.
제 9항에 있어서, 상기 인스턴스 시스템은

인스턴스의 수정이 요청되면, 상기 수정 전 인스턴스 파일의 위치가 포함된 URL 함수와 수정한 인스턴스 파일의 위치가 포함된 URL 함수를 생성함을 특징으로 하는 서비스 시스템.
제 10항에 있어서, 상기 온톨로지 시스템은,

상기 수정 전 인스턴스 파일의 위치가 포함된 URL 함수를 삭제하고, 수정한 상기 인스턴스 파일의 위치가 포함된 URL 함수를 추가함을 특징으로 하는 서비스 시스템.
인스턴스의 생성, 삭제 및 수정 중 어느 하나가 요청되면, 요청된 인스턴스의 생성, 삭제 및 수정을 수행하는 파일을 생성하고, 생성한 상기 파일의 위치가 포함된 URL 함수를 생성하는 생성부;

생성한 상기 URL 함수를 전달하는 전달부;를 포함하는 인스턴스 시스템.