다시 보는 시맨틱 웹 그리고 시맨틱 기술 Ⅱ

1. 지식의 표현

1부에서 우리는 데이터 웹으로서의 시맨틱 웹에 대해 얘기 나누었다. RDF는 웹에서 데이터를 표현하고 교환하기 위한 표준 모델이다. 모두 알다시피 RDF는 두 개체를 링크로 연결하는 구조로 되어있고, 우리는 이를 트리플(triple)이라 부른다. URI에 기반한 트리플들의 연결은 웹을 의미 메타데이터로 구성된 방대한 그래프 구조로 만들어 준다. 재미있게도 트리플 표현의 역사는 기원전 360년경, 아리스토텔레스 시대까지 올라간다.

아리스토텔레스가 로직(logic, λογικ？？)이라는 용어를 처음 사용한 것으로 알려져 있다. 그는 인간의 사고와 인지 체계에 대해 연구하였으며, 특히 “추론” - 인간이 이미 알고 있는 것으로부터 어떻게 새로운 결론을 도출해 낼 수 있는지에 대한 학문을 정립 하였다. 아리스토텔레스는 지식의 표현과 추론 과정을 설명하기 위해 분류 체계와 서술어(predicate)에 기반한 술어논리(predicate logic)를 제안하였다. 시맨틱 웹의 RDF 트리플 및 웹 온톨로지는 모두 고전적 지식 표현 및 논리 체계인 술어 논리, 특히 1차 논리(first order logic)에 기반하고 있다.

전통적 논리학이 인간의 사고와 인지체계, 지식에 대해 얘기해 왔다면, 이제는 컴퓨터를 통해 어떻게 지식을 표현, 공유하고 기존의 방대한 데이터에서 새로운 데이터를 “추론”해 낼 수 있는지에 대해 관심을 가지게 되었다. 시맨틱 웹이 단순 데이터의 웹이 아닌, 지식의 웹으로 불려지는 것도 그 비전이 인류 지식 표현과 교환이 가능한 웹을 구현하겠다는 것과 무관하지 않을 것이다. 데이터를 RDF 형태의 그래프로 구성했다고 시맨틱 데이터가 되는 것이 아니다. “시맨틱”이란 용어가 설명되려면, 의미 표현이 가능하며 컴퓨터가 읽을 수 있는 스키마가 존재해야만 한다. 스키마(RDFS, OWL 등)는 분류체계를 포함한 최소한의 논리체계를 갖추고, 컴퓨터가 <의미> 모호성을 해소할 수 있도록 도와야 한다. 이제, 지식 표현을 위한 다양한 방법을 살펴보고, 시맨틱 웹을 위한 지식 표현 체계를 이해해 보도록 하자.

인류는 오랜 역사 속에서 지식을 표현, 공유하기 위해 많은 노력을 기울였다. 데이터와 정보의 생성 유통이 폭발적으로 증가됨에 따라, 인간이 수작업으로 그 안에 숨겨진 지식을 모두 처리하기는 점점 더 불가능해 지고 있다. 어떤 형태던 컴퓨터의 역할이 기대되고 있는 것이다. 특히, 웹이 인류 지식의 보고가 됨이 따라, 웹에 있는 지식을 컴퓨터에 의해 생산적으로 분석, 발견, 공유, 활용하기 위한 방법을 찾아 내는 것이 점점 더 중요해 지고 있다. 사람만이 이해하는 웹이 아니라, 컴퓨터가 읽고 처리할 수 있는 웹을 구현하기 위해서는 기계가 읽고 처리할 수 있는 명시적(explicit) 지식 표현 체계가 필요한 것이다. 표 1은 다양한 지식 표현 체계를 보이고 있다. 위쪽이 인간에게 익숙한 지식 표현 체계이며, 아래 쪽으로 내려갈수록 기계가 처리하기 유리한 표현 체계가 되겠다.



예를 들어보자, 다음과 같이 자연어로 특정 지식을 기술할 수 있다.

“기업에 종사하는 종업원은 사람들이고, 기업과 종업원은 모두 법적 존재이다. 기업은 직원들을 위해 여행 예약을 할 수 있다. 여행은 한국 내 도시, 혹 미국의 도시를 오고 가는 비행기 혹은 기차를 통해 가능하다. 기업들과 출장지는 도시에 위치하고 있다. 솔트룩스는 홍길동을 위해 서울과 뉴욕 왕복 항공편인 OZ510을 예약하였다.”

이러한 지식은 규칙으로 표현될 수 있으며, 그 안에 숨겨진 지식을 발견하거나 새로운 규칙을 추가함으로 지식을 확장할 수 있다. 기계는 이러한 규칙과 입력된 사실 데이터에 의해 새로운 데이터를 생성해 낼 수 있으며, 이를 우리는 규칙 기반한 추론이라 부른다.

(규칙) 만약 누군가가 날고 있다면, 여행중인 것이다.
(규칙) 만약 누군가의 여행이 한 회사로부터 예약되었다면, 그는 그 회사의 종업원이다.
(규칙 추가) 만약 동일 국가의 근거리 여행이라면, 종업원은 기차를 이용해야 한다.
(추론) 비행 예약이 되어 있는 홍길동은 솔트룩스의 종업원이다
(추론) OZ510은 미국과 한국을 오가는 비행편이다.

그림 1은 동일한 지식을 시맨틱 네트워크로 표현한 것이다. 위에 자연어로 기술된 거의 모든 지식을 온전히 표현해 낼 수 있다. 만약 이 네트워크에 “솔트룩스의 종업원들이 출장간 모든 도시의 이름을 찾아라” 와 같이 질의(query)를 한다면, 시스템은 추론을 통해 {뉴욕, …}를 찾아낼 것이다.

시맨틱 웹에서의 지식 표현은 논리(logic), 규칙(rule), 프레임(frame) 그리고 시맨틱 네트워크(semantic network) 등의 개념을 “웹 온톨로지”를 통해 모두 포괄하고 있다. 본 기고에서는 이미 잘 알려진 RDF, RDFS, OWL, RIF 등에 대해 설명하진 않는다. 단, 보다 실용적인 지식표현과 추론을 위해 개정된 OWL2에 대해서만 2장에서 잠시 살펴 본다.

모든 지식 표현 방법들은 각각의 특징과 상이한 표현력(expressivity) 수준을 가지고 있다. 보다 복잡한 지식 표현과 강력한 추론을 위해서는 이를 수용할 수 있는 표현 방법이 제공 되야 한다. 그림 2는 컴퓨터가 처리할 수 있는 지식 표현 수준과 추론 능력 관계를 설명하고 있다. 일반적으로 RDFS 수준 이상이 되어야 의미적 데이터 상호운영이 가능한 것으로 얘기한다. 현재는 컴퓨터에 의해 OWL-DL 수준의 지식 표현과 추론이 가능하다. 사실, 상용화 관점에서는 OWL-DL도 매우 버겁다고 할 수 있으며, 이는 OWL 2가 제안된 배경이 된다.

2. 온톨로지와 온톨로지 모델링

자, 이제 가장 대표적인 지식표현 체계인 온톨로지에 대해 얘기해 보자. 온톨로지는 논리적 지식표현 체계로서, 표 1에서 거론된 논리, 규칙, 프레임 그리고 시맨틱 네트워크 등의 개념을 모두 통합했다고 할 수 있다. (규칙을 온톨로지의 일부로 볼 수 있는가는 학자마다 관점이 다르다.) 그림 3을 보자, (a)의 시맨틱 네트워크는 지식을 구성하는 개념을 관계로 연결하고 있다. 여기에 프로퍼티(혹은 슬롯/slot)를 추가하면 (b)와 같이 된다. 마지막으로, 논리적 제약조건을 추가해서 (c)와 같이 만들면, 온전한 온톨로지 모양을 갖추게 된다. 물론, 여기에 규칙이 결합될 수 있다.

관점에 따라 다를 수 있으나, 1차 논리를 기준으로 했을 때 온톨로지의 구성 요소를 크게 여섯 가지로 나누어 볼 수 있다. (1) 개념(concept) 혹은 클래스(class), (2) 인스턴스(instance) 혹은 인디비주얼(individual), (3) 관계(relation), (4) 펑션(Function), (5)공리(axiom) 그리고 (6) 규칙(rule) 이다. 전술한 것처럼 규칙을 온톨로지 범위로 볼지는 학자마다 다른 관점을 가지고 있다. 관계는 둘 이상의 개체 개체가 단 하나의 다른 개체와 유일한 관계를 맺는다면 이를 펑션이라 부른다. 홍길동의 ‘친 엄마’는 옥영향(소설 상에서는 춘섬) 한 명이고, 이 경우 ‘친 엄마’ 관계는 펑션이 되겠다. 공리는 쉽게 말해 그 의미가 사전 결정되어 예약되어 있는 특별한 관계로, 증명이 필요 없는 언제나 사실인 관계이다. 공리로 이미 규정된 관계 이름을 임의로 다른 의미로 사용해서는 안 된다. 이러한 온톨로지의 개념을 컴퓨터가 처리하려면, 그림 3과 같은 도식 형태가 아니라, 기계가 읽고 처리할 수 있는 언어로 기술 되어야만 할 것이다. 온톨로지 표현 언어는 표 2와 같이 매우 다양하다. KIF, OWL을 포함해 대부분 1차 논리에 기반하고 있으며, 추론 시 결정 가능성(decidable)을 보장하는 서술논리(Description Logic; DL) 기반의 언어들이 대세를 이루고 있다. 특별히 F-Logic(Frame Logic)의 경우 혼 로직(Horn Long) 기반의 온톨로지 언어로, DL과는 DLP(Description Logic Programming) 수준에서 호환을 유지할 수 있으며, 혼 절(Horn Clause) 형태의 규칙을 동시 사용 가능하다. UML의 경우도 표현력이 많이 부족하지만, 온톨로지 모델링 언어로 사용 가능하며, 다양한 도구를 통해 생산성을 높일 수 있는 장점이 있다. UML을 온톨로지 언어로 사용하면, 공리(Axiom)가 정의되어 있지 않으므로, RDFS 혹은 OWL 2 QL 수준의 추론만 가능하다.

이제, 시맨틱 웹에 좀더 집중을 해 보자. 시맨틱 웹에서의 지식표현은 RDFS와 OWL을 통해 가능하다. 물론 스키마 없이, RDF 트리플 데이터 만으로도 다양한 응용이 가능하겠지만, 추론을 차지하고라도, 의미 모호성 해소와 쓸모 있는 질의를 위해서는 가장 단순한 형태라도 스키마가 반드시 존재해야 한다. 본 기고에서는 RDFS와 OWL 문법 등의 설명은 피하고, 웹 온톨로지 구축 관점에서의 그 특징과 새로 제정된 OWL 2에 대한 개념을 소개해 본다. 문법 관련해서는 많은 참고 자료가 있으므로, 각자가 공부해 보길 바란다[1,2,3]. 우선, OWL DL의 표현력에 대해 잠시 살펴 보기로 하자. 한때는 DL 표현력으로는 부족함이 크기 때문에 OWL Full로 온톨로지를 작성해야 한다는 등, 이해 부족의 시절이 있다. 사실, OWL DL의 표현력이 매우 강력하기 때문에 이를 제대로 쓴다는 것 조차 무척이나 어려운 것이었다. OWL Lite 수준도 때로는 매우 복잡하고 충분할 수 있다. OWL DL은 계산학적 완전성(computational completeness)과 결정 가능성(decidability)이 유지되는 최대의 표현력을 제공한다. 완전성은 모든 결론이 계산될 수 있다는 것이고, 결정 가능성은 모든 계산이 유한한 시간 내에 끝날 수 있다는 것이다. 그림 4를 보자, OWL DL이라고 모두 같은 것이 아니다, DL을 사용하더라도 다양한 표현력 수준을 결정할 수 있고, 이는 대용량 처리(scalability)와 추론 속도에 매우 큰 영향을 미친다. 현재의 DL 추론 엔진은 SHIQO(D)의 모든 표현과 OWL DL 공리에 대한 추론 기능을 제공한다. 그러나, 1억 트리플 이상의 대용량 처리, 0.1초 미만의 실시간 추론 등, 실제 상용적 활용이 가능한 표현 수준은 RDFS++, OWL Horst, OWL2 QL 정도라 하겠다.

활용도가 높고, 더 잘 작동하는 온톨로지를 만들기 위해서는 신경 써야 할 것이 많다. 특히, 효용성 높은 온톨로지를 구축하기 위해서는 클래스 생성자와 공리에 대해 익숙해 질 필요가 있다. 그림 5의 OWL DL 클래스 생성자들을 살펴보자. 의도 대로 작동되고 빠른 추론이 가능한 온톨로지 구축을 위해서는 클래스를 생성할 때, 꼼꼼히 논리적 제약 조건들을 기술하는 것이 중요하다. 2.4절에서 조금 더 자세히 살펴보겠지만, 제약 조건들을 구체적으로 설정하지 않으면, 추론 시 엉뚱한 결론에 도달할 수 있다. OWL 온톨로지를 구축할 때 흔히 하는 실수가 allValueFrom과 someValueFrom을 혼돈하는 것이다. allValueFrom이 적용되면 클래스의 모든 데이터가 특정 제약 조건을 만족해야 하는데, 좀처럼 그런 경우는 많지 않다. 다시 얘기해 allValueFrom의 제약조건은 신중히 사용해야 한다는 것이다. 공리는 추론 속도에 큰 영향을 준다. 추론 품질을 높이기 위해서는 많은 공리를 적용하는 것이 좋지만, equivalentClass/Property, sameIndividualAs, transitiveProperty 등의 공리는 추론 속도를 현격히 떨어뜨릴 수 있음을 이해하고 선별해서 사용해야 한다. 또한, 엉뚱한 추론 결과를 얻지 않으려면, disjointWith의 용도를 명확히 이해해야 한다. 2.4절에서 실제 예와 함께 설명하겠다.

1999년 시맨틱 웹 표준화 작업이 시작되었고, 2004년 드디어 RDF/S와 OWL의 첫 표준(recommendation)이 발표된다. 그 이후 많은 그룹에서 OWL 표준에 기반한 상용 기술을 개발하면서 여러 기술적 문제를 발견하게 된다. 가장 큰 문제는 대용량 처리와 상이한 응용 분야에 대한 최적화 문제였고, 특히 OWL DL의 경우 종종 다항 시간에 답을 내지 못하는 문제가 존재했다. 이러한 산업계의 요구사항을 수용하기 위해 2009년 10월에 OWL 2 표준이 제정되었다[4]. OWL 2에서는 다음과 같이 세가지 OWL 서브셋을 재정의함으로 다항 시간[5] 내에서 추론이 가능하도록 하였다.

- OWL 2 EL : 클래스 혹은 속성(property)가 대단히 많이 필요한 응용을 위해 적합한 프로파일(버전)이다. OWL 2 EL에서 제시된 제약 조건과 공리만을 사용한다면, 상당히 많은 수의 클래스와 속성으로 구성된 온톨로지에 대해서도 빠른 시간(다항 시간) 내에 결정 가능한 추론이 가능하다.
- OWL 2 QL : 인스턴스가 대단히 많은 응용에 적합한 프로파일이다. A-Box 추론 성능이 중요한 응용에서는 권고 된다. OWL 2 QL은 대용량 데이터(facts)에 대한 질의 시스템을 만드는데 적합하며, 기존의 RDB와 결합해 사용 가능한 장점을 가진다. OWL 2 QL 질의는 모두 SQL로 변환 가능하며, 표현력에 제약이 있는 단점이 있다.
- OWL 2 RL : 상대적으로 적은 표현력 손실과 대용량 처리가 동시 필요하다면 OWL 2 RL 사용이 권고 된다. OWL 2 RL은 가능한 표현력 손실을 줄이면서 다항 시간 내에 답을 얻을 수 있도록 설계되었다. 또한, OWL 2 RL은 온톨로지의 일관성 점검(consistency check)과 포함관계(subsumption) 추론이 가능하면서 동시에 규칙 기반 추론을 적용할 수 있는 장점이 있다.
기존 OWL DL과 마찬가지로, OWL 2의 각 프로파일의 적합한 사용을 위해서는 클래스 생성자 및 제약조건과 공리에 대해 충분히 이해할 필요가 있다. 보다 상세한 내용은 OWL 2 Web Ontology Language Profiles 문서[4]를 참고하기 바란다.

막상 특정 도메인에 대해 온톨로지를 처음 구축하려고 한다면, 어디서부터 어떻게 시작할지 막막함을 경험하게 된다. 구축될 온톨로지에 문제는 없는지, 적용 범위는 어떤 수준까지 해야 하는지, 확장성은 있을지 등 수 많은 질문을 하게 된다. 온톨로지 모델링은 매우 지적인 작업이므로, 그 품질과 생 되는데, 그 격차를 줄일 방법을 찾아야만 한다. 온톨로지 구축 생산성과 관리 가능한 품질 달성을고, 이에 기반한 온톨로지 모델링을 수행하게 된다. 대표적인 온톨로지 구축 방법론을 살펴보도록 하자.

그림 6은 프로테제(prot？g？)를 만든 Stanford 대학 팀에서 제시, 가장 기본적으로 사용되는 온톨로지 구축 방법론 이다. (소위 ontology101 방법론이라고도 부른다.) 실제 구축 방법론은 각 단위 프로세스를 반복적으로 적용을 한다.

온톨로지 구축의 첫 작업은 적용 범위와 응용 사례를 결정하는 것이다. 온톨로지가 지식 표현할 도메인은 무엇인지, 그 응용 소프트웨어는 무엇이 될지, 온톨로지가 어떤 질문에 대해 답을 주어야 할지를 결정한다. 그림 7처럼 OntoKnowledge(OTK) 방법론[6]에서 사용하는 ORSD(Ontology Requirements Specification Document)와 CQ(Competency Questions)를 활용하는 것도 좋을 것이다.

필자들이 매번 뼈저리게 느끼는 것은, 활용 어플리케이션과 시나리오를 초기에 명확히 하면 할수록 더 좋은 온톨로지를 더 적은 비용으로 만들 수 있다는 것이다. 특정 응용이 고려되지 않은 범용 온톨로지 구축은 가능하면 피해야 한다. 온톨로지 구축에 있어서 CQ 단계는 온톨로지의 역할, 범위뿐 아니라, 핵심 컨셉과 관계를 추출할 수 있는 가장 중요한 도구이기도 하다.

두 번째 단계는 재활용할 수 있는 자원을 수집하는 것이다. Swoogle[7]이나 솔트룩스의 COMET [8]과 같은 온톨로지 라이브러리를 통해 적합한 온톨로지를 검색, 수정해 활용하거나, LOD, IEEE, CYC 등에서 공개된 온톨로지들을 참조함으로 생산성을 향상시킬 수 있다. 세 번째 단계는 클래스 혹은 속성(property)의 후보가 될 용어들을 수집해 열거하고, 그들을 군집해 보는 것이다. OTK의 경우, 각 군집에서 핵심 용어를 선정해 CQ를 작성하는데 재활용 함으로 middle-out 형태의 방법론이 적용되었다. 네 번째 단계에서는 클래스와 그들의 텍사노미 관계를 정의한다. Top-down 및 bottom-up 형태로 텍사노미 구성을 하게 되는데, 각각의 장단점이 있다. Top-down의 경우 잘 정리된 온톨로지 구조를 가지게 되지만, 작성자의 경험에 의존되거나 적용 범위가 제한적일 수 있고, bottom-up의 경우 온톨로지 구조가 너무 복잡해 지거나, 일관성을 잃을 수 있다. CQ를 중심으로 한 middle-out 방식이 역시 대안이 될 수 있다.

클래스와 텍사노미가 정의되면, 각 클래스에 대한 속성을 정의하고, 제약 조건을 기술함으로 온톨로지 스키마의 골격 구성이 완료된다. 앞에서 강조한 바와 같이 클래스 생성을 위한 제약 조건과 공리의 구성은 온톨로지의 품질과 추론 성능에 직접 영향을 주게 된다. 마지막으로 실 데이터로부터 인스턴스를 생성해 온톨로지의 유용성과 범위를 확인하고, 문제가 발견되면 다시 앞 단계로 돌아가 문제를 보완하게 된다. 온톨로지 구축은 ER 모델에 기반한 DB 스키마 설계보다 무척이나 어렵고 복잡한 과정을 거치게 된다. 최근에는 생산성 향상과 품질 관리가 용이한 다양한 모델링 툴들이 제공되고 있으니, 이를 충분히 활용해야 한다. 기본 방법론 외에 SENSUS 방법론, Cyc 방법론 등 각 응용 도메인 마다 매우 다양한 방법론들이 이미 개발되었으므로 적합한 방법론을 찾아 응용하는 것도 좋겠다.

지식 표현, 추론, 온톨로지와 같은 용어들은 인공지능(AI) 분야에서 일찌감치 연구되던 주제이다. 이 때문에, 시맨틱 웹과 인공지능 관계에 대한 많은 혼란과 논쟁들이 있었다. 특히, 30년 전 인공지능 연구가 성공적이지 못했다 생각하는 사람들은 시맨틱 웹도 실패할 것이라 얘기해 왔다. LOD를 포함해 시맨틱 웹 관련한 기술 발전과 상용화 진척이 이러한 우려를 충분히 불식시킬 수 있다 믿지만, 예전 AI 접근법과 시맨틱 웹에서의 접근법 차이를 이해하는 것도 중요할 것 같다.

？ 산업 표준 언어 존재 : 국제 산업 표준 기구(W3C)에서 표준 지식 표현 언어를 정의
？ 데이터 우선 주의 (RDF) : 이론 보다는 데이터 중심의 실체적 접근
？ 트리플이 URI로 기술 : 웹에 적용하기 위해 모든 데이터는 URI에 기반
？ 결정 가능성(decidable) 보장 : OWL DL 및 OWL 2는 결정 가능성 및 대용량 처리 보장
？ 열린 계 가정 (open world assumption) : RDB, 프롤로그 등, 기존 시스템 과의 근본적 차이

이러한 여러 차이점들은 시맨틱 웹 접근과 과거 AI 접근과의 차별성을 만들어 낸다. 팀 버너스-리는 시맨틱 웹과 AI가 분명 구별되는 상호 보완적 관계임을 깔끔히 정리한 바 있다[9]. 이 중에서 온톨로지 설계 관련해서는 “열린 계 가정(OWA)”을 이해하는 것은 상당히 중요하다. 닫힌 계 가정(CWA)에 기반한 DB 혹은 프롤로그 같은 시스템은 그렇다(Yes) 혹은 아니다(No)로 답을 하는데 반해, 시맨틱 웹에서는 그렇다(Yes) 혹은 모른다(Unknown)로 답을 한다. 예를 들어 지식베이스에 “홍길동은 조선 사람이다.”라는 명제가 유일하게 저장되어 있다고 하자. “장금이는 조선 사람인가” 라는 질의에 대해 CWA 시스템은 ‘아니다’ 라고 대답한다. 반면에 OWA 시스템은 ‘모른다’ 라고 대답하는 것이다. 시맨틱 웹이 OWA에 기반하기 때문에 온톨로지 설계에서도 주의하여야 한다. 특히, 가능하다면 disjointWith 공리를 꼼꼼히 써 주는 것이 좋다. 추론 품질과 속도를 모두 높여줄 수 있다. 예를 들어, ‘사람’ 클래스가 있고, ‘개’ 클래스가 있다 하자, 두 클래스를 disjoint하지 않으면, 시스템은 기본적으로 ‘사람’이면서 동시에 ‘개’인 존재가 있을 수 있다라고 가정하게 된다. 남자이면서 동시에 여자인 존재를 인정하지 않겠다고 하면, 두 클래스를 반드시 disjoint하는 것이 바람직하다.

또한, 시맨틱 웹이 OWA에 기반하기 때문에, 제약조건을 작성할 때도 주의를 기울일 필요가 있다. 그 유명한 피자 온톨로지로 예를 들어보자. 마가리타 피자는 토마토와 모짜렐라 치즈 토핑만을 가지고 있다고 한다. 마가리타 피자 클래스에 제약조건을 작성해 보자.

Class( MargheritaPizza
Pizza
restriction( hasTopping someValuesFrom(TomatoTopping) )
restriction( hasTopping someValuesFrom(MozzarellaTopping) ) )

그럴듯해 보이지만, 위의 제약조건은 오류가 있다. 왜냐하면, 토마토와 모짜렐라 토핑 외에 다른 것들이 올라간 것도 마가리타 피자라고 추론해 버리기 때문이다. 올바른 제약 조건은 다음과 같다.

Class( MargheritaPizza
Pizza
restriction( hasTopping someValuesFrom(TomatoTopping) )
restriction( hasTopping someValuesFrom(MozzarellaTopping) )
restriction( hasTopping allValuesFrom(TomatoTopping or MozzarellaTopping) ) )

3. 시맨틱 웹과 추론

이제 추론(reasoning, inference)에 대한 얘기를 시작하자. 영어와 달리 동양에서 추론이라는 용어는 과도한 오해를 조장하는 경향이 있다. 아마도 추리, 추정, 추측 등이에서 추론 이라는 단어를 찾아보면, 미루어 생각하여 논함, 어떠한 판단을 근거로 삼아 다른 판 내는 추리와 비슷한 개념 등으로 정의되고 있다. 이러한 용어적 혼란 때문에, 추론 시스템이라는 것이 셜록 홈즈처럼 불충분한 증거 속에서도 뭔가를 추리해 내거나, 가능성 있는 것을 추정 혹은 예측을 해 내는 것이리라 상상하는 사람들이 많다. 이것은 거의 “미신”에 가까운 상상이라 하겠다.

시맨틱 웹 혹은 컴퓨터 공학 관점에서, 추론은 “기존에 알고 있던 사실(명제)로부터 새로운 사실(명제)를 논리적으로 유도하는 과정”으로 정의할 수 있다. 물론 넓은 의미에서는 통계적 추론처럼, 논리성이 배제될 수도 있으나, 시맨틱 웹에서의 추론은 1차 논리, 특히 서술논리(DL)와 논리 규칙(logical rule)에 의한 추론만을 그 대상으로 하고 있다. 뭔가 신기한 것을 창의적으로 생각해 내는 시스템이 아니며, 쓰레기를 넣어 금을 만들어 낼 능력은 애초부터 없는 것이다. 그럼 DL 추론과 규칙 기반한 추론을 각각 살펴보자.

OWL DL 추론 시스템은 다음과 같은 문제들을 취급한다.

- 포함관계(subsumption) 추론 : 지식이 올바른가
- 등가(equivalence) 추론 : 중복된 지식은 없는가
- 일관성(consistency) 추론 : 지식 베이스는 일관성을 가졌는가
- 유효성(satisfiability) 추론 : 지식이 의미 있는가 (인스턴스를 가질 수 있는가)
- 지식 질의(querying) 추론 : 인스턴스 i가 클레스 C의 인스턴스 인가

포함관계 추론은 하나의 클래스가 다른 클래스의 하위 개념인지 아닌지를 검사하는 것이다. 이러한 과정을 통해 추론기는 온톨로지 클래스의 계층체계 오류를 발견하고, 올바른 구조를 추론해 낼 수 있다. 이런 이유로 종종 DL 추론기를 분류기(Classifier)라 부르기도 한다. 대표적인 온톨로지 모델링 도구인 Prot？g？와 LUBM 온톨로지 및 데이터 셋을 통해 포함관계 추론 기능을 확인해 보자.

Prot？g？는 Fact++, HermiT 등의 추론기가 내장되어 있고, Racer Pro 등의 다양한 추론기를 추가로 연동할 수 있다. Prot？g？의 ‘Reasoner’ 메뉴에서 ‘Classify…’ 기능을 사용하면, 사람이 구성한 클래스 계층체계(asserted class hierarchy)를 분석해서, 추론된 계층체계(inferred class hierarchy)를 자동 도출해 낼 수 있다. LUBM(The Lehigh University Benchmark)은 Lehigh 대학에서 시맨틱 웹 저장소를 평가하기 위해 만든 것으로, 대학 도메인 온톨로지에 대한 OWL과 DAML버전이 있다. 친절하게도 LUBM 데이터 셋은 툴에 의해서 자동으로 만들 수 있다. LUBM 홈페이지에서 데이터 생성 툴(UBA)과 테스트를 위한 테스트 쿼리를 다운 받을 수 있다[10]. 대부분의 트리플 저장소들은 LUBM을 사용한 시스템 성능을 평가 결과를 공개하고 있다.

그림 8의 왼쪽과 같이 LUBM 온톨로지의 계층 구조를 임의로 뒤섰어 오류를 만든 다음, 추론엔진을 돌려보자 논리적 제약조건들을 점검하여 오른쪽 그림 같이 올바른 클래스 계층 구조를 추론해 낸다. 추론을 통해 위치가 변경된 클래스들이 파란색으로 강조되어 있다. LUBM 내에는 학생이 “Person AND takesCourse some Course”로 정의되었고, 대학원코스(GraduateCourse)가 코스(Course) 의 하위 클래스로 정의되어 있기 때문에 논리적 추론을 수행하면 대학원생의 제약조건 정의, (Person AND takesCourse some GraduateCourse)에 의해 대학원생 클래스가 학생의 하위 클래스로 이동 되는 것이다.

두 번째 추론의 예로, 그 유명한 피자 온톨로지(pizza.owl)와 추론기를 사용해 온톨로지의 일관성 추론을 실험해 보자. CheeseToping 클래스의 하위 클래스이며 동시에 VegetableToping 클래스의 하위 클래스인 ProbeInconsistentTopping 클래스를 새로 추가한다. 이러한 방식은 온톨로지가 올바르게 구축되었는지 살펴볼 때 자주 사용하는데, 추가된 클래스를 탐사 클래스(Probe Class)라 부른다. 논리적으로 문제가 없다면, ProbeInconsistentTopping 클래스의 모든 인스턴스들은 CheeseTopping 클래스의 인스턴스인 동시에 VegetableTopping 클래스의 인스턴스가 될 수 있어야 한다.

탐사 클래스의 추가가 완료되었으면 Prot？g？의 추론 기능을 실행한다. 몇 초 후 그림 9와 같이‘Class Hierarchy (Inferred)’ 창을 통해 추론된 클래스 계층 구조가 출력된다. 추론기가 발견한 일관성에 문제가 있는 클래스가 붉은 글씨로 강조되어 있다.

그렇다면 어떤 과정을 통해 일관성에 문제가 있다는 것이 식별되었을까 사람은 직관적으로 어떤 물질도 식물성이면서 동시에 치즈일 수는 없다는 것을 알고 있다. 추론기의 경우 ProbeInconsistentTopping 클래스의 상위 클래스인 VegetableTopping 클래스와 CheeseTopping 클래스가 상호 disjoint 관계로 정의되었기 때문에, 두 클래스에서 동시에 상속받은 클래스가 존재한다는 것 자체가 모순이 된다는 것을 제약조건 검사를 통해 알게 되는 것이다.

세 번째, 공리 기반한 추론을 통해 지식베이스에의 질의 결과가 확장 가능함을 확인해 보자. 추론 없이 단순 질의를 통해서는 매칭되는 데이터가 발견되지 않았지만, 추론기가 공리를 분석함으로 조건에 부합되는 새로운 데이터를 논리적으로 추론해 내는 경우이다. LUBM 지식베이스에 등록된 대학원생들 중에서 http://www.Department0.University0.edu/GraduateCourse0 코스의 이수자를 모두 찾는 쿼리를 다음과 같이 작성할 수 있다.

PREFIX rdfs:
PREFIX ub:
PREFIX rdf:
SELECT student
WHERE
{
student a ub:GraduateStudent ;
ub:takesCourse .
}

질의 결과로 다음과 같이 4명이 찾아졌다.

student
http://www.Department0.University0.edu/GraduateStudent101
http://www.Department0.University0.edu/GraduateStudent142
http://www.Department0.University0.edu/GraduateStudent44
http://www.Department0.University0.edu/GraduateStudent124

이제, 추론기가 꺼져있는 상태에서 동일한 코스를 이수한 학생(Student)들을 찾아보자.

SELECT student
WHERE
{
student a ub:Student ;
ub:takesCourse .
}

질의 결과는 한스를 이수한 “학생”에 대한 데이터가 없기 때문이다. 이번에는 추론기를 작동시키고 동일한 질의를 해보자. 재미있게도 대학원생에 대한 질의와 동일한 4명의 “대학원생”이 발견되었다. 어떤 과정을 거쳐 추론이 이루어졌을까 추론기는 대학원생(GraduateStudent) 클래스가 학생(Student) 클래스의 subclass이기 때문에, subclass 공리의 의미인 Is-A 관계를 이해한 것이다. 즉, 대항원생 역시 학생이기 때문에, 실제 지식베이스에 데이터가 없더라도, 추론을 통해 질의 결과를 반환할 수 있게 된 것이다.

F-Logic을 사용해 온톨로지와 결합된 규칙 기반 추론의 예를 설명 한다. F-Logic은 DLP 수준의 제한된 공리 추론과, 혼 로직(Horn Logic)에 뿌리를 둔 강력한 규칙기반 추론을 지원한다. 규칙기반 추론은 클래스간의 관계나 속성에 대한 조건부 제약을 규칙으로 표현함으로써 새로운 사실을 추론해 낼 수 있다. 그림 10은 OntoSutdio를 이용해 구축된 온톨로지를 보이고 있다.



그림 10의 온톨로지는 회사, 직원, 문서, 비밀취급인가에 대한 개별 지식이 포괄적으로 표현되어 있다. 만약 어느 날, 특정 직원이 문서에 접근하려면, 본인이 작성한 문서이거나 혹은 문서가 가지는 비밀 등급보다 높은 비밀취급등급을 가져야만 한다는 규정이 새로 추가되었다고 하자. 기존 온톨로지는 이러한 규정을 고려하지 못하고 만들어졌기 때문에, 각 사용자가 접근 가능한 문서에 대한 관계 정보가 전혀 포함하고 있지 못하다. DL만을 사용해 이를 표현해야 한다면, “hasDocument”와 “readDocument” 특성을 기업(company) 클래스와 직원(employee) 클래스에 각각 추가하고, 지식 베이스를 재구성해야 하거나 관련 소프트웨어를 다시 작성해야 하는 막막한 상황이 된 것이다.

규칙기반 추론을 온톨로지에 결합하게 되면, 이 문제는 매우 쉽게 해결 가능하다. 그림 11과 같이 hasDocument와 readDocument에 대한 두 개의 규칙을 생성해 보자. 이 두 규칙은 논리적으로 온톨로지 스키마의 속성으로 정의되어 있지 않지만, 지식베이스에 질의 시에는 두 규칙이 조건부로 상호 결합되면서 동적 속성(관계) 처럼 작동되는 것이다. 결론적으로, 추론 과정을 거쳐 hasDocument와 readDocument의 규칙에 부합되는 데이터가 동적으로 생성되고 마치 온톨로지 속성에 이미 그런 데이터가 저장되어 있었던 것처럼 질의 결과가 제공되는 것이다.



이제 실제 F-Logic 쿼리를 이용해 “Tony Lee”가 접근할 수 있는 문서를 질의해 보자

4. 시맨틱 웹과 추론 기술 발전 전망

한정된 지면 문제로 지식표현과 온톨로지 그리고 추론의 개념을 깊이 있게 소개하지 못해 아쉬움이 크다. 앞에서 얘기한 것처럼, 시맨틱 웹이 과거의 AI와 다른 점은 구체적 목표를 가지고 있는 데이터 중심의 프로젝트라는 것이고, 지식표현과 추론의 경우도 실용성과 상용화를 목적으로 구체적으로 설계되고 표준화 되었다는 것이다. 2004년 RDF/S 및 OWL이 표준화 되었을 무렵, 제일 훌륭한 트리플 저장소 및 추론엔진의 대용량 처리 수준은 겨우 수백만 개 정도였다. 때문에 당시 상용화를 위한 가장 큰 문제는 대용량 처리(scalability)였다. 그러나 현재는 백억 개 이상의 트리플에 대해 수십 밀리 세컨드 내에 질의/추론 가능한 성능을 확보하게 되었다. 필자들의 회사가 참여하고 있는 EU FP7 프로젝트에서는 향후 2년 내에 천억 개 이상의 트리플에 대한 질의와 추론이 가능한 시스템 개발을 목표로 하고 있다. 지난 몇 년간의 기술 발전 및 상용화 속도라면 충분히 가능한 얘기이다. OWL 2의 표준화와 더불어 조만 간에 대용량 처리는 큰 문제가 되지 않을 것으로 보인다. 3부에서는 데이터 상호운용과 시맨틱 검색, 시맨틱 소셜 네트워크 분석 등 실질적 상용 사례들을 시맨틱 기술의 가능성을 살펴보기로 하자.