트리플 레파지토리 벤치마킹 연구 · 2018. 10. 18. · 1.2 RDF 트리플 데이터를 기계가 이해하고 처리할 수 있도록 하기 위해서는 형식적인 데이터

트리플 레파지토리 벤치마킹 연구

오원석 (탑쿼드란트코리아)강 혁 (탑쿼드란트코리아)조도연 (탑쿼드란트코리아)이승우 (KISTI)정한민 (KISTI)김 평 (KISTI)이미경 (KISTI)김재한 (KISTI)성원경 (KISTI)김경선 (㈜다이퀘스트)박진우 (㈜다이퀘스트)

한국과학기술정보연구원

트리플 레파지토리 벤치마킹 연구

오원석 (탑쿼드란트코리아)강 혁 (탑쿼드란트코리아)조도연 (탑쿼드란트코리아)이승우 (KISTI)정한민 (KISTI)김 평 (KISTI)이미경 (KISTI)김재한 (KISTI)성원경 (KISTI)김경선 (㈜다이퀘스트)박진우 (㈜다이퀘스트)

i

목 차

제 1 부 연구 배경 ················································································································· 1

1 시맨틱 웹 ····························································································································· 1 1.1 정의 ································································································································ 1 1.2 RDF 트리플 ··················································································································· 3 1.3 온톨로지(Ontology) ······································································································· 52 시맨틱 웹 기술 ····················································································································· 8 2.1 URI ································································································································ 8 2.2 RDF ································································································································ 9 2.3 RDFS ····························································································································· 9 2.4 OWL ····························································································································· 10 2.5 SPARQL ······················································································································· 123 트리플 레파지토리 ············································································································· 14 3.1 개요 및 특징 ················································································································ 14 3.2 구조 ······························································································································ 15 3.3 종류 ······························································································································ 17

제 2 부 트리플 레파지토리의 필요성 ·················································································· 19

1 웹의 진화 및 시맨틱 웹의 확산 ························································································ 192 DBMS와 트리플 레파지토리 ······························································································ 213 트리플 레파지토리의 활용 ································································································· 22

제 3 부 시장 동향 ··············································································································· 24

ii

1 시맨틱 웹 어플리케이션을 위한 관련 도구들 ···································································· 24 1.1 온톨로지 엔지니어링 ··································································································· 25 1.2 시맨틱 웹 데이터 생성 및 변환기 ·············································································· 27 1.3 추론 엔진 ····················································································································· 352 시맨틱 웹 어플리케이션 ····································································································· 38 2.1 시맨틱 웹 데이터 연계(Linked Data), 매쉬업(Mashup) ············································ 38 2.2 시맨틱 웹 서비스 ········································································································· 43 2.3 시맨틱 검색 ················································································································· 48 2.4 상황인지(Context Awareness) ··················································································· 52

제 4 부 주요 제품 비교 ······································································································ 55

1 제품 특징 ··························································································································· 55 1.1 AllegroGraph ··············································································································· 55 1.2 Oracle ·························································································································· 56 1.3 OWLIM ························································································································ 56 1.4 SDB ······························································································································ 58 1.5 Virtuoso ······················································································································· 59 1.6 OntoBase2.0 ················································································································ 60 1.7 OntoReasoner ·············································································································· 61 1.8 주요 트리플 레파지토리 제품의 특징 비교 ································································ 62 1.9 성능 벤치마킹 대상 각 제품의 문제점 ······································································· 632 성능 벤치마킹 ···················································································································· 64 2.1 제품군 ·························································································································· 64 2.2 벤치마킹 환경 ·············································································································· 64 2.3 데이터 셋 ····················································································································· 65 2.4 벤치마킹 과정 ·············································································································· 683 벤치마킹 결과 ···················································································································· 71 3.1 적재 성능 벤치마킹 결과 ···························································································· 71

iii

3.2 질의 성능 벤치마킹 결과 ···························································································· 764 벤치마킹 결과 분석 ·········································································································· 102 4.1 적재 성능 벤치마킹 분석 ·························································································· 102 4.2 질의 성능 벤치마킹 분석 ·························································································· 103

제 5 부 결론 ······················································································································ 107

참고문헌 ······························································································································· 109

부록1 LUBM 질의 ············································································································· 111부록2 WordNet 질의 ········································································································· 116부록3 BSBM 질의 ·············································································································· 117부록4 OntoReasoner 벤치마킹 결과 ·················································································· 126

1

제 1 부 연구 배경

1 시맨틱 웹

1.1 정의90년대 시작된 World Wide Web은 이전과는 차원이 다른 새로운 방식의 정보생산과 이용수단이 되었다. 누구든지 인터넷을 통해 자유롭게 자신이 원하는 정보를 찾고, 자신이 가진 정보를 웹으로 발행(publishing)할 수 있게 되었으며, 웹을 통해 서로 커뮤니케이션을 하고, 물건을 사고팔기도 하는 웹 중심의 정보 환경이 만들어진 것이다. 이러한 새로운 형태의 정보 환경을 통해 정보 생산량은 폭발적으로 늘어났고, 정보의 증가로 인해 그 안에서 필요로 하는 유의미한 정보를 찾아내는 것이 심각한 문제로 대두되게 되었다.우리에게 익숙한 기존의 웹은 HTML이라는 표현 형식으로 이루어져 있으며, 실제 웹문서의 해석과 그 웹문서가 연결하고 있는 또 다른 웹문서와의 연결된 의미는 그 문서를 읽는 인간에 의해 이루어진다. 예를 들어, 어떤 사람이 ‘제주도’를 여행하기 위해 관련 정보들을 찾고자 할 때, ‘제주도’에 대한 여행 정보와 지도 정보를 각각 웹에서 찾아, 두 정보를 연결하고 조합하여 원하는 여행 정보를 만드는 것은 인간의 작업을 거치지 않으면 안 되는 것이다. 이것은 웹에서 문서를 표현하는 형식인 HTML이 인간이 읽기 편하게 할 목적으로 만들어졌기 때문이며, 웹은 단지 정보를 전달하는 도구일 뿐, 그것을 이해하고 처리하는 기능을 갖지 못했기 때문에 발생하는 문제이다. 시맨틱 웹(semantic web)은 이러한 문제를 해결하고자 탄생하였으며, 인간 중심의 데이터 표현에 중점을 둔 HTML 기반의 기존 웹과 달리, 웹에서 데이터의 의미를 표현함으로써 데이터의 자동적인 상호 교환을 통해 인간과 기계, 기계와 기계 사이의 상호 협력이 가능한 데이터의 웹(the web of data)을 추구한다.

제1부 연구 배경2

[그림 1-1] 인간이 이해하고 처리하는 문서 웹

World Wide Web의 탄생시킨 팀 버너스리(Tim Berners-Lee)는 ‘시맨틱 웹은 잘 정의된(well-defined) 의미를 정보에 부여함으로써 기계와 인간이 더욱 잘 협력할 수 있는 현재 웹의 확장’이라고 정의하였다[1]. 즉 다양한 어플리케이션 간의 자유로운 데이터의 상호 교환이 이루어짐으로써 데이터의 통합(integration) 및 재사용(reuse), 더 나아가 기계 또는 에이전트(agent)에 의한 자동화가 가능하도록 기계가 사용할 수 있는 방식으로 정의되고 연결된 데이터의 웹이 바로 시맨틱 웹의 비전이다[2].

구분 문서 웹 시맨틱 웹유사성 글로벌한 파일 시스템 글로벌한 데이터베이스

기본 객체 문서 사물 및 사물에 대한 해설(description)

링크의 대상 문서(또는 문서의 일부분) 사물(문서 포함)

오브젝트 간의 구조화 정도 상당히 낮음 높음

콘텐츠와 링크의 의미 암묵적(implicit) 명시적(explicit)디자인 목적 인간의 소비 기계, 인간

[표 1-1] 문서 웹과 시맨틱 웹의 비교[3]

제1부 연구 배경 3

[그림 1-2] HTML 문서간의 단순 링크로 이루어진 기존의 웹

[그림 1-3] 시맨틱 웹에서 정보를 표현하는 트리플 형식

1.2 RDF 트리플데이터를 기계가 이해하고 처리할 수 있도록 하기 위해서는 형식적인 데이터 모델을 통해 데이터를 표현해야 한다. 이를 위해 문서 웹에서의 HTML을 대신하여 데이터를 형식화하여 표현하기 위한 방법으로 RDF(Resource Description Framework)가 사용된다. 시맨틱 웹에서 표현하는 데이터의 단위는 리소스(resource)로서 실세계의 사물(thing)을 참조한다. 각 리소스는 웹에서 자신의 정체성을 구별할 수 있는 이름, 즉 URI(Uniform Resource Identifier)를 범용 식별자(global identifier)로서 가진다. HTML로 이루어진 문서들의 집합인 기존의 웹과는 달리 시맨틱 웹에서 기본적인 정보의 표현은 URI로 명명된 리소스들과 이들 간의 의미가 부여된 관계로 나타난다. 이를 표현하기 위한 형식으로 기술 논리(description logic)를 이용한 주어, 술어, 목적어 형태의 트리플(triple)이 이용된다. RDF는 이러한 트리플 기반의 데이터 모델이며, 기계 가독 포맷(machine readable format)인 RDF/XML, Turtle, 및 N3에 의해 표현될 수 있다.

즉 실세계의 개체(entity)는 주어부(subject), 목적어부(object)가 되고, 이 둘 간의 관계는 술어부(predicate)로 표현되며, 이러한 트리플들의 집합은 방향성 있는 그래프(directed graph)로 나타내어진다.

이러한 트리플 형식으로 [탑쿼드란트코리아는 http://www.topquadrant.co.kr이라는 홈페이지를 가지고 있다]라는 사실을 다음과 같이 표현할 수 있다.


[그림 1-4] 구체적인 트리플 표현1

또 다른 예로 [홍길동은 탑쿼드란트코리아에서 일한다]라는 문장은 다음과 같이 표현할 수 있다.

[그림 1-5] 구체적인 트리플 표현2

이 두 트리플은 ‘탑쿼드란트코리아’라는 공통의 노드를 연결함으로써 방향성 있는 그래프로 다음과 같이 표현할 수 있다.

[그림 1-6] 그래프로 병합된 두 문장의 예

여기에서 ‘탑쿼드란트코리아’가 실세계에서 동일한 개체임을 식별하기 위한 것이 URI로, URI는 URL과 동일한 형식으로 보이지만 URL이 HTML 문서를 참조하는


것이라면, URI는 웹 리소스를 참조한다. 또한 URI의 중요한 특징은 역참조(dereference)가 가능하다는 것이다. 즉 URI에 기술된 서버 이름, 프로토콜, 포트 번호, 파일 이름을 통해 리소스의 역추적이 가능하며 이에 따라 리소스의 참조를 통한 데이터의 재사용이나 병합, 매쉬업(mashup) 등이 가능하다.

[그림 1-7] [그림 1-6]의 그래프를 URI로 표현한 예

이러한 그래프 구조는 앞에서 보았듯이 동일한 식별자(URI)를 통해 데이터의 병합이 쉽게 이루어진다. 따라서 상이한 문서에 기술되어 있는 리소스라 하더라도 URI를 통해 같은 리소스라고 판단되면 병합이 가능하다. 또한 그래프 모델은 기존의 그래프 구조를 변경하지 않고 노드를 통해 트리플을 계속 연결시켜 확장할 수 있다. 결과적으로 데이터를 RDF로 기술함으로써 유연성과 확장성이 좋은 데이터 모델을 가질 수 있으며, 웹에 분산되어 있는 다양한 이질적인 데이터들을 유현하게 처리할 수 있게 된다.

1.3 온톨로지(Ontology)철학에서의 온톨로지는 형이상학에 속하는 ‘존재(being, 또는 existence)’ 및 이에 대한 개념적 정의와 분류, 즉 ‘존재에 관한 체계적인 이론’이다[4].


[그림 1-8] 존재론 관점에서 본 온톨로지의 예

컴퓨터 공학과 정보학에서의 온톨로지란 ‘인간이 대상 세계를 바라보는 관점에 따라 개념화하여 이를 인간과 컴퓨터가 이해할 수 있는 형태로 표현한 모델’로서 개념의 타입이나 사용상의 제약 조건들을 명시적으로 정의한 기술(description)이다. 탐 그루버(Tom Gruber)의 유명한 온톨로지 정의에 따르면[3] ‘온톨로지는 형식적이고 명확한 표현으로 공유되는 도메인 지식의 개념화(an ontology is a formal, explicit specification of a shared conceptualization of a domain of interest)’이다. 즉 특정한 영역(domain)에 속하는 개념들을 정형화(formalization)된 형식으로 명시적으로 설명(explicit specification)하고 집단 구성원 간에 합의, 공유함으로써 집단 내의 커뮤니케이션을 원활하게 하기 위한 목적을 가지고 있는 것이다. 이를 위해 특정한 영역을 표현하는 데이터 모델로서 특정한 영역에 속하는 개념과, 개념 사이의 관계를 기술하는 정형(formal) 어휘의 집합을 정의하고 이를 형식 언어(formal language)로 나타낸다. 그 결과 온톨로지를 통해 특정한 영역에 대한 공통의 이해를 가지게 되고, 인간과 인간, 인간과 기계뿐만 아니라 소프트웨어 에이전트(agent)로 대표되는 기계와 기계 사이의 커뮤니케이션이 가능하게 된다. 또한 형식 언어로 표현된 데이터 모델은 합의되고 공유된 지식으로 재사용이 가능하며,


정보의 상호운용성을 위한 표준으로서의 역할을 가지게 된다.앞서 언급했듯이 팀 버너스리(Tim Berners-Lee)의 정의에 따르면 ‘시맨틱 웹은 잘 정의된 의미(well-defined meaning)를 정보에 부여함으로써 기계와 인간이 더욱 잘 협력할 수 있는 현재 웹의 확장’이다. 여기에서 ‘잘 정의된 의미’란 데이터가 공통의 언어와 구조로 표현되어 상호 연결되고 호환될 수 있어야 한다는 것을 의미한다. 시맨틱 웹은 데이터를 공통의 언어와 구조로 표현하기 위한 형식 언어로써 RDF를 채택하고 있다.

[그림 1-9] 온톨로지의 예

시맨틱 웹에서의 RDF 데이터 모델은 특정한 영역에 속하는 개념들을 정형화된 형식에 따라 명시적으로 기술한 온톨로지이며, 더 나아가 RDF 데이터 모델을 기반으로 정의된 어휘 집합인 RDFS, OWL은 더욱 복잡한 지식 표현이 가능한 개념 모델, 즉 더욱 복잡한 구조의 온톨로지를 만들기 위한 도구를 제공한다. 따라서 RDFS, OWL로 표현된 온톨로지는 도메인 지식을 형식 언어로 개념화함으로써 웹 데이터의 의미적 호환과 처리를 가능하게 하는 시맨틱 웹 실현을 위한 핵심기술이라고 말할 수 있다.


2 시맨틱 웹 기술

기계가 데이터의 의미를 이해하고 처리하게 하기 위해 시맨틱 웹은 주요하게 리소스를 명명하기 위한 URI, 분산형 데이터 모델 및 표현 언어로서의 RDF, 데이터의 의미구조 표현을 위한 온톨로지 언어로서의 RDFS, OWL 및 질의 언어인 SPARQL 등의 계층 구조로 구성된다.

[그림 1-10] 시맨틱 웹 레이어 케이크1)

2.1 URI앞에서 언급했듯이 기본적으로 데이터가 실세계의 개체(entity)와 대응되는 리소스(resource)로서 시맨틱 웹에서 통용되는 이름, 즉 범용식별자가 URI(Uniform Resource Identifiers)이다. URI를 통해 실세계의 개체를 참조하는 웹 리소스를 명명하는 것이 가능하게 된다. 즉 ‘제목’, ‘title’, ‘표제’, ‘타이틀’과 같이 하나의 개체

1) http://www.w3.org/2007/03/layerCake.png


를 참조하는 여러 이름이 있지만 ‘http://purl.org/dc/elements/1.1/title’ 이라는 속성을 공통 URI 참조로 사용함으로써 이름의 애매모호함을 없앨 수 있다[6]. 또한 시맨틱 웹에서는 누구나 데이터를 웹에 발행(publish)하는 것이 가능하므로 하나의 리소스를 참조하는 다양한 URI 참조가 생길 수 있지만, 이러한 다양한 URI 참조가 하나의 URI를 참조하게 함으로써 일관성 있고 수월하게 데이터를 교환할 수 있게 한다.

2.2 RDF(Resource Description Framework)웹의 분산성에 적합하도록 설계된 트리플 형식의 그래프 기반 데이터 모델을 형식 언어로 나타내고, 데이터의 의미 구조를 표현하기 위한 RDF는 시맨틱 웹의 공통 데이터 포맷으로서 서로 다른 정보원의 데이터라 할지라도 웹에서의 호환이 가능하도록 해 준다.앞서 보았듯이, RDF는 데이터를 주어, 술어, 목적어의 트리플 형식으로 표현하고, 이러한 트리플들의 집합이 그래프를 구성한다. 그래프 기반의 데이터 모델은 동일한 URI를 갖는 노드를 통해 쉽게 병합되며, 대규모 분산 데이터 환경인 시맨틱 웹의 데이터 모델로서 유연성과 확장성을 제공한다.

2.3 RDFS(RDF Schema Language)RDFS는 RDF에 기반을 두어 데이터의 의미구조, 즉 스키마(schema)를 표현하기 위한 더욱 풍부한 어휘집합(vocabularies)을 가지고 있다. RDFS는 RDF를 위한 스키마 언어이다. 즉 개체(entity)의 종류(rdfs:domain, rdfs:range), 다른 개체와의 관계(rdfs:subClassOf), 개체를 기술하기 위한 술어부 및 그것들 간의 관계(rdfs:subPropertyOf)를 기술하기 위한 어휘 도구들(constructs)을 제공한다. 이러한 도구들을 이용하여 RDFS는 공통의 어휘(vocabulary)와 어휘들 간의 관계(taxonomy)를 정의한다.


[그림 1-11] RDFS로 표현된 와인 온톨로지

2.4 OWL(Web Ontology Language)RDFS의 비교적 단순한 기술에서 좀 더 나아가, 풍부한 데이터 모델을 표현하고자 정의된 것이 OWL(Web Ontology Language)이다. OWL은 RDFS에 기반을 두어 더욱 풍부한 구성자(constructs)를 제공함으로써 데이터 모델의 표현력을 높이고, 복잡한 추론을 가능하게 하며 데이터의 논리적 구조에 대한 일관성(consistency)을 검사하는 역할을 한다. 예를 들어, ‘author와 auteur는 동일한 개념이다’라는 것을 표현하기 위해 owl:sameAs를 사용할 수 있다. 또한 프로퍼티의 역관계를 표현하는 owl:inverseOf나 제한 클래스(restriction class) 등을 사용하여 온톨로지를 더욱 풍부하게 확장할 수 있다.


[그림 1-12] OWL 에서의 inverseOf 구성자의 예

시맨틱 웹의 온톨로지 언어인 RDF, RDFS, OWL 각각에 대한 간략한 특징 및 세부사항을 정리하면 아래와 같다.

온톨로지 언어 세부사항RDF

(ResourceDescriptionFramework)

시맨틱 웹 상위계층의 기반이 되는 기본 프레임워크누구에게나 어떤 것에 대해 기본적인 서술을 하게 하는 메커니즘표현하고자 하는 내용을 계층화(Layering)하는 메커니즘2003년 이후부터 W3C의 권고안

RDFS(RDF

SchemaLanguage)

클래스, 하위 클래스 및 속성들과 같이 객체 언어들과 다른 클래스 시스템에서 익숙한 공통성과 변형성의 기본 개념들을 기술하기 위한 표현력을 가진 언어2003년 이후부터 W3C의 권고안

OWL(Web

OntologyLanguage)

시맨틱 웹에 논리적인 표현력을 부여모델 설계자에게 세부적인 클래스, 개체(entity), 속성들 간의 제약을 표현할 수 있도록 함2003년 이후부터 W3C의 권고안

[표 1-2] RDF, RDFS, OWL의 비교


RDF에서 RDFS, OWL로 진화할수록 데이터의 의미 구조, 즉 시맨틱(semantic)을 표현하는 능력이 증가하며, 이러한 언어를 통해 의미적 상호운용성(semantic interoperability)이 높아지고, 추론 능력이 증대됨을 통해 더욱 복잡한 지식 처리가 가능해진다.

[그림 1-13] 시맨틱의 표현 정도에 따른 추론 능력의 증가 관계2)

2.5 SPARQL2008년 1월 W3C 권고안으로 승인된 SPARQL은 분산되어 있는 시맨틱 웹 데이터를 효과적으로 접근하고 탐색하기 위한 질의 언어이다. 트리플로 구성된 RDF 그래프는 트리플 레파지토리(triple repository)에 저장되어 있건 또는 미들웨어를 통해 RDF 뷰(view)로 변환된 데이터이건 상관없이 다양한 정보원의 데이터를 질의를 통해 병합하고 뷰(view)로 표현함으로써 데이터 통합을 위한 중요한 기능을 수2) Project10X’s Semantic Wave 2008 Report, Industry Roadmap to Web;

http://www.scribd.com/doc/2599547/Project10Xs-Semantic-Wave-2008-Report-Industry

-Roadmap-to-Web-30-


행한다. SPARQL이라는 표준이 확립되기 전까지 RDF 데이터를 검색하기 위한 질의 언어는 RQL(Sesame), RDQL(Jena) 등과 같이 트리플 레파지토리에 따라 다양하게 존재해왔다. 따라서 질의 언어 간의 호환이 문제시 되었으며, SPARQL이라는 표준 질의 언어를 통해 다양한 정보원의 데이터를 접근하게 됨으로써 시맨틱 웹 분야의 중요한 발전을 이루게 되었다. SPARQL은 SQL과 비슷한 문법을 가지고 있다.

[그림 1-14] SPARQL 문법의 예

PREFIX 선언은 질의어 내부에서 사용할 네임스페이스의 약어에 대한 선언이며, 예제에서 사용된 dc:title은 <http://purl.org/dc/elements/1.1/title>로 해석된다.SELECT는 결과값에 대응하는 변수들을 SELECT var1, var2, … , varn의 형식으로 선언한다. WHERE 절은 그래프 패턴의 일치 여부를 통해 특정 데이터를 탐색하기 위한 조건을 기술하는 트리플 집합으로 구성된다. 여기에는 변수(예. ?x)가 포함될 수 있으며, 변수에 값을 대응시킴으로써 대응된 변수 값을 포함하는 트리플과 일치하는 하위 그래프가 선택될 수 있다.

[그림 1-15] SPARQL 예제

이외에 시맨틱 웹 기술을 위한 표준으로 다양한 규칙 기반 시스템 간의 상호 호환을 위한 RIF(Rule Interchange Format)가 있다. RIF는 2009년 7월 표준 권고안이 채택되었으며, 시맨틱 웹에서 규칙 기반 언어 간의 상호 호환을 통해 추론을 지원하는 역할을 한다.


3 트리플 레파지토리(Triple Repository)

3.1 개요 및 특징시맨틱 웹에서 데이터는 RDF, RDFS, OWL 기반의 그래프 모델에 따라 기술되는 트리플 형태로 표현된다. 따라서 트리플 형태의 시맨틱 웹 데이터를 저장하고 관리하기 위한 저장 시스템이 필요하다. ER 모델을 기반으로 한 DBMS와 유사하게 데이터를 저장하고 질의하며 관리하기 위한 도구가 바로 트리플 레파지토리이다.트리플 레파지토리는 RDF 저장소(store), RDF 레파지토리, 트리플 저장소와 같이 다양하게 불린다. 전통적인 데이터베이스 관리시스템(DBMS)과 마찬가지로 트리플 레파지토리는 데이터를 저장하고 질의하는 기본적인 역할을 담당하며, 저장될 수 있는 데이터의 양과, 데이터에 접근하고 업데이트 하는 속도 및 질의 엔진이 지원하는 질의 언어의 다양성에 따라 다양한 제품이 존재한다. 그러나 트리플 레파지토리는 RDF 기반의 방향성 그래프 모델을 사용함으로써 기존의 데이터베이스 관리시스템(DBMS)이 제공하는 일반적인 기능 외에도 다음과 같은 중요한 기능적 특징이 있다.첫째, 트리플 레파지토리는 다양한 데이터 집합을 병합하는 기능을 가지고 있다. 관계형 DBMS는 하나의 시스템에서 다른 시스템으로 데이터베이스 전체를 변환하기 위해서는 별도의 작업을 거쳐야 하는 문제가 있다. 그러나 트리플 레파지토리는 하나의 시스템에서 다른 시스템으로 데이터를 옮기고자 할 때 공통의 RDF 표준 포맷을 이용하므로 별도의 노력이 없이 쉽게 다른 시스템에 통합될 수 있다[5]. 둘째, 트리플 레파지토리는 병합된 데이터들에 대해 기술된 명시적 사실(explicit assertion)로부터 RDFS, OWL의 시맨틱을 통해 데이터의 논리적 일관성을 검사하고 유지한다. 또한 추론(inference)을 통해 새로운 사실(inferred assertion)을 생성하고 이를 트리플 레파지토리에 추가한다. 이를 위해 트리플 레파지토리에는 추론 엔진이 포함되어 있거나 또는 외부 추론 엔진을 위한 인터페이스가 있다.


3.2 구조트리플 레파지토리는 트리플을 색인(index) 및 저장하며, 데이터를 관리하는 기본적인 모듈과 함께 RDF 트리플에 대한 질의 처리를 위한 질의 엔진, 추론을 위한 추론 엔진이 연동된다.

3.2.1 물리적 저장 계층물리적 저장계층은 트리플이 저장되는 곳으로 디스크 또는 메인 메모리에 물리적인 파일 형태로 데이터가 저장되는 저장소와 RDF 트리플을 효과적으로 탐색하기 위한 색인 파일(index file)로 구성된다. RDF 트리플은 대개 BTree 또는 B+Tree 형식의 물리적인 파일로 작성되어 메인 메모리 또는 영속적인 디스크에 저장되는데, 이 경우는 RDB에 매핑하여 저장하는 방식과 RDF 트리플을 위한 고유의 파일구조에 저장하는 방식으로 나뉜다.

[그림 1-16] 트리플 레파지토리의 구조

색인 기술은 RDF 데이터에 대한 질의 처리를 효과적으로 하기 위한 색인을 생성하고 관리하는 기술로, 대략적으로 구조 색인, 경로 색인, 리터럴(literal) 색인이 있다. 구조 색인은 트리플 구조에 대한 질의를 효과적으로 수행하기 위하여 만들어지는 것으로 제품마다 질의 처리를 위한 알고리즘에 따라 고유한 색인 방식을 가진다.예를 들어 트리플 각 구성요소 마다 두 개의 쌍으로 색인을 만들어 하나의 트리플


당 6개의 색인을 만드는 방식3)이 있다. 이외에도 RDFS, OWL 스키마를 고려, 특정 클래스에 존재하는 인스턴스 트리플에 대한 색인을 만들 수도 있다.경로 색인은 RDF 그래프에 대해 주어진 경로에서 도달 가능한 모든 개체(entity)에 대한 정보를 색인하는 것으로 그래프 알고리즘을 이용한다.리터럴 색인은 텍스트 기반 검색을 위한 색인으로 트리플에 나타나는 문자열을 색인한다.

3.2.2 질의 엔진질의 엔진은 트리플 레파지토리에 저장된 RDF 데이터에 대한 질의를 할 수 있도록 질의어를 처리하는 기능을 한다. 대개 질의 파서(query parser), 질의 옵티마이저(query optimizer), 질의 시리얼라이저(query serializer)로 구성된다. 질의 파서는 일반적으로 트리플 형식의 RDF 그래프 모델에 대한 질의 언어인SPARQL의 문법으로 표현된 질의를 트리플 레파지토리 내부에서 처리 가능한 형태로 분석, 변환한다. 질의 옵티마이저는 질의를 빠르게 처리할 수 있도록 다양한 패턴들의 처리 순서들을 최적화하는 모듈이며, 질의 시리얼라이저는 질의 요청 및 질의 결과에 대한 전송에 관련된 모듈이다.

3.2.3 트리플 로더RDF 트리플을 읽고 쓰기 위한 시스템 구성 요소이다. 저장과 질의를 처리하기 위해 저장소에 저장된 파일로부터 표현되는 트리플의 내부적 표현을 RDF 트리플로 변환하는 RDF 시리얼라이저와, 이와 반대로 RDF 파일 입력을 저장소에 저장하기 위한 내부적 표현으로 변환하는 RDF 파서로 구성된다.

3.2.4 저장소 관리시스템 관리를 위한 여러 모듈이 포함된다. 로그 처리, 모니터링 서비스, 수행 작업들을 관리하기 위한 잡 스케줄러(job scheduler) 등이 포함된다. 또한 내부적으로 서버 관리에 필요한 메타 정보를 관리하는 내부 데이터베이스와, 서버 관리자를 위3) 트리플의 구성요소 중 주어부(subject)를 예로 들면, 특정 주어부가 포함된 트리플에 대해 (술

어부(predicate), 목적어부(object)), (목적어부(object), 술어부(predicate))와 같이 두 개의 쌍

으로 색인을 만든다.


한 웹 관리도구 등이 포함된다.

3.3 종류트리플 레파지토리는 데이터를 저장하는 구현 방식에 따라 In-Memory, Native, Non-Memory/Non-Native로 구분한다.

3.3.1 In-MemoryIn-Memory 트리플 레파지토리는 RDF 그래프를 트리플의 형태로 메인 메모리에 저장하는 방식이다. 따라서 대용량 데이터를 저장하기에는 무리가 있으며, 대용량 환경에서 주요한 고려 대상은 아니지만 추론에 있어서는 효과적이기 때문에 디스크 저장 방식의 레파지토리에서 추론 성능의 문제를 해결하고자 할 때 부분적으로 고려되기도 한다. In-Memory 방식은 RDF 데이터가 파일 시스템에 있든, DBMS에 있든 상관없이 API를 통해 데이터에 접근하고 메인 메모리에 저장, 질의할 수 있는 기능을 제공하는 방식(예. Jena API, Sesame API 등)과 RDF 트리플 고유의 형식으로 메인 메모리에 저장, 질의하는 방식(예. BRAHMS, SwiftOWLIM 등)으로 나눌 수 있다.

3.3.2 NativeNative 방식은 RDF 트리플 고유의 데이터베이스를 디스크 형태의 영속적인 스토리지(storage)에 물리적으로 구현하는 방식이다.AllegroGraph, Garlik JXT, OWLIM, Sesame Native, Jena TDB, Mulgara(이전의 Kowari), Virtuoso, Oracle 11g 및 OntoBase2.0, DQReasoner4) 등이 여기에 속한다. Sesame나 Jena는 시맨틱 웹 어플리케이션 개발을 위한 오픈 프레임워크 형태로 Native 방식, API를 통한 In-Memory 방식 및 다음에서 다룰 Non-Native/Non-Memory 방식 모두를 각각 지원한다.RDF 그래프 고유의 데이터 저장 방식인 Native 방식은 현재 다양한 상용 제품 및 오픈 소스의 등장으로 RDF 데이터 저장소의 주요한 구현 방식으로 자리 잡고 있4) KISTI의 OntoReasoner를 기술 이전하여 개발한 Native 방식의 트리플 레파지토리


다. 각 제품은 지원하는 추론 엔진, 대용량 처리 능력(scalability), 제공되는 API, 질의 처리 엔진이 지원하는 질의 언어의 종류, 공간 데이터 처리 지원 등의 특징에 따라 매우 다양하다. 예를 들어 대표적인 상용 제품인 AllegroGraph는 추론 엔진을 내장하고 있어 RDFS++5) 수준의 추론이 가능하며 공간 데이터를 처리하는 기능 및 소셜 네트워크(social network) 분석 기능 등을 특징으로 한다.

3.3.3 Non-Memory/Non-NativeNon-Memory/Non-Native방식은 RDB를 저장소(storage)로 하여 RDF 데이터 모델, 즉 그래프 기반의 데이터 모델을 영속적으로 저장, 처리할 수 있도록 구현된 방식이다. 대표적인 제품으로 OntoReasoner, Jena SDB, Sesame, RDF Store가 있다. Jena SDB는 MySQL, PostgreSQL, Oracle, DB2 등 다양한 데이터베이스에 대한 접근이 가능하며, 다양한 형태의 색인을 데이터베이스로 저장할 수 있도록 하는 환경설정이 가능하다. Jena SDB와 Sesame는 기능적으로 매우 유사한데, MySQL, PostgreSQL, Oracle, DB2 등 다양한 데이터베이스에 접근하기 위한 API(connection API)를 제공하고, 특히 복수의 데이터베이스를 동시에 저장소로 지원할 수 있다 [7]. RDF Store는 Oracle 데이터베이스를 저장소로 이용하며, SQL에 기반을 둔 RDF 질의 인터페이스를 제공한다.

5) OWL에서 자주 쓰이는 구성자로 만들어진 OWL 하위 집합을 말한다.

19

제 2 부 트리플 레파지토리의 필요성

1 웹의 진화 및 시맨틱 웹의 확산

IT 기술의 발전과 더불어 다양한 시스템 사이의 상호운용성이 확보되면서 오늘날의 웹은 웹을 활용하는 사용자의 의식 변화와 함께 개방적이고 지능적인 방향으로 점차 진화하고 있다. 이러한 웹의 진화에 있어 시맨틱 웹은 하나의 큰 흐름으로 볼 수 있다.

[그림 2-1] 웹의 진화6)

6) http://novaspivack.typepad.com/RadarNetworksTowardsAWebOS.jpg


세계적인 IT 기술 관련 연구와 시장 관련 조사 기업인 가트너 그룹(Gartner Group)7)은 시맨틱 웹 발전 전망 보고서에서 향후 10년 동안 기존의 웹 기반 구조에 시맨틱 웹 관련 기술의 발전이 더해져 다양한 산업 분야에서 시맨틱 웹이 활용될 것이라고 전망하고 있다. 2012년이면 70%의 공공 분야 웹 페이지가 일정 수준의 시맨틱 웹 언어를 사용하고, 약 20% 정도의 특정 영역에서는 보다 확장된 수준의 시맨틱 웹 기반 온톨로지가 사용될 것으로 예측하고 있다.

[그림 2-2] 시맨틱 웹의 발전 방향8)

지금까지의 웹은 문서와 문서를 단순히 연결하는 하이퍼링크를 기반으로 발전하여 왔다. 웹을 구성하는 각각의 리소스들은 사람이 읽고 이해하는 것은 가능하지만 컴퓨터가 읽고 이해하기에는 부적합하다. 즉, 시스템 사이의 자동화된 데이터 연계에 있어서는 근본적인 한계가 존재한다. 이러한 한계를 극복하기 위해서는 데이터에 대한 정보를 기술하고, 기술된 데이터 정보를 통해 데이터의 구조와 의미를 파악하여 처리, 가공할 수 있어야 한다.XML을 이용하여 기존의 웹 데이터를 기술하는 것이 가능하긴 하지만 XML의 풍7) http://www.gartner.com

8) http://www.w3.org/2008/Talks/0130-bratt-W3C-Energy/W3C-SemWeb-Appsp.pdf

제2부 트리플 레파지토리의 필요성 21

부한 표현력이 단점으로 작용할 수 있다. 서로 다른 시스템 사이에서의 데이터 연계를 위해서는 데이터를 보내는 곳과 받는 곳에서의 데이터 구조나 의미에 대한 정교한 프로토콜이 필요한데, 동일한 데이터에 대해 지나치게 다양한 표현이 가능하다면 방대한 웹 영역에서 특정 리소스를 식별하기 어려워진다. 이러한 XML의 통제된 의미적 데이터 기술 한계를 극복하고자 세계 웹 표준화 기구인 W3C에서는 시맨틱 웹을 위한 기반 표준 언어로서 RDF(Resource Description Framework)를 채택하였다.시맨틱 웹이 확산되면서 웹에서 유통, 활용되는 정보들이 RDF를 이용하여 표현되는 사례 또한 증가하고 있다. RDF 트리플로 표현된(Represented or Described) 온톨로지는 시맨틱 웹 기반의 지식 자원을 필요로 하는 다양한 응용 영역들에 적용될 수 있으며, 서비스 인프라에 해당하는 RDF 트리플 레파지토리(Triple Repository)는 시맨틱 웹 기술을 활용하기 위해 필요한 가장 핵심적인 시스템이라 할 수 있다. 트리플 레파지토리는 RDF, RDFS(RDF Schema), OWL(Web Ontology Language) 등의 온톨로지 기술 언어로 표현된 시맨틱 웹 데이터를 RDF 트리플로 변환하고 이를 저장, 관리, 질의할 수 있는 시스템으로 정의할 수 있다

2 DBMS와 트리플 레파지토리

트리플 레파지토리의 성능과 품질을 평가하는 관점에서 본다면 DBMS와 유사한 측면이 많다. 그렇지만 트리플 레파지토리의 주목할 만한 차별성은 RDF 데이터 모델의 표준화와 RDF/XML의 표준화에 있다. 즉, 트리플 레파지토리는 RDF 기반의 방향성 그래프(Directed Graph) 모델을 사용함으로써 DBMS가 제공하는 일반적인 기능 외에도 다음과 같은 중요한 기능적 특징들을 가진다. 첫째, 트리플 레파지토리는 다양한 데이터 집합을 병합하는 기능을 가지고 있다. DBMS는 하나의 시스템에서 다른 시스템으로 데이터베이스 이식하거나 변환하기 위해서 스크립트 프로그래밍 등 부가적인 작업을 거쳐야 하고, 그럼에도 그 작업의 성공 여부를 보장할 수 없다는 문제가 있다. 그 이유는 데이터를 표현하고 저장하는 방식이 시스템마다 상이하고, 시맨틱 웹에서의 RDF 트리플과 같은 표준 형식으로 데이터를 직렬화할 수


없기 때문이다. 반면 트리플 레파지토리는 하나의 시스템에서 다른 시스템으로 데이터를 옮기고자 할 때 RDF 표준 포맷을 이용하므로 부가 작업을 요구하지는 않는다. 둘째, 트리플 레파지토리는 병합된 데이터가 가지는 명시적 사실(Explicit Assertion)의 논리적 일관성을 검사할 수 있다. 또한 추론(Inference or Reasoning)을 통해 얻어진 사실(Inferred Assertion)을 생성하고 기존 데이터에 추가한다. 이러한 작업을 수행하기 위해 트리플 레파지토리는 추론 엔진을 포함하거나 외부 추론 엔진과의 연계 인터페이스가 필요하다.트리플 레파지토리는 RDF 트리플을 시맨틱 웹 응용에서 효율적으로 활용하기 위한 시맨틱 웹의 핵심 구성 요소이다. 트리플 레파지토리는 RDF 트리플을 파싱하고 저장하는 파서 또는 트리플 빌더, 질의를 해석하고 처리하는 질의 처리기, 대용량 RDF 트리플을 효과적으로 처리하기 위한 추가 모듈 등으로 구성된다. 트리플 레파지토리의 성능은 저장되고 관리되는 RDF 트리플을 안정적이고 효율적으로 처리하는 능력에 따라 결정된다고 볼 수 있다.

3 트리플 레파지토리의 활용

기업 내 정보 시스템의 상호운용성(Interoperability) 확보를 위해 시맨틱 웹 기술을 적용하기 위해 일반적으로 구성하는 시스템 구성도는 [그림 2-3]과 같다. 기업 내 정보 시스템은 해당 시스템의 고유 서비스를 위해 비즈니스 로직과 정보를 그대로 유지하도록 하여 기존 업무 흐름을 변화시키지 않게 한다. 시맨틱 웹 기술을 적용하여 온톨로지 기반의 지능형 서비스를 구현하기 위해서는 온톨로지 모델(Ontology Schema)의 설계가 선행되어야 한다. 온톨로지 모델을 기반으로 기존의 정보를 온톨로지 모델에 맞게 변환할 수 있는 변환 엔진도 필요한데, 변환 엔진은 기존 정보의 수집 규칙과 온톨로지 변환 규칙에 의해 구동되며, 이렇게 변환된 온톨로지(Ontology Instances)가 트리플 레파지토리에 저장된다. 이러한 구성을 통해 시맨틱 웹 기술이 기업 내 시스템에 적용될 수 있는 것이다.

제2부 트리플 레파지토리의 필요성 23

[그림 2-3] 시맨틱 웹 기술 활용을 위한 시스템에서의 트리플 레파지토리

24

제 3 부 시장 동향

1 시맨틱 웹 어플리케이션을 위한 관련 도구들

시맨틱 웹 어플리케이션을 구현하기 위해서는 RDF 데이터를 저장하고 관리하는 트리플 레파지토리 외에도 시맨틱 웹 데이터의 생성 및 이용에 이르는 각각의 기술과 이를 지원하는 도구들이 필요하다. 먼저 시맨틱 웹 데이터 모델인 온톨로지를 정의해야 하고, 이에 따라 RDF 형식의 시맨틱 웹 데이터를 생성하기 위한 도구가 필요하다. 또한 기존의 레거시 데이터를 RDF 형식으로 변환하기 위한 변환기, 생성된 데이터에 대해 의미 정보를 추론하는 추론 엔진 및 데이터를 접근하고 탐색하기 위한 질의 인터페이스도 필요하다.

[그림 3-1] 시맨틱 웹 어플리케이션 구성을 위한 주요 기술 요소

제3부 시장 동향 25

온톨로지 관리 도구 특징 상용/

오픈소스

Protege클라이언트-서버 기반의 멀티 유저 모드 지원그래프 형식의 온톨로지 가시화(visualization) 기능다양한 데이터베이스 백엔드(backend) 지원다양한 플러그인 제공

오픈 소스

1.1 온톨로지 엔지니어링온톨로지 엔지니어링은 온톨로지를 개발하고 구축하는데 관련된 기술로 개발 방법론을 이용하여 온톨로지를 모델링하고 체계적으로 온톨로지를 개발하며, 수정사항을 관리하고, 여러 온톨로지 간의 매핑과 병합, 조정(alignment)을 통한 온톨로지 상호운용성(interoperability)을 연구하는 기술이다.

1.1.1 온톨로지 개발(Ontology Development)온톨로지 개발은 대개 요구사항 명세, 온톨로지 설계, 온톨로지 구현, 유지보수 및 개선 등의 절차를 거치게 된다. 이에 따라 온톨로지 모델링 기술 및 모델링 도구, 온톨로지의 점진적인 개선을 위한 온톨로지 관리 도구 및 버전 관리 도구가 필요하다. 방법론적인 측면에서 보면 처음부터 새롭게 온톨로지를 구축하는 것이 아니라 기존 지식자원(분류체계, 택소노미(taxomomy), 용어사전, 시소러스(thesaurus) 등)을 이용하여 용어 간 의미관계를 추가하는 식으로 온톨로지를 변환하는 방법이 있으며, 기존의 온톨로지 자원을 재사용하여 새로운 목적에 맞게 확장(extend) 하거나, 가지치기(prune), 또는 지역화(localize) 함으로써 새로운 온톨로지를 만드는 방법이 있다. 두 가지 경우 모두, 온톨로지는 온톨로지 설계자에 따라 그 개념화가 달라지며, 일단 개발되고 나서도 끊임없이 수정되고 진화하게 된다. 따라서 온톨로지에 수정이 이루어지면 적시에 온톨로지 전체에 대해 일관된 수정사항을 적용하고 일관성을 검사하는 기능이 중요하다. 또한 다양한 온톨로지 버전의 생성과 관리 및 다양한 변동 사항 간의 관계를 관리하고, 버전 간의 호환성 및 매핑 등을 다루는 온톨로지 버전 관리기능이 지원되어야 한다.

제3부 시장 동향26

SwoopAnnotea 프로토콜을 이용하여 여러 사용자들 간의 온톨로지의 ‘change set’을 공유하는 기능온톨로지 진단(diagnosis)을 통한 온톨로지 일관성 검사 및 디버깅(debugging) 기능가시화 기능

오픈 소스

TopBraid Composer

여러 포맷의 데이터(XML, 스프레드시트, RDB 데이터 등) 임포트(import) 및 RDF 변환, 온톨로지 임포트 기능그래프 형식의 가시화 기능다양한 추론 엔진 연동 지원 기능다양한 데이터베이스 백엔드 지원데이터 매쉬업(mashup) 기능 제공: SparqlMotion

상용 제품

NEON Toolkit

EU 프로젝트로 네트워크 온톨로지(networked ontology)의 개발, 관리를 위한 모듈성 지원전체 온톨로지 라이프사이클을 관리하는 온톨로지 엔지니어링 및 관리 툴킷 제공온톨로지 모델링, 온톨로지 러닝, 커스터마이징 등 개발 관련 툴들과 온톨로지 매핑, 비온톨로지 자원 통합 기능, 온톨로지 분석, 수리 기능을 지원하는 툴들로 구성

오픈 소스

[표 3-1] 온톨로지 관리 도구1.1.2 온톨로지 매핑(Ontology Mapping)위에서 살펴본 온톨로지 개발(ontology development)외에도 온톨로지 간 상호운용성을 해결하기 위해, 또는 기존의 온톨로지 자원을 다른 목적으로 사용하기 위해 둘 이상의 온톨로지를 병합(merging)하거나, 매핑(mapping), 매칭(matching), 조정(alignment)하는 기술이 있다. 온톨로지의 모듈성, 분산성으로 인해 같은 도메인 지식을 표현하는 다양한 온톨로지가 존재하고, 또 기존의 온톨로지를 재사용하기 위해서 여러 온톨로지를 병합하여 새로운 온톨로지 구조에 맞추는 작업이 필요하기 때문에 온톨로지 병합, 매핑, 조정이 필요하게 된다.


온톨로지 매핑

(Ontology Mapping)

미리 정의된 매핑 규칙에 의해 온톨로지1과 온톨로지2의 개념(클래스), 관계(프로퍼티), 또는 인스턴스(개체)가 동일한 것끼리 일치시킴.

온톨로지 얼라인먼트(Ontology Alignment)

두 온톨로지 간의 유사성을 부분/포함관계, 배타관계, 등가관계 등으로 규정하고 이에 따라 클래스(반드시 논리적으로 동일하지는 않음)를 대응온톨로지 매칭(matching)이라고도 하며 병합/매핑을 포괄하는 광의의 의미로 사용되기도 함.

온톨로지 병합

(Ontology Merging)

둘 이상의 온톨로지로부터 하나의 온톨로지를 생성.합집합(union) 접근 방식: 병합된 온톨로지가 소스 온톨로지들의 중복을 제거한 모든 것을 포함.교집합(intersection) 접근 방식: 소스 온톨로지의 교차되는 부분만으로 구성.

[표 3-2] 온톨로지 매핑, 얼라인먼트, 병합의 정의

이를 지원하는 도구로는 대표적으로 SMART와 PROMPT가 있다. SMART는 반자동 온톨로지 병합/조정 도구로 클래스 이름의 언어적 유사성(동의어, 단어 부분 매핑)을 기반으로 두 온톨로지 간의 클래스를 매핑한다. PROMPT는 Protege 플러그인으로 사용자 인터페이스를 포함하고 있으며 언어적 유사성과 데이터 구조를 기반으로 두 온톨로지 간의 차이를 계산하는 알고리즘에 따라 수정사항을 자동으로 감지하는 기능을 포함하고 있으며, 사용자에게 수정사항을 제안하고 수정에 대한 결과를 지적해 준다.

1.2 시맨틱 웹 데이터 생성 및 변환기시맨틱 웹 데이터를 생성하기 위해서는 처음부터 시맨틱 웹 데이터 모델에 맞는 RDF 데이터를 입력하거나 또는 기존의 레거시(legacy) 데이터를 RDF로 변환하여야 한다. RDF 데이터의 입력은 기존의 RDF 에디터를 이용하거나 또는 어플리케이션의 입력 기능을 통해 이루어지므로 여기에서는 특별히 다루지 않고, 기존의 레거시 데이터의 RDF 변환 기술에 대해 다루고자 한다.


1.2.1 어노테이션(Annotation)기존의 레거시 데이터를 RDF로 변환하기 위한 방법을 RDF 태그를 붙인다고 하여 광의적으로 태깅(tagging), 또는 어노테이션(annotation)이라고 한다. 레거시 데이터베이스(특히 DBMS)의 데이터를 RDF화하는 방법은 다시 특수하게 다루어지므로 여기서는 웹 문서(텍스트, 이미지 등을 포함한)에 대한 어노테이션(즉 RDF 태깅)이라고 표현할 것이다.온톨로지 기반 어노테이션은 도메인 지식에 대한 개념화인 온톨로지 모델에 따라 대상 문서에서 자동 또는 수동으로 RDF로 태깅할 개념을 추출한 뒤, 이에 대해 적절한 온톨로지 상의 개념을 매핑, RDF 데이터로 태깅하고 트리플 레파지토리에 저장한다. 이미지인 경우 의미 기반의 이미지 분석에 따라 추출된 개념 및 이미지 분류나 클러스터링(clustering)을 적절한 온톨로지 개념으로 매핑하여 RDF 태깅 후 저장한다. 텍스트 문서나 이미지 분석에 따른 개념 추출은 개체(entity) 추출, 관계 추출, 이벤트 추출로 나눌 수 있다. 지명, 인명 또는 분류명 등을 기존의 용어집이나 사전 등을 참조하여 단어를 추출하고 추출된 단어가 동의어인 경우에 명확성을 규명(disambiguation)한 뒤 URI를 부여하고, 온톨로지를 이용하여 개체와 그에 대한 관계를 매핑하여 RDF화한 데이터를 트리플 레파지토리에 저장한다.

[그림 3-2] 온톨로지 기반의 웹 문서 어노테이션 [8]9)

9) Fabio Ciravegna, Semantic Web Technologies for Capturing, Sharing and Reusing Knowledge;

http://sssw09.org/slides/SSSW09-FC-slides.pdf


어노테이션시스템 특징 개발기관

KIM(Knowledge &

InformationManagement)

규칙기반 방식KIM 플랫폼: 온톨로지, 지식베이스, 시맨틱 어노테이션, 인덱싱/검색 서버, 인터페이스를 위한 프론트엔드(frontend)로 구성온톨로지와 지식베이스 저장소는 Sesame 이용시맨틱 어노테이션의 정보 추출: GATE 툴킷을 사용함GATE를 이용하여 문서 내용에 대한 메타데이터 생성: 자연어 엔진이 우수

OntoText연구소

SemTag

규칙기반 방식웹페이지의 대용량 어노테이션 탐색기(seeker)의 시맨틱 컴포넌트3단계 프로세스: 스포팅(단어 토크나이저), 학습, 태깅 단계TBD(Taxonomy-Based Disambiguation)로 의미 중의성 해결

IBM

AktiveMedia

텍스트와 이미지에 대한 반자동 어노테이션 수행온톨로지 기반의 RDF로 문서를 어노테이션하는 인터페이스 제공개념과 관계에 대한 어노테이션

텍스트에서 원하는 단어를 하일라이팅함으 로써 추출할 개념/관계 선택

오픈 소스

[표 3-3] 어노테이션 도구

온톨로지 기반의 어노테이션은 의미 관계를 정의하여 단어의 불명확성을 해결한 메타데이터를 생성하므로 지능화된 검색을 가능하게 하며, 정보가 어떤 매체(텍스트, 이미지, 문서 등)에 담겨 있는가에 상관없이 서로 연계됨으로써 새로운 목적으로 재사용될 수 있다. 더불어 추론을 통한 새로운 지식의 발굴도 가능하다. 대표적인 어노테이션 도구로는 AktiveMedia, KIM(Knowledge & Information Management), SemTag 등이 있다.


1.2.2 시맨틱 웹 데이터 변환기(RDBtoRDF Translator)오늘날 대부분의 웹페이지는 데이터베이스를 백엔드(backend)로 하고 있다. 따라서 현재의 문서 웹(web of document)이 데이터의 웹(web of data), 즉 궁극적으로 시맨틱 웹으로 가기 위해서는 DBMS에 갇혀 있는 대부분의 데이터를 RDF 형식의 시맨틱 웹 데이터로 전환(expose)하는 것이 절대적으로 필요하다. 관계형 데이터베이스 데이터를 RDF로 변환하기 위한 다양한 방면의 연구가 진행되고 있는데, 이를 대개 다음과 같은 카테고리로 나눌 수 있다[9]. 가) 매핑 생성 방식(Mapping Generation)RDB 스키마를 RDF 스키마로 매핑하는 매핑 생성 방식은 자동(automatic), 반자동(semi-automatic), 또는 매뉴얼 방식으로 세분할 수 있다. 자동 생성 방식은 RDB 테이블을 클래스로, 컬럼(column) 또는 어트리뷰트(attribute)를 프로퍼티(property)로 하는 매핑 규칙을 생성하고 이에 따라 RDF로 변환하는 방식이다. 자동 생성 방식은 복잡한 도메인의 의미관계까지는 뽑아내지 못하므로 한계가 있지만, 도메인의 특정적인 커스터마이즈(customize)를 위한 출발점으로 많이 이용된다. 따라서 많은 매핑 도구들이 자동 생성 규칙에 더해서 커스터마이즈된 매핑 규칙을 추가할 수 있도록 하는 반자동 방식을 채택하고 있다. 나) 매핑 표현 방식(Mapping Representation)R2O의 경우는 XML 기반 언어로 매핑을 기술하고, Virtuoso는 자체적으로 정의한 ‘Quad Pattern’으로 표현한다. 널리 쓰이고 있는 매핑 언어로는 D2RQ의 매핑언어가 있다. 매핑의 재사용을 증진하고 접근성을 높이기 위해서는 표준화된 매핑 언어가 필요하며, 이를 위해 W3C의 RDB2RDF Working Group10)에서는 R2RML(RDB2RDF Mapping Language)이라는 매핑 언어 표준화 작업을 진행하고 있다. 다) 매핑 구현 방식(Mapping Implementation)매핑 규칙을 생성한 후 이에 따라 데이터를 실제로 변환하는 방식은 두 가지 접근 방식으로 나눌 수 있다. 첫 번째는 정적 변환방식으로 ETL(static Extract Transform Load)이라고 일반적으로 지칭하는데, 매핑 규칙을 이용하여 RDB 데이10) http://www.w3.org/2001/sw/rdb2rdf/


터를 RDF로 변환, 트리플 레파지토리에 한꺼번에 저장하는 방식이다. ‘RDF Dump’라고도 불리는 이 방식은 최신의 데이터를 유지하는데 어려움이 있으나 데이터 분석이나 데이터를 이용한 프로세싱, 또는 복잡한 추론에 알맞은 방법이다. 두 번째 방법은 동적 변환 방식(Dynamic Mapping Implementation)으로, RDB 데이터를 질의를 통해 동적으로 변환하는 방식이다. 이 방식은 데이터의 최신성을 보장하지만 SPARQL 질의를 온톨로지와 데이터베이스 스키마간의 매핑 규칙에 따라 SQL로 동적 변환하므로 질의 처리 성능이 뒤떨어지는 문제점이 있다. 따라서 데이터가 자주 업데이트되는 데이터 셋의 경우, 그리고 많은 추론이 필요로 하지 않는 경우에 적합하다고 할 수 있다. 라) 질의 구현 방식(Query Implementation)동적 변환 방식은 질의 구현 방식과 밀접한 연관이 있다. RDB 데이터를 실제로 RDF로 보관하고 있지 않기 때문에 동적으로 SPARQL 질의를 SQL로 변환하여 질의하고, 질의된 결과 집합인 테이블 형태의 SQL 데이터 셋을 다시 온톨로지 매핑 규칙을 통해 RDF 그래프로 반환해야 한다. 따라서 SPARQL을 관계형 대수(relational algebra)를 통해 SQL로 변환하는 방법에 대한 연구와 질의 최적화에 대한 연구가 진행되고 있다.


시맨틱 웹 데이터 변환 세부기술 관련 도구 제품

매핑 생성 기술 매핑 규칙 생성기매핑 규칙 편집기

D2RQOntoTrans2.0OntoURI

매핑 표현 기술 매핑 표현 언어 D2RQ 언어

매핑 구현 기술

정적 데이터 변환기 /트리플 레파지토리

OntoTrans2.0 /OntoBase2.0

VirtuosoASIO

- Automapper for Web Services Semantic Bridge for SPARQL Endpoints(SBSE)

동적 데이터 변환기 (시맨틱 웹 데이터 중개기)

D2R ServerOntoURIASIO

- Semantic Bridge for Relational Databases (SBRD)

Triplify질의 구현 기술 SPARQL2SQL 질의 처리기

ASIO - Semantic Query Decomposition (SQD)

[표 3-4] 시맨틱 웹 데이터 변환 기술


구분 프로젝트명/회사명

매핑 생성 방식(자동 생성 또는 수동/반자동) 매핑 표현 언어

Green et. alOrdnanceSurvey, 2008

수동/반자동 생성 - 도메인 온톨로지 매뉴얼 생성 - D2RQ엔진을 이용하여 소스 데이터베이스를 스키마 온톨로지로 자동 생성

D2RQ

VirtuosoOpenLink Software, 2007

수동/자동 모두 지원 - DB의 스키마를 XML 스키마로 기술한 후 이를 OWL 온톨로지에 매핑(수동/자동)

SML (SPARQL 기반 Meta Schema Language)

D2RQBerlin University, 2007

수동/자동 모두 지원 - 이용자가 변환을 원하는 특정 테이블/컬럼을 선택할 수 있음

D2RQ 매핑 언어

RDB2OntoTAO Project, 2008

자동 - 자동으로 데이터베이스 스키마 변환 후 이용자가 수정할 수 있음

제한 규칙(Constraints Rules)

Triplify Auer, 2009

수동 - RDB의 웹서버에 설치된 Wrapper를 통해 SQL질의 결과 셋 을 RDF트리플로 변환

SQL

Asio ToolsBBN Technology, 2009

자동(테이블 to 클래스) - DB스키마 →데이터소스 온톨로지 →매핑 온톨로지 →도메인 소스 온톨로지로 변환

D2RQ 매핑 언어

OntoTrans2.0

TopQuadrant Korea, 2009

수동/반자동 생성 - 도메인 온톨로지 매뉴얼 생성 편집기를 이용하여 매핑 규칙 편집

D2RQ과 유사한 매핑 언어

OntoURI KISTI, 2009

수동/반자동 생성 - 도메인 온톨로지 매뉴얼 생성 - DB/온톨로지 스키마 매핑(수동) - 개체 식별과 연계한 URI 생성

XML 형식의 매핑 언어 적용

[표 3-5] RDB 데이터를 RDF로 변환하는 도구들의 특징(1)


구분 RDF 변환방식 (정적/동적)

질의 처리(SPARQL→RDF 또는SPARQL→SQL→RDB)

특징

Green et. al 동적 변환 동적 변환

- SPARQL→SQL→RDB공간 데이터베이스 분야의 데이터 통합 사례오픈 소스

Virtuoso동적 변환

- 스키마 매핑을 통해 SQL 결과 셋을 Virtual RDF Graph로 변환

SPARQL→RDF - Virtual RDF 그래프에 대한 SPARQL 질의 또는 SPARSQL(SPARQL embedded in SQL)

Virtuoso Server를 통해 구조적/비구조적 데이터 통합 플랫폼 제공상용/오픈 소스

D2RQ정적 변환

- 비RDF 데이터를 변환하여 RDF로 블리싱(D2R Server)

동적 변환

정적 변환 - SPARQL→RDF

동적 변환 - SPARQL→SQL→RDB

다양한 데이터베이스 엔진에 대해 테스트 됨

- Oracle, MySQL, Postgre SQL, ODBC Access

오픈 소스

RDB2Onto 정적 변환 정적 변환 - SPARQL→RDF

도메인 온톨로지의 반자동 생성을 통해 레거시 어플리케이션을 시맨틱화 하기 위한 SSOA 기반환경 기초 오픈 소스

Triplify 동적 변환미리 정의된 SQL문 (Select)을 RDF 데이터로 변환하기 위해 설정 파일에 저장

RDB 데이터의 RDF, JSON, Linked Data화를 위한 웹 어플리케이션의 플러그인오픈 소스

Asio Tools 정적/동적 변환정적 변환

- SPARQL→RDF동적 변환

- SPARQL→SQL→RDB

구조적, 비구조적 데이터의 통합 및 웹 서비스 통합 플랫폼 제공 온톨로지 간 통합에 SWRL을 이용상용 제품

OntoTrans2.0 정적/동적 변환

생성된 인스턴스 온톨로지에 대해 SPARQL 질의

매핑 편집을 위한 이용자 인터페이스 및 자체 트리플 레파지토리 이용상용 제품

OntoURI 동적 변환미리 정의된 SQL문 (Select)을 RDF 데이터로 변환하기 위해 설정 파일에 저장

매핑 편집을 위한 이용자 인터페이스개체 식별을 통한 URI 할당상용 제품

[표 3-6] RDB 데이터를 RDF로 변환하는 도구들의 특징(2)


1.3 추론 엔진RDF 데이터는 리소스 간의 의미 관계를 표현하며, 특히, RDF의 확장인 RDFS, OWL은 더욱 복잡한 의미 관계를 표현하도록 설계되었다. 이를 이용하여 온톨로지를 구성하는 개념들 간의 계층 관계와 제한(constraints)을 이용하여 온톨로지의 내용을 논리적으로 검증하고 온톨로지 인스턴스간의 숨겨진 관계를 파악하여 새로운 암묵적 사실을 밝혀냄으로써 지식을 발굴하는 것이 추론 엔진의 역할이다. 이러한 역할을 담당하기 위한 추론 엔진의 기능은 다음과 같이 나눌 수 있다.

1.3.1 온톨로지 일관성 검사 기능 RDFS, OWL 온톨로지는 기술 논리를 기반으로 지식을 표현하는데, 여기에서 온톨로지 계층구조의 클래스 포함 관계를 추론을 통해 재정비함으로써 논리적인 구조의 일관성을 검사한다. 이를 위해 일관성 검사를 위한 핵심 알고리즘 정의와 효율적인 온톨로지 일관성 검사를 위한 최적화 기법이 연구된다. 또한 탐지된 비일관성을 유발하는 온톨로지 개념을 논리적으로 수정하기 위한 계획을 생성하기 위한 기법에 대한 연구도 필요하다.

1.3.2 온톨로지 계층 정보 추론 기능온톨로지 계층 정보를 효율적으로 추론하기 위한 최적화 기법, 핵심 모듈 및 온톨로지 계층정보를 탐색하기 위한 검색 알고리즘이 포함된다. 또한 의도하지 않은 계층정보가 추론될 경우 이를 탐지하고 논리적으로 수정하기 위한 계획 생성 기법이 있다.

1.3.3 온톨로지 인스턴스 추론 기능대용량 인스턴스들을 효율적으로 추론하기 위한 핵심 알고리즘 및 최적화 기법에 따라 인스턴스의 숨겨진 관계를 추론하며, 시맨틱 웹 데이터에 대한 SPARQL 질의 처리와 함께 연동하여 질의 확장 및 질의 결과에 대한 추론을 통해 새로운 지식을 발굴한다.


온톨로지 추론 엔진 개발기관 기능

FaCT, FaCT++

Ian HorroksSoftware/ U. ofManchester

Tableaux 알고리즘 추론 방식온톨로지의 Consistency 검사두 Concept 간 Subsumption 검사두 Concept 제약으로 온톨로지 계층 재분류Single Concept과 Concept Group의 Satisfiability 검사

PelletMIND Lab/ U. ofMaryland

Tableaux 기반 SHOIQ(D) 온톨로지 추론DL-safety 기반 SWRL 추론Consistency, Concept Satisfiability 검사Datatype 추론 지원Classification, Realization 지원Conjunctive ABox 질의 처리온톨로지 Species Validation 및 온톨로지 Repair 기능

KAON2 Univ. ofKarlsruhe

데이터로그 기반 SHIQ 온톨로지 추론DL-safety 기반 SWRL 추론Karlsruhe 대학과 Ontoprise에서 개발Disjunctive/Datalog 추론 방식원격 추론을 위한 독립형 서버 프로그램질의를 수행할 수 있는 추론 엔진외부 응용에서 네트워크를 통해 이용할 수 있는 DIG 인터페이스DL 수준의 OWL과 SWRL을 프로그래밍 할 수 있는 Java API

RacerPro Racer/ Franz Inc.

Tableaux 알고리즘 추론 방식질의처리 후 ABox에 Assertion을 추가 가능복수의 TBox와 ABox 추론을 지원ABox로부터의 Assertion 취소 기능을 지원

1.3.4 도메인 온톨로지 휴리스틱(Heuristic) 추론 기능RDFS, OWL은 기술 논리(Description Logic) 기반이므로 규칙을 표현하는데 한계가 있다. 따라서 이를 보완하기 위한 규칙 기반 추론 기능이 필요한데 대개 SWRL이나 Jena Rule, Jess등을 활용한다.


보쌈 ETRI/ Korea

온톨로지와 규칙을 결합하여 활용 가능질의 처리를 위해 Buchingae 질의 지원, RDFS, OWL, RuleMI, SWRL 등 주요 웹 온톨로지 언어 및 웹 규칙 언어를 지원확장된 Horn Logic, 규칙 우선순위 결정, NAF 및 Classical Negation을 지원

OntoReasoner KISTI/ Korea

Rete 알고리즘을 활용한 규칙 기반 추론 방식전방 추론과 후방추론 병행RDFS++수준의 추론 지원추론 규칙 표현을 위해 OntoRL 사용사용자 정의 추론 규칙 지원

[표 3-7] 대표적인 추론 엔진


2 시맨틱 웹 어플리케이션

앞에서 살펴본 바와 같이 시맨틱 웹 데이터를 생성, 저장, 추론, 질의하는 일련의 기반 기술을 통해 다양한 시맨틱 웹 어플리케이션 개발이 가능하다. 다음에서 대표적인 몇 가지 분야를 살펴보도록 한다.

2.1 시맨틱 웹 데이터 연계(Linked Data), 매쉬업(Mashup)RDF라는 공통의 데이터 포맷이 확장과 병합이 용이한 그래프 기반 데이터 모델이라는 점에서 RDF로 변환된 데이터에 대한 연계와 매쉬업은 시맨틱 웹 환경에서 가장 광범위하고 일상적으로 발생하게 되는 어플리케이션이다. 연계와 매쉬업(또는 융합)을 통해 기존의 데이터를 새로운 목적으로 재사용하고 이를 이용하여 새로운 시맨틱 웹 데이터를 생성하게 됨으로써 시맨틱 웹의 확장과 생태계 조성에 중요한 역할을 하게 된다.

2.1.1 데이터 연계(Linked Data)최근 들어 가장 활발하게 확산되고 있는 시맨틱 웹 응용 분야가 링크드 데이터(linked data)를 이용한 시맨틱 웹 데이터 연계이다. 링크드 데이터는 역참조할 수 있는(dereferenceable) URI를 통해 데이터를 공개, 연결, 공유하는 방법이다. 데이터를 웹에 공개, 공유하기 위해 사물(thing)에 대한 이름으로 URI를 부여하고, URI를 이용해 누구나 웹을 통한 데이터 접근이 가능하도록 하여, URI를 서로 링크(예. owl:sameAs를 이용하여 두 노드를 연결)함으로써 데이터의 매쉬업과 재사용을 가능하게 한다.

[그림 3-3] 비틀즈에 대한 DBPedia의 URI를 통한 링크드 데이터 사례


W3C 산하 SWEO Interest Group이 주도하는 Linking Open Data Community Project는 이러한 링크드 데이터의 비전을 실현하기 위한 기술 및 도구를 개발하고, 다양한 공개 데이터 셋을 웹에 RDF로 퍼블리싱(publishing)함으로써 RDF 링크를 이용한 데이터 웹을 확장할 목적으로 시작되었다. 프로젝트 초기인 2007년 5월 당시 5억 개의 RDF 트리플, 12만 개의 링크로 시작된 링크드 데이터 셋(Linking Open Data Cloud)은 2009년 11월을 기준으로 131억 개의 트리플과 1억 4천 2백만 개의 링크로 급속히 증가했다.11)

[그림 3-4] 링크드 데이터 셋(Linking Open Data Cloud) - 2009년 7월 기준12)

공개 라이선스의 링크드 데이터 셋은 데이터를 RDF 형식으로 변환하고 이를 서로

11) http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData

12) http://www.bbc.co.uk/blogs/radiolabs/s5/linked-data/ui/images/lod.png


링크함으로써 연계, 융합하여 새로운 서비스를 생산하는 기반으로 점차 발전되어 가고 있다. 데이터를 서로 연계할 수 있도록 하기 위해서 다음과 같이 링크드 데이터 퍼블리싱 원칙(Linked Data Principles)에 따라 데이터를 퍼블리싱 한다.

링크드 데이터 퍼블리싱 단계 세부 사항 관련 도구

URI와 RDF 어휘(Vocabular

y) 선정

303 URI, 또는 Hash URI로 리소스에 대한 URI 부여 데이터에 대한 범용식별자인 URI를 부여하기 위한 URI 구조와 네이밍데이터의 구조화를 위한 RDF 데이터 모델 선정

RDF Vocabulary - DoublinCore, FOAF, SKOS, SOIC 등

링크 생성

하나의 데이터 셋에서 다른 데이터 셋으로 연계하기 위한 RDF 형식의 링크 설정ISBN, ISSN, EAN, EPC 코드 등 범용적으로 사용되는 분류번호체계가 연계를 생성하는데 유용하게 이용됨

RDF 링크 생성 프레임워크 - Silk Framework - LinQL Framework - OntoBase2.0 LOD Builder

데이터 셋의 RDF 변환

기존의 레거시 데이터를 RDF로 변환하여 트리플 레파지토리에 저장하거나 동적 변환 방식을 이용하여 링크드 데이터의 뷰(Linked Data View) 생성

D2R ServerVirtuoso Universal ServerPubbyTriplify

데이터 셋의 메타데이터 및 시맨틱

사이트 맵 생성

데이터 셋을 공유하기 위해 필요한 메타데이터 작성저작자, 생성 방식, 생성일 등의 속성 및 데이터 셋에 관한 기술적인 메타데이터 및 다른 데이터 셋과의 링크 관계에 대한 정보 포함. 크롤러나 에이전트가 검색할 수 있도록 시맨틱 사이트 맵(xml 파일)작성

시맨틱 웹 데이터 편집기/브라우저 - Tabulator - Marbles - OpenLink RDF Browser 등

[표 3-8] 링크드 데이터 퍼블리싱 단계 및 지원 도구


이렇게 링크드 데이터 퍼블리싱 원칙으로 공개된 RDF 데이터를 이용하여 데이터를 연계한 혁신적인 어플리케이션 구축 사례로 다음과 같은 DBPedia Mobile[10]을 들 수 있다.

[그림 3-5] iPhone 3G로 구현된 DBPedia Mobile

DBPedia Mobile은 사용자의 위치를 기반으로 DBPedia를 중심으로 한 Linked Data를 이용하여 다양한 데이터 셋으로의 탐색 확장, 그리고 이용자가 현재 위치에 대한 자신의 정보를 퍼블리싱 할 수 있도록 해주는 위치 인식 클라이언트로서 사용 예는 다음과 같다.

모바일 이용자의 현재 위치에 관련된 인물을 탐색거기서 태어났다거나, 사망했다거나, 또는 거기서 일을 했다거나 하는 등의 데이터 셋 안에 있는 관련 정보그 인물이 작가라면 RDF Book Mashup이나 Project Gutenberg 데이터 소스로 탐색 확장이용자가 로컬 밴드에 관심이 있다면 MusicBrainz로 가서 그 앨범에 대해 알아볼 수 있음사진과 리뷰를 통해 현재 위치를 출판할 수 있음


2.1.2 시맨틱 웹 매쉬업앞에서 살펴본 바와 같이 RDF 데이터는 자유로운 연계와 이를 이용한 재사용이 가능하다. 데이터의 연계를 위해서는 먼저 RDF 형식의 데이터가 퍼블리싱 되고 공개되어야 하며, 이를 이용하여 다양한 매쉬업 어플리케이션을 구현하기 위해서는 이러한 시맨틱 웹 데이터의 자동적 처리를 고려한 오픈 API와 매쉬업 도구들이 필요하다.웹 2.0의 출현으로 인해 등장한 매쉬업은 오픈 API, RSS/ATOM Feed를 이용한 콘텐츠 신디케이션(syndication)으로 특징지을 수 있다. 또한 AJAX, JSON, Flex와 같은 프로그래밍 도구를 통해 쉽고 빠르게, 풍부한 이용자 인터페이스를 제공하는 매쉬업 어플리케이션의 생성과 공유가 이루어지게 되었다. 그러나 이러한 웹 2.0 매쉬업은 서로 다른 인터페이스를 제공하고 데이터의 표현이 제각각 다른 문제 때문에 데이터 소스가 추가될 때마다 수동으로 프로그램 코드를 추가해야 하는 문제가 있다. 또 데이터의 표현이 기계가 이해할 수 있는 포맷이 아니므로 인간이 일일이 작업해야 하고 매쉬업의 수준도 인터페이스 수준에 머무르며 데이터의 재사용이 어려운 한계가 있다. RDF 데이터를 이용한 시맨틱 웹 매쉬업은 기계가 이해할 수 있는 공통 표준 포맷(RDF)으로 데이터를 표현하고 URI를 이용하여 데이터를 식별(identify)하므로 동적으로 데이터를 재조합하여 이용자의 새로운 목적에 맞는 매쉬업 어플리케이션을 쉽게 만들 수 있다. 또한 RDF/OWL을 이용하여 데이터의 의미 구조를 표현하므로 데이터 소스가 추가/변경 될 때마다 추가적인 프로그래밍 작업을 할 필요가 없으며, 온톨로지를 공유함으로써 매쉬업을 통해 생성된 데이터도 상호운용성이 보장되어 재사용이 용이하다.시맨틱 웹 매쉬업 도구인 탑쿼드란트社의 SparqlMotion은 URI를 이용하여 웹에 분산되어 있는 RDF 데이터에 접근하고, 이를 통해 데이터들을 조합하여 원하는 목적으로 가공하기 위한 비주얼 플로우 에디터(visual flow editor)로 RDF/OWL 표준 질의 언어인 SPARQL을 이용하여 데이터를 필터링하고 OWL로 모델링된 직관적인 정보의 플로우 다이어그램(flow diagram)을 작성할 수 있도록 하여 이용자가 쉽게 매쉬업을 작성할 수 있도록 해준다. 뿐만 아니라 XML, RSS Feed, TEXT 문서 등의 다양한 형태의 데이터에 대해 임포트(import), 변환, 필터링, 검색 등의 기능을 지원하고 작성된 데이터 플로우 다이어그램(data flow diagram)은 RDF로 기


술된 스크립트로 저장되며 REST 웹 서비스로 제공될 수 있다. 이와 유사한 도구로 DERI의 Pipes라는 SPARQL을 이용한 데이터 플로우 에디터가 있다.

[그림 3-6] TopQuadrant사의 SparqlMotion 예시

2.2 시맨틱 웹 서비스어플리케이션 개발의 모든 과정을 재사용을 통해 자동화하기 위해 리소스를 재사용하는 웹 서비스 기술과 온톨로지를 기반으로 서비스를 기술(description)하여 데이터를 기계가 이해할 수 있도록 하는 시맨틱 웹 기술을 결합한 것이 시맨틱 웹 서비스(semantic web service)이다. 시맨틱 웹 서비스에는 두 가지 방식이 존재하는데 기존의 WSDL을 이용한 웹 서비스 방식에 시맨틱 웹 기술을 확장한 SOA(Service-Oriented Architecture) 기반의 시맨틱 웹 서비스와, REST 기반의 경량 웹 서비스(Light-Weight Web Service, Semantically Enabled Web Services라고도 함)가 있다.


[그림 3-7] 웹 서비스의 발전 방향시맨틱 웹 서비스에는 다음과 같은 기술들이 포함된다.

서비스 디스크립션(service description) 웹 서비스의 기능과 행위를 시맨틱 웹적으로 기술하는 언어를 이용하

여 웹 서비스를 해설(description)하는 기술 서비스의 기능에 대한 디스크립션뿐만 아니라 행위를 해설하는 것에 관

한 기술로 코리어그라피(choreography)와 오케스트레이션(orchestration)에서도 사용

서비스 해설을 위한 형식언어, 서비스에 대한 시맨틱 웹 어노테이션 기술 서비스 발견(discovery)

서비스 온톨로지(WSMO나 OWL-S)와 도메인 온톨로지를 정의하고 두 온톨로지를 조합하여 발견 프로세스에 사용하기 위한 기술

특정한 사례에 따라 적합한 추론 기술을 개발하여 발견 프로세스에 통합하는 기술서비스 조합(composition)

실행 가능한 워크플로우(또는 비즈니스 프로세스)를 구성하는 여러 서비스들을 이용자의 목적에 적합한 서비스로 만들어 내는 기술

다양한 수준으로 추상화된 서비스 해설을 이용하여 서비스를 조합하는 기술서비스 중개(mediation)


서비스 제공자와 요청자 간의 서비스 중개 시 의미적 불일치를 해결함으로써 투명하고 유연한 소프트웨어 컴포넌트를 개발하기 위한 서비스와 데이터 중개에 대한 방법을 제시하는 기술 코리어그라피(Choreography)

서비스 요청자와 제공자 간의 웹 서비스 이용을 위한 상호작용 인터페이스 기술

서비스 행위를 쉽게 표현하기 위한 언어 개발에 관한 기술 코리어그라피를 위한 추론 기술 코리어그라피 언어로 태스크를 정의하고 추론을 이용하여 자동화되고

유연성 있는 동적 서비스를 통합해내기 위한 기술

시맨틱 웹 서비스의 대표적인 구현사례로 WSMO(Web Service Modeling Ontology)를 들 수 있다. WSMO는 ESSI(European Semantic Systems Initiative)에서 선도하고 있는 표준안으로 시맨틱 웹 서비스를 위한 개념 모델과 온톨로지 언어 및 기술 프레임워크로 구성되어 있으며, 2004년에 시작된 유럽 중심의 국제적 컨소시엄(20개 기관으로 구성)에서 연구를 진행하고 있다. WSMO는 시맨틱 웹 서비스(SWS)를 위한 개념모델(SWS 주요 요소들의 온톨로지)로서의 WSMO, 시맨틱 웹 서비스(SWS)를 위한 실행환경인 WSMX, 및 WSMO를 위한 형식언어, 시맨틱 웹을 위한 온톨로지 규칙 언어인 WSML로 구성되어 있다. 개념모델인 WSMO(Web Service Modeling Ontology)는 웹 서비스의 목적(Goals), 웹 서비스의 기능과 인터페이스를 기술하기 위한 웹 서비스(Web Service), 데이터, 서비스 간의 이형성을 중재하는 중개 서비스를 통해 여러 컴포넌트들을 매개하여 서비스를 만들어내는 커넥터(connector)로서의 중개자(mediator), 그리고, 웹 서비스 컴포넌트 들이 사용하는 용어 집합인 온톨로지를 포함한다. WSML(Web Service Modeling Language)은 이를 표현하기 위한 형식 언어로 RDF 기반의 WSMO 온톨로지를 기술하는데 사용되며, 이를 통해 웹 서비스에 대한 의미적 호환과 추론이 가능하다. WSMX(Web Service Execution Environment)는 서비스 요청/제공의 런타임 바인딩(runtime binding)을 위한 소프트웨어 프레임워크로 WSMO에 의해 제공되는 개념 모델에 기반을 두어 다음의 기능을 수행한다.


발견/매칭 서비스목적에 적합한 서비스 선택데이터 중개 제공서비스 구동

[그림 3-8] WSMX 아키텍처와 컴포넌트 [11]13)

최근 들어 급속히 발전하고 있는 분야가 REST(Representational State Transfer) 기반의 시맨틱 웹 서비스이다. SOAP 기반 웹 서비스와 달리 Web 2.0 환경의 서비스 전달 방식으로 데이터 구조와 그 상태만을 전달하며 W3C의 표준과 같은 개념이 아닌 웹(특히, Web 2.0)에서 대중화된 설계 기법으로 웹에서 서비스의 구현이 쉽다는 장점이 있다. REST 기반 웹 서비스의 장점을 다음과 같이 정리해 볼 수 있다.

단순성 URL 기반의 형식으로 리소스를 기술시맨틱 웹과의 통합

시맨틱 웹은 리소스 식별자를 URI로 사용하므로, REST의 URL 기반 식별자를 네이밍 스킴에 통합 가능함

State Transfer Operation

어떤 데이터 저장소나 검색 시스템에도 사용 가능함Web 2.0에서는 이 CRUD(Create, Read, Update, Delete) 오퍼레이션을 HTTP 프로토콜에 대응함

[표 3-9] REST 기반 웹 서비스의 장점

13) http://wiki.wsmx.org/images/2/28/WSMX_Architecture_with_names.png


SOA 기반 웹 서비스 REST 기반 웹 서비스

서비스 디스크립션 WSDL

WADL(Sun 사의 REST 서비스 디스크립션을 위한 Web Application Description Language)

오퍼레이션 디스크립션

SAWSDL - 오퍼레이션에 대한 시맨틱 어노테이션 None

커뮤니케이션 프로토콜 SOAP REST

서비스 접근UDDI에서 리소스 정보를 얻어서 Remote Object 에 직접 접근

URL 형식의 리소스 디스크립션을 통해 접근

평가 구현이 복잡하고 어려움

구현은 쉬우나 시맨틱 웹적인 디스크립션 및 서비스 조합

중개를 위한 기술과 표준이 없음

[표 3-10] SOA 기반 웹 서비스와 REST 기반 웹 서비스 비교


2.3 시맨틱 검색시맨틱 검색은 사용자의 의도와 웹 콘텐츠를 보다 깊은 개념적인 레벨에서 이해하여 단순 키워드 매칭의 한계를 넘어선 차세대 지능형 검색을 지향한다. 기존의 키워드 기반 검색은 검색어인 키워드의 의미적 모호성이 해결되지 않고 용어 간 관계가 표현되지 않는, 다시 말해 문맥을 고려(contextual)하지 않는 통계적 기법을 이용한다. 온톨로지 기반의 시맨틱 검색은 키워드를 온톨로지의 인스턴스에 매핑(색인)하므로 키워드 기반 시스템이 가진 의미의 모호성을 극복함에 따라 관계에 의한 연관 있는 데이터로의 내비게이션이 가능하고 용어 간 의미 관계를 해석, 자연어 검색과 같이 문맥적 의미에 따른 검색이 가능하다. 또한 사용자 중심의 접근 및 검색을 제공하고 온톨로지를 활용한 검색 결과의 랭킹, 클러스터링 및 개인화 같은 검색의 정확도를 높이는 기술도 연구되고 있다. 시맨틱 검색 방식은 키워드 기반 검색 방식과 시맨틱 검색 방식을 결합한 하이브리드 방식, 검색 폼 기반의 방식, 뷰 기반 방식, 자연어 기반 방식 등으로 나눌 수 있다.

[그림 3-9] 시맨틱 검색 시스템 구성도

키워드 검색 및 하이브리드 방식(Keyword-based search, or Hybrid search)

키워드 기반 검색은 키워드를 검색어로 사용하며, 키워드를 온톨로지의 개념에 매칭함으로써 검색을 수행


종류 특징

Naver 시맨틱영화 검색

(Naver / 국내)

네이버 랩(Naver Lab)을 통해 실험적으로 서비스 되고 있는 시맨틱 검색 서비스데이터베이스에 저장되어 있는 구조화된 데이터에 대한 검색영화 및 영화인 DB 콘텐츠 데이터만을 대상으로 함정답형 검색, 시맨틱 추천 키워드, 확장 검색 그래프 기능 구현실버라이트를 이용하여 개발한 비주얼한 그래프 브라우징 제공

하이브리드 검색은 키워드 기반 검색 방식에 시맨틱 검색 방식을 결합하여 키워드의 문맥(context)을 고려한 특정한 타입이나 인스턴스로 어노테이션되어 있는 문서의 일부분 안에서 키워드 매칭을 실행하는 방식

자연어 기반 검색(Natural Language-based search) 자연어 처리(NLP)에 기반을 둔 검색 방식으로 문서의 모든 문장을

언어적으로 그 의미를 해석하고 질의 또한 자연어 형식으로 하는 방식

뷰 기반 검색(View-based search) 그래프 기반 검색 방식이라고도 하며 질의 방식으로 그래프를 만들고

이에 매칭되는 트리플을 검색하는 방식. 온톨로지에 의한 검색 방식이 명확하고 직관적이지만 질의 표현이 제한적임

폼 기반 검색(Form-based search) 온톨로지 구조를 검색 폼으로 만들어서 검색 조건을 입력하여 검색하

는 방식으로 직관적이고 명확, 단순한 장점이 있으나 유연성이 떨어지는 방식

이외에도 온톨로지를 이용한 검색어 자동완성 기술이나 패싯(facet) 검색, 온톨로지를 이용한 검색 결과의 내비게이션, 또는 브라우징 인터페이스 기술 등에 많은 연구가 진행되고 있다.


Nate 시맨틱 검색

(Nate / 국내)

검색어 포함 매칭 방식과 시맨틱 검색을 유기적으로 결합한 시맨틱 통합 검색 서비스검색어를 통해 검색된 문서에 포함된 의미 정보 분석사용자의 검색 의도에 따른 시맨틱 주제 분류질의어에 대한 최적의 검색 결과를 제시하는 예상 답변 기능이슈 타임라인 기능을 이용한 검색어 흐름 파악자연어 검색 기술을 구문이나 문장 분석에 도입블로그, 게시판과 같은 구조화되지 않은 DB를 대상으로 주제 분류와 예상 답변 제시

OntoFrame S3(KISTI / 국내)

시맨틱 웹 기반 정보유통 플랫폼 기반의 학술정보 서비스지식 정보의 의미를 이해하고 그들간의 논리적 추론까지 할 수 있는 국내 최초의 시맨틱 웹 기술 기반 프레임웍해외 학술 논문 기반의 연구주제, 연구자에 대한 심층 서비스 제공온톨로지와 추론을 이용하여 문헌으로부터 다양한 분석 정보 추출연구 주제 동향, 주제별 전문가, 주제별 연구 기관, 연구자 네트워크, 유사 연구자 등의 정보 제공사용자가 입력한 검색어가 주제인지 연구자인지 구분하여 자동으로 검색어에 적합한 화면 구성

STARS(KISTI / 국내)

시맨틱 뉴스 검색 서비스대용량 처리(시맨틱 트리플 인덱싱)온톨로지 기반 그래프 탐색 및 추론 수행시맨틱 랭킹 알고리즘 구현 (Top News)뉴스 및 블로그 의미기반 검색시맨틱 연관 정보 검색 (곶감 뉴스)비주얼 검색 (Touch Graph)

Powerset자연어 처리(NLP) 기반 시맨틱 엔진쉬운 영어 검색의 구조와 뉘앙스를 사용웹 페이지의 모든 문장을 읽고 이해함Wikipedia와 Freebase를 스캔(scan)함리스트 형식의 결과 제공

Configuration(Semantic Map)

Cognition의 Semantic Map - 중요 언어요소 (key linguistic element)의 조합으로 높은 완성도와 이해력을 가짐


자연어 처리(NLP) 기반 시맨틱 검색 엔진의학계에서 쓰이는 대량의 기술적인 유의어를 구분하므로 www.SemanticMEDLINE.com에서 복잡한 건강 정보 및 생명과학 자료들을 검색함

Hakia

자연어 처리(NLP) 기반 시맨틱 검색 엔진의약품, 법률, 재무, 과학, 문학 같은 집약적 주제 검색이 뛰어남문장기반 인덱싱(키워드 인덱싱)형태소/구문/의미 분석랭킹 알고리즘(SemanticRank)검색결과 의미적 클러스터링(고유명사, 인물위주)

Swoogle메타데이터에 접근 권한이 있는 에이전트를 통한 시맨틱 검색 서비스 제공키워드 인덱싱(연관관계 추적)랭킹 알고리즘(메타데이터의 랭킹 메커니즘)시맨틱 기반의 웹 크롤러인 SwoogleBot 사용

Askmenow 자연어 처리(NLP) 기반 시맨틱 검색 엔진휴대폰용 검색 서비스 제공

Falcon-S시맨틱 이미지 검색 엔진(지원 도메인: 축구)질의한 객체(선수, 팀 등)를 식별하여 시맨틱이 접목된 객체의 리스트를 반환함연관된 이미지 검색을 위해 그래프 기반 UI 제공

[표 3-11] 국내외 시맨틱 검색 시스템의 종류 및 특징


2.4 상황인지(Context Awareness)시맨틱 웹은 데이터의 표현방식을 기계가 이해할 수 있도록 데이터의 의미를 태깅(tagging)함으로써 인간과 인간을 연결(connect)하는 웹에서 지식과 지식을 연결하는 웹으로 나아갈 수 있는 기반을 제공하였다. 이를 통해 시맨틱 웹은 새로운 지식을 창출하고, 나아가 인터넷이나 유무선 네트워크로 상호 연결된 많은 컴퓨터, 컴퓨팅 디바이스, 혹은 센서가 생활환경 전반에 스며들어 사용자가 인식하지 않아도 사용자의 상황에 따른 지능화된 서비스를 제공하는 유비쿼터스 웹을 지향한다. 시맨틱 웹 기반의 상황인지는 네트워크화 된 기계와 기계 사이의 커뮤니케이션에서 기계가 데이터를 구조적(structural)으로 혹은 의미적(semantical)으로 이해할 수 있게 함으로써 기계가 데이터 및 서비스를 상황에 맞게 해석하고, 상황과 목적에 따라(context-awareness) 어떻게 사용할 것인지 결정할 수 있도록 하는 것이다.

[그림 3-10] 시맨틱 웹 기반 상황인지를 이용한 지능형 홈 상황인지 처리에 앞서 먼저 상황을 처리하기 위해 필요한 도메인 기반의 온톨로지와 어떤 상황에도 적용 가능한 메타화된 상위 온톨로지(upper ontology)를 구축해야 한다. 이 온톨로지를 상황 모델(context model)이라 하며 입력되는 상황 정보들을 해석하여 그에 알맞은 상황을 도출해 내는 역할을 하게 된다.


상황인지 프로세스는 다음과 같이 대략 세 단계로 나눌 수 있다.

상황정보 수집단계 센서와 같은 고정형 디바이스 또는 PC, 모바일 폰과 같은 모바일 디

바이스로 구성되는 입력 장치로부터 입력되는 기초 데이터들을 전처리하여, 위치, 시간, 이벤트, 조도, 음향, 기온 등과 같은 기초 상황 정보들을 추출해 내고 이를 온톨로지 인스턴스화 하여 트리플 레파지토리에 저장하는 과정

상황인지 해석 단계 입력된 상황 정보를 온톨로지 모델을 통해 해석하고 추론함으로써 좀

더 높은 수준의 상황(context)과 의도(intention)를 도출해내는 과정상황 서비스 도출 단계

도출된 상황(context)과 의도(intention)에 적합한 서비스를 온톨로지 모델에 정의된 서비스 규칙에 따라 도출해 내고 추론된 정보를 바탕으로 이용자가 필요로 하는 최적의 서비스를 찾아 서비스에 응용하는 과정

다양한 센서 데이터들이 실시간으로 입력되는 환경에서 대량의 상황 정보를 처리하여 이용자의 요구에 빠르게 대처하는 것이 상황인지에서는 중요한 이슈이며 이에 따라 온톨로지 기반의 상황인지 처리에서도 대용량 트리플 레파지토리와 이와 연계한 고성능의 분산 추론 기술이 연구되고 있다.


종류 구조 상황정보수집

상황해석 상황모델(Context Model)

보안 및 프라이버시저-레벨 고-레벨

GAIA 확장된 미들웨어

ContextProvider

상황 서비스 모듈

FirstOrderLogic

Inference

DAML + OIL Yes

SOCAM중앙

집중형 서버

ContextProvider

ContextProvider

ContextProvider

(OWL DL + Rule)

Ontology(OWL) -

CoBrA에이전트

기반 분산

시스템

상황수집 모듈

상황수집모듈

Reasoning Engine

(OWL DL + Rule)

Ontology(OWL) Yes

ContextManaging Framework

중앙 집중형 서버

리소스 서버

상황인식

서비스RDFS

ReasoningOntology(RDF) -

CAMUS중앙

집중형 서버

ServiceAgent

ContextInterceptor

OWL DL + Rule

Universal Data

Model(온톨로지

지원)

-

u-Genie중앙

집중형 서버

상황정보 수집 모듈 상황인식

상황인지 및 서비스

매칭(OWL DL + Rule

Reasoning)

Ontology(OWL DL) -

[표 3-12] 온톨로지 기반 상황인지 프레임워크

55

제 4 부 주요 제품 비교

1 제품 특징

1.1 AllegroGraphAllegroGraph14)는 Native 방식 중 가장 널리 알려져 있는, 10억 개 이상의 트리플을 처리하는 대용량 고성능 트리플 레파지토리이다. 또한 시맨틱 웹 응용을 구축에 필요한 데이터베이스뿐만 아니라 응용 프레임워크도 포함하고 있다. Sesame나 Jena API를 통해 자체적으로 제공하는 서버에 직접 접속하거나, Sesame REST(Representational State Transfer) 서버 또는 SPARQL(SPARQL Protocol and RDF Query Language) 프로토콜 서버에 웹을 통해 접근할 수 있다. Sesame 2.1 HTTP 프로토콜을 사용하여 AllegroGraph에 RDF 트리플을 추가, 삭제하거나 SPARQL, 또는 Prolog 언어로 질의할 수도 있다. AllegroGraph는 SPARQL 질의 API를 통해 RDF 트리플에 대한 질의 처리를 수행하며, 추론을 지원하기 위해 RDFS++15) 추론 엔진을 내장하고 있다. 보다 복잡한 추론이 필요한 경우에는 Racer와의 연계 기능을 이용할 수 있으며, 온톨로지 모델링 도구인 TopBraid Composer를 연계할 수 있다. Java, Python, Lisp, C# 등의 언어로 구현된 클라이언트 API를 제공할 뿐만 아니라 Python, Ruby, JavaScript와 같은 HTTP 클라이언트 응용을 만들 수 있는 다양한 언어들과의 인터페이스를 제공한다. 이외에도 AllegroGraph 3.0은 데이터 연계(Federation), 소셜 네트워크 분석(SNA; Social Network Analysis), 공간 정보 저장 및 시간 추론(Temporal Reasoning)과 같은 부가적인 기능들을 제공하고 있다.

14) http://www.franz.com/agraph/allegrograph/

15) OWL의 하위 집합으로 RDFS보다 상위의 표현력을 제공하는 어휘들로 구성되어 있는 경우를 통칭함

제4부 주요 제품 비교56

1.2 Oracle가장 널리 사용되는 DBMS 중 하나인 Oracle은 10g 이후 버전부터 Oracle Spatial의 일부분으로서 시맨틱 웹 데이터와 온톨로지에 대한 저장, 질의, 추론 기능을 지원하고 있다. 시맨틱 웹 기술을 지원하기 위한 별도의 관리자 계정(MDSYS)을 두고 그 하부에서 시맨틱 기술에 특화된 다양한 프로시저들을 제공한다. RDF/RDFS/OWL/SKOS(Simple Knowledge Organization System) 표준들을 지원하며, 사용자 정의 규칙(Rules), Rule Bases, Rule Indexes 및 OWL Subset, RDFS에 의한 추론이 가능하다. 10억 개 이상의 RDF 트리플을 처리할 수 있는 성능을 가지고 있으며, 대용량 데이터 적재를 위한 Bulk Load 기능이 지원된다. 시맨틱 웹 데이터에 대한 효과적인 질의 처리를 위하여 SPARQL 질의를 지원하며, Joseki를 활용하여 웹 서버를 통해서도 SPARQL 질의를 처리할 수 있다. Oracle은 Non-Native 방식의 트리플 레파지토리이므로 SPARQL 질의를 Oracle 백엔드 데이터베이스에서 처리 가능한 SQL(Structured Query Language)로 변환한다. Jena API를 지원하는 Jena Adaptor를 이용하여 Java 인터페이스를 제공한다.

[그림 4-1] Oracle의 시맨틱 웹 데이터 처리16)

1.3 OWLIMOWLIM17)은 Java로 개발된 트리플 레파지토리로 저장소(Storage)와 추론 계층16) http://www.oracle.com/technology/tech/semantic_technologies/pdf/semantic11g_dataint_twp.pdf

17) http://www.ontotext.com/owlim/

제4부 주요 제품 비교 57

(SAIL; Storage And Inference Layer)으로 구성된다. 다시 말해서, 저장 및 질의 기능을 제공하는 Sesame 프레임워크와 결합된 형태라고 할 수 있다.Sesame는 Aduna社에 의해 개발된 오픈 소스로서, RDFS 질의 처리기 및 저장소로서 다양한 질의 언어(예. SPARQL, SeRQL 등)들과 RDF 형식(예. RDF/XML, N3, Turtle 등)들을 지원한다. OWLIM은 Sesame 프레임워크를 질의 처리와 저장을 위한 API로서 활용하기 때문에 Sesame의 특징을 그대로 이어받는다. OWLIM 솔루션은 SwiftOWLIM과 BigOWLIM 두 가지 종류로 나누어지는데, 비상용 제품인 SwiftOWLIM은 In-Memory 방식의 저장소를 사용하는 반면에, 상용 제품인 BigOWLIM은 Native 방식의 저장소를 사용한다. SwiftOWLIM은 In-Memory 방식이라 빠른 추론과 질의 처리 성능을 보여주고 있는데, In-Memory 방식 트리플 레파지토리들 중에서 가장 빠르다고 알려져 있다. SwiftOWLIM이 메모리 기반으로 최대 수백만 개 수준의 트리플을 처리할 수 있지만, Native 방식의 BigOWLIM은 10억 개 이상의 트리플을 처리할 수 있다. SwiftOWLIM은 오픈 소스 라이브러리로 제공되고, BigOWLIM은 상용 제품이긴 하지만 연구나 성능 평가를 위한 목적에 한해 무상으로 제공되기도 한다. RDFS와 OWL Lite의 대부분을 지원하며, TRREE 엔진을 이용한 전방추론(Forward-chaining) 기능을 제공한다. 특히 RDFS, OWL-Tiny, OWL-Horst, OWL-Max 등 네 개의 미리 정의된 규칙 셋을 선택함으로써 다양한 수준의 추론을 가능하게 한다.

[그림 4-2] OWLIM과 Sesame 프레임워크 간 관계도18)

18) http://www.ontotext.com/owlim/OWLIMSysDoc.pdf


1.4 SDBSDB는 다양한 DBMS를 백엔드로 갖는 Non-Native 레파지토리로서 Jena의 다양한 제품 군 중 하나이다. Jena는 HP Lab에서 개발한 시맨틱 웹 응용 구축을 위한 Java 프레임워크로 RDFS, OWL, SPARQL 지원을 위한 프로그램 환경을 제공할 뿐만 아니라 규칙 기반 추론 엔진을 포함하고 있다. Jena를 구성하는 프로그래밍 지원 API와 SPARQL 질의 엔진 외에도 트리플 레파지토리를 가지고 있는데, In-Memory 방식뿐만 아니라 Non-Native, Native 방식의 트리플 레파지토리들을 모두 지원한다. Non-Native 방식의 트리플 레파지토리가 SDB로, SPARQL 서버인 Joseki와 연동하여 SPARQL 질의를 처리한다. 비교적 최근에 개발된 Native 방식의 트리플 레파지토리가 TDB이며, SDB와 마찬가지로 Jena API 및 SPARQL 질의 엔진이 지원된다. SDB는 독자적인 응용, J2EE, 그리고 다른 응용 프레임워크에 사용되는 DBMS를 제공하는 동시에 로드 밸런싱, 보안, 클러스터링, 백업 및 관리 기능을 제공한다. SDB가 지원하는 DBMS로는 Microsoft SQL Server 2005, Oracle 10gR2, IBM DB2, PostgreSQL v8, MySQL 5.0, HSQLDB 1.8, H2 1.0.73, Apache Derby 10.2 등이 있다.

Microsoft SQL Server 2005(SQL Server Express 포함)Oracle 10gR2(Oracle Express 포함)IBM DB2(DB2 Express 포함)PostgreSQL v8MySQL 5.0HSQLDB 1.8H2 1.0.73Apache Derby 10.2

1.5 VirtuosoVirtuoso는 다양한 운영체제(Windows 95/98/NT/2000, Linux(Intel, Alpha, Mips, PPC), Solaris, AIX, HP-UX, Unixware, IRIX, Digital UNIX, DYNIX/PTX, FreeBSD, SCO, MacOS X 등)들과 프로그래밍 언어(Java, .Net, C, C++ 등)들을


지원하는 서버 기반 플랫폼으로, XML, RDF, Free-text 형태의 데이터부터 DBMS, Object-oriented DBMS 데이터까지 다양한 데이터 통합과 접근이 가능하도록 설계된 트리플 레파지토리이다.상용과 비상용 모두 제공되는 Native 방식의 트리플 레파지토리로서, 저장된 RDF 트리플에 질의하기 위한 SPARQL을 지원하며, OWL-DL 수준의 추론이 가능하다. HTTP, SOAP(Simple Object Access Protocol), JDBC(Java Database Connectivity), ODBC Open DataBase Connectivity), OLE DB(Object Linking and Embedding, Database) 등을 이용한 원격 접속을 지원하고, Jena Provider와 Sesame Provider를 통해 Jena와 Sesame API를 지원한다.

[그림 4-3] Virtuoso 시스템 구성도19)

19) http://virtuoso.openlinksw.com/architect/varch.htm


1.6 OntoBase2.0OntoBase2.0은 탑쿼드란트코리아에서 개발한 Native 방식의 트리플 레파지토리로, RDF, RDFS, OWL을 모두 지원하며 RDF/XML, N-Triple, N3, Turtle 등 네 가지 형식의 RDF 트리플 처리를 위한 파서를 모두 지원한다. 또한 확장성을 고려한 메시지 기반의 프레임워크, 로드 밸런싱을 위한 클론 시스템, 대용량 데이터 처리를 위한 분할 파일, 메모리 캐싱 등을 지원한다.질의 언어로 SPARQL을 지원하며, 질의 처리를 위해 Jena의 ARQ(Automatic Repeat Request)를 이용한 질의 처리 엔진을 구현하였다. 또한 빠른 질의 처리를 위한 최적화된 색인 구조를 제공하고 질의 최적화 로직을 통한 질의 최적화를 수행한다. 부가적인 기능으로 데이터베이스 관리, 데이터 복구, 웹 응용 구축을 위한 API들을 제공한다.

[그림 4-4] OntoBase2.0 시스템 구성도

1.7 OntoReasoner시맨틱 서비스 플랫폼 OntoFrame의 핵심 구성 요소 중 하나인 OntoReasoner는 RDF 트리플 저장소(Triple Store)와 추론 엔진으로 구성된다 [12][13][14][15][16]. RDF 트리플 저장소는 RDF/XML, N-Triples, Turtle 등의 형식으로 표현된 온톨로지 스키마와 인스턴스들을 입력 받아 MS-SQL


Server와 같은 백엔드 DBMS 내에서 미리 정의된 테이블 스키마에 맞추어 저장한다. 저장된 온톨로지는 다시 RDF/XML, N-Triples, Turtle형식으로 추출될 수 있다. RDF 트리플 저장소는 SPARQL을 지원하고, SPARQL 질의는 자동적으로 SQL로 변환되어 실행되며, 그 결과는 SPARQL-Results/XML 형식으로 반환된다. COUNT, MIN, MAX와 같은 집계 함수를 지원하도록 SPARQL 문법을 확장하였으며, 조인(Join) 횟수를 줄이기 위한 확장 클래스-속성 뷰 기법을 적용하여 빠른 응답 속도를 보장한다. 추론 엔진은 Rete 알고리즘을 활용한 규칙 기반 추론을 수행하며, 전방 추론과 함께 일부 추론에 대해서는 DBMS 뷰(View)를 활용한 후방 추론(Backward-chaining)도 지원한다 [17][18]. RDFS 어휘 집합과 OWL-Lite의 일부 어휘들에 대한 함의(Entailment) 추론 및 사용자 정의 규칙 추론을 지원하는데, 와일드 패턴을 갖는 추론 규칙에 대해서는 온톨로지 스키마를 참조하여 동적으로 구체화시킴으로써 효율적인 추론을 수행할 수 있도록 한다.

ECPV Generator

RDF Handler

Reasoner

API

Ontology

RDF & OWL Parser

Triple StoreRDFSRules

OWLRules

UserRules

SPARQL Parser

SPARQL Evaluator

SPARQL-SQL Convertor

Manager UserServices

s p o…

s p o… s p o

…s p o

…s p o

…

s p o…

s p o…

s p o…

DBMS

Query Result Handler

SPARQL-Results/XMLSPARQL

RDF/XMLN-Triples

Turtle

wmei. . .

wmei.p rdf:type rdf:Propertyrdf1

rdfs2tokeni.wme1.s rdf:type tokeni.wme2.o

rootp=“rdfs:domain”

wmei. . .

p=“rdfs:range”

wmei.p=stokeni. . .

wmei. . .

wmei.p=stokeni. . .

rdfs3tokeni.wme1.o rdf:type tokeni.wme2.o

wmei.s rdf:type rdfs:Resourcerdfs4a

wmei.o rdf:type rdfs:Resourcerdfs4b

p=“rdfs:subPropeertyOf”

wmei. . .

wmei.o=stokeni. . .


p=“rdf:type”

o=“rdf:Property”wmei. . .

rdfs6wmei.s rdfs:subPropertyOf wmei.s

wmei. . .

tokeni.wme2.o=stokeni. . .

ruleXtokeni.wme1.o rdf:type tokeni.wme3.s

α-Net

β-Net

s=o

…

RDF & OWL Writer

ECPV Generator

RDF Handler

Reasoner

API

Ontology

RDF & OWL Parser

Triple StoreRDFSRules

OWLRules

UserRules

SPARQL Parser

SPARQL Evaluator

SPARQL-SQL Convertor

Manager UserServices

s p o…

s p o… s p o

…s p o

…s p o

…

s p o…

s p o…

s p o…

DBMSs p o…

s p o… s p o

…s p o

…s p o

…

s p o…

s p o…

s p o…

DBMS

Query Result Handler

SPARQL-Results/XMLSPARQL

RDF/XMLN-Triples

Turtle

wmei. . .




wmei. . .

p=“rdfs:range”

wmei.p=stokeni. . .

wmei. . .

wmei.p=stokeni. . .





wmei. . .

wmei.o=stokeni. . .


p=“rdf:type”



wmei. . .



α-Net

β-Net

s=o

…wmei. . .




wmei. . .

p=“rdfs:range”

wmei.p=stokeni. . .

wmei. . .

wmei.p=stokeni. . .





wmei. . .

wmei.o=stokeni. . .


p=“rdf:type”



wmei. . .



α-Net

β-Net

s=o

…

RDF & OWL Writer

[그림 4-5] OntoReasoner 시스템 구성도


1.8 주요 트리플 레파지토리 특징 비교

제품명 저장소 관리 및 접근

질의 지원 방식 추론 엔진

온톨로지 편집기 통합 여부

상용/비상용/오픈소스

AllegroGraphJava, Lisp, C# API 및 HTTP 클라이언트

클라이언트 API를 통한 SPARQL 지원

추론 엔진 내장,RDFS++ 지원, Racer 지원

TopBraid Composer

Franz Inc,상용제품

Oracle 커맨드 라인 도구, 웹 인터페이스 SPARQL　지원

OWL Subset, RDFS 지원,사용자 정의 규칙, Rule Bases, Rule Indexes 지원

TopBraid Composer, OntoStudio

Oracle,상용제품

SwiftOWLIM 커맨드 라인 도구,웹 인터페이스

SPARQL, SeRQL 지원

추론 엔진 내장, RDFS, OWL-Tiny, OWL-Horst, OWL- Max 수준 추론 지원

TopBraid Composer(Sesame,OWLIM Reasoner)

OntoText,오픈소스

SDB 커맨드 라인 도구, Java API

Joseki 서버를 통한 SPARQL 지원

추론 엔진 내장, OWL-DL, OWL-Lite, RDFS 수준 추론 지원

TopBraid Composer, Protėgė

HP Lab, 오픈소스

Virtuoso 커맨드 라인 도구, Java/.Net API SPARQL 지원

OWL-DL, 　OWL-Lite, RDFS 수준 추론 지원

TopBraid Composer

OpenLink,오픈소스 /상용제품

OntoBase2.0 웹 인터페이스 SPARQL 지원OWL-Horst 및 OWL2 RL 지원 예정,사용자 정의 규칙 추론 지원 예정

TopBraid Composer(진행 중)

TopQuadrant Korea,상용제품

OntoReasoner 커맨드 라인 도구,웹 인터페이스 SPARQL 지원

추론 엔진 내장,RDFS++ 수준 지원,사용자 정의 규칙

해당 사항 없음 KISTI

[표 4-1] 주요 트리플 레파지토리 제품 비교


1.9 성능 벤치마킹 대상 각 제품의 문제점트리플 레파지토리 문제점

AllegroGraph

평가버전의 트리플 적재 제한으로 5,000만 건 이상의 RDF 트리플 셋을 적용하여 벤치마킹할 수 없음.최적화된 성능을 구현하기 위해서는 AllegroGraph 서버의 튜닝이 필수적이며 유료 기술 지원이 필요할 수도 있음.결과 개수가 많은 질의들의 경우 질의 실행에 많은 시간이 소요됨.

OracleSPARQL의 OPTIONAL, FILTER 구문을 완벽히 지원하지 않음.데이터 셋 적재에 많은 시간이 필요함.Oracle 서버의 튜닝을 위한 전문적인 지식이 요구됨.

SwiftOWLIM 큰 규모의 데이터 셋을 처리하기 위해 많은 메모리 용량이 필요.

SDB저장소로 사용되는 RDBMS에 따른 성능의 차이가 있었음데이터 셋 적재에 많은 시간이 필요함. 저장소로 사용되는 RDBMS의 튜닝이 필요함.

Virtuoso큰 규모의 데이터 셋을 적재할 때 트랜잭션과 관련된 오류가 일어남. Virtuoso Universal Server에 대한 튜닝이 필수적.

[표 4-2] 성능 벤치마킹 대상 각 제품의 문제점


2 성능 벤치마킹

2.1 제품군AllegroGraph RDFStore Free Server Edition ver.3.220) Oracle 11g Release 221)SwiftOWLIM ver.3.0.beta12 (with Apache Tomcat ver.6.0.20)22)SDB ver.1.3.0 (with MySQL ver.5.1.39 linux x86_64)23)Virtuoso 6.0.0 Open-Source Edition24)OntoBase2.025)

2.2 벤치마킹 환경 CPU | Intel Xeon CPU E5420 @ 2.50GHz (x4)RAM | 16 GB OS | Red Hat Enterprise Linux ver.4.1.2-14

(Kernel ver.2.6.18-53.el5) JDK | JDK 1.6.0_14 (64bit)

JVM Heap Memory Size 10GB (-Xmx10240m 옵션 적용)

20) http://www.franz.com/agraph/allegrograph/

21) http://www.oracle.com/technology/tech/semantic_technologies/index.html

22) http://www.ontotext.com/owlim/

23) http://openjena.org/SDB/

24) http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/

25) http://www.topquadrant.co.kr/


2.3 데이터 셋제품들의 성능 벤치마킹을 위한 데이터로서 LUBM26)과 WordNet27), BSBM28)의 데이터 셋을 사용하였다.

2.3.1 LUBM(The Lehigh University Benchmark)객관적인 벤치마킹을 위해 세계적으로 널리 사용되고 있는 LUBM(The Lehigh University Benchmark) 데이터 셋을 사용하였는데, 이는 Lehigh 대학에서 SWAT(The Semantic Web and Agent Technologies) 프로젝트의 일환으로서 개발된, 트리플 레파지토리의 효율적인 평가를 위한 성능 평가 기법이다. 트리플 레파지토리의 저장, 질의뿐만 아니라 추론 성능을 측정하기 위해 가장 널리 이용되며, 대규모 데이터 셋을 통해 트리플 레파지토리의 상용화를 가늠해 보기에 적합하다. LUBM 데이터 셋은 통상적으로 LUBM(10, 0), LUBM(100, 0)과 같이 표기한다. 10, 100의 값은 RDF 트리플로 생성되는 대학의 수를 의미하며, 0은 무작위로 데이터를 생성하기 위해 데이터 자동 생성기(UBA; Univ-Bench Artificial Data Generator)에 설정하는 값이다. LUBM 데이터 셋의 규모는 일반적으로 대학의 수에 따라 결정되며, LUBM(8000, 0)의 경우 임의의 8,000개 대학에 관련된 10억 개 이상의 RDF 트리플을 포함하고 있다. LUBM 데이터 셋은 Univ-Bench라고 부르는 OWL-Lite 기반의 어휘 집합을 사용하며 RDF 트리플로 기술된다. Univ-Bench는 총 43개의 클래스들과 32개의 속성(25개의 객체 관계 속성(Object Property)과 7개의 데이터 타입 속성(Data Type Property))으로 구성되며, OWL29)과 DAML의 두 가지 버전으로 배포된다. 데이터 자동 생성기를 통해 Univ-Bench의 클래스와 속성들로 구성되는 개체들을 반복적으로 생성하여 성능 평가를 위한 적절한 규모의 데이터 셋을 만들 수 있으며, 객관적인 질의 및 추론 평가를 위한 14개의 질의들을 동시에 제공한다 (부록1 참조).

26) http://swat.cse.lehigh.edu/projects/lubm

27) http://wordnet.princeton.edu

28) http://www4.wiwiss.fu-berlin.de/bizer/BerlinSPARQLBenchmark/spec

29) http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl


2.3.2 WordNetWordNet은 영국 프린스턴 대학에서 개발한 영어 어휘 지식 정보 기반의 데이터베이스를 말한다. 각각의 단어 의미 사이의 의미 관계에 의해서 기술되는 관계적 어휘 데이터베이스 또는 명사, 동사, 형용사, 부사에 대한 의미적 연결 관계로 이루어진 동의어 집합(Synset)이라고도 정의할 수 있다.일반적인 사전들은 단어 중심으로 표현되어 있지만, WordNet은 의미 중심으로 표현되어 의미 네트워크를 구성한다는 점이 다르다. WordNet에 대한 RDF/OWL 형태의 데이터 셋은 W3C에서 제공한다.30)대표적인 데이터 셋인 WordNet 2.0 Full Set은 RDF 형식의 WordNet Full Schema와 Words, WordSenses, Synsets, 그리고 Words와 WordSenses, Synsets를 연결하는 속성들로 구성되며, 약 8백만 개 이상의 트리플들을 포함하고 있다.참고로 WordSenses는 약 150,000개의 영어 어휘 의미를 담고 있으며, Synsets는 WordSenses의 어휘들과 관련된 약 115,000개의 동의어들에 대한 데이터 셋을 말한다.성능 벤치마킹에서 사용한 질의는 ‘RDF/OWL Representation of WordNet’31) 문서에 소개되어 있다. [부록2]

2.3.3 BSBM(Berlin SPARQL Benchmark)전자상거래에서 발생할 수 있는 수많은 데이터들을 가정하고, 이들 데이터에 대한 트리플 레파지토리의 SPARQL 질의 처리 성능을 평가하기 위한 평가 기법이다.무거운 추론 과정에 의지하지 않는 시맨틱 웹 응용프로그램이 증가하고, 이러한 웹 환경에서 자율적으로 생산되는 데이터들이 늘어나면서, 추론을 필요로 하지 않는 대규모 데이터 처리 성능에 대한 트리플 레파지토리의 효과적인 평가가 요구되었다. BSBM은 이와 같은 평가 요구에 맞추어 복잡한 추론 성능보다는 대용량 데이터에 대한 저장 및 질의 성능을 효과적으로 측정하기 위해 디자인되었다.BSBM Tools32)에 포함되어 제공되는 Data Generator를 이용하여 원하는 규모의 데이터 셋을 임의로 생성할 수 있으며, 생성된 데이터 셋은 상품 정보, 상품 생산30) http://www.w3.org/2006/03/wn/wn20

31) http://www.w3.org/TR/wordnet-rdf/

32) http://sourceforge.net/projects/bsbmtools/


자(Producer)와 공급자(Vendor) 정보, 소비자 정보, 소비자들이 작성한 상품 평가 정보 등의 데이터를 담고 있다. 데이터 셋의 규모는 Data Generator에 입력되는 Product의 수(Scale Factor)를 통해 조절 가능하다. 참고로 1M 규모의 데이터 셋은 약 100만여 개의 트리플들로 구성된다. 데이터 셋에 대한 질의 성능은 12개의 SPARQL 질의 유형 및 이를 따르는 25개의 질의로 구성된 질의 믹스(Query Mix)를 통해 측정한다.본 성능 벤치마킹에서는 12개의 기본 질의 유형을 이용하여 각 제품의 질의 성능을 평가하였다. [부록3]


2.4 벤치마킹 과정

2.4.1 제품의 설치벤치마킹 과정의 첫 번째 단계는 각각의 제품들을 벤치마킹 할 시스템에 설치하는 일이다. 제품 설치와 관련된 정보는 제품의 패키지에 포함되어 있는 가이드 문서와 해당 웹 사이트에서 제공하는 관련 문서들을 참고하였다. 일반적으로 압축 파일 형태의 제품 패키지를 벤치마킹 할 시스템 내 임의의 디렉터리에 압축 해제하고, 가이드 문서에서 언급하고 있는 환경 설정 파일들을 시스템 환경에 맞게 변경해 주는 것으로 설치가 완료된다.본 성능 벤치마킹에서는 각각의 제품들이 서버/클라이언트 방식으로 데이터를 처리할 수 있도록 벤치마킹 환경을 구성하였으며, 제품 성능 향상을 위한 별도의 튜닝 과정은 생략하였다.

2.4.2 테스트 모듈 작성트리플 레파지토리 별로 작성된 테스트 모듈은 파일 형태의 RDF 트리플을 읽어 트리플 레파지토리에 저장하는 모듈(적재 모듈)과 SPARQL로 질의하는 모듈(질의 모듈)로 구성된다. 테스트 모듈의 역할은 기본적으로 IP 주소, Port 번호, 사용자 ID, 비밀번호와 같은 설정 정보들을 통해 트리플 레파지토리와의 연결이나 해제를 수행하며, 성공적으로 트리플 레파지토리와 연결되면 데이터 셋의 적재와 질의를 수행하고 각 작업의 소요된 시간을 측정한다. 테스트 모듈을 구성하는 프로그램 코드들은 Java로 작성되었으며, 가능한 경우 설치 패키지에 포함되어 있거나 웹 사이트를 통해 제공되는 예제 코드들을 사용하였다. 이는 불필요하거나 자의적인 프로그램 코드로 인해 발생할 수 있는 성능 저하를 최소화하기 위함이다.

2.4.3 데이터 셋 생성LUBM 데이터 셋은 다음과 같은 과정을 통해 준비하였다. 우선 LUBM 데이터 자동 생성기인 UBA1.7을 이용하여 RDF/XML 형식의 데이터 셋을 생성하였다. 이렇게 생성된 데이터 셋과 이를 SwiftOWLIM ver.2.9.1, OntoReasoner를 통해 적재하고 추론하여 얻어진 사실들을 병합하여 N-Triple 형식의 데이터 셋으로 변환하


였으며, 추론 수준은 OWL-Horst를 적용하였다 . 본 벤치마킹에서는 N-Triple 형식으로 변환한 LUBM(10, 0), LUBM(50, 0), LUBM(100, 0), LUBM(200, 0), LUBM(8000, 0) 규모의 데이터 셋을 사용하였다.

Data Set LUBM(10, 0) LUBM(50, 0) LUBM(100, 0) LUBM(200, 0)Number ofRDF　Triples 2,105,548 11,004,111 22,164,905 44,143,939

[표 4-3] 벤치마킹에서 사용한 LUBM 데이터 셋 규모

WordNet의 데이터 셋은 앞서 언급한 웹 사이트에서 간단히 다운로드 받을 수 있다. 본 성능 벤치마킹에서는 WordNet 2.0 Full Set을 사용하였다. BSBM의 데이터 셋 생성은 BSBM Tools에 포함되어 있는 Data Generator를 이용하였다. 벤치마킹에서 사용된 데이터 셋 중 가장 작은 규모인 250K 데이터 셋과 가장 큰 규모인 50M 데이터 셋을 생성하고, 중간 정도 규모로서 25M 데이터 셋을 추가하였다.

Data Set 250K 25M 50MScale Factor 666 70,812 139,250Number ofRDF　Triples 250,030 25,000,244 48,458,570

[표 4-4] 벤치마킹에서 사용한 BSBM 데이터 셋 규모

데이터 셋의 최대 규모는 총 트리플 수가 5,000만 개를 넘지 않는 범위로 정하였다. AllegroGraph의 평가 버전이 저장할 수 있는 최대 트리플의 수를 5,000만 개로 제한하고 있기 때문이다.


2.4.4 제품별 성능 벤치마킹벤치마킹은 데이터 셋을 읽어 트리플 레파지토리에 저장하는 작업과 저장된 RDF 트리플에 대해 질의하는 작업으로 나누어 진행하였다. LUBM 데이터 셋에 대하여 데이터 셋 적재 시간과 질의 응답 시간을 트리플 레파지토리 별로 측정하였으며, 각 작업 소요 시간은 10번의 반복 수행을 거쳐 그 평균값으로 정하였다. 결과 당 질의 응답 시간(QTPR; Query Time Per Result)을 추가로 계산함으로써 외부 벤치마킹 결과와 비교할 수 있도록 하였다. 소요 시간 측정 범위는 순수하게 데이터를 적재하거나 질의에 응답한 부분으로 국한하였다. LUBM(200, 0)까지의 벤치마킹을 위해 사용한 트리플 레파지토리들은 OntoBase2.0을 제외하고는 모두 비상용 제품(Free Edition)이기 때문에 상용 제품과 성능 면에서 다소 차이가 있을 수 있다. 튜닝에 의해서도 벤치마킹 결과가 달라질 수 있으나 최적화된 제품 튜닝과 관련해서는 전문적인 기술 지원 서비스를 요구하는 부분이므로, 본 벤치마킹에서는 배제하였다.

[그림 4-6] 벤치마킹 절차도


Data Set Repository Load Time (sec) Triple #

LUBM(10, 0)

AllegroGraph 102.7000

2,105,548OntoBase2.0 75.0619

Oracle 226.0467 OWLIM 191.3684 SDB 1,033.8386

Virtuoso 284.4150

LUBM(50, 0)


11,004,111OntoBase2.0 544.9962

Oracle 3,871.1514 OWLIM 957.8858 SDB 12,068.0750

Virtuoso 1,465.9187

LUBM(100, 0)

AllegroGraph 1,126.5702

22,164,905OntoBase2.0 1,243.7215

Oracle 17,947.6389 OWLIM 1,212.5340 SDB 29,606.7600

Virtuoso 3,278.6461

LUBM(200, 0)

AllegroGraph 2,653.8897

44,143,939

OntoBase2.0 2,851.2438 Oracle 46,981.4678 OWLIM 7,706.8855 SDB 73,135.4451

Virtuoso 6,801.6746 [표 4-5] LUBM 데이터 셋 제품별 적재 시간 비교

3 벤치마킹 결과

3.1 적재 성능 벤치마킹 결과

3.1.1 LUBM


seconds

[그림 4-7] LUBM 데이터 셋 제품별 적재 시간 비교

0

10000

20000

30000

40000

50000

60000

70000

80000

LUBM(10, 0) LUBM(50, 0) LUBM(100, 0) LUBM(200, 0)

seco

nds

AllegroGraph OntoBase2.0 Oracle OWLIM SDB Virtuoso

[그림 4-8] LUBM 데이터 셋 규모에 따른 제품별 적재 성능 변화



WordNet 2.0 Full Set


8,176,353OntoBase2.0 431.2577

Oracle 3,895.0499 OWLIM 774.4747 SDB 6,497.8495

Virtuoso 1,057.3721 [표 4-6] WordNet 데이터 셋 제품별 적재 시간 비교

3.1.2 WordNet

seconds

[그림 4-9] WordNet 데이터 셋 제품별 적재 시간 비교



BSBM250K


250,030OntoBase2.0 14.0554

Oracle 44.5544 OWLIM 18.2215

SDB 48.6782 Virtuoso 38.1546

BSBM25M


25,000,244OntoBase2.0 2530.7349

Oracle 18388.6078 OWLIM 2256.8275

SDB 20756.1364 Virtuoso 4300.9281

BSBM50M


48,458,570OntoBase2.0 4387.6907

Oracle 53095.0081 OWLIM 5494.2520

SDB 57438.2167 Virtuoso 8497.8378

[표 4-7] BSBM 데이터 셋 제품별 적재 시간 비교

3.1.2 BSBM


seconds

[그림 4-10] BSBM 데이터 셋 제품별 적재 시간 비교

0

10000

20000

30000

40000

50000

60000

70000

BSBM250K BSBM25M BSBM50M

seco

nds


[그림 4-11] BSBM 데이터 셋 규모에 따른 제품별 적재 성능 변화


3.2 질의 성능 벤치마킹 결과

3.2.1 LUBM(10, 0)

Query Query Response Time (sec) ResultsAllegroGraph OntoBase2.0 Oracle OWLIM SDB VirtuosoQ1 0.0049 0.0412 2.8503 0.6808 0.0128 0.0013 4Q2 0.1763 0.3413 0.2665 2.2777 0.0790 0.0205 28Q3 0.0022 0.0048 0.1642 0.2216 0.0022 0.0005 6Q4 0.0074 0.0058 0.0261 0.0248 0.0057 0.0018 34Q5 0.0286 0.0127 0.4601 0.3108 0.0085 0.0064 719Q6 3.2104 0.6349 0.9132 0.7505 0.8234 0.8138 99,566Q7 0.0067 0.0075 0.0118 0.6236 0.3994 0.0019 67Q8 0.6510 0.3282 0.7114 0.5246 1.2939 0.1637 7,790Q9 3.9458 1.3119 1.7899 3.0203 0.2949 0.4882 2,540Q10 0.0028 0.0057 0.0500 0.2947 0.0027 0.0008 4Q11 0.0100 0.0091 0.0220 0.0139 0.0035 0.0021 224Q12 0.0897 0.0093 0.0218 0.0821 0.0065 0.0033 15Q13 0.0030 0.0445 0.0051 0.2697 0.0029 0.0009 33Q14 2.3633 0.4308 0.6871 0.5495 0.6134 0.3837 75,547Avg. 0.7502 0.2277 0.5700 0.6889 0.2535 0.1349 13,326

[표 4-8] LUBM(10, 0) 데이터 셋 제품별 질의 응답 시간 비교


0

0.5

1

1.5

2

2.5

3

3.5

seconds

Query 1 Query 2 Query 3 Query 4 Query 5 Query 6 Query 7

LUBM(10, 0)


0

0.5

1

1.5

2

2.5

3

3.5

4

seconds


LUBM(10, 0)


[그림 4-12] LUBM(10, 0) 데이터 셋 제품별 질의 응답 시간 비교


Query QTPR (ms)AllegroGraph OntoBase2.0 Oracle OWLIM SDB Virtuoso

Q1 1.2300 10.3025 712.5825 170.2075 3.2050 0.3350 Q2 6.2964 12.1907 9.5179 81.3457 2.8229 0.7332 Q3 0.3583 0.7917 27.3667 36.9267 0.3617 0.0800 Q4 0.2179 0.1706 0.7688 0.7300 0.1679 0.0535 Q5 0.0397 0.0176 0.6399 0.4323 0.0118 0.0089 Q6 0.0322 0.0064 0.0092 0.0075 0.0083 0.0082 Q7 0.0999 0.1119 0.1766 9.3070 5.9618 0.0278 Q8 0.0836 0.0421 0.0913 0.0673 0.1661 0.0210 Q9 1.5535 0.5165 0.7047 1.1891 0.1161 0.1922 Q10 0.6875 1.4300 12.4900 73.6625 0.6800 0.1950 Q11 0.0447 0.0406 0.0981 0.0620 0.0158 0.0095 Q12 5.9800 0.6213 1.4533 5.4740 0.4313 0.2213 Q13 0.0918 1.3494 0.1558 8.1739 0.0864 0.0279 Q14 0.0313 0.0057 0.0091 0.0073 0.0081 0.0051 Avg. 1.1962 1.9712 54.7188 27.6852 1.0031 0.1370

[표 4-9] LUBM(10, 0) 데이터 셋 제품별 QTPR 비교


3.2.2 LUBM(50, 0)

Query Query Response Time (sec) ResultsAllegroGraph OntoBase2.0 Oracle OWLIM SDB VirtuosoQ1 0.0029 0.0288 4.0704 3.2706 0.0129 0.0185 4Q2 4.7019 4.9565 3.0517 5.1767 0.3229 0.4822 130Q3 0.0021 0.0033 0.1757 1.2264 0.0022 0.0162 6Q4 0.0061 0.0134 0.1284 0.0861 0.0055 0.0021 34Q5 0.0282 0.0084 1.9378 1.6929 0.0090 0.0082 719Q6 18.5661 3.4055 4.3257 3.7460 4.2791 5.7838 519,842Q7 0.0055 0.0067 0.0121 1.9453 0.0049 0.0035 67Q8 0.6652 0.9453 0.3304 0.9794 0.2987 0.1746 7,790Q9 20.3416 8.1320 11.9634 16.3609 10.6681 3.0561 13,639Q10 0.0019 0.0038 0.2022 1.7647 0.0028 0.0009 4Q11 0.0099 0.0113 0.0824 0.0468 0.0037 0.0161 224Q12 0.4281 0.0237 0.0158 2.2439 0.0044 0.0303 15Q13 0.0120 0.2308 0.0092 1.8077 0.0063 0.0038 228Q14 13.9864 2.4763 3.2479 2.8729 3.0252 4.0460 393,730Avg. 4.1970 1.4461 2.1109 3.0872 1.3318 0.9745 66,888



0

2

4

6

8

10

12

14

16

18

20

seconds


LUBM(50, 0)


0

5

10

15

20

25

seconds


LUBM(50, 0)








3.2.3 LUBM(100, 0)

Query Query Response Time (sec) ResultsAllegroGraph OntoBase2.0 Oracle OWLIM SDB VirtuosoQ1 0.0029 0.0573 1.4813 0.9581 0.0133 0.0025 4Q2 19.2305 10.4670 12.7896 9.9384 2.0771 1.7800 264Q3 0.0021 0.0036 1.6731 2.5227 0.0023 0.0014 6Q4 0.0061 0.0054 4.3452 0.1814 0.0053 0.0023 34Q5 0.0286 0.0084 1.8167 3.0703 0.0084 0.0092 719Q6 39.9747 6.9169 6.9449 9.6834 8.8508 11.5649 1,048,532Q7 0.0052 0.0071 0.0072 2.5751 0.0061 0.0086 67Q8 0.6923 1.6840 4.5172 1.5248 10.8646 0.1781 7,790Q9 41.1658 18.2559 28.6334 18.8594 28.7543 5.8877 27,247Q10 0.0018 0.0036 1.7736 3.5857 0.0027 0.0014 4Q11 0.0099 0.0167 1.3938 0.0984 0.0037 0.0035 224Q12 0.8483 0.0412 4.2138 9.0932 0.0368 0.0034 15Q13 0.0234 0.5885 0.0127 2.9572 0.0104 0.0081 472Q14 29.7816 5.3904 5.6328 5.6861 6.7452 9.4411 795,970Avg. 9.4124 3.1033 5.3740 5.0524 4.0986 2.0637 134,382



0

5

10

15

20

25

30

35

40

seconds


LUBM(100, 0)


0

5

10

15

20

25

30

35

40

45

seconds


LUBM(100, 0)








3.2.4 LUBM(200, 0)

Query Query Response Time (sec) ResultsAllegroGraph OntoBase2.0 Oracle OWLIM SDB VirtuosoQ1 0.0071 0.1159 10.0263 2.2966 0.0325 0.0083 4Q2 77.7700 7.9497 28.3877 11.4180 6.6544 7.4116 499Q3 0.0022 0.0043 16.0319 5.9483 0.0046 0.0012 6Q4 0.0109 0.0341 1.1211 0.4774 0.0067 0.0024 34Q5 0.0287 0.0091 10.5965 8.4439 0.0117 0.0107 719Q6 93.2902 13.5656 61.4625 22.3705 17.2766 24.2258 2,088,195Q7 0.0052 0.0107 125.8662 5.1419 0.0068 0.0048 67Q8 0.7145 4.1692 4.9875 4.3457 23.4224 0.1917 7,790Q9 82.2652 43.5406 107.1003 40.3432 59.7981 12.1926 54,285Q10 0.0019 0.0038 10.2367 8.2571 0.0027 0.0017 4Q11 0.0101 0.0590 0.5425 0.2057 0.0057 0.0038 224Q12 1.7610 0.1084 0.3880 50.3141 0.0748 0.0037 15Q13 0.0443 1.1517 20.9007 8.7550 0.0225 0.0163 916Q14 63.9761 9.7294 16.3162 11.1938 13.2567 18.5589 1,584,743Avg. 22.8491 5.7465 29.5689 12.8222 8.6126 4.4738 266,964



0

20

40

60

80

100

120

140

seconds


LUBM(200, 0)


0

20

40

60

80

100

120

seconds


LUBM(200, 0)








0

5

10

15

20

25

30

35

LUBM(10, 0) LUBM(50, 0) LUBM(100, 0) LUBM(200, 0)

seco

nds


[그림 4-16] LUBM 데이터 셋 규모에 따른 제품별 질의 성능 변화 (평균 질의 응답 시간 비교)

3.2.5 LUBM(8000, 0)본 절에서는 LUBM(8000, 0) 데이터 셋을 이용하여 현존하는 대표적 트리플 레파지토리의 질의 성능 벤치마킹 결과를 제시한다. 본 벤치마킹 결과 중 OntoBase2.0과 SDB에 대한 결과와 OntoReasoner, AllegroGraph, BigOWLIM 각각에 대한 결과 (부록4 참조)는 서로 다른 벤치마킹 환경에서 얻어진 결과로서 상호간 직접적인 비교는 불가능함을 미리 알리고자 한다. 본 절의 기술 목적은 LUBM(200, 0) 등 비교적 소규모에서만 동작하는 트리플 레파지토리들과 달리 대표적 트리플 레파지토리들이 얼마나 뛰어난 성능을 보일 수 있는 지를 간접적으로 설명하는 데 있다. 즉, 본 절에서 벤치마킹된 트리플 레파지토리들은 현실적인 시맨틱 웹 기술 적용 규모를 암시하는 동시에, 현재까지의 빠른 발전 속도에 비추어 앞으로의 무한한 진화 가능성을 보여주고 있는 것이다.Native 방식의 트리플 레파지토리 중 AllegroGraph는 평가 버전이 저장할 수 있는


최대 트리플의 수가 최대 5,000만 개로 제한되고 있기 때문에 벤치마킹이 불가능하였으며, Oracle은 다른 데이터 셋에 대한 적재 성능 벤치마킹 결과가 현저히 느려서, Virtuoso는 데이터 셋을 적재하는 과정에서 트랜잭션(transaction) 오류가 발생하는 경우가 있었기 때문에 안정적인 벤치마킹의 진행을 위해 배제하였다. SwiftOWLIM은 In-Memory 방식의 트리플 레파지토리이기 때문에 대용량 데이터 셋에 대한 벤치마킹이 원천적으로 불가능하였다. 그 결과 Native 방식의 트리플 레파지토리는 OntoBase2.0이, Non-Native 방식의 트리플 레파지토리로는 SDB만이 성능 평가 대상이 되었다. KISTI가 개발한 OntoReasoner는 2009년 연구 개발을 통해 성능이 대폭 향상된 3.0 버전의 벤치마킹 결과를 부록 4를 통해 공식적으로 배포하고 있어 별도의 벤치마킹을 진행하지 않고 [표 4-17] 등을 통해 재정리만 하였다. 이 결과에는 세계적 수준의 상용 트리플 레파지토리들인 AllegroGraph, BigOWLIM이 포함되어 있다.SDB의 경우, LUBM(8000, 0)을 적재하는데 2주가 넘는 시간이 걸릴 정도로 불안정하여 적재 성능을 측정하는 자체가 의미가 없었기 때문에 적재 성능 결과를 비교 제시하지 않았다.벤치마킹 결과들을 정리한다면 Non-Native 방식에 있어서는 OntoReasoner가 가장 안정적이고 빠른 속도를 보여주어 Native 방식에 기반을 둔 세계적 수준의 상용 트리플 레파지토리들과 대등하거나 우월한 성능을 보이고 있음을 확인할 수 있다. OntoBase2.0 역시 짧은 기간 국내에서 개발된 트리플 레파지토리임에도 불구하고 Native 방식 중 BigOWLIM과 비견할 정도로 상당히 안정적인 성능을 보여주고 있어 향후 획기적인 성능 향상이 기대된다. Native 방식과 Non-Native 방식은 적재, 질의 응답 외에도 백엔드 측면에서 고려할 사항들이 많고 그 적용 영역에서도 차이가 나기 때문에 이들 간의 직접적인 비교는 큰 의미가 없다.


벤치마킹 환경

CPU | Intel Xeon CPU E5420 @ 2.50GHz (x4) RAM | 16 GB OS | Red Hat Enterprise Linux ver.4.1.2-14(Kernel ver.2.6.18-53.el5)

QueryOntoBase2.0 SDB

ResultsTime(ms) QTPR(ms) Time(ms) QTPR(ms)

Q1 39 9.75 67 16.75 4Q2 665,082 263.08 975,246 385.77 2,528Q3 14 2.33 19 3.16 6Q4 46 1.35 29 0.85 34Q5 30 0.04 48 0.066 719Q6 148,452 0.00 215,100 0.00 83,557,706Q7 16 0.23 12 0.17 67Q8 583 0.07 551,020 70.73 7,790Q9 1,193,274 0.54 1,913,515 0.87 2,178,420Q10 11 2.75 10 2.50 4Q11 22 0.09 74 0.33 224Q12 36 2.40 1,773 118.20 15Q13 91,625 2.46 71,122 1.91 37,118Q14 167,092 0.00 194,290 0.00 63,400,587Avg. 161,479 21.93 280,166 42.95 10,656,087.29

[표 4-16] LUBM(8000, 0) 데이터 셋 질의 응답 시간 (OntoBase2.0, SDB)


0

100

200

300

400

500

600

700

800

900

1000

seconds

Q1 Q2 Q3 Q4 Q5 Q6

OntoBase2.0 SDB

0

200

400

600

800

1000

1200

1400

1600

1800

2000

seconds

Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14

OntoBase2.0 SDB

[그림 4-17] LUBM(8000, 0) 데이터 셋 질의 응답 시간 비교(OntoBase2.0, SDB)


벤치마킹 환경

CPU | Intel Xeon CPU X5450 @ 3.00GHz (x2) RAM | 28 GB OS | Windows Server 2003 Release 2

QueryOntoReasoner

ResultsTime(ms) QTPR(ms)

Q1 4 0.98 4Q2 128,560 50.85 2,528Q3 4 0.70 6Q4 14 0.40 34Q5 49 0.07 719Q6 111,822 0.00 83,557,706Q7 9 0.13 67Q8 247 0.03 7,790Q9 530,603 0.24 2,178,420Q10 3 0.70 4Q11 4 0.02 224Q12 17 1.11 15Q13 113 0.00 37,118Q14 88,708 0.00 63,400,587Avg. 61,440 3.95 10,656,087.29[표 4-17] LUBM(8000, 0) 데이터 셋 질의 응답 시간 (OntoReasoner)


0

20

40

60

80

100

120

140

seconds

Q1 Q2 Q3 Q4 Q5 Q6

OntoReasoner

OntoReasoner

0

100

200

300

400

500

600

seconds

Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14

OntoReasoner

OntoReasoner

[그림 4-18] LUBM(8000, 0) 데이터 셋 질의 응답 시간 비교(OntoReasoner)


3.2.6 WordNet

Query Query Response Time (sec) ResultsAllegroGraph OntoBase2.0 Oracle OWLIM SDB VirtuosoQ1 8.0403 0.0947 12.7370 0.4681 0.2595 0.0402 18

[표 4-18] WordNet 데이터 셋 제품별 질의 응답 시간 비교

0

2

4

6

8

10

12

14

seconds

WordNet


[그림 4-19] WordNet 데이터 셋 제품별 질의 응답 시간 비교


3.2.7 BSBM250K


Q2 0.0141 0.0217 OPTIONAL 구문 인식 오류 0.0090 0.0134 0.0028 20

Q3 0.3825 0.0084 0.0326 0.0207 0.0045 0.0011 0Q4 0.2517 0.0061 0.0204 0.0340 0.0058 0.0016 0Q5 3.2043 0.1326 0.0632 0.2819 0.0428 0.0045 2Q6 0.1381 0.0241 0.0250 0.0260 0.0137 0.0040 1


Q8 0.0064 0.0193 0.1833 0.0061 0.0051 0.0048 1Q9 0.0049 0.1072 0.0132 0.4456 0.0055 0.0018 6

Q10 1.1408 0.0476 FILTER 구문 인식 오류 0.0056 0.0066 0.0072 1

Q11 0.0038 0.0042 0.0652 0.0068 0.0018 0.0004 10Q12 0.0075 0.0152 0.0199 0.0096 0.0055 0.0018 8Avg. 0.4455 0.0404 0.0531 0.0745 0.0105 0.0126 -

[표 4-19] BSBM250K 데이터 셋 제품별 질의 응답 시간 비교


0

0.5

1

1.5

2

2.5

3

3.5

seconds

Query 1 Query 2 Query 3 Query 4 Query 5 Query 6

BSBM 250K


0

0.2

0.4

0.6

0.8

1

1.2

seconds


BSBM 250K


[그림 4-20] BSBM250K 데이터 셋 제품별 질의 응답 시간 비교


3.2.8 BSBM 25M



Q3 3.0174 0.1135 0.0051 0.3287 0.0088 0.0030 0Q4 6.0166 0.0066 0.0110 0.6635 0.0176 0.0042 0Q5 81.5402 13.5869 0.4231 6.9137 2.0203 0.0968 5Q6 2.9614 2.1131 1.6710 0.9322 2.2875 0.4783 3


Q8 0.0077 1.1316 0.0123 0.0067 0.0071 0.0059 2Q9 0.0016 0.0683 0.0035 42.6361 0.0129 0.0049 6

Q10 25.9438 3.0450 FILTER 구문 인식 오류 0.0120 0.0092 0.0050 2

Q11 0.0017 0.0058 8.2843 0.0078 0.0016 0.0007 0Q12 0.0067 0.1003 0.0099 0.0117 0.0081 0.0038 8Avg. 10.2151 1.9783 1.1616 4.3236 0.3712 0.0523 -

[표 4-20] BSBM 25M 데이터 셋 제품별 질의 응답 시간 비교


0

10

20

30

40

50

60

70

80

90

seconds


BSBM 25M


0

5

10

15

20

25

30

35

40

45

seconds


BSBM 25M


[그림 4-21] BSBM25M 데이터 셋 제품별 질의 응답 시간 비교


3.2.9 BSBM50M



Q3 5.7601 0.0064 0.3517 0.7683 0.0073 0.0022 0Q4 11.4765 0.0100 0.1217 1.5133 0.0096 0.0024 0Q5 140.3026 73.2446 2.3630 14.2764 11.6435 0.0881 5Q6 13.9666 7.7800 75.5984 6.2006 23.2886 0.8744 3


Q8 0.0120 1.3046 8.4310 0.0142 0.0120 0.0022 0Q9 0.0016 0.0720 0.1419 82.8590 0.0163 0.0158 6

Q10 45.5374 6.7999 FILTER 구문 인식 오류 0.0204 0.0125 0.0364 1

Q11 0.0051 0.0057 15.0353 0.0088 0.0018 0.0022 0Q12 0.0051 0.1594 0.0511 0.0283 0.0084 0.0547 8Avg. 19.6814 8.1115 12.9795 8.9262 2.9369 0.0916 -

[표 4-21] BSBM50M 데이터 셋 제품별 질의 응답 시간 비교


0

20

40

60

80

100

120

140

160

seconds


BSBM 50M


0

10

20

30

40

50

60

70

80

90

seconds


BSBM 50M


[그림 4-22] BSBM50M 데이터 셋 제품별 질의 응답 시간 비교


0

5

10

15

20

25

BSBM250K BSBM25M BSBM50M

seco

nds


[그림 4-23] BSBM 데이터 셋 규모에 따른 제품별 질의 성능 변화 (평균 질의 응답 시간 비교)


4 벤치마킹 결과 분석

4.1 적재 성능 벤치마킹 결과 분석BSBM250K와 LUBM(10, 0)과 같이 비교적 작은 규모의 데이터 셋에 대해서는 모든 벤치마킹 대상들이 큰 차이 없이 빠른 속도로 적재를 수행하였다. 그렇지만 데이터 셋 규모가 커지면서 Oracle과 SDB의 속도 감소가 다른 트리플 레파지토리에 비해 두드러졌다. 약 800만 개 정도 규모인 WordNet 데이터 셋에서부터 속도의 차이를 확인할 수 있었으며, [그림 4-7]과 [그림 4-10]에서 보듯이 데이터 셋 규모가 커질수록 그 둔화 폭이 급격히 증가하였다. Oracle과 SDB는 모두 DBMS를 RDF 트리플의 저장소로 사용하는 Non-Native 방식이라는 공통점이 있다. RDF 트리플을 DBMS 내부 테이블로 변환하여 저장하는 과정에서 성능 저하가 발생하는 것으로 생각해 볼 수도 있을 것이다. 반면 OntoReasoner의 경우, Non-Native 방식임에도 불구하고 적재 성능에 있어 상당한 수준에 올라 있는데 이는 적재 최적화를 위한 여러 가지 기법들이 적용되어 있기 때문이다 (본 보고서에서는 지면상 기법과 성능 평가 결과를 생략함).In-Memory 방식으로 동작하는 SwiftOWLIM 역시 Apache Tomcat을 사용한 서버/클라이언트 방식을 채택하였는데, 이는 서버/클라이언트 방식으로 동작하는 다른 트리플 레파지토리와의 벤치마킹에 있어서의 형평성 때문이다. 서버와의 통신 영향으로 라이브러리 방식으로 적재할 때보다 다소 성능 저하가 있었으며, LUBM(200, 0) 데이터 셋의 경우 Oracle이나 SDB 만큼은 아니지만 적재 성능 저하가 상대적으로 커지는 모습을 확인할 수 있었다. 5,000만 개 이상의 보다 큰 데이터 셋을 적용하여 벤치마킹을 계속한다면 가용한 메모리의 한계에 이르는 시점부터 현격한 적재 성능 감소가 있을 것으로 예측된다. 참고로 힙 메모리(Heap Memory)를 충분히 적용하지 않고 SwiftOWLIM에 데이터 셋을 적재하는 경우에는 LUBM(50, 0)의 소규모 데이터 셋에서조차 ‘Out of Memory Exception’이 발생하였다. Virtuoso는 약 4천 8백만 개 규모의 데이터 셋인 BSBM50M(Berlin SPARQL Benchmark 50M)을 적재하는 과정에서 트랜잭션(Transaction) 관련 오류가 발생하였다.


[그림 4-24] Virtuoso에서 발생한 트랜잭션 오류

4.2 질의 성능 벤치마킹 결과 분석

4.2.1 AllegroGraphLUBM의 경우 해당 웹 사이트에서 제공하는 테스트 코드를 테스트 모듈에서 큰 변경 없이 그대로 사용하였음에도 특히 질의　6번, 9번, 14번의 실행에 많은 시간이 소요되었다. 이들 질의는 질의 결과의 수가 다른 질의들에 비해 상대적으로 많다는 공통점이 있다. 각각의 질의에 대한 특징을 살펴보면, 우선 질의 6번의 경우 단 하나의 클래스에 대해서만 질의하지만 UndergraduateStudent와 Student간의 명시적 subClassOf 관계와 GraduateStudent와 Student간의 암시적인 subClassOf 관계가 추론된다는 특징이 있다. 질의 9번의 경우는 질의 6번을 바탕으로 복잡도가 증가한 형태이다. 3개의 클래스에 대해서 질의하며, Faculty, Course 클래스의 계층구조가 추가되어 더 복잡한 추론이 이루어진다. 질의 14번의 경우 6번과 형태면에서는 유사하나 어떠한 추론도 일어나지 않는다. 하지만 6번 질의 다음으로 많은 결과를 돌려준다. 질의 2번에서도 상대적으로 낮은 성능이 눈에 띄는데, 질의 2번 역시 9번과 유사하게 3개의 Class와 3개의 Property들이 포함되어 있어 복잡도가 증가된 질의이다. LUBM 2번, 6번, 9번 14번을 제외한 LUBM의 나머지 질의들에 대해서는 평균적인 질의 성능을 나타냈다. WordNet의 경우 Oracle을 제외한 다른 트리플 레파지토리보다 낮은 성능을 보였으며, BSBM의 경우에도 전체적으로 낮은 질의 성능을 보였다. 특히 질의 5번과 10번이 두드러졌다. 질의 5번과 10번 모두 다양한 상품 및 구매 조건에 따른 FILTER 구문이 여러 수준에 걸쳐 적용되었다는 특징이 있으며, 중복 데이터를 방지하기 위한 DISTINCT 구문, 정렬을 위한 ORDER BY, 결과 수 제한을 위한 LIMIT 구문이 포함되어 있다.


1.2.2 OntoBase2.0LUBM과 WordNet의 경우 전체적으로 평균보다 다소 높은 성능을 보였다.BSBM의 경우에는 질의 유형에 따라 평균과 유사하거나 다소 낮은 성능을 나타냈지만, 특정 질의에 대해 두드러지게 낮은 성능을 나타냄 없이 고른 성능 분포를 보여주었다. 1.2.3 OracleLUBM의 경우 전체적으로 평균보다 낮은 성능을 보였다. 특히 LUBM(200, 0)에서 질의 7번이 현저하게 낮은 성능을 나타냈다. 질의 7번은 질의 9번과 유사하게 질의 6번에 Course 클래스가 추가되어 복잡도가 증가한 형태이다. 2개의 클래스에 대해 질의하고, 그에 따라 6번 질의보다 복잡한 추론이 수행된다. 질의 6번과 9번의 결과 역시 낮은 성능을 나타낸 것은 7번 질의가 현저하게 낮은 성능을 나타낸 것과 무관해 보이지 않는다. 데이터 셋 규모가 증가할수록 평균적인 질의 성능이 크게 감소하는 것도 또 하나의 주목해야 할 결과이다.WordNet의 경우 Oracle이 가장 낮은 성능을 보였다. WordNet 데이터 셋에 대한 질의는 단순한 SELECT 구문의 처리 성능을 평가하기 위한 것이다.BSBM의 경우에는 질의 2번, 7번, 10번에서 OPTIONAL 또는 FILTER 구문이 포함된 SPARQL 질의를 제대로 인식하지 못하는 오류가 발생하였다.


[그림 4-25] Oracle의 SPARQL　OPTIONAL, FILTER 구문 인식 오류

BSBM의 다른 질의에 대해서는 대체적으로 빠른 성능을 보였지만, 질의 11번에서 는 다소 낮은 성능을 나타냈다. 질의 11번은 조건식에 UNION이 포함된 것을 제외하면 단순한 SELECT 구문과 크게 다를 것이 없는 구문이다. BSBM의 경우에도 데이터 셋의 규모가 증가할수록 평균적인 질의 성능이 크게 감소하였다.

1.2.4 SwiftOWLIMSwiftOWLIM은 독자적인 서버를 제공하지 않기 때문에 라이브러리 방식으로 사용하는 것이 일반적이지만, 다른 트리플 레파지토리와의 형평성을 고려하여 서버/클라이언트 방식으로 벤치마킹하였다. 벤치마킹을 위한 서버로는 Apache Tomcat을 사용하였으며, 그 결과 Apache Tomcat의 성능이 SwiftOWLIM의 성능에 직접적인 영향을 미쳤다. 따라서 SwiftOWLIM을 라이브러리 방식으로 사용할 경우 벤치마킹 결과보다 훨씬 빠르고 우수한 성능을 예상할 수 있다. LUBM의 경우 AllegroGraph를 제외한 다른 레파지토리와 비교하여 전반적으로 낮은 성능을 보였으나, WordNet의 경우엔 매우 빠른 질의 성능을 보였다. 단순한


SELECT 구문의 처리 성능이 우수함을 알 수 있다.BSBM의 경우 평균과 비슷한 성능을 보였으나 질의 5번은 상대적으로 약간 낮은 성능을 나타냈고, 질의 9번의 경우는 현저히 낮은 성능을 나타냈다. BSBM 질의 5번은 앞서 언급한 바와 같이 여러 FILTER 구문을 통해 다양한 조건을 적용하는 질의이며, 질의 9번은 조건식이 있는 DESCRIBE 구문이다.

1.2.5 SDBSDB의 질의 성능은 저장소로 사용되는 RDBMS의 성능에 직접적인 영향을 받았다. 참고로 HSQLDB와 MySQL로 테스트한 결과 MySQL을 사용했을 때의 성능이 더 우수했다.LUBM의 경우 평균과 비슷한 성능을 보였으며, 질의 9번의 경우 약간 낮은 성능을 보였다. 질의 9번은 각각 3개의 클래스와 프로퍼티(property)를 포함하는 복잡도가 높은 질의이다.WordNet의 경우 평균과 비슷한 성능을 보였으며, BSBM의 경우엔 전체적으로 평균보다 다소 높은 성능을 보였다.

1.2.6 VirtuosoLUBM의 경우 다른 트리플 레파지토리에 비해 평균적으로 높은 성능을 보였다. 데이터 셋의 규모가 커질수록 질의 6번, 질의 14번의 처리 속도가 다소 늦어지는 결과가 나왔다. 이들 질의는 결과의 수가 많다는 공통점이 있다.WordNet의 경우 벤치마킹 제품군 중 가장 높은 성능을 나타냈다. 단순한 SELECT 구문에 대하여 매우 빠른 처리가 가능함을 알 수 있으나, LUBM의 결과와 비교하여 볼 때 데이터 셋의 규모가 커진다면 성능이 크게 감소할 수도 있을 것으로 보인다.BSBM의 경우에도 평균적으로 높은 성능을 보였다. SPARQL의 다양한 질의 유형을 거의 완벽하게 처리할 수 있는 능력을 나타낸 것이라고 할 수 있을 것이다.

107

제 5 부 결론

웹의 진화에 있어 시맨틱 웹은 이미 하나의 큰 흐름이며, 시맨틱 웹의 확산에 따라 링크드 데이터(linked data)와 같은 RDF 트리플 형태의 시맨틱 웹 데이터 역시 빠르게 증가하고 있다. 따라서 시맨틱 웹에 특화된 시맨틱 웹 데이터를 효과적으로 저장, 관리, 질의할 수 있는 트리플 레파지토리는 반드시 필요하다.트리플 레파지토리의 유형 가운데 메모리를 저장소로 활용하는 In-Memory 방식의 트리플 레파지토리는 그 한계가 너무도 분명해 보인다. SwiftOWLIM의 적재 성능 벤치마킹에서 힙 메모리(heap memory)를 적게 적용하여 벤치마킹을 진행하는 경우 ‘Out of Memory Exception’이 빈번히 일어나는 결과가 이를 잘 말해준다. 상용화된 서비스의 경우 적게는 수 백 만에서 많게는 수 억 개 이상의 데이터를 처리해야 하는데 이를 모두 메모리 기반으로 처리할 수는 없는 노릇이다. 따라서 디스크 기반의 물리적 저장소를 시맨틱 웹 데이터의 저장소로 이용하는 것은 필수적이다. RDF 트리플 구조에 최적화된 저장소를 갖는 Native 방식의 트리플 레파지토리의 경우 시맨틱 웹이란 큰 흐름 속에서 Non-RDF 데이터베이스에 대한 가장 훌륭한 대안이 될 수 있다. 우선 OntoBase2.0, AllegroGraph, BigOWLIM 등 고성능을 가진 상용 트리플 레파지토리의 성능 벤치마킹 결과에서 나타난 것처럼 적재 및 질의 성능 모두 평균 또는 그 이상의 고른 결과를 나타내면서도 DBMS보다 가볍다. 또한 데이터베이스 엔진 자체가 RDF 트리플을 위해 고안되지 않은 기존의 DBMS와 달리 RDF 트리플에 최적화되어 설계된 Native 방식의 트리플 레파지토리는 RDF 데이터의 연계는 물론 OWL2 RL이나 OWL-Horst와 같은 ‘Entailment Rule’에 의한 대용량 온톨로지의 효율성 측면에서도 유리한 점이 있다. 국내에서는 KISTI가 개발한 State-of-the-art 수준의 Non-Native 방식 트리플 레파지토리인 OntoReasoner와 함께 탑쿼드란트코리아가 개발한 Native 방식 트리플 레파지토리인 OntoBase2.0이 세계적 수준의 트리플 레파지토리들과 견주어도 손색이 없을 만큼 우수한 성능을 확보하였으며, ㈜다이퀘스트에서도 Native 방식의 트리플 레파지토리가 가지는 장점을 고려하여 Non-Native 방식의 OntoReasoner를


KISTI로부터 기술 이전 받아 DQReasoner라는 Native 방식의 트리플 레파지토리를 추가 개발하여 필드에 적용할 준비를 하고 있다.그렇지만 아직까지는 서비스 플랫폼 구성 요소로서의 안정성 측면에서 DBMS처럼 오랜 기간 동안 실무 영역 적용을 통해 철저하게 검증된 Non-Native 방식의 트리플 레파지토리에 비해 보완해야 할 부분들이 존재하는 게 현실이다. 그렇기 때문에 당분간은 고도로 진화된 검색 엔진의 경우처럼 두 가지 방식이 공존하면서 서로 경쟁하는 구도로 발전할 것으로 예측된다. 시급히 실무에 적용할 필요가 있는 분야에서는 안정성을 고려하여 DBMS를 저장소로 하는 Non-Native 방식의 트리플 레파지토리가 주로 적용될 것이며, 급격히 늘어나는 대규모 데이터 처리를 이슈로 하여 안정성이 확보된 Native 방식의 트리플 레파지토리가 그 적용 영역을 확대할 것이다.

109

참고문헌

[1] T. Berners-Lee, J. Hendler, and O. Lassila, "The Semantic Web", Scientific American Magazine May, 2001.[2] "The Semantic Web Vision", http://www.w3.org/2001/sw/[3] T. Gruber, "A Translation Approach to Portable Ontology Specifications", Knowledge Acquisition 5(2), 1993.[4] R. Mizoguchi, 최기선, 황도삼 공역, "차세대 웹과 지식 처리의 핵심기술 : 온톨로지 공학", 두양사, 2009.[5] D. Allemang and J. Hendler, "Semantic Web for the Working Ontologist", Elsevier, 2008.[6] K. Masahede, 황석형, 양해술 공역, "시맨틱 웹을 위한 RDF/OWL입문", 홍릉과학출판사, 2008.[7] K. Wilkinson, C. Sayers, H. Kuno, and D. Reynolds, "Efficient RDF Storage and Retrieval in Jena2", The 1st International Workshop on Semantic Web and Databases, 2003.[8] F. Ciravegna, "Semantic Web Technologies for Capturing, Sharing and Reusing Knowledge", The 7th International Semantic Web Conference, 2008.[9] S. Sahoo, W. Halb, S. Hellmann, K. Idehen, T. Thibodeau, S. Auer, J. Sequeda, and A. Ezzat, "A Survey of Current Approaches for Mapping of Relational Databases to RDF", W3C RDB2RDF Incubator Group, 2009. [10] "How to Publish Linked Data",http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/[11] "WSMO", http://www.wsmo.org/[12] 이미경, 정한민, 류범종, "시맨틱 웹 기반 학술정보서비스에 관한 연구", 한국지능정보시스템학회 추계학술대회, 2009.[13] 이미경, 정한민, 성원경, "OntoFrame: 시맨틱 웹 기반의 추론 서비스", 한국IT서비스학회 추계학술대회, 2008.

참고문헌110

[14] 정한민, 이미경, 성원경, "URI를 이용한 개체 중심적 통합 검색 시스템", 정보과학회논문지: 소프트웨어 및 응용 35(7), 2008.[15] 이미경, 정한민, 성원경, "KISTI의 차세대 정보 서비스 연구", 한국IT서비스학회 춘계학술대회, 2008.[16] W. Sung, H. Jung, P. Kim, I. Kang, M. Lee, and D. Park, "A Semantic Portal for Researchers Using OntoFrame", The 6th International Semantic Web Conference and the 2nd Asian Semantic Web Conference, 2007. [17] 이승우, 류범종, "메모리 및 DBMS 기반의 하이브리드 Rete 추론", 한국컴퓨터종합학술대회, 2009.[18] S. Lee, H. Jung, P. Kim, and B. You, "Dynamically Materializing Wild Pattern Rules Referring to Ontology Schema in Rete Framework", The 1st Asian Workshop on Scalable Semantic Data Processing (AS2DP), 2009.

111

부록1 LUBM 질의[Query1]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?XWHERE { ?X rdf:type ub:GraduateStudent ; ub:takesCourse <http://www.Department0.University0.edu/GraduateCourse0> . }

[Query2]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?X ?Y ?ZWHERE { ?X rdf:type ub:GraduateStudent . ?Y rdf:type ub:University . ?Z rdf:type ub:Department . ?X ub:memberOf ?Z . ?Z ub:subOrganizationOf ?Y . ?X ub:undergraduateDegreeFrom ?Y . }

[Query3]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?XWHERE { ?X rdf:type ub:Publication ; ub:publicationAuthor <http://www.Department0.University0.edu/AssistantProfessor0> . }

부록1 LUBM 질의112

[Query4]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?X ?Y1 ?Y2 ?Y3WHERE { ?X rdf:type ub:Professor ; ub:worksFor <http://www.Department0.University0.edu> ; ub:name ?Y1 ; ub:emailAddress ?Y2 ; ub:telephone ?Y3 . }

[Query5]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?XWHERE { ?X rdf:type ub:Person ; ub:memberOf <http://www.Department0.University0.edu> . }

[Query6]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?XWHERE { ?X rdf:type ub:Student .}

부록1 LUBM 질의 113

[Query7]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?X ?YWHERE { ?X rdf:type ub:Student . ?Y rdf:type ub:Course . ?X ub:takesCourse ?Y . <http://www.Department0.University0.edu/AssociateProfessor0> ub:teacherOf ?Y . }

[Query8]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?X ?Y ?ZWHERE { ?X rdf:type ub:Student . ?Y rdf:type ub:Department . ?X ub:memberOf ?Y . ?Y ub:subOrganizationOf <http://www.University0.edu> . ?X ub:emailAddress ?Z . }

[Query9]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?X ?Y ?ZWHERE { ?X rdf:type ub:Student . ?Y rdf:type ub:Faculty . ?Z rdf:type ub:Course . ?X ub:advisor ?Y . ?Y ub:teacherOf ?Z . ?X ub:takesCourse ?Z . }

부록1 LUBM 질의114

[Query10]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?XWHERE { ?X rdf:type ub:Student ; ub:takesCourse <http://www.Department0.University0.edu/GraduateCourse0> . }

[Query11]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?XWHERE { ?X rdf:type ub:ResearchGroup ; ub:subOrganizationOf <http://www.University0.edu> . }

[Query12]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?X ?YWHERE { ?X rdf:type ub:Chair . ?Y rdf:type ub:Department . ?X ub:worksFor ?Y . ?Y ub:subOrganizationOf <http://www.University0.edu> . }

부록1 LUBM 질의 115

[Query13]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?XWHERE { ?X rdf:type ub:Person . <http://www.University0.edu> ub:hasAlumnus ?X . }

[Query14]PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?XWHERE { ?X rdf:type ub:UndergraduateStudent .}

116

부록2 WordNet 질의PREFIX wn20schema: <http://www.w3.org/2006/03/wn/wn20/schema/>SELECT ?aSynsetWHERE { ?aSynset wn20schema:containsWordSense ?aWordSense . ?aWordSense wn20schema:word ?aWord . ?aWord wn20schema:lexicalForm "bank"@en-US . }

117

부록3 BSBM 질의[Query1]PREFIX bsbm-inst: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/>PREFIX bsbm: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/>PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT DISTINCT ?product ?labelWHERE { ?product rdfs:label ?label . ?product a <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductType18> . ?product bsbm:productFeature <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductFeature833> . ?product bsbm:productFeature <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductFeature61> . ?product bsbm:productPropertyNumeric1 ?value1 . FILTER (?value1 > 136) }ORDER BY ?labelLIMIT 10

부록3 BSBM 질의118

[Query2]PREFIX bsbm-inst: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/>PREFIX bsbm: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/>PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>PREFIX dc: <http://purl.org/dc/elements/1.1/>SELECT ?label ?comment ?producer ?productFeature ?propertyTextual1 ?propertyTextual2 ?propertyTextual3 ?propertyNumeric1 ?propertyNumeric2 ?propertyTextual4 ?propertyTextual5 ?propertyNumeric4 WHERE { <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product536> rdfs:label ?label . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product536> rdfs:comment ?comment . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product536> bsbm:producer ?p . ?p rdfs:label ?producer . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product536> dc:publisher ?p . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product536> bsbm:productFeature ?f . ?f rdfs:label ?productFeature . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product536> bsbm:productPropertyTextual1 ?propertyTextual1 . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product536> bsbm:productPropertyTextual2 ?propertyTextual2 . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product536> bsbm:productPropertyTextual3 ?propertyTextual3 . <ht tp : / /www4.wiwiss . fu-ber l i n . de /b i zer /bsbm/v01/ i ns tances /da taFromProducer11/Product536> bsbm:productPropertyNumeric1 ?propertyNumeric1 . <ht tp : / /www4.wiwiss . fu-ber l i n . de /b i zer /bsbm/v01/ i ns tances /da taFromProducer11/Product536> bsbm:productPropertyNumeric2 ?propertyNumeric2 . OPTIONAL { <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product536> sbm:productPropertyTextual4 ?propertyTextual4 } OPTIONAL { <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product536> bsbm:productPropertyTextual5 ?propertyTextual5 } OPTIONAL { <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product536> bsbm:productPropertyNumeric4 ?propertyNumeric4 }}

부록3 BSBM 질의 119

[Query3]PREFIX bsbm-inst: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/>PREFIX bsbm: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/>PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT ?product ?labelWHERE { ?product rdfs:label ?label . ?product a <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductType39> . ?product bsbm:productFeature <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductFeature2068> . ?product bsbm:productPropertyNumeric1 ?p1 . FILTER ( ?p1 > 156 ) ?product bsbm:productPropertyNumeric3 ?p3 . FILTER (?p3 < 152 ) OPTIONAL { ?product bsbm:productFeature <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductFeature151> . ?product rdfs:label ?testVar } FILTER (!bound(?testVar)) }ORDER BY ?labelLIMIT 10


[Query4]PREFIX bsbm-inst: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/>PREFIX bsbm: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/>PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>SELECT DISTINCT ?product ?label ?propertyTextualWHERE { { ?product rdfs:label ?label . ?product rdf:type <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductType42> . ?product bsbm:productFeature <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductFeature193> . ?product bsbm:productFeature <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductFeature2181> . ?product bsbm:productPropertyTextual1 ?propertyTextual . ?product bsbm:productPropertyNumeric1 ?p1 . FILTER ( ?p1 > 457 ) } UNION { ?product rdfs:label ?label . ?product rdf:type <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductType42> . ?product bsbm:productFeature <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductFeature193> . ?product bsbm:productFeature <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/ProductFeature2219> . ?product bsbm:productPropertyTextual1 ?propertyTextual . ?product bsbm:productPropertyNumeric2 ?p2 . FILTER ( ?p2> 488 ) } }ORDER BY ?labelOFFSET 5LIMIT 10


[Query5]PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>PREFIX bsbm: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/>SELECT DISTINCT ?product ?productLabelWHERE { ?product rdfs:label ?productLabel . FILTER (<http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer14/Product638> != ?product) <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer14/Product638> bsbm:productFeature ?prodFeature . ?product bsbm:productFeature ?prodFeature . <ht tp : / /www4.wiwiss . fu-ber l i n . de /b i zer /bsbm/v01/ i ns tances /da taFromProducer14/Product638> bsbm:productPropertyNumeric1 ?origProperty1 . ?product bsbm:productPropertyNumeric1 ?simProperty1 . FILTER (?simProperty1 < (?origProperty1 + 120) && ?simProperty1 > (?origProperty1 - 120)) <ht tp : / /www4.wiwiss . fu-ber l i n . de /b i zer /bsbm/v01/ i ns tances /da taFromProducer14/Product638> bsbm:productPropertyNumeric2 ?origProperty2 . ?product bsbm:productPropertyNumeric2 ?simProperty2 . FILTER (?simProperty2 < (?origProperty2 + 170) && ?simProperty2 > (?origProperty2 - 170))}ORDER BY ?productLabelLIMIT 5

[Query6]PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>PREFIX bsbm: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/>SELECT ?product ?labelWHERE { ?product rdfs:label ?label . ?product rdf:type bsbm:Product . FILTER regex(?label, "sashayed")}


[Query7]PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>PREFIX rev: <http://purl.org/stuff/rev#>PREFIX foaf: <http://xmlns.com/foaf/0.1/>PREFIX bsbm: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/>PREFIX dc: <http://purl.org/dc/elements/1.1/>SELECT ?productLabel ?offer ?price ?vendor ?vendorTitle ?review ?revTitle ?reviewer ?revName ?rating1 ?rating2WHERE { <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer8/Product336> rdfs:label ?productLabel . OPTIONAL { ?offer bsbm:product <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer8/Product336> . ?offer bsbm:price ?price . ?offer bsbm:vendor ?vendor . ?vendor rdfs:label ?vendorTitle . ?vendor bsbm:country <http://downlode.org/rdf/iso-3166/countries#DE> . ?offer dc:publisher ?vendor . ?offer bsbm:validTo ?date . FILTER (?date > "2008-06-20T00:00:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> ) } OPTIONAL { ?review bsbm:reviewFor <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer8/Product336> . ?review rev:reviewer ?reviewer . ?reviewer foaf:name ?revName . ?review dc:title ?revTitle . OPTIONAL { ?review bsbm:rating1 ?rating1 . } OPTIONAL { ?review bsbm:rating2 ?rating2 . } }}


[Query8]PREFIX bsbm: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/>PREFIX dc: <http://purl.org/dc/elements/1.1/>PREFIX rev: <http://purl.org/stuff/rev#>PREFIX foaf: <http://xmlns.com/foaf/0.1/>SELECT ?title ?text ?reviewDate ?reviewer ?reviewerName ?rating1 ?rating2 ?rating3 ?rating4 WHERE { ?review bsbm:reviewFor <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer11/Product486> . ?review dc:title ?title . ?review rev:text ?text . FILTER langMatches( lang(?text), "EN" ) ?review bsbm:reviewDate ?reviewDate . ?review rev:reviewer ?reviewer . ?reviewer foaf:name ?reviewerName . OPTIONAL { ?review bsbm:rating1 ?rating1 . } OPTIONAL { ?review bsbm:rating2 ?rating2 . } OPTIONAL { ?review bsbm:rating3 ?rating3 . } OPTIONAL { ?review bsbm:rating4 ?rating4 . }}ORDER BY DESC(?reviewDate)LIMIT 20

[Query9]PREFIX rev: <http://purl.org/stuff/rev#>DESCRIBE ?xWHERE { <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromRatingSite1/Review2174> rev:reviewer ?x }


[Query10]PREFIX bsbm: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/>PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> PREFIX dc: <http://purl.org/dc/elements/1.1/>SELECT DISTINCT ?offer ?priceWHERE { ?offer bsbm:product <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromProducer9/Product394> . ?offer bsbm:vendor ?vendor . ?offer dc:publisher ?vendor . ?vendor bsbm:country <http://downlode.org/rdf/iso-3166/countries#US> . ?offer bsbm:deliveryDays ?deliveryDays . FILTER (?deliveryDays <= 3) ?offer bsbm:price ?price . ?offer bsbm:validTo ?date . FILTER (?date > "2008-06-20T00:00:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> )}ORDER BY xsd:double(str(?price))LIMIT 10

[Query11]SELECT ?property ?hasValue ?isValueOfWHERE { { <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor2/Offer2450> ?property ?hasValue } UNION { ?isValueOf ?property <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor2/Offer2450> }}


[Query12]PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>PREFIX rev: <http://purl.org/stuff/rev#>PREFIX foaf: <http://xmlns.com/foaf/0.1/>PREFIX bsbm: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/>PREFIX bsbm-export: <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/vocabulary/export/>PREFIX dc: <http://purl.org/dc/elements/1.1/>CONSTRUCT { <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm-export:product ?productURI . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm-export:productlabel ?productlabel . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm-export:vendor ?vendorname . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm-export:vendorhomepage ?vendorhomepage . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm-export:offerURL ?offerURL . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm-export:price ?price . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm-export:deliveryDays ?deliveryDays . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm-export:validuntil ?validTo } WHERE { <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm:product ?productURI . ?productURI rdfs:label ?productlabel . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm:vendor ?vendorURI . ?vendorURI rdfs:label ?vendorname . ?vendorURI foaf:homepage ?vendorhomepage . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm:offerWebpage ?offerURL . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm:price ?price . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm:deliveryDays ?deliveryDays . <http://www4.wiwiss.fu-berlin.de/bizer/bsbm/v01/instances/dataFromVendor4/Offer8075> bsbm:validTo ?validTo }

126

부록4 OntoReasoner 벤치마킹 결과

[ISBN 978-89-6211-508-6]

오원석 강 혁 조도연 이승우 정한민김 평 이미경 김재한 성원경 김경선 박진우

2010년 2월 12일 인쇄2010년 2월 12일 발행

발 행 처

대전광역시 유성구 어은동 52-11 305-806

전화 : 042-869-1004등록 : 1991년 2월 12일 제 5-259호

발행인박 영 서

인쇄처㈜ 미래미디어

Documents

트리플 레파지토리 벤치마킹 연구 · 2018. 10. 18. · 1.2 RDF 트리플 데이터를 기계가 이해하고 처리할 수 있도록 하기 위해서는 형식적인 데이터