구글 ‘검색 알고리즘’ 베일 벗는다

기사입력 2008-06-02 19:26 기사원문보기
광고
[한겨레] 다양한 검색모델 최근 공개

“페이지 랭크는 기술 일부

검색 특징 계속 설명할 것”


뛰어난 검색 품질로 전세계 검색시장을 평정한 구글이 베일에 가려져 왔던 검색시스템의 구조에 대해 언급했다. 구글의 검색 품질을 책임지고 있는 기술담당 부사장 유디 맨버는 지난달 20일 구글의 공식 블로그에 글을 올려 검색 알고리즘 구조를 설명했다.

구글은 검색 결과에 순위를 매기는 알고리즘을 ‘왕관의 보석’과 같은 존재라며, 경쟁력 유지와 악용 방지를 이유로 철저하게 비밀에 부쳐왔다. 구글 검색은 창업자인 세르게이 브린과 래리 페이지가 개발한 ‘페이지 랭크’라는 알고리즘으로 유명하다. 페이지 랭크는 특정 웹페이지로 이어진 링크의 수와 그 링크가 있는 사이트에 연결된 링크의 수를 따져, 해당 페이지의 신뢰도와 적절성을 계산해 보여주는 구조다. 페이지 랭크 기술은 ‘구글 폭탄’을 낳기도 했다. 구글에서 ‘miserable failure’(참담한 실패)를 검색하면 조지 부시 미국 대통령을 소개하는 백악관 홈페이지로 연결되는 식이다. 부시를 조롱하려고 누리꾼들이 특정 사이트로 연결되는 링크를 생성한 데 따른 것이고, 한국에서도 ‘학살자’와 같은 구글 폭탄이 만들어졌다. 검색 알고리즘은 노출될 경우 검색 신뢰성이 위협받을 수 있는 최고의 기업비밀이다.

맨버는 이제 페이지 랭크 기술은 구글 검색시스템의 일부에 불과하다며, 구글의 다양한 검색 모델을 설명했다. 여기에는 △문장과 동의어, 맞춤법 실수 등 언어의 모호성을 처리하는 기술 △두 단어 이하로 묻는 이용자들의 질문 습관 △30분 전에 만들어진 페이지와 오랜 시간 유지된 페이지 중 어느 것이 더 적절한지를 판단하는 시간 모델 △이용자마다 검색 목적이 다른 데 따른 개인화 모델 △1000분의 1초 안에 모든 것을 처리해야 하는 기술 등이 쓰인다고 맨버는 밝혔다. 그는 구글이 지난해에만 450건의 검색 품질 개선작업을 했다며, 앞으로 비밀주의를 벗고 블로그를 통해 구글 검색의 특징을 설명하겠다고 밝혔다.
Posted by cykaneys
참조할 페이지 : http://nanet.empas.com/search/nanet_detail.html?vt=A&i=621070846&sn=KDMT1200716684&q=&q2=
제공 : 국회도서관

논문명/저자명 :
지능형 이미지 검색 시스템을 위한 추론 기반의 웹 온톨로지 구축 / 김수경

표제지
목차
국문요약 12
I. 서론 14
1.1 연구 필요성 및 목적 14
1.2 연구 내용 및 방법 19
1.3 논문 구성 20
II. 관련 연구 및 기술 21
2.1 온톨로지와 시맨틱 웹 21
2.1.1 온톨로지의 정의 21
2.1.2 온톨로지 기능 23
2.1.3 온톨로지의 종류 24
2.1.4 시맨틱 웹과 웹 온톨로지 25
2.1.5 온톨로지 개발 툴 27
(1) 프로떼제 28
(2) Composer 29
2.2 온톨로지 표현 언어 32
2.2.1 시맨틱 웹 온톨로지 표현 언어 33
(1) RDF 34
(2) OWL 36
(3) SWRL 38
2.2.2 서술 논리 40
2.3 온톨로지 구축 기법 42
2.3.1 국외 온톨로지 구축 기법 43
(1) Cyc 43
(2) KATUS 44
(3) Gruninger & Fox 방법론 45
(4) METONTOLOGY 46
(5) Ontology Development 101 48
(6) OTKM 49
(7) DOLCE 51
(8) Lifecycle of a Casual Web Ontology Development 52
2.3.2 국내 온톨로지 구축 기법 53
III. 시맨틱 웹에 적합한 웹 온톨로지 구축 기법 56
3.1 온톨로지 구축 기법 분석 56
3.1.1 기존 온톨로지 구축 기법 비교 분석 56
3.1.2 온톨로지 구축을 위한 참조 요소 59
3.2 시맨틱 웹에 적합한 웹 온톨로지 구축 기법 제안 61
3.2.1 웹 온톨로지 구축을 위한 참조 요소 61
3.2.2 웹 온톨로지 구축 기법 제안 64
(1) 단계 1 : 온톨로지 구축 목적 설정 64
(2) 단계 2 : 온톨로지 전체 구조 설정 67
(3) 단계 3 : 온톨로지 정보 확보 및 분석 단계 68
(4) 단계 4 : 온톨로지 내부 구조 설계 단계 70
(5) 단계 5 : 온톨로지 생성과 편집 단계 73
(6) 단계 6 : 온톨로지 유지 보수 73
3.2.3 웹 온톨로지 특징에 따른 온톨로지 구축 기법 비교 75
IV. 제안된 기법을 이용한 웹 온톨로지 구축 78
4.1 온톨로지 설계 78
4.1.1 온톨로지 구축 목적 설정 78
(1) 온톨로지 구축 대상 선택-주제 선택 79
(2) 온톨로지 구축 범위 결정 80
4.1.2 온톨로지 전체 구조 설정 82
4.1.3 온톨로지 정보 확보 및 분석 83
(1) 동물 분류 온톨로지 84
(2) 양 온톨로지 86
(3) 용어 온톨로지 90
(4) 이미지 정보 프레임 온톨로지 95
4.1.4 온톨로지 내부 구조 설계 96
(1) 동물 분류 온톨로지 내부 구조 설계 96
(2) 양 온톨로지 내부 구조 설계 98
(3) 용어 온톨로지 내부 구조 설계 101
(4) 이미지 정보 프레임 온톨로지 내부 구조 설계 104
4.2 도메인 온톨로지 생성과 검증 108
4.2.1 개별 도메인 온톨로지 생성과 편집 108
(1) 온톨로지 개발 툴과 물리적 환경 108
(2) 동물 분류 온톨로지 111
(3) 양 온톨로지 생성 113
(4) 용어 온톨로지 생성 116
(5) 이미지 정보 프레임 온톨로지 생성 117
4.2.2 개별 도메인 온톨로지 검증 121
(1) 동물 분류 온톨로지의 검증 122
(2) 양 온톨로지의 검증 124
(3) 용어 온톨로지 검증 124
(4) 이미지 정보 프레임 온톨로지 검증 125
(5) 일관성 검사를 통한 온톨로지들의 검증 126
4.2.3 SWRL 기반의 임의 규칙 추론 검증 126
(1) CQ 목록 정의 127
(2) 인간 가독 문법 정의 127
(3) 규칙 언어 정의 128
V. 실험 및 성능 평가 130
5.1 실험 시스템의 목적 및 구조 130
5.1.1 실험 시스템 시나리오 131
5.1.2 실험 시스템 구조 132
5.1.3 이미지 주석과 이미지 파일 연결 133
5.2 실험 시스템 환경 및 구현 134
5.2.1 지능형 이미지 검색 시스템 세부 구조 135
5.2.2 이미지 주석 정보와 이미지 파일 등록 136
5.2.3 이미지 내용 검색 138
5.2.4 용어 온톨로지 인스턴스 등록 140
5.2.5 이미지 지식 기반 온톨로지 조회 141
5.3 실험 시스템 성능 비교 평가 143
5.3.1 측정 요소 143
5.3.2 비교 대상 시스템 개요 145
5.3.3 비교 검색 실험과 분석 148
VI. 결론 154
VII. 참고문헌 156
Abstract 162
Posted by cykaneys

출처 : http://www.kosen21.org/pls/kosendev/WEBZINE_CLIENT.contents_view?n_webzine_seq=44&n_board_seq=408&n_data_seq=823&n_total=4

시맨틱 웹과 온톨로지

최중민 : joongmin   한양대학교

1. 시맨틱 웹의 개요

현재의 웹은 사람이 보고 잘 이해할 수 있도록 하기 위한 브라우저의 디스플레이 또는 레이아웃 기술에 초점을 맞추고 있다. HTML 언어의 특징이 바로 이러한 디스플레이용이라는 사실이 이를 뒷받침하고 있다. 하지만 HTML을 이용하여 문서의 내용과 의미를 나타내는 시맨틱 정보를 표현하기는 어려우며, 따라서 사람이 아닌 프로그램 또는 소프트웨어 에이전트가 자동으로 문서로부터 의미를 추출하기 어렵다. 시맨틱 웹은 메타데이터의 개념을 통하여 웹 문서에 시맨틱 정보를 덧붙이고 이를 이용하여 소프트웨어 에이전트가 이 의미 정보를 자동으로 추출할 수 있는 환경을 조성하는 것이다. 부수적으로 의미 정보의 자동 추출뿐 아니라 정보의 확장이나 공유 등도 가능하게 해준다.

시맨틱 웹은 기존의 웹과 완전히 구별되는 새로운 웹의 개념이 아니라 현재 웹을 확장하여 웹에 올라오는 정보에 잘 정의된 의미를 부여하고 이를 통해 컴퓨터와 사람이 협동적으로 작업을 수행할 수 있도록 해주는 패러다임이다. 시맨틱 웹의 궁극적인 목적은 웹에 있는 정보를 컴퓨터가 이해할 수 있도록 도와주는 표준과 기술을 개발하여 시맨틱 검색, 데이터 통합, 네비게이션, 타스크의 자동화 등을 지원하는 것이다.

시맨틱 웹을 실현하기 위한 다양한 접근 방법이 제시되었다. 하지만 HTML을 기반으로 한 현재의 웹을 개선하는 기본 취지에서 보면 시맨틱 웹을 달성하기 위해 웹 프로토콜과 같은 하위 레벨의 개념을 정의하고 이 하위레벨을 이용하여 다음 레벨의 개념을 정의하는 계층구조(layered structure)를 설정하는 것이 일반적인 연구 방향이다. 현재까지 연구가 진행된 시맨틱 웹 계층구조의 요소에는 XML, RDF, 온톨로지 등이 있으며, 따라서 이 글에서는 각각의 필요성과 시맨틱 웹에서의 역할을 주로 기술하고자 한다.


2. 시맨틱 웹에서의 XML과 RDF의 역할

XML은 시맨틱 웹의 구문적 기반 계층(syntactical foundation layer)을 구성한다. HTML에 비해서 XML은 잘 정의된 구조화 문서를 작성할 수 있도록 해준다. 즉, 요소라고 불리는 시작 태그와 종료 태그가 반드시 쌍으로 존재해야 한다는 것과 중첩 구조가 반드시 지켜져야 한다는 등의 제약조건이 반드시 만족되어야 한다. 시맨틱 웹과 관련된 XML의 역할은 이러한 구조화된 문서의 생성을 이끌어낸다는 것도 있지만 태그의 이름을 사용자가 자유롭게 정의할 수 있기 때문에 의미정보를 나타낼 수 있는 태그 이름을 사용할 수 있다는 것이 더 큰 비중을 차지한다.

하지만 이러한 XML 표현 방법이 시맨틱 웹을 달성하기에는 미흡한데, 그 이유는 첫째, 서로 다른 사람이 같은 의미를 뜻하면서도 다른 이름을 사용하여 태그를 정의할 수 있고, 둘째, 같은 내용에 대해서도 여러 가지 구조를 가진 XML 문서를 사용할 수 있어서 구조는 다르지만 동일한 내용의 문서라는 것을 에이전트 프로그램이 파악하기는 매우 어렵다.

RDF는 XML의 문제점을 해결하고 시맨틱(의미)에 초점을 맞추기 위해 제시된 기반구조이다. RDF의 근본을 이루는 개념은 메타데이터이다. 메타데이터는 데이터에 대한 데이터, 즉 어떤 객체나 리소스에 대한 서술적인 정보를 말한다. 웹 문서에 대한 메타데이터라고 한다면 그 문서의 주제, 요약, 저자, 작성 날짜와 같이 그 문서의 외적인 요소들을 망라한다고 볼 수 있다. RDF는 구조화된 메타데이터의 생성, 교환, 재사용 등을 가능하게 해주는 기반구조이다.

RDF 모델은 리소스(Resource), 특성(Property), 서술문(Statement)의 개념으로 구성된다. 웹 페이지나 웹 사이트 등의 모든 사물은 리소스로 표현되고, 각 리소스의 특성이나 다른 리소스와의 관계 등을 특성으로 나타낸다. 어떤 리소스의 한 특성에 대한 값을 나타내는 것이 서술문이며 이것이 RDF 문의 기본 단위가 된다. RDF의 서술문은 그래프 모델로 나타낼 수도 있고 다음의 예처럼 XML로 표현할 수 있다. RDF를 XML로 표현한 것을 Serialization이라고 한다. 이 RDF 문은 http://www.w3.org라는 리소스의 책임기관(Publisher), 제목(Title), 작성일(Date)의 세 가지 특성에 대한 정보를 표현하고 있다.



RDF 모델은 XML이 가지고 있던 문제점을 다음과 같이 해결하고 있다. 즉, 의미가 리소스와 그 특성 값으로 표현되므로 같은 내용(의미)에 대해서는 해석이 하나로만 귀결된다는 것이다. 달리 표현하면 XML에서와 같이 서로 다른 구조를 가진 여러 가지 표현방법이 존재하지 않기 때문에 문서의 내용에 대한 이해가 쉽다. 하지만 RDF에서도 XML의 문제점 중 하나였던 태그 이름의 중첩성과 모호성은 여전히 존재한다. 즉 서로 다른 태그이지만 실제로는 같은 의미일 수 있고, 반대로 같은 태그이지만 사용자에 따라서 다른 의미로 쓰일 수도 있다. 이 문제는 온톨로지의 개념으로 해결해야 한다.


3. 온톨로지의 필요성과 역할

온톨로지에 대한 정의는 여러 가지가 있지만 가장 널리 통용되는 Gruber의 정의에서는 온톨로지가 “공유된 개념화에 대한 정형화되고 명시적인 명세”로 표현된다. 이 정의를 세부적으로 살펴보면 1) 개념화(Conceptualization)는 온톨로지가 사람들이 사물에 대해 생각하는 바를 추상화한 모델이라는 것을 의미하고, 2) 명시적 명세(Explicit specification)는 개념의 타입이나 사용상의 제약 조건들이 명시적으로 정의되어야 한다는 것을, 3) 정형화(Formal)된다는 것은 온톨로지를 프로그램이 이해할 수 있어야 한다는 것을, 4) 공유(Shared)되어야 한다는 것은 온톨로지가 합의된 지식을 나타내므로 어느 개인에게만 국한되는 것이 아니라 그룹 구성원이 모두 동의하는 개념이어야 함을 나타낸다.

온톨로지는 단어와 관계들로 구성된 사전으로 간단히 나타날 수도 있고, 어느 특정 도메인에 관련된 단어들을 계층적 구조로 표현하고 추가적으로 이를 확장할 수 있는 추론 규칙을 포함할 수 있다. 온톨로지의 역할 중 하나는 서로 다른 데이터베이스가 같은 개념에 대해서 서로 다른 단어나 식별자를 사용할 경우에 이를 해결해주는 데 있다. 예를 들어, 주소를 포함하는 두 데이터베이스에서 postal code와 zip code는 같은 것을 의미하다. 이 두 데이터베이스의 정보를 비교하거나 통합하려는 프로그램이 있다면 이 두 단어가 같은 것을 지칭한다는 사실을 알아야 하며 이것이 바로 온톨로지를 통해서 이루어진다. 온톨로지는 웹 기반의 지식 처리나 응용 프로그램 사이의 지식 공유, 재사용들을 가능하게 하는 아주 중요한 요소로 자리잡고 있다.

온톨로지에는 계층분류(taxonomy)와 추론규칙(inference rule)에 대한 정의가 포함된다. 계층분류는 객체의 클래스와 서브클래스, 그들간의 관계를 정의한다. 예를 들어, 주소를 뜻하는 address는 위치를 뜻하는 location의 서브타입이므로 address는 location의 서브클래스로 정의될 수 있고, city codes는 location에만 적용될 수 있으므로 city codes의 대상은 반드시 location 클래스의 객체여야 한다는 제약조건이 관계로 정의될 수 있다. 추론규칙은 프로그램이 새로운 사실을 자동으로 추출하거나 제약조건에 맞지 않는 오류를 찾아내는데 이용된다.

온톨로지를 표현하기 위해 스키마와 구문구조 등을 정의한 언어가 온톨로지 언어이며 현재 DAML+OIL, OWL, Ontolingua 같은 온톨로지 언어가 정의되었다. 이 중에서 2004년에 웹 표준화 단체인 W3C에서 표준안으로 채택된 OWL은 웹 리소스에 대한 시맨틱 마크업 언어이며 RDF에 기반을 두고 이들을 확장한 프레임 기반의 온톨로지 표현 언어이다. 기본적으로 OWL로 표현된 온톨로지는 크게 Class 요소와 Property 요소로 구성된다. 또한 OWL 온톨로지에서는 복잡한 형태의 논리적 표현과 property restriction을 적용해 풍부한 지식 표현을 가능하게 하였다. 다음은 OWL로 표현된 온톨로지의 한 예로서 Tosca, Salome, Turandot를 멤버로 가지는 오페라 클래스를 정의하고 있다.



이러한 온톨로지를 이용한 시맨틱 웹 프로토콜은 컴퓨터들이 다른 종류의 데이터를 구별할 수 있도록 하는데 목표를 두고 있다. 이런 식별 기능이 갖춰지면 애플리케이션은 온라인 주소록과 휴대폰과 같은 기기들 간에 정보 교환을 보다 자동적으로 수행할 수 있게 된다. 그리고 웹사이트 또한 특정 방문객의 필요에 따라 자신을 자동적으로 재설정할 수 있으며, 검색 엔진도 보다 뛰어난 정확도로 사용자가 원하는 결과들만 보여줄 수 있다.


4. 시맨틱 웹 응용

시맨틱 웹의 응용은 에이전트 기반의 웹 서비스 제공과 Annotation이나 Authoring 등과 같은 유용한 응용 프로그램의 개발로 요약된다. Annotation은 시맨틱 웹을 가장 쉽게 응용할 수 있는 메커니즘이다. Annotation은 이미 존재하는 웹 페이지에 대해 추가적인 설명을 덧붙여서 다시 웹에 publish하는 것으로 주로 정보 검색의 정확도를 높이는 데 크게 기여할 수 있다. 이러한 annotation을 가능하게 해주는 툴로서는 OntoMat-Annotizer, SHOE, Annotea, Annozilla, COHSE Annotator 등이 있다.

MusicBrainz는 응용 프로그램으로서 사용자들이 자신의 데이터베이스로 음악 메타데이터를 POST 방법을 이용하여 저장하고 또 이 데이터를 다른 사용자가 GET 방법을 이용하여 검색할 수 있도록 해준다. 음악 데이터에 대한 메타데이터라고 하면 앨범 이름, 아티스트 이름, 제작사, 트랙 번호, 연주 시간 등의 데이터를 말한다. 이를 위해 RDF 문을 사용하며 이러한 기능들이 FreeAmp라는 MP3 플레이어에 내장되어 있다. 따라서 FreeAmp를 수행시켜 음악 CD를 열게 되면 MusicBrainz 서버에 트랙 이름과 아티스트에 대한 메타데이터를 요청해서 정보를 얻게 되고 이 정보에 따라 트랙을 선택하거나 기타 원하는 다른 작업을 할 수 있다.

ITTalks는 OWL의 이전 버전인 DAML+OIL을 이용하여 IT 분야와 관련되는 세미나 또는 초청 강연들에 대한 데이터베이스를 운영하고 이를 이용하여 웹을 통해 세미나 내용을 검색할 수 있는 응용 서비스이다. ITTalks의 데이터베이스는 세미나 관련 정보에 대한 웹 페이지와 DAML specification을 자동으로 생성하는데 사용되며 또한 세미나와 연관된 에이전트 기반 서비스의 중심 역할을 수행한다. 세미나에 대한 메타데이터를 DAML로 표현하기 위해 ITTalks에서는 calendar, person, place, profile, talk, topic 등 여러 가지 종류의 온톨로지를 정의하고 이용한다. 또한 세미나의 주제와 사용자 관심도 등을 이 온톨로지를 이용해 자동으로 분류하거나 DAML을 소프트웨어 에이전트간의 통신언어로 사용하는 등 고수준의 기능도 갖추고 있다.

최근 들어서는 어도비, HP, IBM, 노키아, 오라클 등의 기업에서 시맨틱 웹 프로토콜을 이용한 응용 프로그램을 개발하고 있거나 이미 제품으로 상용화시키기도 하였다. 이 외에도 주로 지능형 플랫폼이 요구되는 e-비즈니스 분야, 고객관리 분야, 바이오 정보 분야, 의료 분야 등에서 시맨틱 웹을 이용한 응용 서비스 개발에 관심을 기울이고 있다.


5. 국내외 연구동향과 향후 발전방향

시맨틱 웹에 대한 연구는 현재 크게 언어, 기반구조, 온톨로지, 휴먼 인터페이스 등의 세부 주제로 나누어서 얘기할 수 있다.

시맨틱 웹 언어는 온톨로지 언어와 같은 의미로서 시맨틱 웹의 내용을 표현하는데 반드시 필요한 도구이기 때문에 시맨틱 웹의 초기 단계에서는 이러한 언어의 개발이 가장 활발한 연구분야일 수밖에 없다. 잘 정의된 언어가 존재해야 시맨틱 웹의 주요 이슈인 상호운용성이 성취될 수 있으므로 언어에 대한 연구결과는 시맨틱 웹의 다른 분야에 대해서도 많은 영향을 끼친다. 이미 RDF, RDF 스키마, DAML+OIL, OWL 등의 시맨틱 웹 언어에 대한 제안서와 표준들이 많이 도출되었지만 시맨틱 웹 언어에 대한 표준이 주로 구문구조 위주로 정의되어 왔으며 앞으로 각 구문구조에 대한 의미를 부여하는 방향으로 연구가 이루어져야 한다.

기반구조는 프로토콜이나 전송방법 등을 의미한다. 이러한 기반구조는 온톨로지나 변환, 추론 엔진 등의 저장소를 제공할 필요는 없지만 이러한 저장소에 접근하기 위한 표준 방법을 가지고 있어야 한다. 기반구조는 웹 자원의 식별과 탐색, 상호운용성 지원 방법, 지식 보호 방법, 신뢰성 있는 지식 소스 선택 방법 등에 대한 방향으로 연구가 진행되고 있다.

온톨로지는 시맨틱 웹에서 가장 중심에 있는 개념으로서 응용 프로그램 사이에 통신을 할 때 단어에 대한 동의를 이끌어내는데 중요하다. 현재 온톨로지에 대한 연구는 온톨로지 개발 방법, 이론적 이슈, 전략적 온톨로지 필요성 인식 및 개발, 향상된 툴의 개발 등에 방향이 맞추어져 있다.

휴먼 인터페이스는 응용 프로그램에 대한 사용자 인터페이스와 좀 더 넓은 의미의 조직 인터페이스(organizational interface)를 모두 지칭한다. 사용자 인터페이스는 사람들이 시맨틱 웹 기술을 이용해서 서로 통신하기 위한 소프트웨어와 하드웨어를 의미하고, 조직 인터페이스는 그룹 사이의 상호작용에 필요한 인터페이스를 말한다.

시맨틱 웹에 대해서 가장 활발한 연구를 하는 기관은 웹 표준화 단체인 W3C라고 할 수 있다. 원래 W3C는 웹과 관련된 언어나 프로토콜, 소프트웨어, 툴과 같은 상호운용적인 기술을 개발하는 기관이며 주로 표준화 작업에 중점을 두고 있다. 시맨틱 웹에 대한 노력은 주로 RDF와 온톨로지에 대한 표준을 정의하는 방향으로 이루어지고 있으며 여러 소위원회를 통해 세부적인 사항을 결정하고 있다.
국내에서의 시맨틱 웹 연구는 주로 인공지능 연구 그룹과 데이터베이스/전자상거래 연구 그룹을 중심으로 진행되고 있지만 아직 초기 단계라고 할 수 있다. 인공지능 연구 그룹에서는 시맨틱 웹의 온톨로지나 Logic의 개념이 인공지능에서 다루는 지식표현과 추론, 학습 등의 주제와 크게 다르지 않기 때문에 웹을 도메인으로 하여 기존의 지식을 응용하는데 주력하고 있다. 인공지능 워크샵이나 지능형 에이전트 워크샵과 같은 인공지능 연구그룹의 학술활동이 최근 이 부분에 대한 비중을 높이고 있으며 추후의 국내 인공지능 그룹의 연구방향이 시맨틱 웹을 중심으로 이루어질 것으로 예상하고 있다. 데이터베이스/전자상거래 연구 그룹에서는 이전부터 관심을 가져온 XML의 표현 방법을 바탕으로 XML과 RDF의 데이터베이스와의 연계성에 중점을 두고 시맨틱 웹 연구를 해오고 있다. 또한 전자상거래 분야에서 상거래 문서들의 상호운용성을 위한 XML 기반 언어 개발이나 시맨틱 웹 정보의 보안 처리 문제 등도 다루고 있다.

최근 정부에서도 시맨틱 웹의 중요성을 깨닫기 시작하여 시맨틱 웹과 지식처리엔진 등 지능형 e-비즈니스 플랫폼 기술 개발에 투자를 하고 있으며, 이 지능형 e-비즈니스 플랫폼 기술이 지금의 전자거래처리시스템을 지능화, 자동화한 차세대 기술로 ERP, e-Marketplace, SCM 등 기존 e-비즈니스 시스템에 적용할 경우 생산성을 향상시키고 거래비용을 획기적으로 절감해줄 수 있을 것으로 기대한다.
Posted by cykaneys

Twine and Linked Data on the Semantic Web

Tim Berners-Lee just posted his thoughts about the importance of Linked Data on the Semantic Web. Linked data support is built-into Twine. All the data in Twine is accessible as open-standard RDF and OWL today and will be accessible to other applications via several API's including SPARQL. You can learn more about Twine's support for Linked Data and see some examples here.

Tim says:

In all this Semantic Web news, though, the proof of the pudding is in the eating. The benefit of the Semantic Web is that data may be re-used in ways unexpected by the original publisher. That is the value added. So when a Semantic Web start-up either feeds data to others who reuse it in interesting ways, or itself uses data produced by others, then we start to see the value of each bit increased through the network effect.

 

So if you are a VC funder or a journalist and some project is being sold to you as a Semantic Web project, ask how it gets extra re-use of data, by people who would not normally have access to it, or in ways for which it was not originally designed. Does it use standards? Is it available in RDF? Is there a SPARQL server?

Twine provides RDF and supports SPARQL (although while we are in beta we have not opened our SPARQL API yet, but we will...). At the same time Twine also protects privacy by only providing its data according to permissions. Apps can only get Twine data they permission to see such as their own data or their owner's or users's data, data that has been shared with them, or public data in Twine.

Twine is also designed to consume external Linked Data via it's APIs. Twine will be able to consume external RDF and OWL ontologies, as a means to enable other applications and users to extend its functionality and add new data to it.

Posted by cykaneys

My Visit to DERI -- World's Premier Semantic Web Research Institute

Earlier this month I had the opportunity to visit, and speak at, the Digital Enterprise Research Institute (DERI), located in Galway, Ireland. My hosts were Stefan Decker, the director of the lab, and John Breslin who is heading the SIOC project.

DERI has become the world's premier research institute for the Semantic Web. Everyone working in the field should know about them, and if you can, you should visit the lab to see what's happening there.

Part of the National University of Ireland, Galway. With over 100 researchers focused solely on the Semantic Web, and very significant financial backing, DERI has, to my knowledge, the highest concentration of Semantic Web expertise on the planet today. Needless to say, I was very impressed with what I saw there. Here is a brief synopsis of some of the projects that I was introduced to:

  • Semantic Web Search Engine (SWSE) and YARS, a massively scalable triplestore.  These projects are concerned with crawling and indexing the information on the Semantic Web so that end-users can find it. They have done good work on consolidating data and also on building a highly scalable triplestore architecture.
  • Sindice -- An API and search infrastructure for the Semantic Web. This project is focused on providing a rapid indexing API that apps can use to get their semantic content indexed, and that can also be used by apps to do semantic searches and retrieve semantic content from the rest of the Semantic Web. Sindice provides Web-scale semantic search capabilities to any semantic application or service.
  • SIOC -- Semantically Interlinked Online Communities. This is an ontology for linking and sharing data across online communities in an open manner, that is getting a lot of traction. SIOC is on its way to becoming a standard and may play a big role in enabling portability and interoperability of social Web data.
  • JeromeDL is developing technology for semantically enabled digital libraries. I was impressed with the powerful faceted navigation and search capabilities they demonstrated.
  • notitio.us. is a project for personal knowledge management of bookmarks and unstructured data.
  • SCOT, OpenTagging and Int.ere.st.  These projects are focused on making tags more interoperable, and for generating social networks and communities from tags. They provide a richer tag ontology and framework for representing, connecting and sharing tags across applications.
  • Semantic Web Services.  One of the big opportunities for the Semantic Web that is often overlooked by the media is Web services. Semantics can be used to describe Web services so they can find one another and connect, and even to compose and orchestrate transactions and other solutions across networks of Web services, using rules and reasoning capabilities. Think of this as dynamic semantic middleware, with reasoning built-in.
  • eLite. I was introduced to the eLite project, a large e-learning initiative that is applying the Semantic Web.
  • Nepomuk.  Nepomuk is a large effort supported by many big industry players. They are making a social semantic desktop and a set of developer tools and libraries for semantic applications that are being shipped in the Linux KDE distribution. This is a big step for the Semantic Web!
  • Semantic Reality. Last but not least, and perhaps one of the most eye-opening demos I saw at DERI, is the Semantic Reality project. They are using semantics to integrate sensors with the real world. They are creating an infrastructure that can scale to handle trillions of sensors eventually. Among other things I saw, you can ask things like "where are my keys?" and the system will search a network of sensors and show you a live image of your keys on the desk where you left them, and even give you a map showing the exact location. The service can also email you or phone you when things happen in the real world that you care about -- for example, if someone opens the door to your office, or a file cabinet, or your car, etc. Very groundbreaking research that could seed an entire new industry.

In summary, my visit to DERI was really eye-opening and impressive. I recommend that major organizations that want to really see the potential of the Semantic Web, and get involved on a research and development level, should consider a relationship with DERI -- they are clearly the leader in the space.

Posted by cykaneys

Associative Search and the Semantic Web: The Next Step Beyond Natural Language Search

 

Our present day search engines are a poor match for the way that our brains actually think and search for answers. Our brains search associatively along networks of relationships. We search for things that are related to things we know, and things that are related to those things. Our brains not only search along these networks, they sense when networks intersect, and that is how we find things. I call this associative search, because we search along networks of associations between things.

 

Human memory -- in other words, human search -- is associative. It works by "homing in" on what we are looking for, rather than finding exact matches. Compare this to the the keyword search that is so popular on the Web today and there are obvious differences. Keyword searching provides a very weak form of "homing in" -- by choosing our keywords carefully we can limit the set of things which match. But the problem is we can only find things which contain those literal keywords.

 

There is no actual use of associations in keyword search, it is just literal matching to keywords. Our brains on the other hand use a much more sophisticated form of "homing in" on answers. Instead of literal matches, our brains look for things things which are associatively connected to things we remember, in order to find what we are ultimately looking for.

 

For example, consider the case where you cannot remember someone's name. How do you remember it? Usually we start by trying to remember various facts about that person. By doing this our brains then start networking from those facts to other facts and finally to other memories that they intersect.  Ultimately through this process of "free association" or "associative memory" we home in on things which eventually trigger a memory of the person's name.

 

Both forms of search make use of the intersections of sets, but the associative search model is exponentially more powerful because for every additional search term in your query, an entire network of concepts, and relationships between them, is implied. One additional term can result in an entire network of related queries, and when you begin to intersect the different networks that result from multiple terms in the query, you quickly home in on only those results that make sense. In keyword search on the other hand, each additional search term only provides a linear benefit -- there is no exponential amplification using networks.

 

Keyword search is a very weak approximation of associative search because there really is no concept of a relationship at all. By entering keywords into a search engine like Google we are simulating an associative search, but without the real power of actual relationships between things to help us. Google does not know how various concepts are related and it doesn't take that into account when helping us find things. Instead, Google just looks for documents that contain exact matches to the terms we are looking for and weights them statistically. It makes some use of relationships between Web pages to rank the results, but it does not actually search along relationships to find new results.

 

Basically the problem today is that Google does not work the way our brains think. This difference creates an inefficiency for searchers: We have to do the work of translating our associative way of thinking into "keywordese" that is likely to return results we want. Often this requires a bit of trial and error and reiteration of our searches before we get result sets that match our needs.

 

A recently proposed solution to the problem of "keywordese" is natural language search (or NLP search), such as what is being proposed by companies like Powerset and Hakia. Natural language search engines are slightly closer to the way we actually think because they at least attempt to understand ordinary language instead of requiring keywords. You can ask a question and get answers to that question that make sense.

 

Natural language search engines are able to understand the language of a query and the language in the result documents in order to make a better match between the question and potential answers. But this is still not true associative search. Although these systems bear a closer resemblance to the way we think, they still do not actually leverage the power of networks -- they are still not as powerful as associative search.

 

A natural language search can understand the meaning of a query like "books about Harry Potter" and it knows this is not the same as "Books by Harry Potter." But ultimately what is happening is that a linguistic expression is being converted into a more sophisticated keyword search. The language in the query is being mapped to documents that contain text that answers a question, or to data objects that match the thing being asked for. This is certainly better than keyword search but it is still ultimately just a smarter form of literal matching. It is not really making use of associative search along networks of semantic relationships in the data (other than linguistic relationships between words in the query) or any sort of sophisticated reasoning.

 

By comparison, associative search doesn't merely understand the meaning of the query, it understands and can reason about relationships in the data. This is an important distinction.

 

An associative search returns documents that represent things that are related, via various forms of associations (semantic links), to the things in the query. An associative search looks through a network of associations for the things that are most connected to the items in the query. By specifying more specific starting points, the set of things which are connected to all those starting points is narrowed. Thus an associative search is an intersection of multiple networks. The items that are most strongly intersected are the results that are most likely to matter.

 

Associative search is a very different approach to search from keyword search (which merely looks for things with the keywords in them) and natural language search (which merely looks for things that contain content that matches the meaning of the question). It also happens to be more similar to how our brains actually think.

 

On its own, associative search represents an important advance in the way we search. But by adding some simple reasoning to an associative search it becomes even more powerful. Reasoning adds the ability to generalize or get more specific, and to weight various paths through the network of relationships in more sophisticated ways, such as based on logical relationships or inferences through the network.

 

A simple example of reasoning is transitivity -- for example, if A is a part of B and B is a part of C, then A is a part of C. If we know that the "part of" relationship is transitive, then whenever we see chains of "part of" links between things we can make transitive inferences. In an associative search these inferences are quite useful. For example, we can search for all the parts of a 747 jet. Using transitive reasoning along networks of relationships we can find all the parts, even those things that are "parts of parts." Similarly we could find "all products of Sony" including products of subsidiaries and business units of Sony. Transitive inferences across transitive links is just one type of reasoning; there are many other variations that are possible, which when combined together become even more useful.

 

Our current search tools -- whether they are keyword based or natural language based do not support true associative search, let alone reasoning. But we do see associative search starting to appear in a very different breed of application: social networks. A search in LinkedIn for example, is an associative search. Will social networks do an end-run around traditional search engines to provide the next-generation of search? It's quite possible. Facebook and LinkedIn are far better positioned than Google today for associative search. In fact, I would venture that this is how Facebook could give Google some serious competition. But they have to hurry if they are going to do this -- Google has clearly realized the power of "social search" and is rapidly moving to leverage it in their own search results.

 

Ultimately associative search is more than just social search however. To be really effective, associative search engines need to understand and leverage the full spectrum of relationships between things, not just social relationships. They need to see and understand more types of relationships between more types of things. In order to accomplish this, associative search engines need the Semantic Web.

 

The Semantic Web provides exactly what is needed to enable associative search, with reasoning, on the Web-at-large. Using RDF and OWL, content can be marked up with metadata that specifies not only its intended meaning and structure, but also the various kinds of semantic relationships it has to other content and to other concepts. In other words, these standards provide a way to add a new network of semantically defined associations to the data on the Web. For example a document about Microsoft can be linked to the concepts "Software Company," "Software Manufacturer," and "Redmond." It can also be linked to a data record that represents "Microsoft" and the properties that define it as a company. The "Microsoft" object can then link to companies that are "suppliers" and "customers" and "competitors" as well as to things which are connected as "products" or "services."

 

This rich network of relationships between things goes far beyond documents. It contains relationships to people, places, other organizations, products, events, services, etc. It's similar to a social network, but instead of just containing people and social relationships, it contains more types of things and relationships between them. This is really what the Semantic Web enables. One can imagine that as this new semantic data becomes visible on the Web (which is rapidly happening in fact), the power of search will be dramatically improved. Associative search is coming soon to a Web near you!

 

With that in mind, here is an example of how Semantic Web enabled associative search will work in the future.

 

PROBLEM: I am trying to remember name of the organizer of a conference I once attended.

 

WHAT I ALREADY  KNOW:

 

l       I know this person and have corresponded with them in the past.

l       The conference was related to government and the Internet.

l       It took place in a town near Big Sur, but I can't remember the name of the town.

l       The organizer of the conference once introduced me to a male celebrity, but I can't remember the celebrity's name.

l       I gave a talk at the Conference about Web 3.0.

l       My friend, Sue Smith, also spoke at the conference.

l       The conference I attended took place in the Spring, but I am not sure if it was last year or two years ago.

 

In the above example, I cannot remember the specific keywords that will help me generate a query to find the answer. Instead, I remember a number of relationships and generalizations about the answer. Present day search engines cannot see these relationships, and they have no ability to understand a generalization and look at things it contains.

 

The ability to intersect the sets formed by relationships and generalizations is a fundamental feature of human memory and search. But our present day tools don't have these capabilities. Thus we have to spend time translating our questions into keywordese, rather than just asking our questions in the actual language of human thought.

 

There are two ways to approach solving this.


The first way is to create artificial intelligence which, given a question in natural language English, can understand it and reason about the question as well as understand and reason about the information in the set of documents being searched, in order to intelligently arrive at candidate answers. This is computationally intensive, and very hard to program. This is why AI hasn't quite happened yet on this scale.

 

A perhaps easier approach is to use the Semantic Web. In the Semantic Web approach, metadata is embedded into content that describes the meaning of the content, it's various important properties, and its relationships to other concepts. On the basis of this metadata, the problem becomes much simpler to solve. Instead of doing high-level AI it becomes essentially a statistical search.

 

Now let's look at how using the Semantic Web could help us solve the above problem via an associative search:

 

Items are connected to more general or specific concepts by virtue of semantic linkages between concepts. For example, the conference I am looking for is related to the concepts "Government" and "Technology." If I can at least remember that then I can find conferences related to government and technology. Furthermore, since the concept "Policy" is a subset of government it may be related to that topic as well.

 

Likewise, things are connected to things that are "near" them via geographic links. Because the conference was near Big Sur it is in Northern California, along the coast. It is probably in a town that is geographically close, ror example Carmel-by-the-Sea is a town that is near the Big Sur area.

 

The organizer of the conference introduced me to a male celebrity. There are several celebrities in my social network. If the fact that I met certain people via introductions from other people was stored using semantic links, then this too would be searchable. For example, "find all celebrities I was introduced to by my connections" would be a solvable query. Similarly, "find people who introduced me to celebrities" would also be solvable.

 

The fact that I gave a talk at the conference could also be semantically represented on a data record describing the conference, as well as on my own profile. Thus there could exist a link such as "speaker at" which links me to various conferences I have spoken at. I could then get a list of all the conference I have spoken at. I could also look for all the conferences where both myself and Sue Smith were speakers.

 

Or, better yet, there could be a link called "Gave talk about" which links me to an instance describing each talk I have given. From such an instance there could then be "Gave talk at" links to all the events where I have given that talk. So I could look up my "Web 3.0" talk and then see all the conferences where I gave that talk.

 

Temporal relations can also be generalized and semantically represented. For example, the conference I am looking for took place in the spring. Therefore only look for conferences that took place in or near months that are considered to be in the spring season.

 

By intersecting the results of the above searches we narrow down very precisely to a set of people I might be looking for, or just to a single qualifying person.

 

For example the answer I was seeking for was that the organizer was named Robert Jones, and the conference was about Government and Technology Policy in Carmel-by-the-Sea last spring.

 

This result should be easily findable via associative search starting from the above set of things I remember. But if for some reason the answer is still not there, there is another capability which the brain uses that we need to add to our search engines:

 

1단계 : Perturbation, or what could be called "prospecting."

Perturbation = 섭동 : 수학에서 해가 알려진 다른 비슷한 문제와 비교하여 문제를 푸는 방법. 보통 이 방법으로 구한 해는 근사값일 뿐이다.

The query I entered is comprised of a question and a set of facts related to the answer I am seeking. But there is a possiblity that I asked the question incorrectly, or some of the facts I added were incorrect, or insufficient. Perturbation can correct for this by introducing variations into the question and the facts in order to explore the space of answers that are "near" them as well.

 

There are many ways to go about adding perturbation to the system -- for example, we can search more than one hop out from every link, or we can search for other types of relationships that are highly correlated with relationships we are asking for explicitly, or we can include results for things which are strongly connected to things that are found.

 

From a user-interface standpoint perturbation can be controlled with a simple "sliding lever" in the user interface for "Precision." If the user sets very high Precision as a requirement then there is no perturbation -- the results are exact matches to the query and facts. If there is low Precision as a requirement then there can be more perturbation, thus the results are fuzzy and may include things that are near what I asked for but not exactly what I specified, enabling me to discover things via relevant relationships that I could not even remember to mention as facts.

 

2단계 : Reasoner

 

Finally, using a reasoner, the results found by the above search can be analyzed such that those results which are most likely to be what I am looking for, given the facts I have included as constraints, are presented first. Reasoning becomes the ranking algorithm in the system, rather than something like Pagerank. The answers that actually make the most sense in the context of my question are delivered first.

 

The above illustration describes how searches that are powered by the Semantic Web will work, once this technology is widely adopted. This is how the brain works, and how our search engines should work as well. 

 

This is not a pipedream -- in fact it is already happening in research settings and in the government. Within 15 years, if not a lot sooner, we will see these capabilities emerge in consumer-grade search interfaces.

 

Posted by cykaneys

Semantic Web 관련기술



RDF

...시맨틱 웹에서는 RDF(Resource Description Framework)를 이용하여 컨텐츠에 의미를 표현한다. RDF는 메타데이터의 기술과 교환을 위한 프레임워크이며 시맨틱 웹의 핵심 요소라 할 수 있다. RDF는 다양한 메타데이터 사이의 의미적 연결을 위해 의미(semantics), 구조(structure) 및 구문에 대한 공통적인 규칙을 지원한다. 이러한 메커니즘을 통해 기계가 이해할 수 있는 정보 자원을 교환하는 메타데이터 사이의 상호운용 (interoperation)을 지원한다. RDF는 다양한 메타데이터의 의미를 정의하지 않고 메타데이터에 필요한 데이터 요소를 정의해 사용할 수 있게 만든다. RDF는 다음의 주요한 특성을 제공하기 위해 설계되었다.
  • 메타데이터의 상호운용성 지원
  • 기계가 이해할 수 있는 메타데이터의 의미 정의
  • 풀 텍스트(full-text) 검색보다 자원 탐색에서 향상된 정확성 실현


RDF

스키마

...RDF 데이터 모델 명세서는 정보 자원(resource)의 특성(property)들을 선언하고, 특성과 다른 자원 사이의 관계를 정의하기 위한 어떤 메커니즘도 제공하지 않는다. 이런 문제는 RDF 스키마 명세서에서 구체화한 RDF 스키마에 의해 해결할 수 있다. RDF 스키마는 자원의 특성을 기술하기 위해 사용될 수 있는 자원의 집합을 기술하고, 웹 자원을 기술하기 위해 이용된 메타데이터의 구조를 해당 애플리케이션에서 사용되는 특정한 어휘로 정의한다.

...RDF 스키마 명세서는 몇 가지의 기본적인 클래스와 특성들로 구성돼 있고, 주어진 도메인(domain)에 적용하기 위해 다른 도메인으로부터 확장될 수 있다. 클래스는 계층적인 방법으로 정렬되고, 특성의 이용은 클래스의 멤버에 의해 제약될 수 있다. (그림 1)은 클래스, 하위 클래스, 자원의 개념을 나타낸다. 클래스는 둥근 사각형으로 자원을 점으로 표시하고 있다. 화살표는 자원으로부터 화살표가 정의하는 클래스로 연결된 것이다.

...하위 클래스는 둥근 사각형(하위 클래스)으로서, 다른 클래스(상위 클래스)에 의해 완전히 싸여 있음을 보여주고 있다. 만약 자원이 클래스에 속하면, 포함된 클래스를 정의한 자원값은 상위 클래스에 대해 명시적(explicit) 또는 묵시적인(implicit) rdf:type 특성이 존재하게 된다. 접두사 rdf:와 rdfs:는 자원이 RDF 데이터 모델인지 RDF 스키마 명세서의 일부인지를 나타낸다.



OWL

...W3C에 의해 개발된 RDF와 RDF 스키마는 웹 자원의 메타데이터를 기술할 수 있는 표준이지만, 속성의 제약과 클래스의 상속 관계를 표현하는데 제한이 있었다. OWL은 웹에서 온톨로지를 기술하기 위해 RDF와 RDF 스키마보다 풍부한 표현력을 지원하기 위한 많은 특성들을 포함하고 있다. OWL은 미국 주도로 개발된 DAML과 유럽 공동체에 의해 개발된 OIL을 기반으로 확장된 언어이며, 두 언어를 통합한 DAML+OIL의 많은 특징을 계승하고 있다. DAML+OIL과 마찬가지로 OWL도 RDF 스키마의 상위 수준에서 어휘의 의미를 정의하고 있으며 RDF의 클래스와 속성을 이용한다. (그림 2)는 RDF/RDFS, DAML, OIL과 OWL 사이의 서브 클래스 관계를 보여주고 있다.

...OWL은 도메인에 따른 다양한 형태의 요구 항을 수용하기 위해 서로 다른 3개의 서브 언어, OWL Full, DL(Description Logic), Lite등을 정의하고 있다. OWL Full은 OWL이 지원하는 모든 기능을 포함하고 있는 반면 명세서를 지원하는 애플리케이션의 개발이 힘들고 사용자가 원하는 질의에 대한 빠르고 완벽한 답을 얻기 힘들다. OWL DL/Lite는 Full에 기술된 특정 속성에 제약이 있는 반면 애플리케이션의 개발과 언어의 사용에 용이함이 있다. 3개 언어의 특징은 다음과 같다.


OWL

후보


권고안

...최근 W3C는 웹 온톨로지 언어(OWL)를 후보 권고안으로 발표(2003년 8월 18일)하였다. 후보 권고안에는 OWL을 정의하는 6개의 후보 권고안 명세서가 포함되어 있다. 후보 권고안 명세서의 내용은 다음과 같다.


● Web Ontology Language (OWL): Overview
- 내 용 : 언어의 중요한 특징을 목록화하여 제공하는 간단한 소개
- http://www.w3.org/TR/owl-features/
● Web Ontology Language (OWL) Guide Version 1.0
- 내 용 : 사용법 소개
- http://www.w3.org/TR/owl-guide/
● OWL Web Ontology Language Reference
- 내 용 : OWL의 모델링 핵심 어휘 소개
- http://www.w3.org/TR/owl-ref/
● Web Ontology Language (OWL) Abstract Syntax and Semantics
- 내 용 : 언어의 형식적 표준 정의
- http://www.w3.org/TR/owl-semantics/
● Web Ontology Language (OWL) Test Cases
- 내 용 : 다양한 테스트 케이스
- http://www.w3.org/TR/owl-test/
● Web Ontology Language (OWL) Use Cases and Requirements
- 내 용 : 웹 온톨로지 언어의 쓰임새와 OWL의 요구사항 기술
- http://www.w3.org/TR/webont-req/

출처: http://www.giscampus.co.kr/webzine
Posted by cykaneys

[시맨틱웹] 2.5. RDF가 무엇인가요?

Saturday, July 23rd, 2005 at 10:16 pm

아래 글은 본래 시맨틱웹 시리즈 FAQ 10에 들어가지 않지만, RDF의 개념도 설명하지 않고 시리즈 다음 편인 “꼭 RDF를 사용해야 하나요? XML 으로도 충분해 보이는데”를 한다는 것이 여러모로 무리인 것 같아 가볍게 RDF 개념을 설명하고 넘어가고자 한다. 사실대로 이야기 하자면, 아래 글 역시 시맨틱웹 카페에 있는 글인데, 시맨틱웹 자체에 대해 그리 깊지 못하게 이해하고 있을 때 쓴 글이라 구멍 투성이. (다시 읽어봤는데, 다행히도 틀린 것은 없는 것 같다. ㅋㅋ)

———————————————————–

RDF 개요

세상을 바라보는 방법은 여러가지가 있겠지만 그중 하나는 모든 것을 관계성에 근거를 두고 바라보는 것이다. 즉, 두 객체(object)를 놓고 봤을 때, 두 객체의 관계를 중심으로 하여 객체들을 연결을 시키는 것이다. 또 그 두 객체중 하나는 다른 어떠한 객체와 관계를 형성하고 그 관계를 따라 연결이 된다. 이런 식으로 계속 어느 객체, 또는 사물에 관게성을 줌으로서 계속 연속의 연속을 따라 나아가며 커다란 관계성의 그물을 형성하면 그것들 자체가 하나의 세계관이 될 수가 있다. 예를 들어보는 것이 아마 이해하는데 훨씬 도움이 많이 될 것이다:

1. 세종대왕은 조선의 왕이었다.
2. 세종대왕은 한글의 창시자이다.
3. 한글은 대한민국의 표준어이다.
4. 대한민국의 수도는 서울이다.
5. 서울은 1988년도 올림픽의 주최도시였다.
……

1번의 예에서는 “세종대왕”과 “조선”이 “~의 왕이다”라는 관계를 맺고 있으며 2번에서는 “세종대왕”과 “한글”이 “~의 창시자이다”라는 관계를 맺고 있음을 알 수 있다. 사실 우리 삶에서도 관계성에 기초에서 상황을 기술하는 경우가 허다한데, 가장 흔한 예 중의 하나는 “내 친구의 여동생의 남자친구의 할머니의 스승님은 1940년대 가장 활발하던 독립군 중 준 하나이였다” 것과 비슷한 사람의 관게를 통한 연결이다. 이런 식으로 정보나 데이터를 나타내는 형태를 흔히 일컬어 데이터 모델이라고도 한다.

RDF (Resource Description Framework) 은 월드와이드상에 존재하는 리소스에 관한 정보를 위에서와 같이 관계성에 근거를 두고 나타내 주는 형식 또는 언어이다. 좀더 정확하게는 (:주어 :서술어(predicate) :목적어) 의 형식을 이루는데, 1번의 예를 보면 “세종대왕”은 주어, “조선”은 목적어, “~는 ~의 왕이다”는 서술어임을 알 수 있다. 때로는 ‘리소스, 속성 (property), 리소스’ 라고 대신 표현을 하며 이 하나를 통틀어 문장이라고 부르기도 한다. 그러면 웹에서는 어떤 것들이 더 구체적으로 RDF를 사용할 수 있는가?

1. 김태우 — RunsBlogAt –> http://twlog.net
2. 김태우 — IsAdministratorOf –> http://cafe.daum.net/semanticweb
3. 김태우 — IsInterestedIn –> http://en.wikipedia.org/wiki/Web_2.0
……

이같은 예들은 끝없이 들 수 있다. 이것이 바로 RDF의 강점이다. 웹상의 어느 리소스들이나 위와 같이 단순한 형식으로 표현이 가능하다는 것. 리소스나 관계의 정의들도 단순히 “김태우”라는 어떠한 인물 또는 객체에 국한되는 것이 아니라, URI 로 대체함으로서 표현범위에 사실상 무한한 자유를 준다. 즉, 이제는 웹상의 모든 정보를 컴퓨터가 처리할 수 있는 정형화된 형태로 나타날 수 있다는 것이다.

그렇다면 시맨틱웹에는 RDF가 왜 그리도 중요할까?

총 700쪽이 넘는 백과사전 한권을 샀다고 해보자. 그리고 책을 산 사람은 어떠한 특별한 정보를 찾고 싶어한다. 그런데 불행히도 이 책에는 색인이 존재하지도 않고 책의 구성 또한 주제별도 아니고 가나다순도 아니라고 해보자. 이 사전에서 원하는 정보를 찾는 단 한가지 방법은 사실상 책을 모두 훑어 보는 것이다. 이럴 경우에는 원하는 것을 찾는데 소요되는 시간뿐이 엄청날 뿐만 아니라 때로는 모두를 훑어본 후에도 원한는 자료를 놓쳐서 찾지 못할 경우가 있다. 그 사전 자체에 관한 정보인 색인과 쪽수와 주제별 구성등은 우리가 원한는 정보를 찾는데 훨씬 수월하게 해준다. 이런 의미에서 이런 것들을 메타데이터(Metadata: ‘데이터에 관한 데이터’라는 뜻) 라고 하는데, 메타데이터가 있다는 것은 곧 정보의 검색과 추출, 처리등을 훨씬 신속정확하게 할 수 있다는 것을 뜻한다. 우리가 흔히 접하는 메타데이터의 예는 전화번호부, 도서목록, 영화평 등이 있다. 메타데이터에 관해서는 2장에서 더 자세히 공부하기로 한다.

RDF는 웹의 리소스에 관한 메타데이터를 표현할 수 있게 해주는 언어이다. 이제는 웹페이지내에 존재하는 모든 내용을 읽고 맞는 내용을 찾으려고 할 필요없이 (이것이 바로 현재 검색엔진들의 작동방식) 각자 페이지에 관한 요약 또는 필요점만 보고 정보를 찾아낼 수 있는 것이다. 그리하여 웹상의 모든 문서와 리소스에 관한 자료들을 컴퓨터들이 처리할 수 있는 일관된 형식으로 나타내고 결국 이로 인해서 시맨틱웹이 가능해지는 것이다. 이미 RDF는 널리 상용화가 되기 시작했으며 이는 모질라 브라우저에서 내부 데이터구조를 나타나는데 사용되고 있으며, 뉴스 사이트에서 많이 사용되는 RSS 1.0, 사람의 프로필과 일촌관계를 나타나는 FOAF에서 찾아볼 수 있다.

RDF를 이해한다면 시맨틱웹은 한 반 정도는 이해한다고 할 수 있다. 물론 이세상이 그렇게 간단하지만은 않은 것처럼, RDF도 좀더 많은 복잡한 기능을 요구하는 RDF 스키마와 온톨로지를 필요로 하게 된다. 그렇지만 시맨틱웹의 기초를 RDF와 같은 표준으로 성공적으로 잡았다는 사실 자체로 이미 W3C은 시맨틱웹의 현실화를 좀더 우리 앞에 바짝 이끌어 왔다고 할 수 있다. RDF가 시맨틱웹을 이해하는데 중요한 만큼 이 강좌를 좀더 복습하고 아래에 있는 링크들에서 RDF에 관한 더 자세한 공부도 많이 하기를 바란다. RDF에 관한 자세한 내용은 4장에서 배우기로 한다.

Posted by cykaneys
Creative Commons License

프로젝트의 특성상 한참을 프레임워크에 매달려오다가, 정말 최근에 들어서야 시선이 넓어지기 시작했다. 그동안 웹 2.0이니 뭐니 하는 그런 추세들을 모르는 척 한 건 아니지만, 뭔가 절실하고 구체적으로 그림이 그려질랑말랑하는, 그런 말랑말랑한 생각들이 이제야 들기 시작한 것이다. 말랑말랑, 어감이 좋은데?

그런고로, 생각을 정리하는 차원에서 3부에 걸쳐 이런 저런 이야기를 풀어볼까 한다. 어렵게 생각하면 어렵고, 쉽게 생각하면 쉬우니까 글이 길어도 부담 갖지 말고 그냥 쭈욱 읽어 내려가자. 혹시나 문서 끝까지 읽은 사람이 있으면 질문을 던져도 좋다. 피터지게 공부해서 답해줄 생각이다. (나도 잘 모르거든, 그래서 공부해야 답할 수 있다) 잘못된 부분에 대한 지적은 다소 부드러운 어조로 해줬으면 좋겠다. (나는 섬세하니까)


#1 온톨로지(Ontology)



아주 오래전부터 온톨로지라는 영역이 연구되어왔다. 존재론 쯤으로 해석하면 이건 뭐 돈 많고 시간이 남아돌던 부르조아 시대까지 거슬러 올라가겠지만, 컴퓨터 영역으로 한정하면 그렇게까지 거슬러 올라갈 필요는 없을 듯 싶다. 1913년, Webster's Revised Unabridged Dictionary는 온톨로지를 다음과 같이 정의했다.

That department of the science of metaphysics which investigates and explains the nature and essential properties and relations of all beings, as such, or the principles and causes of being.

철학적으로 접근한 이러한 정의는 이후 knowledge engineering, natural-language processing과 같은 인공지능 분야에서 채용하였고 1990년 후반에 들어서면서 intelligent information integration, information retrieval on the Internet, knowledge management 등으로 그 영역이 확장되었다.

인공지능 분야에서 온톨로지는 지식의 공유와 재사용을 목적으로 만들어진다. 이 분야에서 온톨로지는 여러 사람에 의해 다양하게 정의되었는데, 특히 Gruber는 온톨로지를 다음과 같이 소개했다.

An ontology is a formal explicit specification of a shared conceptualization.

온톨로지는 공유되는 개념에 대한 형식적이고 명시적인 명세이다. 공유를 목적으로 하기 때문에 그것은 밖으로 도출(explicit)되어야 하고, 그것을 알아보려면 어떤 형식(formal)을 갖추어야 한다. 그러한 명세(specification)를 온톨로지라고 부른다. 다음은 간단한 온톨로지의 예이다.



온톨로지는 스키마와 인스턴스로 구분해서 생각해 볼 수 있다. 스키마는 위의 그림에서 동그라미로 정의된 어떤 '체계'를 정의한다. 인스턴스는 이렇게 정의된 체계 내에서 실제로 존재하는 '무엇'을 나타낸다. 위의 그림에서 네모로 그려진 [Peter]는 Peter라는 사람을 정의하고 있다. [Peter]는 단순한 데이터에 불과하다. 그러나 이것이 스키마와 결합되면 Peter는 'PhD-Student이고, Student이면서 Reseacher이고, Person이다'라는 정보를 추론할 수 있다. 단지 Peter에 대해 서술한 데이터로부터 (그 자체만으로는 고작 Peter의 나이나 주소 쯤 적혀있었을텐데) 스키마를 통해 명시적으로 서술하지 않은 정보를 얻어냈다. 이것을 추론(inference)이라고 한다.

그래, 그래서 어쩌라고?

좋은 질문이다. 수많은 어플리케이션은 자체적으로 데이터를 관리한다. 데이터베이스를 이용하든, 파일을 이용하든, 메모리를 이용하든, 어떤 방법으로 간에 그것들은 자체적으로 데이터를 관리한다. 문제는 어플리케이션들이 자체적으로 관리하는 데이터가 상호 호환성이 전혀 없다는 것이다. 엔터프라이즈 환경에서 규모가 꽤 큰 쇼핑몰 두 곳을 통합하려할 때, 상호간의 호환성이 전혀 없기에 개발자는 아주 미친듯이 둘 사이를 이어주려고 막코딩을 하거나 데이터베이스를 다시 설계해서 두 곳의 데이터를 통합하려 들 것이다. 어느 세월에...

만약 두 어플리케이션이 (사람)이라는 개념을 정의하고 그에 대한 인스턴스로 고객을 관리했다면 어떨까? 분명 A 쇼핑몰과 B 쇼핑몰은 (사람)이라는 개념을 다르게 표현할 수도 있다. 그래도 같은 개념을 정의한 것이므로 두 개념간의 관계를 정의하면 상호 데이터는 호환이 가능해진다. 예를 들어보자.

쇼핑몰 A는 (사람)이라는 개념을 http://A.com#Person이라고 정의한다. Person은 속성으로 name을 갖는다. 반면 쇼핑몰 B는 (사람)이라는 개념을 http://B.com#Human이라고 정의한다. Human은 속성으로 name과 age를 갖는다.

두 쇼핑몰의 데이터를 통합하려하는데 Person과 Human이 동일하다는 것을 알았다. 일부 속성의 누락은 발생하지만 같은 개념을 표현하고 있다. 따라서 다음과 같은 스키마를 추가할 수 있다.


자 이제 A 쇼핑몰의 어플리케이션이 Person을 검색하면 기존의 Person 데이터 뿐만 아니라 추론을 통해 Human 데이터를 얻을 수 있다.

애초에 두 쇼핑몰이 잘 정의된 (사람)이라는 개념을 채용했다면 통합은 훨씬 수월했을 것이다. 그러나 그렇지 않은 경우라도 두 개념 사이를 잇는 스키마를 추가하는 것으로 데이터의 통합을 이룰 수 있다. 예를 하나 더 들어보자.

얼토당토 않게도, 이 기업은 학원 C를 인수했다. 학원 C는 학생과 강사의 데이터를 정의하는데 (학생)이라는 개념은 http://C.com#Student 로, (강사)라는 개념은 http://C.com#Teacher 로 정의했다. 가만히 보니 학생과 강사는 모두 사람이다. 따라서 다음과 같은 스키마를 추가할 수 있