터미널 서비스를 이용하면 클라이언트와 서버 세션간에 텍스트와 이미지의 복사, 잘라내기, 붙여넣기 등을 할 수 있다. 하지만 아쉽게도 파일의 복사, 잘라내기, 붙여넣기를 지원하지 못하고 있는데 터미널 서비스 확장기능을 이용하면 가능하다.

이 기사에서는 터미널 서비스의 확장판인 파일 복사기능을 이용해서 클라이언트와 서버세션간의 파일의 복사, 잘라내기, 붙여넣기를 이용하는 방법에 대해서 알 수 있다.

File Copy를 사용하여 다음과 같은 작업을 수행할 수 있다.

여러 파일과 폴더를 복사, 잘라내기, 붙여넣기
Windows 32비트 또는 16비트 클라이언트 상에서 복사, 잘라내기, 붙여넣기.
File Copy를 사용하려면, 서버에서는 다음의 과정을 수행한다.

http://www.microsoft.com/
windows2000/techinfo/reskit/tools/hotfixes/rdpclip-o.asp에 접속한다.
오른쪽 Download 메뉴에서 dpclip_hotfix.exe 파일을 다운로드 한다.
시작 - 실행 - Regedit를 실행한다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\Terminal Server\AddIns\Clip Redirector 로 이동한다.
Name을 더블 클릭한다.
RDPCLIP을 FXRDPCLP으로 바꾼다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\Terminal Server\Wds\rdpwd 로 이동한다.
Startup Programs 값을 더블 클릭한다.
RDPCLIP을 RXRDPCLP으로 바꾼다.
( 만약 드라이브 공유를 설치했다면 FXRDPCLP을 DRMAPSRV로 바꾼다.)
리소스 킷 폴더에 있는 rdpclip.exe 파일의 이름을 fxrdpclp.exe로 변경한다.
다음 그 파일을 %systemroot%\System32 폴더에 복사한다.
리소스 킷 폴더에 있는 fxfr.dll 파일을 %systemroot%\System32 폴더로 복사한다.
컴퓨터를 재시작한다.
클라이언트에서는 다음의 과정을 수행한다.

32-bit fxfr.dll 파일을 Program Files\Terminal Services Client 폴더로 복사한다.
Program Files\Terminal Services Client 폴더에 있는 rdpdr.dll 파일이름을 rdpdr.pss로 바꾼다.
32-bit rdpdr.dll 파일을 Program Files\Terminal Services Client 폴더로 복사한다.
File Copy를 사용하려면 단지 클라이언트나 Terminal Services session에 있는 파일 또는 파일들을 선택하고 Ctrl+C를 누른다음, 다른 Terminal Services 나 Client session에서 붙여넣기를 하면 된다.
신고
document.write("");
Posted by 사우람

출처 : http://www.tech-farms.com/

 

터미널 서비스를 이용하면 클라이언트와 서버 세션간에 텍스트와 이미지의 복사, 잘라내기,
붙여넣기 등을 할 수 있다. 하지만 아쉽게도 파일의 복사, 잘라내기, 붙여넣기를 지원하지
못하고 있는데 터미널 서비스 확장기능을 이용하면 가능하다.

그럼, 터미널 서비스의 확장판인 파일 복사기능을 이용해서 클라이언트와 서버세션간의 파
일의 복사, 잘라내기, 붙여넣기를 이용하는 방법에 대해서 알아보자.
===================================

File Copy를 사용하여 다음과 같은 작업을 수행할 수 있다. 

여러 파일과 폴더를 복사, 잘라내기, 붙여넣기 
Windows 32비트 또는 16비트 클라이언트 상에서 복사, 잘라내기, 붙여넣기. 
File Copy를 사용하려면,

서버에서는 다음의 과정을 수행한다. 

 1) http://www.microsoft.com/
windows2000/techinfo/reskit/tools/hotfixes/rdpclip-o.asp에 접속한다. 
 2) 오른쪽 Download 메뉴에서 dpclip_hotfix.exe 파일을 다운로드 한다. 
 3) 시작 - 실행 - Regedit를 실행한다. 
 4) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\Terminal Server\AddIns\Clip Redirector 로 이동한다. 
 5) Name을 더블 클릭한다. 
 6) RDPCLIP을 FXRDPCLP으로 바꾼다. 
 7) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\Terminal Server\Wds\rdpwd 로 이동한다. 
 8) Startup Programs 값을 더블 클릭한다. 
 9) RDPCLIP을 RXRDPCLP으로 바꾼다.
  ( 만약 드라이브 공유를 설치했다면 FXRDPCLP을 DRMAPSRV로 바꾼다.) 
10) 리소스 킷 폴더에 있는 rdpclip.exe 파일의 이름을 fxrdpclp.exe로 변경한다. 
11) 다음 그 파일을 %systemroot%\System32 폴더에 복사한다. 
12) 리소스 킷 폴더에 있는 fxfr.dll 파일을 %systemroot%\System32 폴더로 복사한다. 
13) 컴퓨터를 재시작한다. 

클라이언트에서는 다음의 과정을 수행한다. 

 1) 32-bit fxfr.dll 파일을 Program Files\Terminal Services Client 폴더로 복사한다. 

 2) Program Files\Terminal Services Client 폴더에 있는 rdpdr.dll 파일이름을 rdpdr.ps
s로 바꾼다. 
 3) 32-bit rdpdr.dll 파일을 Program Files\Terminal Services Client 폴더로 복사한다. 


** File Copy를 사용하려면 단지 클라이언트나 Terminal Services session에 있는 파일 또
는 파일들을 선택하고 Ctrl+C를 누른다음, 다른 Terminal Services 나 Client session에서 
붙여넣기를 하면 된다. 

<파일설명>
* Rdpclip.exe - The Terminal Services RDP protocol clipboard extension facility. Thi
s replaces the RdpClip that is included with Windows 2000. 
* Fxfr.dll &#8211; Extends Terminal Services clipboard redirection through the virtu
al channel to support large streams. 
* Rdpdr.dll &#8211; This file replaces the normal Terminal Services Rdpdr.dll, which
 provides clipboard and file redirection. This version makes use of Fxfr.dll. 
* Fxfr.ini - Server-side registry setup file. 
* Fxfrinst.bat - Install file. 

신고
document.write("");
Posted by 사우람

http://www.devbank.co.kr/

 

안녕하세요. 데브뱅크 운영자 오종혁입니다.

오늘은 프로젝트 관리기법에 대해 알아보기 전에 프로젝트란 무엇이며, 무엇을 프로젝트라고 하는 지에 대해 말씀을 드리려구요..

백과사전에 찾아보니 "프로젝트란 각 부문 ·사업부 ·섹션 간에 기술상 ·관리상 복잡하며 교차적 관계에 있는 개별계획으로 프로젝트 매니저에 의한 조정과 관리가 필요한 것을 말한다." 라고 되어있네요.. 맞는 이야기긴 하지만, 정말 어렵네요.

제가 생각하는 프로젝트란?

1. 비연속적인 (즉 시작과 끝이 있는) 일
2. 독립적인 예산을 가지고 있는 일
3. 서로다른 기술, 및 문화를 가진 사람들이 모여서 하나의 목적을 가지고 하는 일

등으로 정의하고 있습니다.

사실, 우리는 프로젝트라는 단어를 많이 사용하고, 여기저기서 아주 많이 듣고 있습니다. 하지만, 프로젝트가 정확하게 뭔가 하고 물어보면 많이 당황하게 되죠. 그냥 일이라고 이야기 하기도 하고, 작업이라고 이야기 하기도 하죠. 하지만, 우리가 직장에서 인사, 회계, 총무, 업무 그리고, 기타 일반적으로 하는 일들을 프로젝트라고 말하지는 않습니다. 그건 위의 정의에 위반되기 때문이죠.

프로젝트만이 프로젝트 매니지먼트(프로젝트 관리)를 했을 때 효과를 볼 수 있는 것입니다. 프로젝트는 역사적으로는 1960년대에 미군에서 잠수함을 축조할때 처음 도입한 방법이라고 하더군요. 그리 오래되지는 않았죠? 그 때 기존의 하던 방법보다, 프로젝트 관리기법을 도입했을 때, 프로젝트의 기간단축, 예산단축에 많은 효과를 보게 되었고, 그 뒤에 선진국들의 지속적인 학문적 연구를 통해 대형 공사나 단위가 크고 많은 사람들이 투입되는 프로젝트에는 어디에나 PM이란 사람이 따라다니게 되었습니다.

웹사이트 개발도 규모가 작기는 하지만 프로젝트라고 볼 수 있으며, 몇몇 프로젝트 매니지먼트를 하시던 분들이 프로젝트 관리기법중 일부를 웹사이트 개발에 도입하게 되고, 효과를 보고, 그러다보니 웹PM이란 단어가 등장하고 지금은 여러사람들이 웹PM을 해보려 노력하고 있는 상황입니다.

웹사이트를 제작하는 프로젝트의 경우는 사실, 다른 거대 프로젝트(건설, 토목, 조선등)들에 비해 매우 간단할 수가 있습니다. 왜냐하면, 투입되는 기술의 형태가 크게 디자인, 프로그램, 기획정도이며, 인력과 시간이외의 다른 자원이 그리 많이 필요하지 않기 때문이죠.

예를 들어 하나의 화학공장을 건설하는 프로젝트라고 한다면, 토목, 건축, 화공, 기계, 배관, 계장, 전기 등의 다양한 기술진들이 서로 모르는 분야와 통합적으로 하나의 생산품을 설계해 내야 하며, 다양한 재료의 구매와 시공 그리고, 감리에 이르기 까지 수많은 분야의 인력이 투입되게 됩니다. 사실, 이렇게 서로다른 분야가 복잡하게 얽혀 있을 수록 프로젝트 관리가 더욱 필요하게 되고, 효과도 그많큼 커지는 것이기는 합니다.

어쨌든 웹사이트제작에서도 프로그램과 디자인이라는 서로의 전혀 다른 기술분야의 인력이 조화있게 업무를 연계해 나가야 하는 것이라는 점에서는 프로젝트관리가 어느정도 효과를 볼 수 있는 분야라는 판단이 드네요.

 

* 웹사이트 제작 프로젝트 관리의 목적


그럼 웹사이트 제작 프로젝트 관리의 목적은 무엇일까요? 웹사이트를 제작하는 데 있어 프로젝트 관리를 사용하는 이유는

1. 최소의 자원(인력과 시간)을 투입하여 적정한 시기에 웹사이트를 오픈하는 것
2. 주어진 예산 안에서 사이트가 완성되고, 웹에이전시라면 적정한 이익을 남기는 것
3. 사이트의 목적에 부합하는 최고의 퀄리티가 확보된 사이트를 만드는 것

이라고 볼 수 있습니다.
즉 같은 사이트를 만든다고 해도, 가장 효율적으로 적은 시간에 적은 인력을 가지고 가장 좋은 상품을 만들어 내는 것이지요. 그럼 이제 부터 이것을 조금이나마 가능케 하는 방법들을 하나씩 말씀드리겠습니다.

1. 인력관리

웹사이트 제작은 컴퓨터, 인터넷라인, 서버등 웹사이트를 제작하는 업체라면 기본적으로 갖추고 있는 고정장비를 제외하면, 프로젝트마다 따로 준비할 구매없이 인력과 시간의 투자만이 필요한 노동집약적 프로젝트 입니다. 실제로 웹사이트 제작의 90%이상 예산이 인건비 이기도 하구요..

그만큼 웹사이트 제작 프로젝트에 인력관리가 중요하겠지요.
사실, 그동안 인력에 대한 관리는 여러 기업과 회사들에서 여러모로 연구가 되고, 시행착오를 겪어온 부분이기도 합니다.

인사고과등의 평가제를 시행하여 보기도 하고, 상벌제를 두기도하고, 업무실적에 따른 인센티브를 주기도 하고, 직원들에 대한 복지를 늘리기도 하고 등등의 여러가지 방법들을 동원하여 직원들이 열심히 일을 하게하고, 수익의 원천이 되도록 노력해왔습니다. 하지만, 저의 개인적인 경험으로는 여러가지 합리적인 제도를 도입하고, 제도적으로 일을 하게 하는 것도 중요하지만, 우리나라의 일하는 문화에서는 이보다는 인간적인 관계가 더 중요하더군요. 해외에서 연구된 인력관리의 방법들이 성공할 확율이 그리 높지는 않다는 것을 보면, 인력의 관리는 그 사회의 문화에 더 기인하는 것 같습니다.

특히 개발기간이 정해져 있는 프로젝트 작업의 경우는 더욱 인력에 대한 관리가 중요합니다. 웹사이트 개발은 90%이상이 노동력으로 인해 진행되는 작업이고, 중간에 프로젝트에 투입된 인력에 변동이 발생한다면, 그 프로젝트에 치명적인 위험요소가 될 가능성이 매우 높습니다.

만일 프로그래머 1명, 디자이너 1명, 기획자 1명이 하나의 사이트를 의뢰받아 만들고 있다고 생각해 보세요. 이런 경우 한명이라도 인력에 차질이 생기게 되면, (.. 회사를 그만둔다거나, 사고가 생겼다거나, 몸이 아프다거나 여타의 이유로 인해서) 촉박하게 돌아가는 프로젝트에서 한명이 빠지면, 프로젝트의 기간을 맞추기가 정말 어려워지죠.. 또한, 프로젝트 관리자로서 인력이 중간에 빠져나가는 부분을 막기란 불가능 할 수도 있습니다. 여러가지 계약이 있다해도 말이지요..

인력 리스크가 나타나는 시기나 가능성에 대해 프로젝트 관리자가 어느정도 예상할 수 있다면, 갑자기 닥치는 것보다는 훨씬 리스크를 줄여갈 수 있는 여지가 많아지게 됩니다. 이를 위해서 프로젝트 관리자는 프로젝트에 투입된 인력이 그리 많지 않다면, 핵심적인 인력에 대해 좀 더 친숙하게 다가가고 그사람이 프로젝트에 대해 개인적으로 생각하는 부분이나, 개인 사생활에도 조금은 관심을 가질 필요가 있습니다. 갑작스런 사고가 아니라면 조금은 미리 닥쳐올 인력로스에 대해 미리 짐작할 수 있게 되니까요..

그리고, 평소에 웹사이트 제작 기술에 대한 많은 인력들과 유대관계를 맺어 둘 필요도 있습니다. 갑작스런 프로젝트 인력의 공백을 매꿔줄 사람들을 많이 알고 있다면, 그만큼 프로젝트가 실패할 확율을 줄일 수 있게 되는 것입니다.

합리적이고 체계적인 것을 좋아하는 제가 인력에 대한 부분 만큼은 매우 뜬구름 잡는 이야기들을 하고 있는 듯 하네요. 이 것은 실제로 프로젝트를 꾸려가다보니, 사람과 사람의 관계에 대한 문제로 접근하여, 위험성을 파악하고, 이 위험성을 극복하는 대처를 해야한다는 것을 몸으로 느끼게 되었기 때문입니다.

더 이야기 한다면 잔소리가 될것같아 인력공백의 위험성에 대한 이야기는 이쯤에서 마치고요. 또하나 덧붙여 말씀드린다면, 각 인력들과의 커뮤니케이션 통로를 좀 넓혀야 한다는 이야기를 하고 싶네요. 특히 프로그래머, 디자이너의 경우 서로 많이 다른 문화적 환경에 살고 있는 사람입니다. 생각하는 방식도 많이 다르고 일을 추진하는 방법도 다르고, 의사전달을 하는 방법도 조금을 다르기 때문에 많은 트러블들을 만들지요. 기획자, 프로그래머, 디자이너가 서로 정확하게 의사를 전달하고 받아들일 수 있도록 중간에서 많은 노력을 해야 합니다.

사실, 프로젝트 매니저가 일을 시키는 입장이고, 개발자는 그 일을 하는 사람입장입니다. 그래서 프로젝트 관리자로서는 일방적으로 일을 시키고, 그 일을 시간내에 끝을 내야 하는 것이라고 생각하기 쉽지만, 어떤 방식이 실제 프로젝트를 성공적으로 이끄는 데 중요한 것인지를 한번 정도 더 생각을 해 보시는 것이 좋습니다. 서로가 참신한 아이디어와 의견을 충분히 교환할 수 있게 하고, 그에 대한 결정을 프로젝트 매니저가 모두가 납득할 수 있는 이유로 인해 신속하게 결정하고 일을 진행할 수 있는 팀웍을 만들어가는 것이 가장 훌륭하겠지요. (너무 어려운 이야기 입니다.) 팀웍이 맞는 다면 팀원들 또한 일이 즐겁고 인력에 대한 리스크도 가장 줄일 수 있는 길이 될 것입니다.

<@NHN@LINEBREAKER@NHN@>

2. 문서관리

 

문서관리에 대해 이야기 해 보도록 하죠..

사실, 많은 회사에서 대부분의 사람들이 문서관리를 매우 등한시 하고, 귀찮아하고, 잘 안하고 있습니다. 아마, 이글을 읽으시는 분들중에도 프로젝트를 진행하면서 체계적으로 문서를 관리하시는 분은 많지 않으리란 생각이 드네요..

그러다가, 우린 어떤 문제에 닥쳤을때 특히, 거래처(클라이언트등)와 이견이 생겼을 때 또 이것이 크게 문제시 될때 부랴 부랴 문서들을 찾고, 보관해 두지 못했음을 한탄하기도 하고, 회사의 윗분들에게 꾸지람을 듣기도 하죠.. 하지만, 그것도 잠시, 일이 바쁘고, 귀찮다는 핑계로 어느정도 시간이 지나면, 문서정리란 흐지부지 되게 마련이죠..

하지만, 프로젝트를 진행해 가면서 관련된 문서를 정리해 두는 것은

1. 프로젝트의 원활한 진행과 추후 문제가 되는 부분에 대한 대비..
2. 회사의 업무 노하우의 축적
3. 체계적인 의사결정 수단

등을 위해 중요한 일입니다.

최근 많은 회사들이 ISO 인증을 받고 있죠.. 이 인증을 받은 회사들은 ISO 규정에 따라 문서를 정리하도록 되어있습니다. 그리고, 형식적이나마 하고들 있죠.. 그도 아닌 중소 회사들은 전혀 체계가 잡히지 않은 문서관리를 하고 있기도 합니다.

그럼, 웹사이트를 제작하는 프로젝트에서는 어떤 문서들을 정리하고, 저장해 두어야 할까요?

1) 계약관련문서


프로젝트에는 대부분 계약서가 있죠. 특히 의뢰를 받은 경우는 당연하겠지요. 계약서는 가장 중요한 문서중에 하나입니다. 클라이언트와의 논쟁이 발생하면, 분쟁해결의 근간이 되는 문서입니다. 이 문서는 대부분 보관을 하시겠지요.. 또하나 덧붙인다면, 견적 및 제안서등을 보관해 두는 것이 좋습니다. 사이트를 제작하다보면, 계약이전에 상담 또는 영업시, 아님 견적서에 들어간 내용들에 대한 언급이 많이 발생하게 되죠..

2) 기획관련문서


사이트를 기획하면서 발생되는 문서들, 사이트 구조도, 사이트 맵, 스토리보드, 플로우챠트등이 보관되어야 합니다. 이는 추후 사이트의 업데이트에도 중요한 문서가 되며, 회사의 노하우를 축적한다는 의미도 있습니다. 그리고, 프로젝트가 끝나고 기획문서를 포함하여 제출해야 하는 경우도 있죠..
이런 기획문서들이 클라이언트(의뢰자)의 승인을 받은 경우라면 계약서에 버금가는 중요한 문서가 되기도 합니다. 사실, 웹사이트라고 하는 것이 계약단계에 사이트의 하나하나 모든 것을 지정할 수가 없기 때문에 개발이 진행되면서 차차 승인을 받아가게 되는 데, 이때 승인 받은 기획문서들은 추후 사이트의 오픈시 의뢰자와의 마찰을 줄일수 있는 문서가 되기도 합니다.

3) 의사전달문서


웹사이트라고 하는 것이 대략의 안을 가지고 시작하는 경우가 많고, 상품자체가 차차 완성되어 가다 보니 의뢰자와 중간중간에 많은 이야기가 오고가게 되고, 그에 따라 계약시와 비교하여 많은 부분 변경이 이루어지게 됩니다. 이런 사이트를 계약서에만 의존하여 분쟁을 해결하기가 정말 힘든 경우가 많지요.. 팩스와 메일을 프린트하여 보관하고, 전화로 통하를 한경우는 통화내역을 요약하여 정리해 두고, 만나서 회의를 한경우는 회의록을 만들어 두는 것이 좋습니다. 경우에 따라서는 회의록이나 유선통화내역정리 문서들을 의뢰자에게 보내어 승인을 받아두기도 하죠...

이런 문서들은 프로젝트의 리스크를 많이 줄이는 데 기인하게 됩니다. 조금은 귀찮고 힘들지만, 나중에 크게 문제가 될 부분을 줄여나간다는 측면에서 반드시 필요한 작업이라는 것을 기억해 두시기 바랍니다.

그리고, 모든 문서는 추후에 찾기 쉽도록 문서넘버를 정리하고, 철하여 두는 것이 좋습니다.
정말 귀찮고 힘든일이지만, 이런 일들이 몸에 베고 근간이 되어야 훌륭한 프로젝트 관리자가 될 수 있답니다..

 

3. 리스크관리

 

사이트를 의뢰받아 만들다 보면, 정말 여러가지 이유로 인해 문제들이 발생하고 또, 이런 문제들 때문에 사이트 제작 기간이 늘어나거나, 일이 중복되거나, 처음보다 더 많은 인력이 투입되거나 심지어 사이트 제작을 포기해야하는 상황들이 발생하곤 합니다.

이럴때 많은 사람들이 "그건 어쩔 수 없는 일이었어" 라든가 "운이 나빴지" 라든가 혹은 사이트 의뢰자의 잘못이라면 그곳을 욕을 하기도 합니다.

하지만, 적어도 프로젝트 관리를 하는 사람이라면, 그런 일들을 최소화하도록 노력하고, 불가항력적인 일이 일어난다고 해도, 그일에 대해 피해를 최소화 할수 있는 방안들을 마련해 두어야 합니다.

사이트를 여러번 만들다 보면, 정말 재수없어서 발생한 일이라고 생각했던 일들이 이따금 일어난다는 사실을 알게 됩니다. 예를 들어, 의뢰자가 도산을 한다거나, 제작하던 컴퓨터의 하드디스크가 박살난다거나, 뭐 사무실에 홍수가 난다거나 등등.. 그럼 과연 이런일들을 막을 수 있단 말인가요? 어떻게 보면, 불가항력처럼 보이는 일들이죠.. 작게는 디자이너나 프로그래머가 갑자기 아프다거나, 상을 당했다거나, 사고를 당할 수도 있죠.

경험이 조금 많은 사람이라면, 어떤 요인들이 사이트 제작에 위험요소로 작용하는 지를 알고 이 요소들에 대한 리스트를 작성할 수 있을 것입니다.

예를 들어볼까요?

1. 인력에 대한 리스크
2. 고객에 대한 리스크
3. 예산에 대한 리스크
4. 재난에 대한 리스크
5. 기타 리스크

이처럼 리스크 군을 나눈 후에 그안에 세부적으로 위험요소가 될 수 있는 사고들을 적어넣습니다. 그리고, 그 일들이 일어나기를 막을 수 있는 방법들과, 그 일이 일어났을 때 대처해야할 방법들을 적어 놓습니다. 그리고, 생각지 못했던 위험사고들이 생겨날때마다 업데이트하여, 사이트 제작에 방해되는 요소들을 미리 준비해 두는 것입니다.

예를 들어 사무실이 홍수가 잘나는 지역에 있다고 가정해 보고, 만일 어느여름 비가 무지 많이 와서 사무실이 홍수가 나 컴퓨터가 모두 물에 잠긴 상황을 리스크로 잡아 두었다면, 아마 그 프로젝트 관리자는 작업파일을 사무실 컴퓨터에만 백업해놓지 않고, IDC 센터나 백업 서비스를 이용한다거나, 집의 컴퓨터에 수시로 백업을 받겠지요.. 그러면, 이 리스크에 대해 안전해 지는 것입니다. 사실, 홍수가 나서 사무실 작업이 모두 날라갔다고 한다면, 그 모든 일을 처음부터 다시해야 하는 것을 당연하겠지요. 너무 황당한 예였나요? 하지만, 황당한 일이 일어나지 말란 법도 없지요..

또하나 예를 들어볼까요? 아주 어려운 프로세스인 작업이고, 자신의 회사에 아주 실력이 좋은 프로그래머가 있어 프로젝트를 수행한다면, 당연히 그 프로그래머의 인력공백은 엄청난 프로젝트 리스크가 될 수 있습니다. 물론 그 프로그래머 자신도 이 프로젝트가 끝날때 까지 열심히 일을 할 것으로 마음먹고 있다고 해도, 그 사람이 사고를 당하거나, 아님, 갑자기 다른회사에서 엄청난 제안을 해서 마음이 바뀔 수도 있구요.. 갑자기 아플수도 있지요.. 그럼 이런 경우도 리스크 체크리스트에 있다면, PM은 어느정도 그사람에 대한 관심을 가지게 되고, 막을 수 있는 일이라면 막고, 만일 그렇지 않다하더라도 아무 생각이 없이 있을 때보다 인력공백이 생길 시기를 조금은 빨리 알게될 가능성이 높아집니다. 그렇다면 대처할 시간이 조금 더 생기게 되는 것이요.. 아니면, 대체인력에 대한 대안을 미리 만들어 놓을 수도 있겠지요.

바로 리스크 관리란,, 모든 위험요소를 막겠다는 것이 아니라 최대한 위험을 줄이고, 또 위험이 일어날 일에 대해 미리 생각해 두고, 또 위험이 일어날 것을 조금이라도 미리 알수 있게 하고자 하는 것입니다.

신고
document.write("");
Posted by 사우람


  (1) 등장 배경

RDBMS가 현실 세계를 잘 반영하고 있는 것은 아닙니다. 관계형 데이터 모델(data model)에 부과된 제약에 의해 제한을 받게 되는데, 이러한 제약들로는 균일성(uniformity), 레코드 지향성(record orientation), 필드 값의 원자성(atomicity) 등이 있습니다. 또한 어떤 응용 프로그램의 경우 RDBMS가 지원하지 못하는 데이터 값이나 SQL보다 더 풍부한 표현력을 원할 때도 있습니다.

이상과 같은 관계형 시스템의 제한을 극복하고, 더 확장된 언어를 제공하기 위해 등장한 것이 객체지향(object-oriented) 모델입니다. 하지만 이 또한 완전한 모델이 아니기 때문에 질의 처리와 같은 관계형 모델의 많은 장점을 버려야 하는 단점을 안고 있습니다.


(2) 객체의 특징

6장에서는 객체의 정의에 대해서만 언급했는데, 여기서는 그 특징들에 대해서도 살펴보도록 하겠습니다. 우선 객체가 가지고 있는 특징을 대표하는 단어를 나열하면 다음과 같습니다.

캡슐화 (encapsulation)

6장에서 "객체는 변수들과 그와 관련된 메소드들의 묶음"이라고 정의했습니다. 현실 세계의 모든 사물(개념적인 사물도 포함)은 객체가 될 수 있기 때문에 자동차를 예로 들어보겠습니다.

자동차는 바퀴, 엔진, 의자 등의 또 다른 객체를 소유하고 있으며, 이들은 모두 객체의 변수로 생각할 수 있습니다. 이 변수에 지름이 70Cm인 바퀴, 2,500cc 엔진, 가죽 의자 등의 값이 들어가게 됩니다. 또한 자동차는 시동을 건다, 사람을 태운다, 달린다 등의 행위를 표현하는 메소드들을 가지고 있습니다. 즉, 자동차라는 객체는 내부(작은 원)에 ㅇ,ㅁ등으로 구성된 변수들이 있고, 그 주위를 메소드들이 둘러싸고 있다고 보시면 됩니다.

이와 같이 변수의 내용이 외부(큰 원 바깥)에 보여지지 않도록 보호하는 것을 캡슐화(encapsulation)라고 합니다.
캡슐화를 간단하게 정의하면 '자세하고, 세부적이지만 외부 세계에서는 크게 중요하지 않은 것을 외부로부터 숨기는 것'이라고 생각하시면 됩니다. 자동차에서 운전자가 볼트나 너트 등이 어디에 붙어 있는지, 연료가 어디로 이동되는지, 바퀴가 어떻게 회전하는지 등에 대해서는 알 필요가 없기 때문에 이것들에 대한 학습은 필요가 없다는 것이죠.

이러한 캡슐화의 첫번째 장점은 모듈화(modularity)가 가능하다는 것입니다. 모듈화란 객체에 대한 원시 프로그램(source program)이 다른 원시 프로그램과는 별개의 독립적인 프로그램으로 작성되고 유지될 수 있음을 의미합니다.

위에서 예를 든 자동차를 이용해서 설명하면, 자동차에 사용되는 바퀴, 나사, 의자, 오디오(각각이 모듈에 해당하겠죠!) 등은 하나의 공장에서 모두 제작하지 않고, 전문화된 공장에서 특정 상품을 생산하면 더 질 좋고 특화된 제품을 생산할 수 있을 것입니다. 이렇게 자동차의 생산에 사용되는 모든 부품 (모듈화된 객체)을 모듈화시켜 필요할 때 갖다 사용하게 하는 것입니다.

두번째 장점은 외부에 공개된 변수들과 메소드들 이외의 정보들에 대해서는 은닉 (information hiding)할 수 있다는 것입니다.

자동차 운전자는 자동차의 엔진이 어떻게 작동하는지, 바퀴와 차체가 어떻게 연결되어 있는지 등의 정보에 대해서는 알 필요가 없습니다. 만약 모두 다 알아야 한다면 우리 나라의 교통환경이 조금은 좋아지겠죠? 이렇게 내부의 세세한 정보를 알 필요 없이 그 사용법만 알면 사용할 수 있도록 제공해주는 캡슐화의 장점이 바로 정보의 은닉입니다.


메시지 (message)

 

앞에서 언급한 자동차는 하나의 객체로 구성된 것이 아니고, 바퀴라는 객체, 엔진이라는 객체, 차체라는 객체 등 다양한 객체들로 구성되어 있습니다. 즉, 최소 단위의 객체를 이용해서 또 다른 객체를 생성할 수 있으며, 이들을 서로 연관시켜 다른 기능과 특성을 갖는 또 다른 객체를 생성할 수 있습니다. 이렇게 여러 객체들을 모아서 다른 객체를 만들면, 객체들끼리의 의사소통이 필요하게 됩니다. 이렇게 객체들 간의 의사소통이나 통신을 하기 위해서 사용되는 것이 바로 메시지(message)입니다. 예를 들면 엔진이라는 객체의 회전 동작이 바퀴에 전달되는 과정이 바로 메시지에 의해서 발생된다는 것입니다.

메시지는 다음과 같이 세 가지의 구성요소를 가집니다.


메시지를 받을 객체(바퀴)
메시지를 받아서 수행되는 메소드의 이름(바퀴 회전하기)
수행되는 메소드에서 필요로 하는 매개 변수 혹은 파라미터(시속 50Km로 회전)


메시지를 사용할 때의 장점으로는 다음의 두가지가 있습니다.

객체의 행동은 객체에 포함된 메소드들에 의해서 표현되는데, 메소드들 간의 메시지
    전달은 객체들간의 모든 상호 작용을 표현할 수 있습니다.

객체들간에 메시지를 주고 받기 위해서 객체들이 반드시 한 기계 내에 존재할 필요가
    없습니다.

자동차가 전진하고, 정지하고, 후진하는 모든 과정은 운전자가 브레이크, 엑셀레이터, 기어 등의 객체를 이용한 결과입니다. 이러한 객체들의 단순한 조작이 자동차를 움직이게 하기 위해서는 객체간에 힘과 방향이 전달되어야 합니다. 이 힘과 방향이 바로 객체들 사이의 메시지가 되는 것입니다. 전진하기 위해서는 기어를 바꿔주고 엑셀레이터를 밟으면 됩니다. 기어를 바꿀 때 '기어 변경'이라는 메시지가 전달되고, 엑셀레이터를 밟을 때, '엔진의 출력을 높여라'라는 메시지가 엔진에 전달되는 것입니다.

 

클래스 (class)

세상에는 동일한 종류의 많은 객체들이 존재하고 있습니다. 예를 들어 본인이 A사의 B 모델 차를 소유하고 있다면, 이 B모델의 차는 자동차라는 개념(최소 4개의 바퀴와 하나의 엔진, 운전석 등은 반드시 가짐)을 물려받은 하나의 구체적인 실체입니다.

컴퓨터적인 용어를 사용하면, B 모델의 차는 자동차라는 객체(틀) 클래스(class, 개념, 설계도)의 한 인스턴스(instance, 실체)입니다. 즉, 클래스라는 설계도를 바탕으로 객체라는 틀(자동차의 경우 생산 라인이 되겠죠!)을 제작한 후에, 이 틀에 맞춰 인스턴스라는 실제 자동차를 만든다라고 보시면 됩니다.

소프트웨어에서 클래스란 객체에 대한 설계도라고 할 수 있는데, 이에 대한 좀 더 정확한 정의를 내리면 '클래스는 같은 종류의 모든 객체들에 공통인 변수들과 메소드들을 정의한 설계도 또는 청사진이다'라고 할 수 있습니다.

자동차 객체를 사용하기 위해서는 그 자동차 객체가 있어야 하고, 자동차 객체를 생성하려면 자동차 클래스가 있어야 합니다. 객체가 생성될 때, 시스템은 그 객체에서 그 객체가 속한 클래스에 정의된 인스턴스 변수들을 위한 기억 공간을 할당하게 됩니다. 객체의 메소드들은 객체의 인스턴스 변수들을 사용하므로 객체가 생성되어야 그 객체의 인스턴스 메소드들을 사용할 수 있습니다. 인스턴스 변수들과 달리 객체의 메소드들은 객체마다 기억 공간을 잡으며 존재하지 않습니다.

요약하면, 제일 먼저 자동차에 대한 설계(클래스)가 이루어집니다. 이 설계도를 바탕으로 모형(객체)이 만들어지고, 모형이 성공적이면 이 모형에 맞춰 실제 제품(인스턴스)을 생산해서 판매(메모리 영역을 점유)하게 되는 것입니다.


객체와 클래스를 분명하게 구분하여 사용하는 사람은 드물기 때문에 일반적으로 혼용해서 많이 사용합니다. 여러분도 이해하시기 편하게 생각하시면 될 것입니다. 클래스는 재사용성(reusability)이라는 장점을 가지고 있으며, 어떻게 생각하면 객체의 장점이 클래스의 장점이 될 수도 있습니다. 즉, 설계도를 이용해서 자동차를 반복 생산할 수 있다고 보시면 됩니다.

 

상속 (inheritance)

 

일반적으로 객체가 속한 클래스를 알면 그 객체의 구조와 행동에 대해 알 수 있습니다. 객체 지향 시스템에서 새로운 클래스를 기존에 존재하는 클래스의 하위 클래스(서브클래스)로 만들 수 있습니다. 예를 들어 EF 소나타는 소나타 III, 소나타 II, 소나타 등의 후속으로 등장했기 때문에 EF 소나타는 소나타의 서브클래스라고 할 수 있습니다.

각 서브클래스는 그 클래스 자체의 상위 클래스(슈퍼클래스)로부터 변수들과 메소드들을 상속(inheritance) 받습니다. 즉, 슈퍼클래스에서 공통된 특성을 작성하고, 서브클래스들은 슈퍼클래스의 특성을 상속 받는 것입니다. 마치 자식들이 부모의 외모나 성격들을 상속 받는 것과 같은 이치라고 생각하시면 됩니다. 그렇다고 자식이 부모와 완전히 동일한 것은 아니죠. 자신에게 필요한 다른 성격을 가지는 것처럼 객체도 자신에게 더 필요한 변수들과 메소드들을 가질 수 있습니다.

상속은 하나의 슈퍼클래스를 상속 받는 단일 상속과 여러 슈퍼클래스로부터 상속 받는 다중 상속으로 구분되며, 상속을 받는 서브클래스는 슈퍼클래스의 속성과 메소드들을 상속 받습니다.

상속이 갖는 이점에는 다음의 두가지가 있습니다.

슈퍼클래스로부터 공통된 특성을 상속받기 때문에 슈퍼클래스의 코드를 여러번
    재사용할 수 있습니다.

다양한 융통성을 가질 수 있도록 프로그래밍할 수 있습니다.

이상의 내용이 약간은 어려우시겠지만 이해하고 있으면 상당히 유용하게 사용될 것 같아 장황하게 설명을 드렸습니다. 그럼 다시 데이터베이스적인 관점으로 넘어가도록 하겠습니다.

 


   
(3) 객체지향 모델

객체지향 모델은 앞에서 언급된 객체지향 프로그래밍에 근거를 두고 있습니다. 여기서는 모든 것을 언급하기 보다는 핵심적인 모델링 개념에 대해 간단히 요약하는 것으로 끝내겠습니다.

객체와 객체식별자
현실 세계에서 임의의 한 존재는 하나의 객체가 될 수 있으며, 각각의 객체는 하나의 객체 분류 시스템에서 유일한 이름(식별자 OID: Object Identifier)을 갖습니다. 즉, 한국 사람이라는 객체 분류 시스템에서 그 사람의 유일한 객체 식별자는 주민등록번호가 되는 것입니다.
속성과 메소드

객체는 하나 이상의 속성을 가지며, 속성 값상에서 작동할 수 있는 하나 이상의 메소드가 존재합니다. 객체의 속성 값 또한 객체입니다. 이때 속성은 하나의 값(더 이상 쪼갤 수 없는 최소 단위의 객체)을 가질 수도 있고, 여러 개의 값을 집합 형태(쪼갤 수 있는 객체)로 가질 수도 있습니다.
사람의 경우 눈이라는 객체는 망막, 수정체 등의 속성을 가지고, 본다, 굴린다 등의 메소드를 가지며, 망막은 더 작은 세포 단위의 객체로 나눌 수가 있는 것입니다.

캡슐화와 메시지 전달

어떤 객체의 속성값과 그 속성에 속한 메소드들에 접근하기 위해서는 그 객체로 메시지를 보내야 합니다. 각 객체에 명기된 공용 인터페이스를 통하지 않고는 그 객체에 접근할 수 없습니다.

클래스

같은 속성들과 메소드들을 공유하는 모든 객체는 하나의 클래스로 묶을 수 있습니다.

클래스의 상속

임의의 객체지향 시스템에서 클래스는 임의 개수의 하위 클래스를 가질 수 있습니다.

 


   


객체지향 개념은 각각 다른 세 분야에서 발전되어 왔습니다.

프로그래밍 언어
프로그래밍 언어에서는 Simula-67 을 객체지향 프로그래밍 언어의 효시로 보며, 이 분야에서도 기존의 프로그래밍 언어를 확장하는 방식과 새로운 객체지향 언어를 개발하는 방법으로 나누어져 개발되었습니다.
인공지능(AI : Artificial intelligence)

프로그래밍 언어에서 얼마나 사람의 사고를 잘 반영할 수 있느냐에 따라 인공지능 분야도 많은 영향을 받기 때문에, 인공지능 분야에서도 객체지향에 대한 연구가 많이 수행되었습니다. 초창기 LISP로부터 Prolog,이를 더 확장한 버전까지 개발되어 사용되고 있습니다.

데이터베이스 분야

데이터베이스 분야에서는 의미 데이터 모델(semantic data model) 연구에 의해 객체지향 프로그래밍 언어와 비슷한 데이터 모델링 개념을 추출하여, 이에 대한 확대 개발 연구가 계속 진행 중입니다.

여기서, 우리의 학습 대상인 데이터베이스쪽으로 시선을 돌려보겠습니다.

데이터 모델은 실세계 엔티티와 그들의 제약 조건 및 관계들을 논리적으로 조직하는 것으로, 객체지향 개념을 갖고 있는 데이터 모델을 객체지향 데이터 모델이라고 합니다. 1장에서 언급한 것처럼 관계형 데이터베이스에서 사용된 데이터는 다른 데이터와 관계가 없는 경우 무의미한(정보가 없는) 자료가 됩니다. 하지만 객체는 객체 자체가 하나의 정보단위로 의미를 가지고 있습니다.(위에서 언급한 의미 데이터 모델이란 말이 이를 나타내고 있습니다!)

객체지향 데이터베이스는 객체들의 집합이며, 객체지향 데이터 모델에 따라 객체들의 동작 및 상태와 관계를 정의하고 있습니다. 객체지향 데이터베이스 시스템(OODBMS)은 객체지향 데이터베이스를 정의하고 조작할 수 있는 데이터베이스 시스템인 것입니다.



   


객체지향 데이터베이스(OODB : Object-oriented Database)에 대해서 아직까지 정확한 개념이 정립되지 못했는데, 그 원인은 다음과 같습니다.

첫째 , 객체지향 데이터 모델에 대한 표준이 없다는 것입니다.

객체지향 데이터 모델의 표준이 명확하게 정의되지 못한 원인은 객체지향 프로그래밍 언어의 표준이 명확하게 정의되지 못한 데서 찾을 수 있습니다. 즉, 꼬리에 꼬리를 무는 결과를 가져왔다는 얘기가 됩니다.

좀더 자세히 살펴보면, 프로그래밍 언어 분야에서나 데이터베이스 분야에서 객체지향 개념을 위한 의미의 단일 표준에 동의하지 않고 있는 실정입니다. 그렇기 때문에 상업적으로 성공한 몇 개의 프로그래밍 언어, 예를 들어 LISP나 C++에 의해 객체지향 개념의 표준이 흔들리고 있다는 것입니다. 이렇게 객체지향 프로그래밍 언어가 힘의 논리에 지배되기 때문에 데이터베이스 시스템도 표준이 명확하게 마련되지 않고, 그 결과 OODBMS 시장이 혼란한 상황에 부딪혀 있습니다.

둘째 , 비객체지향 데이터베이스 내에 미미하나마 기본적인 객체지향 개념이
    존재한다는 이유에서입니다.

CAD(Computer Aided Design), CASE(Computer Aided Software Engineering) 등도 데이터베이스화 할 수 있습니다. 또한 혼합문서의 경우도 데이터베이스화 할 수 있습니다. 하지만 이런 종류의 응용 프로그램에 관계 데이터베이스 기술을 적용하기에는 많은 제한이 있습니다. 혼합문서의 경우 단순 텍스트뿐 아니라 그림, 음성 등의 데이터도 저장할 수 있기 때문에 이런 데이터는 관계 데이터 모델에서는 구현하기가 어렵기 때문입니다. 그렇다고 객체지향 데이터베이스 기술을 적용하기도 어렵습니다. OODB의 경우 관계 데이터 모델을 사용하기 어렵기 때문에, CAD나 CASE의 경우 설계 객체의 모든 관계나 혼합 문서 내의 모든 요소들간의 관계를 모델링하기에는 불충분합니다.

또한 관계형 데이터베이스이지만 객체지향 개념을 갖도록 관계형 모델, 언어를 확장하려는 노력이 이미 존재했습니다. 그 결과 POSTGRES라는 무료 DBMS의 경우 RDBMS이지만 여기에 객체지향 개념을 많이 내포하고 있습니다.

객체지향 데이터베이스는 앞서 언급한 바와 같이 표준화가 아직 완성되지 않았고, 사용상의 문제점을 안고 있으므로 아직 적극적으로 사용하기에는 무리가 있다고 할 수 있습니다. 그러나 향후에는 객체지향 데이터베이스가 시장 전반을 점유하게 될 것으로 예상되고 있습니다.


객체 캡슐화에 의한 모듈화 정보 은닉의 장점이 있습니다.
객체들 간의 정보 전달은 메시지를 통해서 이루어집니다.

인스턴스는 객체가 실제적으로 구현된 상태입니다.

클래스는 객체들의 공통 변수들과 메소드들을 정의한 객체의 설계도라고 할 수 있습니다.

클래스의 사용으로 발생되는 장점은 재사용할 수 있다는 점입니다.

클래스는 슈퍼클래스의 속성이나 메소드들을 상속 받을 수 있습니다.

객체지향 모델링은 객체와 객체 식별자, 속성과 메소드, 캡슐화와 메시지,
클래스, 상속 등에 대한 개념을 필요로 합니다.

신고
document.write("");
Posted by 사우람

한의학 및 보완대체의학에서의 의학 온톨로지 개발

 

 본 발표는 의학영역에서의 지식에 대한 구조화, 지능적인 처리에 대한 내용을 다루는 것으로 발표는 1) 우리 세대에게 요구되는 미해결의 응용분야에 대한 해결방안으로서 온톨로지 공학의 이용을 예를 들어 설명, 2)온톨로지의 개요, 구성, 구현, 이용, 배경 등에 대한 설명, 3) 의학영역에서의 온톨로지, 4) 한의학에서의 온톨로지 구축의 순으로 진행된다.

 

배경

 최근의 정보처리에 있어서 중요한 진전은 그리드(Grid)와 시맨틱웹(Semantic web)이다. 이것들은 모두 '연결의 지능화'라고 요약할 수 있으며 모든 분야에 영향력을 강화해 나갈 것이며, 응용분야로서 가장 중요한 분야가 의료산업과 의학연구 분야이다. 이 중 시맨틱 웹은 차세대 웹 기술이자 최근 지능적인 지식처리에 관한 연구의 화두가 되고 있는데, 시맨틱 웹의 구현을 위한 핵심 기술은 온톨로지(Ontology)와 관계된 것들이다.


온톨로지

 온톨로지('O'ntology)는 철학의 한 분과학문으로서 '존재론'으로 번역되며, 원래 '존재들과 존재들의 속성에 대한 설명들'이란 의미로 사용되었다. 그런데, 정보과학에서 온톨로지('o'ntologies)는 "특정 영역의 용어들과 그들간의 관계를 명시적이고 정형화한 명세(Explicit formal specifications of the terms in the domain and relations among them)"로 정의된다. 의료영역에서 보면, 온톨로지는 넓은 의미에서 의료지식을 기록하고 있는 데이터베이스라고 간주할 수 있으며, 지식과 관련된 데이터라는 의미에서는 지식베이스(Knowledge-base)이다. 그러나, 온톨로지는 그 자신이 담고자 하는 영역의 지식을 좀 더 그대로 표현하기 위해서 표현력이 높은 언어를 이용하여 만들어진 것으로 전통적인 데이터베이스와 그 구별이 된다. 온톨로지는 개념(Concepts), 관계(Relations), 개념의 계층(Concept Hierarchy), 관계를 통한 개념과 개념의 연결로서의 함수(Function), 공리(Axioms) 등 다섯 개의 구성물로 되어 있음, 용도에 따라 상위온톨로지(Top-level ontologies), 영역온톨로지(Domain ontologies), 과업온톨로지(Task ontologies), 응용온톨로지(Application ontologies)가 있다. 현재 의료영역에서의 온톨로지 연구는 세 가지 다른 전통에서 뿌리를 두고 있다. 첫째, 온톨로지는 인공지능의 지식표현(Knowledge Representation) 방법에서 출발하였으며, 온톨로지를 즉, 의료지식을 표현하기 위한 언어로 주목받고 있는 기술논리(Description Logic)는 지식표현의 논리적 접근방식의 엄격성과 구조적 접근방식의 직관성을 통합시킨 방법이다. 둘째, 의학 영역은 표준화된 용어시스템을 통해서 병원의 의료정보, 문헌정보의 공유, 정리, 조직화를 효율적으로 처리하고자 하였다. 이러한 의학영역에서의 자발적인 요구는 자연스럽게 의학영역에서 온톨로지 관련 연구가 활성화 되도록 이끌었다. 셋째, 웹 상의 자원(source)을 지능적으로 통합, 검색, 추출하기 위해서 시맨틱 웹 연구가 활성화되었으며 이것이 정보과학을 온톨로지 연구로 이끌고 있다.


온톨로지의 활용

 온톨로지는 비즈니스 절차의 모델링, 디지털 도서관, WordNet에서의 정보 검색, 정보통합, 지능적인 에이전트, 기계 학습, 자연어 처리, 데이터 마이닝, HCI 등에서의 지식처리를 위해서 사용되고 있다.


의학 영역의 온톨로지와 활용

 현재까지 개발된 진료영역에서의 온톨로지 중 주목할 만한 것은 GALEN, Med, SNOMED CT, Foundational Model of Anatomy, UMLS 등이 있다. GALEN은 기술논리 기반의 GRAIL(GALEN Representation and Integration Language)에 의해서 표현된 온톨로지로서 멘체스터 대학을 중심으로 하는 유럽 연합에서 개발되었다. MED는 미국 콜롬비아 대학에서 개발되어 병원에서 실제 사용되고 있는 시스템이며, Foundational Model of Anatomy는 해부학 정보에 대한 프레임 기반의 온톨로지로서 워싱턴 대학에서 개발되고 있으며, SNOMED CT는 전자의무기록을 위한 용어시스템으로 CAP(American College of Pathologist)에서 개발 판매되고 있으며, UMLS는 NLM(National Library of Medicine)에서 개발되어 있으며 많은 응용이 시도되고 있다. 각각의 시스템은 온톨로지라고 말할 수 있는 것부터 좀 복잡한 용어시스템이라고 말할 수 있는 것까지 다양한 표현력을 가지고 있다. 예를 들어 UMLS나 SNOMED CT를 포함한 기존의 용어 시스템은 아직까지 지식표현을 위한 언어들이 가지고 있는 속성(property)의 이행성(transitivity), 카디넬러티(Cardinality), 인스턴스의 표현, 속성의 상속(Inheritance) 등을 비롯한 개념들을 처리하기 위한 논리적 추론 기능을 가지고 있지 못하다. 그러나, 이러한 시스템들은 급속하게 온톨로지라고 불릴 수 있는 형태로 발전하고 있다.


한의학 영역에서의 온톨로지 개발

 한의학 영역에서의 온톨로지 연구는 두 가지의 의미를 가지고 있다. 첫째, 의학 일반에서 기술한 온톨로지의 필요성이 한의학 분야에서도 동일하게 적용된다. 즉, 전자진료부 시스템, 문서 검색시스템, 학술문헌 관리 등에서 새로운 기능들을 요구하고 있다. 그 요구에 필요한 새로운 기술이 한의학의 지식을 의미 기반으로 다룰 수 있는 표준화된 방법들로 기술(記述)하는 온톨로지 기술(技術)이며, 이것을 통해서 지식표현이 가능할 수 있게 된다. 둘째는 한의학의 고유 지식은 서구자연과학의 지식구조와는 다른 특성을 함유하고 있다. 그것은 유사성(Similarity)과 유비추론(Analogical Reasoning)이라고 요약할 수 있으며 이에 대한 온톨로지로서의 표현은 한의학 지식의 적절한 표현에 필요할 뿐 아니라, 인지과학, 지식공학 등에도 기여할 것으로 믿는다. 그러나 현재는 한의학과 관련된 온톨로지는 전세계적으로 아직 개발된 바가 없으며, 이에 대한 일부의 연구가 한국, 일본, 영구 등지에서 이루어지고 있으며, 표준화된 방법에 의해서 개발된 온톨로지는 지적 재산권으로서도 가치를 지닐 것으로 생각된다.


참고 문헌

1. 김홍기, 김명기, 의료정보학에서의 온톨로지 기술, 대한의료정보학회지 2003:9(3):213-219
2. 박경모, 박종현, Protege를 이용한 한의학의 구조화된 증상 입력을 위한 온톨로지 개발, 제20차 

                          대한의료정보학회 춘계학술대회 논문집.충청남도 아산. 2003. 5.30-31.
3. Alexander Maedche. Ontology Learning for the Semantic Web, Kluwer Academic

                          Publishers, 2002
4. Dieter Fensel et al ed. Spinning the Semantic Web, MIT Press, 2003
5. Sean Bechhofer, Ian Horrocks and Peter F. Patel-Schneider, Tutorial on OWL, ISWC,

                          Sanibel Island, Florida, USA, 20th October, 2003

 


 
2003년 12월

경희대 동서의료공학과, 박경모

http://informatics.snuh.org/1211_abstract.html

신고
document.write("");
Posted by 사우람

지식기반 통합 Repository 구축

 

양해섭
한국방송통신대 정보전산원 정보관리기술사

 

효율적인 정보자원관리가 기업 경쟁력의 중요한 요소로 자리잡고 있다. 이는 정보화 관련업무가 표준화, 단순화, 자동화 등을 실천하고 이를 뒷받침해줄 정보기술 도구로써 IT 관련 지식을 담아놓을 Repository 활용을 통해 그 목표를 이룰 수 있다. 이에 한국방송대의 사례를 중심으로 정보자원관리 전략과 Repository 구축방안을 짚어본다.

정보자원관리의 구성요소는 자원, 프로세스, 기능, 운영시스템 등으로 이루어져 있으며 기업이나 기관에서 IT관련조직의 업무 활동은 환경에 따라 다소 차이가 있을 수 있다. 그러나 일반적으로 정보화 사업계획을 수립하는 기획업무, 시스템을 구축하는 개발업무, 개발된 시스템을 운영하는 유지보수업무 등으로 구분해 볼 수 있다. 현재의 일반적인 정보자원관리 업무 현황을 살펴보면 <그림1>과 같다.

<그림1> 정보자원관리 현황 개념도



그동안 많은 정보화 사업이 수행돼 왔고, 정보자원관리의 중요성이 높지만 실제 현장에서는 이를 소홀히 해온 결과 다음과 같은 문제점들이 발생하게 됐다. 첫째, IT업무프로세스의 표준화 미흡으로 업무간 상호관계의 불일치성이 발생하고 IT담당자는 같은 실수를 반복하고 있다. 둘째, 개방형 환경의 다양한 시스템 운영관리 업무의 복잡성이 증대됐다. 셋째, 응용시스템에서 설계문서와 프로그램간 형상관리가 제대로 이루어지고 있지 않아 효율적인 운영에 어려움이 있었다. 마지막으로 기술변화에 능동적이지 못하고 관리적 요소가 강화된 결과 단위기능 개발비용 및 유지 보수비용의 증가를 초래하게 됐다.
이같은 문제점들을 해결하기 위해 한국방송대는 정보자원관리 전략을 수립하고 지식기반 통합 Repository에서 정보를 관리하고 활용하는 방안을 찾기로 했다.

효율적인 정보자원관리를 위한 전략

한국방송대는 효율적인 정보자원관리를 위해서 장단기 전략 목표를 가지고 이에 대한 준비를 했다. 또한 <그림2>와 같은 정보자원관리 전략 프레임워크를 기반으로 현실에 적합한 수준부터 단계적으로 진행하도록 계획을 수립했다.

<그림2> 정보자원의 통합적 관리 프레임워크 개념



<그림3> 지식기반 통합 Repository 구성도


성공적인 정보자원의 통합적 관리를 위한 시스템 구축 전략은 다음과 같다.

▲환경분석단계
·경영환경분석: 정보자원 환경 파악, 핵심성공요소 및 요구사항도출.
·정보기술동향분석: 정보기술의 트렌드 파악, 새로운 IT기술의 적용 가능성 분석.

▲현황분석단계
정보자원관련 인적 자원들이 IT업무처리를 효율적으로 수행할 수 있도록 현재의 업무 프로세스를 분석하고 현행 정보시스템의 문제점 및 개선방향을 도출.
·업무 프로세스 분석: 지식생성, 축적, 활용 등의 업무 프로세스 분석으로 표준화 및 단순화에 중점을 두고 연계대상 업무처리의 흐름을 분석하며 응용의 개발범위를 고려하여 정의한다.
·정보시스템 분석: 애플리케이션, 데이터베이스, 보안, 네트워크 등을 파악하고 이미 구축된 정보시스템의 문제와 통합적 관리를 위한 개선방향을 도출한다.
·요구사항 정의 및 선진모델 자료수집: 이해당사자의 요구사항과 개선과제를 도출하기 위해 인터뷰 및 프로토타입 제작 리뷰 회의를 통해 사용자의 요구 수준을 파악하고, 외부기업 및 기관의 선진사례 자료를 수집한다.

▲시스템 목표 수립 및 구축방향 선정단계
정보자산관리시스템을 통해 성취할 목표를 명확하게 정의하는 한편 향후 정보자원관련 이해당사자 차원을 넘어 전사적 차원의 전략이 되도록 고려한다.
·정보시스템 구축의 원칙 설정: 핵심 성공요소 및 요구사항을 도출, 시스템 구축 및 기본설계원칙 정의, 시스템에 적용될 기술요건 및 지식관리전략 수립.
·솔루션 및 개발대상 부문 분류: 도입될 솔루션목록은 자동화업무(CASE,통합검색, 콘텐츠 관리 시스템 등) 중심으로 도출하고, 나머지는 개발부문으로 정의.

▲구축 효과 분석단계
정보자산관리 시스템 구축에 따른 정성적, 정량적 효과를 분석한다.
·정성적 효과분석: 이해 당사자별 효과를 분석(경영자, 관리자, 실무자 등).
·정량적 효과분석: 정보기술 자산에 대한 활용과 시스템에 대한 투자대비 효과분석(ROI), BSC(Balanced Scorecard)에 근거해 학습 및 성장, 내부 프로세스, 고객, 재무적 관점에 근거한 주요 측정지표의 분석.

▲단계적인 실행계획 수립단계
정보자원관리는 장기적인 안목을 가지고 현실적인 구현으로의 접근이 가능하도록 단계별로 구축에 대한 일정계획 및 필요한 관리운영정책 그리고 자원투자 계획이 고려돼야 한다. 또한 이는 시스템 구축보다는 향후 운영관리 이행계획이 매우 중요하므로 이에 대하여 충분히 고려돼야 한다.
·실행계획: 단계별 추진일정 및 소요자원계획을 수립하고 구현의 우선순위 설정, 단계적으로 투자될 예산과 변화될 환경에 대한 리스크 관리계획 수립.
·운영관리계획: 정보자원관리의 특성상 이해 당사자들의 적극적인 참여가 성공요인이며 이는 적절한 인센티브와 통제가 이뤄질 수 있도록 직무로 규정화해 적극적 참여를 독려하고 장기적으로는 품질관리가 수반될 수 있도록 운영관리계획을 수립한다.

지식기반 통합 Repository 구축방안

다음은 정보화부문 자원관리를 위한 통합 Repository 구축 사례로서 목적은 급변하는 IT관련 지식공유 및 활용을 통해 업무능률 향상에 도움을 주는데 있다.



▲정보자원관리의 시스템 구성과 기능
정보자원관리시스템은 유무형의 정보자산을 통합적으로 관리하기 위해 시스템자산관리, 업무 프로세스를 관리하기 위한 PCS(Process Control System)를 구성한다. 프로그램과 기술문서에 대한 관리는 형상관리를 통해 관리가 이루어지며, 루틴화된 업무와 프로젝트성 업무가 함께 이뤄진다.

▲통합 Repository 구축시 고려사항
·시스템구조 설계 고려사항: 사용자들의 다양한 요구를 수용하기 위해 통합 Repository시스템 구조를 설계하는데 있어 개방형 정보기술(J2EE or .NET) 적용 및 기존시스템과의 인터페이스가 함께 고려돼야 한다. 또한 정보자원관리 통합 Repository 구조는 다양한 콘텐츠를 저장관리 할 수 있어야 하며 업무 생산성을 위해 내부 업무시스템과의 연계수준을 정의하고 설계를 해야 한다. 효율적 정보자원 활용을 위해 웹 환경에서 정보포털이 제공하는 개인화 체계를 적용해 조직, 직위, 역할에 따라 차별적인 콘텐츠 오너십을 제공하기 위해 사용자접근관리와 권한관리 설정이 가능해야 한다.
·통합 Repository 구성을 위한 데이터베이스 설계 고려사항: 통합 Repository 설계는 용도에 따라 정보자원관리 분류체계, 코드설계, 데이터교환 표준을 정의하고 단일 데이터베이스 환경에서 데이터의 통합 및 무결성 운영을 목표로 업무처리의 표준화·단순화·자동화 노력이 필요하다. 이는 자료 및 콘텐츠 통합관리에서 중요한 고려사항이다. 정보자원관리시스템이 관리해야 하는 데이터는 텍스트에서 멀티미디어 데이터까지 다양하므로 데이터베이스 구축 관련기술(메타데이터, 시소러스, 온톨로지, Directory Service, Contents Management System, Wrapper& Mediator등)에 대한 표준과 솔루션 선정에 대한 검증활동이 이뤄져야 하고 전문가들의 참여가 확보돼야 한다.
·정보자원관리 기능 구축에 대한 주요 고려사항: 지식기반 통합 Repository의 가치는 변화하는 업무 및 정보기술지식에 대한 지속적 변화의 이력관리가 이뤄질 수 있도록 형상관리 기능이 제공돼야 한다. 또 프로그램과 문서간의 동기화 기능, 조직과 역할에 맞는 개인화 정보를 제공하고 검색과 리포트 기능도 제공돼야 한다. 주의할 점은 초기부터 많은 기능을 구현하기보다는 조직의 능력에 맞는 수준에서 시작하고 개선된 모델로 발전을 위해 분석통계가 함께 고려되고 모듈의 재사용성을 높이기 위해 개발시 CBD(Component Based Development)방법론 적용도 고려해 볼만하다.

정보자원관리의 향후 발전방향

이처럼 정보자원관리시스템은 기관내의 다양한 애플리케이션 통합과 업무 프로세스 결합을 통해 확장이 필요하다. 현 IT자원의 상태와 향후 관리목표에 대한 명확한 이해를 바탕으로 연속적인 학습과 진화를 위한 노력이 요구되며 개선된 정보자원관리시스템 모델에 대한 발전방향은 다음과 같다.
·정보자원은 일관된 관점에서 인적자원, 물적자원, 지식자원, 아키텍처 자원 등 체계적 관리를 통해 비용 대비 효율성 제고를 위한 통합 표준 프레임워크 구축 지원. ·정보화 투자의 효과 측정 및 관리를 통해 투자효과 평가 극대화를 위한 평가모델체계 구축(예: 통계정보시스템 연계 및 Balanced Scorecard 도입).
·표준화된 정보기술기반의 시스템 상호호환성 증진을 위한 웹서비스 기술 적용.
·통합 Repository 활용 극대화를 위한 지능형 웹(시멘틱웹)의 온톨로지, 시소러스 등의 기술을 적용을 통한 컴포넌트 기반의 정보기술 적용.

한편 현재의 IT 인프라스트럭처 기반 정보자원관리시스템은 앞으로 비즈니스에서 IT에 이르는 기업의 모든 자원을 전사적 아키텍처(Enterprise Architecture)로 통합 관리할 수 있는 시스템으로 진화 발전할 것으로 전망된다.

출처 : 경영과컴퓨터[2004년도 7월호]

출처 http://www.dbguide.net/lib/columns/dbg_view.jsp?idx=534

신고
document.write("");
Posted by 사우람

정보과학회지 제22권 제4호 통권 제179호(2004. 04)

(최호섭, 옥철영)

 

                                          정보검색시스템과 온톨로지

 

1. 서 론


인간의 사고방식을 컴퓨터가 이해할 수 있고, 이러한 인간과 컴퓨터의 의미적인 상호 작용(semantic interaction)이 컴퓨터와 컴퓨터 사이에서도 그대로 반영될 수 있는 기술적 환경이 조성되도록 하는 것은, 인공지능뿐만 아니라 정보검색, 지식기반 시스템 등이 궁극적으로 추구하는 연구 개발의 목적이라 할 수 있다. 특히 수많은 지식 정보의 저장소로 생각할 수 있는 웹을 중심으로, 웹상의 지식 정보에 인간의 사고방식을 반영할 수 있는 잘 정의된 의미(semantic)를 부여한다면, 현재 컴퓨터를 이용한 정보 검색이나 문서 해석 및 이해 등이 지능화될 뿐만 아니라 나아가 인간의 사고방식과 같은 추론 기능까지 갖출 수 있는 시스템이 개발될 수 있을 것이다.

정보검색시스템은 사용자가 원하는 지식 정보를 얼마나 정확하고 빠르게 검색하여 의미 있는 지식 정보를 제공할 수 있는가에 따라 시스템의 성능과 평가가 좌우된다고 할 수 있다. 즉, 정보검색시스템은 사용자 측면에서는 다양한 정보 검색을 통해 의미 있는 지식 정보를 제공받을 수 있도록 하는 매개체 역할을 담당하며, 개발자 측면에서는 정보 검색에서의 질의 처리 성능, 대용량 정보 처리 방법, 색인 기술 등과 같이 지식 정보에 대한 표현, 저장, 조직, 접근 등의 기술적 처리의 효율성에 초점을 맞춘다. 최근 이러한 정보검색시스템의 기술적․활용적 측면에서 강조되고 있는 것이 의미 있는 지식 정보를 어떻게 컴퓨터가 이해하고 처리할 수 있는가에 초점이 맞춰지고 있다.

이러한 연구 방향과 더불어 최근 국내 학계에서도 높은 관심을 보이면서 관련 분야에서 많은 연구가 진행 중인 것이 바로 Tim Berners-Lee가 1998년에 제안한 시맨틱 웹(semantic web)이다. 시맨틱 웹은 잘 알려진 바와 같이, 컴퓨터간의 정보교환을 가능하게 하며 웹상의 데이터의 의미를 사람이 아닌 컴퓨터가 이해․처리할 수 있는 기술로서, 기존의 웹과 구분되는 것이 아니라 웹의 지식 정보에 잘 정의된 의미를 부여함으로써 웹상의 수많은 데이터가 의미 있는 지식 정보로 표현될 수 있는 방법을 보여준다고 할 수 있다.

시맨틱 웹 기술의 등장은 정보에 대한 표현, 공유, 재사용 등에 인식을 증대시키면서 인공지능 분야에서 부분적으로 연구되었던 지식 표현(knowledge representation), 추론(inference), 의미망(semantic network), 온톨로지(ontology)에 대한 관심 영역을 이끌어 내는 계기가 되었다. 특히 온톨로지는 시맨틱 웹의 핵심 기술이자 핵심 구성 요소로서 자리를 잡아 가고 있으며, 국외에서는 특정 영역 중심의 domain 온톨로지를 비롯한 upper, core, task 온톨로지 등을 실제로 구축하여 시맨틱 웹 기술에 활용함과 동시에 여러 애플리케이션에의 활용 방법을 모색하고 있는 실정이다. 그러나 국내에서는 실질적인 온톨로지가 소규모 연구실에서의 실험적인 수준으로 구축되거나 이론적 수준에 그치고 있는 실정이다. 이러한 국내의 상황은 정보검색시스템 관련 개발 기술에서 온톨로지를 어떻게 활용할 것인가에 대한 여러 가지 논의가 계속되고 실험적인 수준에 그치고 있는 것과 일맥상통한다.

본고에서는 온톨로지에 대한 이론적 개념 정립과 더불어 온톨로지 구축 사례, 정보검색에서의 온톨로지 활용 동향 등을 간략하게 살펴보고자 한다.


2. 온톨로지 개념 정립


2.1. 온톨로지에 대한 해석


‘온톨로지’라는 용어에 대하여 Guarino, N.은 다음의 [표1]과 같이 해석이 가능하다고 정리하고 있다[20].


[표1] Possible interpretations of the term "Ontology"     

Ontology as a philosophical discipline

Ontology as an informal conceptual system

Ontology as an formal semantic account

Ontology as a specification of a "conceptualization"

Ontology as a representation of a conceptual system via a logical theory

5.1 characterized by specific formal properties

5.2 characterized only by its specific purpose

Ontology as a the vocabulary used by a logical theory

Ontology as a (meta-level) specification of a logical theory


위의 해석 중 가장 일반적으로 사용되는 것이 4 혹은 5의 해석으로, 대부분의 연구자들이 "an ontology is an explicit specification of a (shared) conceptualization"[25][26]라는 정의를 이용하고 있으며, 덧붙여 시맨틱 웹에서는 특정 목적과 영역의 중요성을 강조하고 있다. 위의 일반적인 온톨로지의 정의를 세부적으로 살피면, 공유(share)라는 것은 개념이 해당 그룹 구성원뿐만 아니라 컴퓨터 간에 합의된 지식에 바탕을 두고 있다는 것을 의미하고, 개념화(conceptualization)는 특정 목적을 위해서 표현하고자 하는 대상 세계에서 일어나는 현상에 연관된 개념들을 파악하기 위한 추상적 모델을 말한다. 또한 형식적(formal)이라는 것은 기계 가독형이어야 한다는 것을 의미하며, 명시적(explicit)이라는 것은 개념의 종류와 그들 간의 관계, 그리고 그 개념들의 사용에 있어서 주어지는 제한점들을 명백하게 정의하는 것을 의미한다[1][2].

이러한 온톨로지의 해석들을 통해 기존의 시소러스(thesaurus)나 어휘 데이터베이스(lexical database), 의미망 등과 같이 다양한 형태의 어휘 집합(lexical set)들을 온톨로지의 일종으로 판단하여 온톨로지를 구축하고 표현하는 경우도 있다. 즉 온톨로지가 가지고 있는 일반적인 구성 요소인 개념(concept), 관계(relation), 속성(property) 등이 표현되어 있는 어휘 집합(lexical set)들을 온톨로지로 변환 또는 구축하는 사례를 살펴보면, 다음의 [표2]와 같이 비슷한 형태이지만 다양하게 구축되고 있음을 알 수 있다[4].


[표2] Ontology Example

Ontology

Example

(in practice)

Simple concept hierarchies

Semantic network

Thesaurus

Frame system

Logical models

Lexical field

Category

Taxonomies on the Web

Catalogs for on-line shopping

Domain-specific standard terminology

Etc.

 

이것은 시맨틱 웹에서의 웹 온톨로지(web ontology) 등장으로 인해, 기존의 시소러스나 의미망, 어휘 데이터베이스, 표준분류체계 등(예, WordNet, UMLS, UNSPSC, RosettaNet, etc.)을 RDFs, DAML+OIL, OWL과 같은 웹 온톨로지 언어를 이용하여 온톨로지로 표현하는 연구 개발이 활발하게 진행됨과 동시에, 기존의 계층적 구조로 표현된 어휘 집합들을 재사용하고 구축 시간을 단축하기 위한 구축 사례가 많아짐으로써 이러한 온톨로지의 실질 구축 사례가 다양한 형태로 표현되었다고 할 수 있다. 물론 [표2]와 같은 사례들을 통해 온톨로지는 클래스(class)와 서브클래스(subclass)의 관계, 즉 개념간의 계층적 구조를 형성하고 있다는 점과 어떠한 의미적 관계(semantic relation)를 가지고 있다는 점에서는 위의 사례들이 공통적일 수 있으며, 웹 온톨로지 언어의 사용 여부와 활용적인 측면에서는 다르다고 할 수 있는 것이다.

 

2.2. 온톨로지의 개념


2.1절과 같이 온톨로지에 대한 해석들과 형태적인 사례를 통해 온톨로지가 어떠한 형식으로 표현되고 있는지를 간략하게 살폈다. 그렇다면 온톨로지에 대한 해석만 가지고는 온톨로지를 파악하기가 쉽지 않을 뿐만 아니라, 실질적으로 온톨로지를 구축하는 측면에서도 기존의 시소러스 구축 원리나 표준분류체계 등의 구축 원리를 이용한다면 문제가 될 수 있다. 이러한 문제가 발생하는 것은 ‘개념’과 '관계', 그리고 ‘개념화’에 대한 이해 때문이라 할 수 있다. ‘개념’은 사전적으로 여러 관념 속에서 공통된 요소를 뽑아내어 종합하여 얻은 하나의 관념으로 정의될 수 있으며, ‘개념’은 일반적으로 언어로 표현된다. ‘관계’는 어휘의미론(Lexical Semantics)에서의 의미 관계(semantic relation)와 조금 폭넓은 의미에서의 개념 관계(conceptual relation)가 있다. 특히 시소러스나 WordNet에서 일반적으로 사용 중인 의미 관계는 상하 관계, 동의/유의 관계, 부분전체 관계 등이 보편적으로 사용되며, 개념 관계는 조금 넓은 의미에서 구성원 관계(has_member), 위치 관계(has_location) 등으로 세분화하여 개념간의 관계를 설정할 수 있다. ‘개념화’는 사물이나 표상을 어떤 성질․공통성․본질에 착안하여 그것을 추출하여 파악하는 과정으로서, 그 형태적 표현은 분류적 구조(classified structure)와 계층적 구조(hierarchical structure)로 나타날 수 있다[4].

이러한 개념화 양상은 기존의 시소러스와 의미망 등과 같은 계층적 어휘 집합과 온톨로지를 구분하기 어려운 것 중의 하나이다. 이러한 온톨로지에 대한 어느 정도의 개념 정립을 위하여, [그림1]을 통해 간략하게나마 시소러스와 온톨로지의 차이점을 확인함과 동시에 어떠한 연관성이 있는지를 확인할 수 있다[13]. 덧붙여 [그림2]를 통해서는 커뮤니케이션을 위한 기본적인 온톨로지의 원리를 파악할 수 있다[9]. 이를 통해 온톨로지의 기본 개념을 어느 정도 이해할 수 있으리라 판단된다.

 

##########0*

[그림1] Thesaurus versus Ontology

 

##########1*

[그림2] Ontology for Communication


즉 [그림1], [그림2]를 통해 온톨로지가 단순히 용어(term)의 체계적 구조화가 아니라 개념들을 특정한 영역의 개념에 대한 정의와 관계, 그리고 개념이 가지는 특수한 속성들로 이루어진 집합체임을 알 수 있다. 또한 온톨로지는 사람과 사람 사이의 원활한 커뮤니케이션처럼 기계와 기계 사이에도 형식적 모델을 통해 원활하게 커뮤니케이션이 가능하도록 하는 의미적인 구조를 가져야 하는 것도 알 수 있다.

이러한 온톨로지의 일반적인 개념 속에 추가적으로 고려해야 하는 것이 바로 추론과 통합(integration) 기능이다[9][10][11][31][32]. 온톨로지가 단순하게 계층적 구조와 의미관계 등으로 구성되어 있다면, 온톨로지의 유용성은 시소러스와 의미망, 분류체계, 어휘 데이터베이스 등과 다를 바 없을 것이다. 즉 온톨로지를 통해, 사람이 가지는 사고방식과 비슷한 추론 방법으로 새로운 개념을 유추하고 관계를 설정할 수 있어야 하는 것이다. 또한 다양한 온톨로지를 어떻게 통합할 수 있는가도 중요한 문제이다. 온톨로지의 정의에서도 알 수 있듯이 온톨로지의 특징 중에 하나인 공유는 온톨로지를 구축함에 있어 반드시 고려해야 하는 문제임으로, 여러 분야에서 다양하게 만들어진 온톨로지를 어떻게 통합하느냐에 따라 온톨로지의 통용성을 확인시킬 수 있을 것이다.

이상의 내용을 2.1절과 더불어 전산학적인 입장에서 정리한다면, 온톨로지를 다음과 같이 정리할 수 있을 것이다.

* 일정한 체계에 의한 어휘 사전이나 용어의 확보

* 특정 영역(specified domain)뿐만 아니라 보편 영역(generic domain)의 기본 개념에 대한 정의와 그들 간의 관계에 대한 명세화

* 개념, 관계, 속성들의 유기적인 집합

* 전산적 처리가 가능한 구조화와 구체화

* 공유와 재사용의 가능

* 논리적 추론

* 통합

 

2.3. 온톨로지 구축 고려 사항


온톨로지의 구축 단계를 간략하게 설명하면,  특정한 목적과 영역을 고려한 다음, 개념을 자동․반자동 추출하거나 어휘 사전을 확보하여, 확보된 개념들을 정의하고 조직화해야 한다. 조직화한다는 것은 개념들 간의 관계를 설정함과 동시에 개념이 가지는 특수한 속성을 추출하여 체계화시키는 것을 의미하는 것으로서, 이론적 체계와 더불어 실질적인 구축 원리를 마련해야 한다. 다음 단계로 온톨로지를 표현할 웹 온톨로지 언어나 기계 가독형 표현 언어(machine readable representation language)를 설정하여 형식화하고 실질적으로 구현하여야 하며, 구축 중인 온톨로지와의 다른 온톨로지와의 통합 문제와 기존에 존재하는 많은 자원(resources)을 어떻게 활용할 것인가를 모색해야 한다. 그리고 마지막으로 구축된 온톨로지를 대상 애플리케이션(target application)에서 실험하거나 사용 패턴(usage patterns)을 분석하여 평가해야 한다. 또한 이러한 평가 결과를 바탕으로 유지․보수를 해야 하며, 조금 더 발전적인 온톨로지로 개선해야 한다[4][10][15][27][28].

 

##########2*

[그림4] General Ontology Development methodology


이러한 일련의 구축 단계에서 가장 어려운 문제는 바로 온톨로지를 실질적으로 구축하는 이론적 체계와 원리가 아직까지 마련되지 않았다는 것이다. 기존의 구축 사례들을 살펴보면, 온톨로지의 실질적인 구축 측면보다도 기존의 시소러스나 의미망, 분류체계 등을 이용한 온톨로지 구축이나 기구축된 온톨로지를 이용한 애플리케이션 개발이 대부분을 차지한다. 이것은 온톨로지 구축에 있어서 국내외적으로 가지는 공통적인 문제라 할 수 있다. 이를 위해서는 WordNet, UMLS와 같이 관련 학문에 대한 이론 습득과 더불어 자연언어처리 기법의 활용을 통한 언어 습득 및 이해 처리 등과 같은 부수적인 연구가 뒤따라야 할 것이다.

이외에 온톨로지를 구축에 고려해야 될 사항을 정리하면 다음과 같다.


온톨로지 구축 대상자 선정

온톨로지 구축 방법(자동/반자동/수동)

응용분야별 온톨로지 구축 원리 파악

기구축된 시소러스, 분류 체계 활용 방법

범용적/국제적 수준의 온톨로지 구축

온톨로지 저작 도구 개발

온톨로지 구축 관련 표준 방식 연구

시맨틱 마크업 언어 표준안 개발

기타


3. 온톨로지 기반 정보검색시스템


3.1. 온톨로지 개발 및 활용 동향


시맨틱 웹의 등장은 온톨로지 자체에 대한 연구 개발뿐만 아니라 온톨로지에 기반한 많은 애플리케이션 개발에도 영향을 미치기 시작했다. 이러한 온톨로지 연구 개발과 활용에 대한 대표적인 사례가 유럽을 중심으로 2000년부터 시작된 OntoWeb Project[29][34], On-to-Knowledge Project[32], 그리고 미국을 중심으로 한 W3C Semantic Web Activity(Web Ontology WG, Semantic Web Best Practices and Development WG...)[30] 등이라 할 수 있다.

OntoWeb Project’는 프로젝트 명칭이 “지식 관리와 전자상거래를 위한 온톨로지 기반 정보 교환(ontology-based information exchange for knowledge management and electronic commerce)”으로서, 온톨로지 기반 기술을 유럽 공동 시장에 제공할 수 있도록 함과 동시에 ISO, ANSI, W3C, IEEE 등에서 제시하는 국제 표준에 발맞추어 나가면서 이들 단체에게 표준화와 관련된 여러 정보를 제공할 수 있도록 여러 가지 온톨로지 기반 정보 교환 방법을 연구하는 장기적인 프로젝트이다. 이 프로젝트에서는 다양한 온톨로지 기반 애플리케이션 개발뿐만 아니라 평가 방법에 대한 연구를 비롯하여, 성공적인 시나리오와 가이드라인을 제공함과 동시에, 온톨로지 저작 도구(OntoEdit)[30] 등을 사용자에게 제공하고 있다. OntoWeb에서 온톨로지 활용하는 분야는 정보검색, 전자상거래, 지식관리 등을 많은 응용 분야에서 테스트와 평가를 거치고 있다. [그림5]에서 OntoWeb 프로젝트의 개괄적인 내용을 확인할 수 있다.

 

##########3*

[그림5] Clusters of ontology-based application with some additional evaluation criteria(OntoWeb Project)


On-To-Knowledge(OTK) Project’는 온톨로지를 이용한 내용 기반 지식 관리를 위한 각종 도구와 방법 등을 개발하기 위한 프로젝트로서, 특히 기업에서의 시맨틱 웹 기술 활용을 통한 지식 관리에 중점을 둔 연구 개발 프로젝트라 할 수 있다. 또한 OTK의 결과물을 살펴보면 시맨틱 웹 기반의 지식 관리 도구를 Intranet/WWW에서의 지식 정보 추출, 의미적 표현과 분석, 사용자 질의 제어 등을 고려한 도구를 실질적으로 개발하였다는 점에서 의의가 있다고 할 수 있다. OTK의 결과물 중 시맨틱 웹 기반의 지식 관리를 위한 도구는 [그림6]에서 확인할 수 있으며, 그 외 OTK 프로젝트 연구자가 참여하여 개발된 웹상에서 XML/RDF 기반 온톨로지와 추론  기능을 고려한 웹 온톨로지 언어인 OIL(Ontology Inference Layer), 지식 공학과 관리를 위한 방법론, 산업적 활용 가능성에 평가와 피드백 등이 프로젝트의 결과물로 제시되었다고 할 수 있다. 그리하여 OTK 프로젝트의 파트너였던 British Telecom Call Center, Swiss Life 생명보험회사 등에서 각각 Intranet 기반 가상 Community에서 온톨로지를 이용하여 정보를 공유하거나, 대용량 문서에서 관련 정보를 검색하는 업무에 온톨로지를 이용함으로써 실제 기업에서의 활용과 평가도 확인할 수 있다.


##########4*

[그림6] Tool for Semantic Web-based knowledge management


W3C Semantic Web Activity’는 W3C의 6개 분야 중 하나인 기술과 사회 분야(Technology and Society Domain)에서 다루는 웹 기술과 응용 표준 개발에서 필요한 6개의 활동 중 시맨틱 웹을 다루는 활동이다. 이 활동에는 세부적으로 Semantic Web Coordination Group, RDFCore Working Group(2001), RDF Data Access Working Group(2004), Web-Ontology Working Group(2001), Semantic Web Best Practices and Development Working Group(2004), Semantic Web Interest Group 등으로 형성되어 있다. 이 활동은 시맨틱 웹과 관련된 표준화와 더불어, 시맨틱 웹의 온톨로지 표준화에 앞장서고 있다. 특히 2002년 웹 온톨로지 언어인 OWL(Ontology Web Language)의 필요사항에 대한 초안 버전 1.0을 발표한 이후, 현재 많은 온톨로지 응용 분야에서 온톨로지를 OWL로 표현하고 있다.

 

##########5*

[그림7] Semantic Web Application: Semantic Search <TAP(building the semantic web) Project>[36]


3.2. 정보검색과 온톨로지


최근 정보검색 기술은 랭킹 시스템, 중복검색 결과 제거, 메타 검색, 분산․통합 검색, 전문 검색 등 다양한 분야의 정보들 중 사용자에게 더욱더 빠르고 정확하게 의미 있는 정보를 전달하고 하는 기술로 계속 발전하고 있다. 특히 최근에는 자연언어처리 기술을 이용한 의미기반 정보검색 기술이나 질의응답시스템 등이 활발하게 연구되고 있다[3].

이러한 연구 개발 흐름은 기존의 정보검색 기술 중의 하나였던 디렉토리 서비스, 키워드 기반 검색 등은 문서의 의미를 판단할 수 있는 기술은 아니었으므로, 그만큼 사용자의 의도에 맞는 정답 문서를 제공하지는 못하였다. 그리하여 사용자의 질의를 확장하기 위한 색인어 확장용으로 시소러스를 이용하여 사용자에게 의미 있는 문서를 제공하거나, 자연어 질의를 형태소 분석, 구문 분석, 의미 분석 단계를 거쳐 사용자의 의도를 분석하여 지식베이스와 추론 기법을 이용하여 의미 있는 문서를 제공하는 정보검색 기술이 이용되고 있다. 그러나 이러한 정보검색 기술 또한 아직까지 사용자의 질의 분석에서의 오류, 문서에서의 정확한 의미 분석 처리 문제, 단어 의미 중의성(word sense ambiguity) 문제 등 여러 가지 문제 때문에 실생활에서 사용하기에는 더 많은 시간이 필요할 것으로 보인다.

이러한 정보검색 기술 연구는 시맨틱 웹에서의 온톨로지 역할이 증가함에 따라, 현재의 웹 구조에 시맨틱 웹 기술을 결합한 시맨틱 웹 기반의 검색 시스템이 국내외적으로 개발 중에 있다. 즉 온톨로지 기반 정보검색 기술은 중요한 정보가 있는 자원을 빠르게 찾아 사용할 수 있다는 점과 자원을 찾는 정확도를 향상시킬 수 있다는 점에서 중요한 기술로 자리 잡아 가고 있다. 또한 검색엔진이 온톨로지에 정의된 개념과 규칙을 활용하면서, 온톨로지를 검색 향상을 위해 추론 규칙을 이용하기 때문에, 단순히 사용자의 질의와 일치되는 문서만 보여주는 것이 아니라 사용자의 질의의 의미를 분석하여 그와 관련된 정보를 온톨로지에 표현된 관계에 따라 다시 질의를 적절하게 바꿀 수도 있게 한다[2][14].

그러나 아직까지 국내외적으로 온톨로지 기반 정보검색시스템이 아직 개발 단계에 있거나 시범적인 운용 서비스 단계에 있기 때문에 온톨로지를 이용한 실질적인 활용 실태를 정확하게 확인하기는 힘들지만 몇몇 프로젝트의 결과물이나 보고서, 시범 운용 서비스 사이트를 통해 그 내용을 확인할 수 있다.

온톨로지 기반 정보검색시스템을 개발하기 위해서는 일련의 기술 정보를 마련해야 하는데, [그림8]는 ‘OntoWeb’ 프로젝트에서 온톨로지 기반 정보검색 애플리케이션 개발과 활용을 위한 가이드라인 항목과 정보검색시스템 설계 단계에 필요한 주요 사항을 나타낸 것이다.

 

##########6*

[그림8] Checklist for the implementation of an ontology application


3.3. 온톨로지 기반 정보검색시스템


온톨로지 기반 정보검색시스템을 개발하기 위해서는 [그림8]과 같이 일련의 가이드라인을 기술해야 한다. 즉 온톨로지를 이용한 애플리케이션의 성질을 결정하고, 사용자와 관련된 사항을 확인하고, 특정 조직의 정보과 지식에 대한 분석, 소유권 문제, 특정 조직 내 시스템 조사, 추론 처리 결정, 평가 기준과 측정 기준 결정, 활용 가능한 범위 결정, Data noise 고려, 존재하는 온톨로지들에 대한 연구, 온톨로지 관리 도구와 처리 절차 분석 등 여러 가지 사항들을 고려해야 한다.

온톨로지 기반 정보검색시스템 개발을 위해서는 여러 가지 요소 기술들이 필요함과 동시에 실질적인 온톨로지 구축과, 구축 기관과의 연계, 기존 정보검색 기술과의 융합 기술, 개발 결과의 적극적 활용 방법 등 많은 부분들을 고려하지 않으면 안 된다. 이는 시맨틱 웹에서의 온톨로지 활용 방법이 주요 관심사가 되면서 이러한 온톨로지 기반 정보검색시스템 개발은 앞으로 여러 연구 기관에서 대규모 또는 중소규모 실험 및 구축 개발이 진행될 것이다.

현재까지 연구 개발이 진행되고 있는 몇몇 온톨로지 기반 정보검색시스템의 사례를 통해, 실질적으로 온톨로지를 어떻게 정보검색에서 활용하고 있는지를 살펴보도록 한다.

[그림9]는 시맨틱 웹 기반 검색 시스템 구조를 설명한 것이다[1]. 이 시스템 구조는 서브시스템인 검색엔진과 온톨로지로 구분할 수 있는데, 온톨로지 저장소(ontology repository)를 중심으로 상위가 검색엔진이며, 하위가 온톨로지 시스템 구조이다. 검색엔진은 사용자가 시맨틱 웹의 사용과 에이전트와 RDF, 온톨로지를 이용한 추론 엔진의 연동에 대한 서브시스템 구조이며, 온톨로지 서브시스템은 시맨틱 웹에서 온톨로지를 생성하고 유지․관리하기 위한 시스템 구조이다[1]. [그림10]은 OntoWeb 프로젝트에서 온톨로지 기반 정보검색시스템의 기본적인 구조[30][36]를 설정한 것이다. 이들에서 알 수 있는 것은, 정보검색시스템에서 온톨로지가 더 많은 관련 결과들을 검색하기 위한 가이드 역할을 담당한다는 것인데, 더 나아가 더 많은 관련 결과는 개념에 대한 의미를 컴퓨터가 정확히 이해한다는 전제가 따른다는 것을 알 수 있다. 이는 이전의 정보검색시스템에서 해결하지 못한 질의나 문맥에서의 의미에 대한 처리 방법의 해결이라 할 수 있다.

 

##########7*

[그림9] Architecture of Semantic Web based Retrieval System

 

##########8*

[그림10] Basic architecture for ontology based information retrieval applications

 

ETRI에서 개발 중인 질의응답시스템인 anyQuestion는 엄밀한 의미에서는 시맨틱 웹 기술을 이용한 시스템은 아니지만, 백과사전을 기반으로 지식베이스를 구축하고, 이 지식베이스와 ETRI 어휘 개념망(온톨로지)을 유기적으로 연결시켜 일반적인 온톨로지 활용 기법을 어느 정도 이용하고 있는 시스템이라 할 수 있다[5]. 이것은 ‘개념망+정답문서집합(answer set)+속성집합’으로 이루어진 지식베이스를 활용한 의미기반 정보검색시스템에서도 반영되고 있다[3]. 즉 자연언어처리 기술, 질의응답 처리 기술, 텍스트 마이닝 기술 등을 시스템의 기반 기술로 하여, 사용자의 질의 의도를 분석하고, 온톨로지와 더불어 사실 정보(facts)와 지식 정보로 구성된 지식베이스가 유기적으로 연결되어, 온톨로지의 기본 활용 방법을 사용함과 동시에, 개체명 인식 기술과 의미 분석 기술 등을 활용하여 정확한 답을 제시할 수 있는 온톨로지와 지식베이스 기반 질의응답시스템이라 할 수 있다. 현재 백과사전 ‘인물’ 범주를 중심으로 시범적으로 서비스하고 있다(http://anyq.etri.re.kr).

 

##########9*##########10*

[그림11] "AnyQuestion 1.0" Question Answering System


OntoBroker는 웹 문서를 분석하기 위하여 온톨로지를 이용함과 동시에 온톨로지 기반 질의 처리를 하고 있는 시스템으로서[37], 확장된 HTML 문법을 사용자들이 문서를 온톨로지 구조로 마크업하기 위하여 제안되었으며,  사용자들이 OntoBroker Interface를 통해 수집된 지식 정보를 검색하고 문헌의 내용을 이해하기 위하여 그 지식 정보를 이용하게 한다. 여기에서 사용된 온톨로지는 정보 제공자와 탐색자를 위한 공통된 언어이며, 개념과 의미관계, 특정한 규칙으로 구성되어 있다. [그림13]은 OntoBroker의 구조를 나타낸 것이다.

 

##########11*

[그림12] OntoBroker Architecture

 

MELISA(MEdical Literature Search Agent)는 의학 분야 문헌 검색 에이전트 시스템[26]으로서, 의학에서의 온톨로지 기반 정보검색 에이전트의 프로토타입이라 할 수 있다. 이 시스템은 질의 생성에 사용되는 의학 지식을 중심으로 구축된  Medical 온톨로지, 18,000 카테고리로 만들어진 MeSH(Medical Subject Headings) 온톨로지와 Terms 등을 사용하여 기존 의학 분야 문헌검색시스템의 성능을 향상시키고자 개발된 문헌검색시스템이라 할 수 있다. 사용자 질의에 대한 처리 문제와 의학 분야 문헌의 질의에 의한 문헌 검색 정확률 향상을 위해, 검색 엔진의 중요한 요소이자 질의 생성 모듈에의 활용으로 Medical 온톨로지를 사용하고 있다.

 

 

##########12*##########13*

[그림13] General structure of MELISA(left), and Classes & instances of the medical ontology(right)


OSE(Odyssey Search Engine) 시스템은 온톨로지를 사용한 특정 영역 지식(domain knowledge)에 기반한 검색 시스템[23]으로서, 분산되고 이질적인 지식 정보에 상관없이 다양한 영역에서 특정 영역의 정보를 제어할 수 있도록 하는 검색 에이전트 시스템 개발을 목적으로 하고 있다. 또한 domain 온톨로지는 사용자의 특정 영역 정보의 식별과 검색을 위한 시스템의 기본 개념들이다.


##########14*

[그림14] Basic Architecture of Odyssey-Search Engine

 

이외에 온톨로지 기반 정보검색시스템을 다음과 같이 정리할 수 있다.

온톨로지 기반 이미지 검색 시스템과 관련하여, 먼저 Helsinki University 박물관의 이미지 데이터베이스를 바탕으로 한 시맨틱 웹 기술을 이용한 검색시스템 연구 개발[25]이 진행 중으로, 이 시스템은 이미지의 의미 주석과 검색을 위해 promotion 온톨로지에 기반한 이미지 검색시스템개발을 목표로 하고 있다. 이와 더불어 고대 가구 검색시스템에 사용하기 위하여 미술․건축 시소러스(AAT; Art and Architecture Thesaurus)의 고대 가구를 중심으로 RDFS를 이용한 온톨로지로 구축하는 방법과 ATT와의 연결 방법을 제시한 연구[18]도 있다.

또한, 온톨로지 기반의 교차언어 정보검색시스템 개발도 최근 연구가 활발한데, 대표적인 연구 기관으로 New Mexico State Univeristy의 CRL(Computing Research Laboratory)이 유명하다. 이 연구실은 Mikrokosmos Ontology를 이용한 다국어 기계번역으로 유명한데, 온톨로지 기반의 교차 언어 정보 검색(CLIR; Cross Language Information Retrieval) 시스템 연구 개발[20]이 진행 중에 있다. 국내에서도 온톨로지 기반 한의학 처방 관리시스템[6]이나 온톨로지 기반 웹 검색시스템[7] 등이 개발되고 있으나 아직까지 실험적인 수준에 그치고 있다.

현재 이러한 일련의 온톨로지 기반 정보검색시스템에 대한 평가 방법[24][31]에 대한 연구도 많이 진행되고 있다. 하지만 아직까지 정확한 평가 기준을 마련하기에는 어려운 실정이다.


4. 결 론


시맨틱 웹에서의 온톨로지 활용 기술은 웹 서비스 관련 분야뿐만 아니라 생물정보학, 자연언어처리, 데이터베이스, 인공지능, 정보검색, 기계번역, 분산시스템 등 다양한 분야에서 연구 대상으로 삼고 있다. 이것은 기존의 시소러스나 의미망, 어휘 데이터베이스 등과 같은 어휘의 계층적 구조와 어휘들의 관계로 표현되었던 어휘 집합 체계를 특정 분야에서만 활용했던 것과는 사뭇 다르다. 즉 온톨로지가 갑자기 관련 분야의 핵심 연구 대상으로서 차세대 정보 처리의 핵심 기술이나 자원으로 부각된 이유는, 먼저 웹이라는 거대한 지식 정보의 처리 방법과 현재 우리가 처한 수많은 지식 정보의 체계화 방안이 어느 정도 일맥상통함과 동시에, 다음으로 그 지식 정보의 처리에 사람의 사고방식과 동일한 형태의 의미 정보를 컴퓨터에 담아, 컴퓨터가 의미를 이해할 수 있도록 만든다는 메커니즘 때문이라고 판단된다.

현재 온톨로지에 대한 연구는 국내외적으로 지식기반․지능형 시스템 개발에서는 제외할 수 없는 핵심 기술이자 자원으로 인식되고 있다. 또한 많은 연구자들이 이 온톨로지에 관심을 가지고 있는 것도 사실이다. 하지만 국내에서는 아직까지 국외의 온톨로지 관련 프로젝트와 연구 활동처럼 근본적인 기반 연구가 되어 있지 못한 실정이다. 정보검색시스템뿐만 아니라 다른 온톨로지 활용 시스템 개발을 위해서는 이러한 기반 연구가 선행되어야 하며, 국가적 차원의 연구 기관과 대규모 프로젝트를 통해 국내외 온톨로지 표준화 작업의 참여뿐만 아니라, 시맨틱 웹 기술의 국내 기반 확충과 성장, 국제 표준에의 참여를 위해 많은 연구자들이 노력해야 할 것이다.


참고문헌


[1] 이재호, “시맨틱 웹의 온톨로지 언어”, 정보과학회지, 제21권, 제3호, pp. 18-27, 2003

[2] 양정진, “시맨틱 웹에서의 온톨로지 공학”, 정보과학회지, 제21권, 제3호, pp.28-35, 2003

[3] 장명길 외, “의미기반 정보검색”, 정보과학회지, 제19권, 제10호, pp. 7-18, 2001

[4] 옥철영, “한국어정보처리와 온톨로지”, 2004 한국어정보처리연구회 동계 튜토리얼 자료집

[5] 최호섭, 옥철영, 김창환, 왕지현, 장명길, “질의응답시스템을 위한 백과사전 기반 지식베이스와 온톨로지”, 제15회 한글 및 한국어 정보처리학술대회 자료집, pp. 177-183, 2003

[6] 이현실, 이두영, “온톨로지 기반 한의학 처방 지식관리시스템 설계에 관한 연구”, 정보관리학회지, 제20권, 제1호, pp. 341-371, 2003

[7] 김현희, 안태경, “온톨로지를 이용한 인터넷웹 검색에 관한 실험적 연구”, 정보관리학회지, 제20권, 제1호, pp. 417-455, 2003

[8] 정도헌, “시맨틱웹을 위한 온톨로지 언어와 구현사례 연구”, 정보관리연구, 제34권, 제3호, pp. 87-109, 2003

[9] 이강찬, 김성한, 민재홍, 박기식, 정인정, “시맨틱 웹 기반의 검색 시스템 구조”, 주간기술동향, 제1094호, IITA IT정보단, 2003, http://www.itfinder.or.kr

[10] Berners-Lee, T., Hendler, J., Lassila, O., "The Semantic Web", Scientific American, 2001

[11] Maedche A., Ontology Learning for the Semantic Web, Academic Publishers, 2002

[12] Davies, J., Fensel, D., Harmelen, F.V., Towards The Semantic Web, JOHN WILEY & SON Ltd, 2003

[13] Fensel, D., Hendler, J., Lieberman, H., Wahlster, W., Spinning the Semantic Web, The MIT Press, 2003

[14] Latifur Kahn, Feng Luo, "Ontology Construction for Information Selection", Proceedings of the 14th IEEE International Conference on Tools with Artificial Intelligence, pp. 122-127, 2002

[15] Daconta, M.C., Obrst, L.J., Smith, K.T., The Semantic Web, Wiley Publishing Inc. 2003

[16] Paola Velardi, Paolo Fabriani, Michele Missikioff, "Using Text Processing Techniques to Automatically Enrich a Domain Ontology", Proceedings of the international conference on Formal Ontology in Information System, pp. 270-284, 2001

[17] Gloria L. Zúñiga, "Ontology: its transformation from philosophy to information systems", Proceedings of the international conference on Formal Ontology in Information System, pp. 187-197, 2001

[18] Wielinga, B.J., Schreiber, A.Th., Wielemaker, J., Scandberg, J.A.C, "From Thesaurus to Ontology", Proceedings of the international conference on Knowledge capture, pp. 194-201, 2001

[19] Yannis Tzitzikas, Collaborative Ontology-based Information Indexing and Retrieval, Doctoral Dissertation, Department of computer science, University of Crete, 2002

[20] Abdelali. A., Cowie, J., Farwell, D., Ogden, B., Helmreich, S., "Cross-Language Information Retrieval using Ontology", TALN 2003, 2003

[21] José Saias, Paulo Quaresma, "A methodology to create ontology-based information retrieval systems", EPIA'03-11th Portuguese Conference on Aritificial Intelligence, pp. 424-434, 2003

[22] Guarino, N., Giaretta, Pierdaniele., "Ontology and Knowledge Bases-Toward a Terminological clarification", In N. Mars (ed.), Towards Very Large Knowledge Bases: Knowledge Building and Knowledge Sharing, pp. 25-32, IOS Press, 1995

[23] Braga, R.M.M., Werner, C.M.L., Mattoso, M., "Using Ontologies for Domain Information Retrieval", 11th International Workshop on Database and Expert Systems Applications (DEXA'00), pp. 836-840, 2000

[24] Aitken, S., Reid, S., "Evaluation of an Ontology-Based Information Retrieval Tool", 12th European conference on Artificial Intelligene(ECAI'00) Workshop on Applications of Ontologies and Problem-Solving Method, 2000

[25] Hyvönen E., Styrman A., Saarela, S., "Ontology-based Image Retrieval", Number 2002-03 in HIIT Publications, pp. 15-27, Helsinki Institute for Information Technology(HIIT), 2002

[26] Abasolo, J.M., Gómez, M., "MELISA. An Ontology-based agent for information retrieval in medicine", ECDL 2000 Workshop on the Semantic Web(SemWeb2000), pp. 73-82, 2000

[27] Gruber, T., "A Translation approach to portable ontology specifications", Knowledge Acquisition, vol.5, no.2, pp. 199-220, 1993

[28] Gruber, T., "Toward Principles for the design of ontologies used for knowledge sharing", International Journal of Human-Computer Studies, vol.43, no.5/6, pp. 907-928, 1995

[29] Uschold, M., Gruning, M., "ONTOLOGIES: Principles, Methods, and Applications", AIAI-TR-191, Artificial Intelligence Applications Institute(AIAI), the University of Edinburgh, 1996

[30] Uschold, M., King, M., Moralee, S., Zorgios, Y., "The Enterprise Ontology", AIAI-TR-195, Aritificial Intelligence Applications Institute (AIAI), the University of Edinburgh, 1997

[31] IST Project IST-2000-29243 OntoWeb report,  Project Full Title: Ontology-based information exchange for knowledge management and electronic commerce

[32] Moench, E., Ullrich, M., Schnurr, H., Angele, J., "SemanticMiner: Ontology-based Knowledge Retrieval", whitepaper, http://www.ontolprise.de

[33] http://www.w3c.org

[34] http://www.daml.org

[35] http://www.ontoknowledge.org

[36] http://www.cs.umd.edu/projects/plus/SHOE/

[37] http://ontoweb.aifb.uni-karlsruhe.de

[38] http://tap.stanford.edu

신고
document.write("");
Posted by 사우람
[이슈] 온톨로지에 대한 새로운 접근...06/24

 

 온톨로지(ontology)에 대한 관심이 높아지고 있다. 온톨로지란 어휘나 개념의 정의 또는 명세로서 정보시스템 분야에서는 시스템이 다루는 내용에 해당하는 구성요소(개념)를 의미한다. 분야마다 그리고 전문가마다 정의가 조금씩 차이를 보이고 있으며 또 잘못된 이해를 바탕으로 추상적인 견해를 피력하기도 한다.

 

◇ 어원 및 기본 개념

 온톨로지는 철학에서의 존재론으로 실재(reality)에 대한 정확한 이해를 추구하는 학문이다. 실재, 즉 이 세상을 규정하기 위해 이 세상에 존재하는 실체들에 대한 명확한 이해와 정의가 필요한데, 단순화시켜 말하면 ‘이 세상의 기본이 되는 구성요소에 대한 명확한 이해와 정의’라고 할 수 있다.

 컴퓨터 분야에서의 온톨로지 역시 정보시스템의 대상이 되는 분야에 존재하는 개체와 개념에 대한 명세로서 철학적 용어를 빌어 쓰는 데 무리는 없어 보인다. 모든 정보시스템은 정보시스템이 바라보는 적용영역(실재)에 대한 관점(view)의 반영이라 할 수 있는 온톨로지를 갖고 있다. 물론 그것이 독립된 형태로 구축되어 있지 않고 데이터베이스나 프로그램 코드에 스며들어 있을 수는 있으나 어쨌든 해당 응용의 개체나 개념, 프로세스 등은 엄연히 존재한다.

 

◇ 구성 및 기반 시스템

 온톨로지는 의료·기계제조·부동산·금융 등 특정 응용영역에 대해 만들어지는데, 그 분야의 기본 개념에 대한 정의와 그들간의 관계에 대한 명세로 이뤄진다. 가장 단순한 형태로는 어휘사전이나 용어모음을 생각할 수 있지만 컴퓨터가 처리할 수 있을 만큼의 구조성과 구체성을 갖춰야 온톨로지로 불리는 것이 일반적이다.

 온톨로지의 기본은 해당 영역에 존재하는 개념들이다. 예를들어 책·컴퓨터·책상·의자·구매·입찰 등이다. 각 개념은 다시 그 개념을 설명하는 속성들을 갖게 되는데, 예를들어 책은 저자·출판사·쪽·가격 등의 속성을 갖고 입찰은 대상·날짜·방식·조건 등의 속성을 가질 수 있을 것이다. 또 개념들은 서로 관계를 가질 수 있는데, 가장 기본적인 관계는 상하포함관계다. 예를들어 동화책은 책에 포함되는 하위개념이 된다. 발전된 온톨로지에서는 속성의 특성, 좀 더 복잡한 형식의 관계 등을 정의함으로써 풍부한 내용을 담을 수 있게 된다.

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

 

◇ 적용사례

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

 가장 먼저 온톨로지 개념을 적용한 컴퓨터 분야는 역시 지식표현과 활용을 연구하는 인공지능 분야다. 특히 에이전트 분야는 이미 90년대 초부터 분산된 환경에서 에이전트들이 상호작용을 통해 의미있는 문제를 해결하기 위해서는 서로 공유할 수 있는 기본 지식기반의 필요하다는 것을 인식하여 일종의 온톨로지라 할 수 있는 개념 계층도(concept hierarchy) 등을 이용했으며, 지식과 정보를 교환하기 위한 질의어(예 KQML-Knowledge Query and Manipulation Language)와 지식교환형식(예 KIF-Knowledge Interchange Format) 등을 정의했다. 특히 미 국방연구처(DARPA)의 DAML-OIL(DARPA Agent Markup Language - Ontology Inference Layer)은 대표적인 온톨로지 표현언어 및 형식으로 받아들여지고 있다.

 또 다른 대표적인 분야는 정보검색이다. 용어모음이나 동의어사전 형태만으로도 불필요한 오류를 방지할 수 있고 검색효율을 높일 수 있다. 예를들어 사용자가 잘못 기재한 ‘불공정 거레’라는 키워드는 온톨로지를 이용해 ‘불공정 거래’로 바로잡아질 것이며, ‘불공정 경쟁, 독점, 덤핑, 정부 보조금’과 같은 유사 또는 관련어를 이용해 더욱 풍부한 검색서비스를 제공할 수 있게 된다. 개방형 디렉터리 프로젝트(ODP http://www.dmoz.com)에서는 자발적으로 참여하는 사람들에 의해 인터넷 정보의 분류체계를 만들고 있으며, 이 분류체계는 구글(http://www.google.co.kr) 등 상용검색사이트를 비롯한 수많은 사이트에서도 사용될 정도로 대표적인 웹정보 분류체계로 받아들여지고 있어 처음 방문하는 사이트에서도 익숙한 분류 카테고리를 이용할 수 있는 경우가 점점 많아지고 있다.

 시맨틱 웹(semantic web)의 궁극적 목표는 컴퓨터도 이해할 수 있는 지식의 원천으로서의 웹을 만드는 것인데, HTML 형태의 문서들로 이뤄진 현재의 웹은 사람에게 정보를 주는 역할은 하고 있지만 컴퓨터 프로그램이 각 문서의 내용을 정확히 파악할 수 없다는 문제의식에서 출발한다.

 ‘불공정 거래에 대한 사례를 열거한 석사 또는 박사 논문’에 해당하는 문서를 컴퓨터 프로그램이 찾을 수 있도록 하기 위해 우선 문서내용에 의미있는 태그(tag)를 붙여야 하며, 각 태그가 의미하는 개념에 대한 온톨로지가 있어야 할 것이다. 시맨틱 웹의 중심에 확장성표기언어(XML)를 기반으로 하는 RDF(Resource Description Framework)와 DAML-OIL을 발전시킨 OWL(Ontology Web Language)이 있는 것은 이러한 이유다.

 유비쿼터스 컴퓨팅(ubiquitous computing)은 또 다른 흥미로운 분야다.

 휴대형의 작은 무선기기들이 동적으로 임의 네트워크를 형성하는 환경에서 각 기기들이 서로의 서비스 기능을 광고하고 또 인식할 수 있어야 하는데, 서로 다른 시기에 상이한 업체에 의해 제조된 기기들 사이에서 이를 가능하게 하기 위해서는 동적으로 접근이 가능한 온톨로지의 사용이 타당한 대안으로 제시된다.

 

◇ 전자상거래에서의 온톨로지

 온톨로지가 가장 널리 파급될 가능성이 있는 분야는 전자상거래 분야다. 컴퓨터 프로그램이 상거래의 일부 또는 전부를 맡아서 처리하는 것이므로 프로그램이 다양한 상거래 개념을 이해하고 처리해야 할 것이다. 로제타넷과 같은 전자상거래 프래임워크는 종합 온톨로지라 할 수 있는데, 예를들어 로제타넷의 PIP(Partner Interface Process)는 거래 프로세스의 온톨로지로 볼 수 있고 로제타넷비즈니스사전(RNBD)과 로제타넷기술사전(RNTD)은 각각 비즈니스와 기술적인 개념들의 온톨로지로 볼 수 있다. 즉 표준화할 수 있고 일반화할 수 있는 개념들을 컴퓨터가 처리할 수 있는 형식으로 명시함으로써 공유할 수 있고 재사용이 가능한 틀을 제공할 수 있는 것이다.

 전자카탈로그 또한 온톨로지와 직접적으로 관련이 있다. 상품분류체계의 표준인 국제상품분류코드체제(UNSPSC)나 HS, e클라스(eClass) 등은 각각 상품이라는 개념들을 나름대로의 관점으로 계층관계를 정의한 단순한 형태의 온톨로지라 할 수 있다. 안타까운 것은 이들 분류체계가 전자카탈로그 구축의 핵심으로 인식되고 있다는 점이다. 예를들어 전자카탈로그 구축작업이 이들 분류체계 밑단에 상품을 달아보려는 노력으로 시작되곤 하는데, 이는 주객이 전도된 경우다.

 상품 온톨로지 또는 전자카탈로그 온톨로지의 중심은 상품이며, 그 상품에 어떤 속성이 있는가는 2차적인 문제다. UNSPSC의 어느 부분에 이 상품이 분류되는가는 이 상품을 바라보는 하나의 관점인 속성에 불과할 뿐 이 상품을 결정짓는 핵심사항이 될 수 없는 것이다. 구축하는 전자카탈로그의 질적인 우수성 확보라는 측면에서 온톨로지 기반의 방법론을 권고하는 바다.

 

◇ 향후 과제

 조달청이 국가조달물품을 중심으로 한 온톨로지 구축에 나선다는 것은 매우 고무적인 일이다. 풍부한 상품정보를 기반으로 온톨로지를 구축한다면 앞서 언급한 지식의 공유와 재사용, 시스템 연계 측면에서 G2B뿐만 아니라 민간 B2B 분야에 미치는 긍정적 파급효과가 클 것으로 기대된다.

 산업자원부가 추진하는 B2B 시범사업은 벌써 40개 업종에 걸쳐 진행되고 있는 의욕적인 사업으로, 다른 것을 제외하더라도 구축될 엄청난 상품 콘텐츠만으로도 의미있는 사업이라 할 수 있다. 다만 이 상품 콘텐츠의 질적 수준을 확보하는 것이 무엇보다도 중요하며 이를 위해 온톨로지적인 접근방법과 해당기술의 개발·보급이 시급하다고 판단된다. 도서관·박물관 등과 같은 문화정보화사업이나 디지털 콘텐츠 구축사업 역시 결과물인 콘텐츠의 질과 사용편이성을 높여야 할 것이며, 온톨로지 기반의 방법은 이 분야에도 기여할 수 있을 것으로 생각된다.

 온톨로지는 분명 콘텐츠다. 하지만 콘텐츠를 어떻게 담고 조작하며 서비스할 것인가는 쉽지 않은 기술적 문제다. 미국과 유럽의 온톨로지 기술에 대한 연구는 90년대 후반부터 본격화됐으며 빠른 속도로 발전하고 있다. 많은 종류의 콘텐츠 개발사업에 바로 적용될 수 있는 온톨로지 응용기술의 개발과 보급이 무엇보다 시급하며, 차세대를 바라보는 중장기적 연구노력도 함께 병행될 수 있어야 할 것이다.

 

 이상구 서울대 교수
 
서울대학교 계산통계학과 졸업
 미국 노스웨스턴대 석·박사
 미국 EDS R&D 연구원
 현 서울대 컴퓨터공학부 교수
현 서울대 e비즈니스기술연구센터장
 연구분야:데이터베이스, e비즈니스 기술

신고
document.write("");
Posted by 사우람

##########0*정보획득 능력의 차이가 사람의 능력을 좌우한다. 원시시대에는 귀동냥으로 정보를 획득했지만, 시대가 흐름에 따라 문자를 통한 정보획득이 가능해지면서 축적된 정보의 활용이 가능해졌다. 인쇄술의 발달은 정보의 대중화를 이루었으며, 매스컴은 문자를 넘어서서 음성과 멀티미디어 정보를 실시간에 저렴한 비용으로 배포할 수 있게 했다.

 

그러나 이런 모든 정보유통의 발전도 지난 10여 년간 웹 중심의 인터넷이 이루어낸 정보유통의 변화와 비교 할 수 없다. 인터넷은 정보소비자와 정보생산자의 구별을 없애고 정보획득 장벽을 철폐함으로써 정보유통의 민주화와 대중화를 가져왔다. 멀티미디어 정보를 비롯한 모든 종류의 정보를 거의 공짜에 가까운 비용으로 배포하고 획득할 수 있게 했다. 이런 정보유통의 혁명은 사회민주화와 세계화를 이루어 내면서, 동시에 정보획득 불균형의 확대라는 새로운 문제를 야기했다. 더구나 인터넷에 의해 무차별로 배포되는 정보에서 알짜 정보를 찾고, 거짓 정보, 쓰레기 정보, 불필요한 정보를 제거하는 것은 현재 사용하는 단순링크(링크에 정보가 없이 지시만 하는) 기반 인터넷에서는 현실적으로 불가능하다.

 

정보를 이용하려면, 먼저 다양한 방법으로 정보를 획득하고, 이를 자신이 원하는 목적에 따라 분석하고 가공하여 정보를 통합하고, 이를 바탕으로 정보를 활용하거나 또는 통합한 정보를 다시 배포하게 된다. 그런데 단순링크 기반 인터넷에서는 색인어에 기반을 둔 정보검색시스템이나 주제에 따라 홈페이지를 분류한 분류시스템에서 제공하는 정보를 바탕으로 필요한 정보를 획득해야 한다. 그런데 정보검색 시스템이 제시하는 정보는 지나치게 많으며, 분류시스템의 분류방법은 대부분 사용자가 원하는 형태로 되어있지 않다.

 

따라서 정보획득이 우연에 의해 이루어질 수밖에 없다. 이 문제를 가장 쉽게 해결하는 방법은 언어나 멀티미디어 정보를 인간처럼 이해하여 처리할 수 있는 기술을 개발하는 것이다. 그러나 이런 기술이 조만간 개발될 가능성은 없다. 한편, 오랜 기간 동안 특정 분야에서 정보를 획득한 경험자는 자기만의 경험적 지식을 바탕으로 필요한 정보를 획득한다. 그리고 일부 전문가는 정보획득에 필요한 정보(일종의 메타정보)를 모은 사이트를 만들기도 한다.

 

그런데 같은 분야의 전문가라도 각자 정보획득에 사용하는 방법 또는 표현 방법에 차이가 있다. 그런데 이런 전문가가 정보획득에 도움을 주고자 만든 사이트 자체가 역시 단순링크 기반으로 정보가 표현됨으로써 한계가 있다. 더구나 다양한 전문가가 각자 다른 관점에서 정보를 찾는 방법을 표현했다면 모든 사이트를 방문하여 분석하고, 그 결과를 바탕으로 필요한 정보를 획득해야 하므로 어려움이 크다. 정보이용자는 자신이 원하는 정보만을 자신이 원하는 형태로 제공받기를 원한다. 지금처럼 거의 무한으로 확장되고 있으면서 거짓정보와 진짜정보, 필요한 정보와 불필요한 정보가 뒤섞인 인터넷 환경에서 정보유통의 효율화를 이루면서, 정보이용의 격차를 극복하고, 정보 이용을 극대화하려면 사용자가 원하는 정보만을 획득할 수 있는 방법론이 제공되어야 한다.

 

이 일환으로 Tim Berners-Lee가 제시한 새로운 인터넷 환경이 시맨틱웹이다. 시맨틱웹이 정말 이런 문제를 해결할 수 있을지는 아무도 모른다. 그러나 지금까지 제시된 방법론 중에서는 가장 설득력이 있다. 이 글에서는 시맨틱웹의 장점, 한계, 극복해야 할 점 등을 중심으로 시맨틱웹의 가능성과 한계를 살펴보겠다.

 

시맨틱웹, 가능성과 한계

 

##########1*인간은 의미 또는 개념에 따라 정보를 획득하고 가공한다. 그러나 기존기술로는 기계가 언어를 이해하기는 불가능하다. 따라서 Tim Bereners-Lee는 의미를 인간이 직접 메타정보로 제공하는 방법을 생각했다. 즉, 인터넷에서 접근할 수 있는 또는 세상에 존재하는 객체(object, URI로 표현)에 대해 의미에 기초하여 정보의 내용과 개념 따위를 표현하는 체계를 만든 것이 시맨틱웹이다. 정보 제공자나 이용자가 경험에서 얻은 정보획득에 필요한 메타정보 또는 자기가 접근한 사이트나 페이지의 내용에 대한 정보 따위를 의미에 기초하여 기록하여 인간뿐 아니라 기계도 활용하게 하는 것이다.

 

그런데 ‘의미(뜻)’ 그 자체를 정의하거나 표현하기는 매우 어렵다. ‘커피’라는 말은 그 차체로 뜻이 있지만, 응용분야에 따라 의미를 더 세분화해야 할 수도 있다. 즉, 문맥에 따라‘커피나무’, ‘커피열매’, ‘음식’또는 ‘음료수’따위로 다르게 해석할 수 있다[홍재성(서울대) 교수의 발표 중]. 따라서 어떤 차원에서 의미를 표현하느냐에 따라 달라질 수 있다. 따라서 우리가 쓰는 단어를 그대로 의미표현에 쓸 수는 없다. 시맨틱웹에서 뜻하는‘의미표현’은 인간뿐 아니라 기계(프로그램)도 이해할 수 있는‘의미’를 뜻한다. 기계가 이해한다는 말은 매우 중요하다. 즉, 인간이 메타정보를 주면, 그것을 이해하여 프로그램이 의미에 따라 정보를 통합하여 제공할 수 있어야 한다는 전제조건을 가정한 것이다. 따라서 응용분야에서 기계가 하나로만 해석할 수 있는‘의미’단위를 가정해야 한다.

 

그런데 이런 의미를 모두가 공감하게 표현하는 방법은 없다. 이에 따라서 일종의 name space에서 이야기하는 의미 표현방법을 시맨틱웹이 도입하고 있다. 즉, 나는 “여기서 이 단어를 이런 의미로 사용한다.”라고 선언하고, 그에 따라 의미를 표현하는 접근을 취한다. name space는 어떤 용어(terminology)를 어떤 의미 (gloss, 주석으로 구체화)로 사용하겠다고 정의한 것이다. 예를 들어, ‘역학’을 쓸 때, 물리학에서 이야기하는 ‘역학(力學)’으로 쓰겠다거나 주역에서 말하는‘역학(易學)’으로, ‘역학(疫學, 질병 관련)’또는‘역학(曆學)’으로 쓰겠다는 것을 의미에 따라 구별하여 쓸 수 있게 하는 것이다.

 

용어뿐 아니라 개념을 표현할 때도 의미해석에 중의성이 없어야 한다. Dublin Core에 의해 날짜를 표현하면 해석이 언제나 일정한 것이 예가 된다. 예를 들어, “URI가 가리키는 객체(사이트)에는 어떤 정보가 있는데 신뢰도는 어느 정도다”라는 것을 개념화하여 기계가 이해할 수 있는 형태로 표현할 수 있어야 한다. 이렇게 함으로써 기계가 뜻을 이해하고, 정보를 정확히 추출하며, 또한 다양한 정보를 통합하여 제공할 수 있다. 개념화하여 정보를 표현하기 위한 언어가 RDF(Resource Description Framework)이며, RDF에 형(type)을 제공하여 의미적 완결성을 보장하기 위한 방법이 RDFSchema이다. RDF가 3개 요소(triple, URI, Property,Value)로 지식을 표현하는 것은 이것이 가장 단순하면서 보편적인 지식표현 구조이기 때문이다. 또 RDF로 표현된 메타데이터에서 필요한 정보를 추론하고, 정보를 통합하기 위한 도구가 OIL이다.

 

그런데 인간이 의미에 따라, 중의성이 제거된 개념화를 거쳐 메타데이터로 정보를 표현하기는 매우 어렵다. 더구나 같은 내용을 사람에 따라 다른 방법으로 표현할 수도 있다. 따라서 시맨틱웹은 분야별로 개념표현 방법을 표준화하고, 이를 바탕으로 메타데이터를 표현한다. 그러나 인간이 정보를 표준화한 방법으로 제공해야 한다는 것은 시맨틱웹의 한계가 될 수 있다.

 

Tim Berners-Lee는 이 문제가 개방 환경인 인터넷의 특성에 의해 많은 사람(다수의 힘)이 다양한 형태로 메타데이터를 제공할 것이므로 해결할 수 있다고 본다. 그런데 현재 상용화된 시맨틱웹 기반 응용 시스템은 많아야 100개 내외의 개념만 활용하고 있다. 이는 언어처리나 지식처리 분야에서 사용하는 개념의 수에 비하면 매우 적다. 그 이유는 응용분야를 제약함으로써 그만큼 필요한 지식을 표현하는 데 쓰이는 개념의 수가 적은 데 기인할 수도 있고, 개념의 수가 너무 다양해지면 그만큼 인간의 노력이 더 들기 때문일 수도 있다. 기존 시맨틱웹 응용 시스템은 인간이 직접 표현한 메타정보와 데이터베이스의 구조에서 얻은 메타정보 및 기계가 자동처리하여 얻은 메타정보(정보검색시스템이 제공한 시맨틱웹의 가능성과 한계 순위정보, 다른 시맨틱웹이 제공하는 정보)를 바탕으로 정보를 통합하여 정보를 제공한다.

 

최근 시맨틱웹의 응용영역은 크게 확장되고 있다. 인터넷에서 프로그램과 프로그램이 의미에 따라 정보를 교환하기 위한 시맨틱웹에 기반을 둔 웹서비스를 구상하기도 하고(시맨틱 웹서비스), 업무 흐름(business process)을 시맨틱웹에 기초하여 정의하고 이를 인터넷으로 통합하려고 노력하고도 있다. 또 제품의 사양, 하드웨어/소프트웨어 특성, 개인의 성향, 개인이 느끼는 가게나 제품에 대한 인상 등을 시맨틱웹에 의한 메타데이터로 표현하려고 하고도 있다.

 

‘Semantic Web Challenge 2003’에서 시맨틱웹 응용 시스템의 최소한 요구조건을 다음과 같이 정의했다. 응용시스템이 활용하는 정보가 지리적으로 분산되고, 소유권이 다양하여 제어가 어려우며 구조적으로나 의미상으로 이질적이며 실세계 자료를 바탕으로 해야 하고, 정보가 계속 변하는 개방형 환경에서 작동하는 응용시스템이어야 하며, 응용시스템이 사용하는 자료가 형식론적 표현(formal description)을 따라야 한다.

 

위에서 말하는‘지리적’이란 정의는 인터넷이 가진 분산 환경을 뜻하지만, 실제는‘개념적으로 분산되어 있다’는 말이 더 적합하다. 시맨틱웹에서 개념화는 매우 중요하다. 그런데 응용목적, 응용분야, 개념화하는 사람에 따라 사용하는 용어나 개념화에 차이가 나게 마련이다. 그러나 인터넷의 개방적 특성으로 볼 때, 이 모든 차이를 인정하면 제어가 어려워질 가능성이 크다. 따라서 시맨틱웹은 공통의 온톨로지를 이용한 개념화를 가정한다. 시맨틱웹에서 뜻하는 온톨로지는 특정영역에서 사용하는 어휘를 뜻한다. 이는 name space로 구현된다.

 

온톨로지에 쓰인 어휘들은 여러 가지 방법으로 체계화 할 수 있는데, 가장 손쉬운 방법이‘is-a’관계에 의한 시소러스 형태의 체계화이다. 이 외에도 ‘part-of’나 여러 다른 방법으로 어휘 간 관계를 정의할 수 있다. 그런데 온톨로지는 사용하는 언어가 다르거나, 온톨로지를 정의한 집단(전문분야)이 다르면 달라진다. 한편, 같은 내용을 같은 온톨로지로 표현하더라도 개념화가 다르면 결과는 다르다. 개념화할 때 사용하는 온톨로지가 다르면 만들어진 메타데이터도 달라진다. 같은 내용을 다른 목적에서 다른 온톨로지로 개념화하여 표현하면 달라진다.

 

그런데 시맨틱웹 응용시스템은 필요한 정보가 다른 온톨로지에 기초하여 다른 개념화에 의해 표현되었더라도, 온톨로지를 번역하고 개념을 추론하여 해당 응용시스템이 요구하는 정보로 가공하여 응용시스템의 메타데이터 형태로 변환할 수 있어야 한다고 주장한다. 이를 위해서는 메타데이터의 의미를 표현하는 언어가 형식론적으로 표현되어야 한다. 이렇게 되어야 추론을 통하여 지식을 변환할 수 있다.

 

위에서 말한 정의는 다른 온톨로지를 사용함에 따른 메타데이터에 쓰인 용어의 차이, 개념화를 다르게 함에 따른 표현구조나 의미표현 방법의 차이, 메타데이터를 만든 목적의 차이에 따른 개념화의 차이 등 개방적 구조에 따른 문제점을 극복하고, 정보를 획득하여 가공하고 통합하여 제공할 수 있는 응용시스템을 시맨틱웹 응용시스템으로 정의한다. 그러면 시맨틱웹에서 주장하는 온톨로지와 자연언어처리나 지식표현에서 말하는 온톨로지에 차이는 있을까? 기본적으로 RDF는 모든 지식을 표현할 수 있다. 따라서 제한 없이 자유롭게 쓴다면 차이가 없다. 더구나 언어처리나 지식표현에서 의미를 표현하기 위해 의미요소를 정의하는, 예를 들어 몬테규가 사용하는 의미표현은 name space와 유사한 면이 많다.

 

그러나 시맨틱웹은 일반상식을 표현하기 위한 의미체계를 가정하지 않는다. 따라서 언어처리나 지식표현에서 시맨틱웹, 개념화 그리고 온톨로지 요구하는 수준보다는 매우 낮은 수준의 의미표현을 가정한다. 즉, 응용영역을 제한하고, 그 영역에서 문제를 해결하는데 필요한 수준에서 의미를 표현하려고 한다. 따라서 지금까지 구현된 시맨틱웹 응용시스템은 100개 내외의 개념만 사용하고 있다. 의미표현에서 더 중요하고 더 큰 차이는 언어처리나 인공지능에서는 문제에 내재하는 중의성(ambiguity, 전산학에서는 모호성으로 번역)을 기계가 제거하는 데 온톨로지를 사용하지만, 시맨틱웹은 처음부터 중의성이 제거된 자료를 대상으로 하며, 추론과정에서도 중의성이 발생하지 않는다고 본다는 면이다. 사람이 처음부터 메타데이터를 만들 때, 또는 다른 프로그램에서 정보를 가져올 때 이미 자료에 중의성이 없다는 가정은 시맨틱웹이 의미기반의 메타데이터를 쓰되 언어처리나 인공지능에서 극복하지 못한 기술적 장벽을 피하려는 시도로 보인다.

 

따라서 언어처리나 인공지능을 위한 지식표현방법을 시맨틱웹 응용에 바로 적용하는 것은 매우 위험하다. 더구나 인공지능에서 말하는 시맨틱 네트워크를 시맨틱웹과 동일시하는 것은 잘못되었다. 언어처리나 인공지능을 위한 지식표현은 온톨로지의 번역이나 통합이라는 개념을 쓰지 않지만 시맨틱웹이 이 개념을 쓰는 이유도 영역에 따라 또는 응용분야에 따라 다르게 표현된 정보를 활용하고, 통합하려는 시도에서 나왔다. 그런데 아주 제한된 수준에서 만들어진 온톨로지가 아니고, 실제 문제에 활용된 온톨로지를 자동으로 통합하고, 이를 통해 필요한 정보를 의미에 따라 번역하여 활용할 수 있을까? 그렇게 희망적이지는 않다. 한 가지 해결방법은 워드넷과 같은 일반적 의미체계를 기반으로 영역별 온톨로지를 만드는 방법이 있다. 이렇게 하면 어느 정도 자동으로 온톨로지를 통합할 수 있다.

 

이에따라 최근에는 온톨로지를 통합하면서 인간이 어느 정도 개입하는 방법을 주로 쓰고 있다. 그렇더라도 무작위로 만든 온톨로지를 통합하기는 쉽지 않을 것이다. 이에 대한 연구가 잘 되느냐가 시맨틱웹의 성공에 큰 영향을 줄 것이다. 온톨로지가 통합되면 개념화하여 표현된 지식의 변환이 가능할까? 이 또한 부정적인 면이 많다. 물론‘사람과 직업, 주소’, ‘자동차를 만든 회사’따위의 간단한 지식은 쉽게 변환할 수 있다. 그러나 선호도를‘상, 중, 하’로 분류한 사이트와‘1-10’의 단위로 분류한 사이트의 개념을 통합하려면 어려움이 상당히 있다.

 

더구나 어떤사람의 건강에 대한 평가를 수치로 표현한 정보를 얻었더라도, 그 수치가 구체적으로 무엇을 뜻하는지를 정보를 제공한 사이트에서 정확히 얻지 못한다면 수치는 의미가 없다. 그런데 시맨틱웹은 개방성을 가정하므로 이런 문제는 쉽게 해결하지 못할 것이다. 더구나 수치에 대한 판단이 통계를 바탕으로 지속하여 바뀐다면 그 내용을 메타데이터로 받지 않는 한 사용할 수 없다. 지식(메타데이터) 또는 정보의 재활용은 시맨틱웹의 성공에 중요한 요소다. 온톨로지의 개발은 어렵고 비용이 많이 들므로 대부분 기존에 개발된 온톨로지를 쓰거나 약간 바꾸어 쓸 것이라는 면은 시맨틱웹의 성공에 긍정적인 면이다.

 

또 어떤 전문분야 사람이 자신이 가진 정보획득 지식이나 경험을 표현하는 방법은 비슷하므로, 한번 개발한 온톨로지나 개념화 방법은 비슷한 영역에서 같이 사용될 것이라는 것도 같다. 또 전자상거래와 같이 자신의 정보를 최대한 다른 필요로 하는 사람이 원하는 형태로 쉽게 획득할 수 있게 하려는 의도가 있는 사이트는 표준화만 한다면 이 온톨로지를 따를 것이므로 역시 시맨틱웹이 힘을 발휘할 것이다.

 

여러 기관이 정보를 공유해야 하는 분야도 시맨틱웹 개념이 잘 활용될 수 있다. 또 웹서비스를 활용한 ASP(Application Service Provider), 분산정보처리 등도 시맨틱웹이 잘 활용될 수 있는 분야로 본다. 기존 인터넷은 정보과부하에 따라 한계에 도달했으며, 어떤 형태로든 이 문제를 해결해야 한다. 이 해결방법은 의미에 의한 정보접근일 수밖에 없다. 또 인터넷에 있는 정보의 양으로 볼 때 기계가 능동적으로 의미에 기초하여 사용자가 원하는 형태로 정보를 통합하고 가공하여 제공해야 한다. 그러나 이런 문제를 해결할 만큼의 지능성이 있는 기계의 개발은 쉽지 않다. 따라서 이 문제의 극복 방법으로 현재 가장 실현가능성이 큰 것이 시맨틱웹이다.

 

글: 권혁철 교수(부산대학교 전자전기정보컴퓨터공학부·hckwon@pusan.ac.kr)

* 본 내용은 원문을 요약 발췌한 내용입니다.
자세한 내용은 원문 출처를 통해 확인하실 수 있습니다.

원문출처: http://www.kisti.re.kr/html/kisti/knowledge/infra_2004_15/15_19.pdf
내용출처: 한국과학기술정보연구원: 지식정보인프라지 통권 15호

신고
document.write("");
Posted by 사우람

[ 시맨틱 웹의 개요와 연구동향 ]
=======================================================================

목 차

1. 시맨틱 웹의 개요
2. 시맨틱 웹에서의 XML의 역할
3. 시맨틱 웹에서의 RDF의 역할
4. 온톨로지의 필요성과 역할
5. 시맨틱 웹 응용
6. 국내외 연구동향과 향후 발전방향
참고문헌


1. 시맨틱 웹의 개요


Tim Berners-Lee에 의해 1989년에 처음 제안된 월드와이드웹은 널리 알려진 클라이언트-서버 개념과 쉽게 익힐 수 있는 간단한 HTML 언어를 이용하여 편리성을 추구한 덕분에 일반 사용자 누구나 쉽게 정보를 접근하거나 게시할 수 있게 되었고, 결과적으로 폭발적인 정보의 증가를 가져왔다. 웹에는 현재 수많은 기관과 커뮤니티, 개인들이 서로 다른 목적으로 생성한 셀 수 없을 정도의 많은 문서와 정보가 포함되어 있다. 사용자들은 이러한 정보를 이용하기 위해 브라우저에 URL 주소를 직접 입력하거나 하이퍼링크를 따라가기도 하고, 검색엔진의 도움을 받기도 한다. 이러한 단순성이 현재 웹의 성장을 가져온 중요 열쇠가 되기도 하였다.

하지만 이런 단순성이 웹의 정보가 감당할 수 없을 정도로 방대해진 현 상황에서는 문제점으로 작용하기도 한다. 검색 측면에서 보면 현재의 웹 검색엔진은 주로 단어의 빈도수나 어휘 정보를 이용하여 문서의 유사도를 측정하고 랭킹을 매기기 때문에 사용자의 질의와는 관계없는 많은 문서를 결과로 가져올 수 있고 이로 인해 사용자는 불필요한 정보를 걸러내느라 시간을 낭비하게 된다. 또한 HTML로 여러 관련 문서를 확장하거나 통합, 공유하는 것은 매우 어렵다.

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

Tim Berners-Lee는 시맨틱 웹이 기존의 웹과 완전히 구별되는 새로운 웹의 개념이 아니라 현재 웹을 확장하여 웹에 올라오는 정보에 잘 정의된 의미를 부여하고 이를 통해 컴퓨터와 사람이 협동적으로 작업을 수행할 수 있도록 하는 패러다임이라고 그 역할을 정의하였다.[1] 대표적인 월드와이드웹 표준화 단체인 W3C(World Wide Web Consortium)에서는 시맨틱 웹을 RDF나 기타 다른 표준을 기반으로 웹에 있는 데이터를 추상적으로 표현하는 것이라고 정의하였다. 두 가지의 정의가 어떻게 보면 일맥 상통한다고 할 수 있으며 결국은 기존의 웹 데이터에 의미를 부여할 수 있는 표현 방법을 제시하는 것으로 요약된다.

시맨틱 웹의 궁극적인 목적은 웹에 있는 정보를 컴퓨터가 좀 더 이해할 수 있도록 도와주는 표준과 기술을 개발하여 시맨틱 검색, 데이터 통합, 네비게이션, 타스크의 자동화 등을 지원하는 것이다. 세부적으로 기술한다면 다음과 같은 작업을 가능하게 하는 데 있다.

 

  • 정보를 검색할 때 더욱 정확한 결과를 가져온다.

  • 서로 다른 이형질 소스의 정보를 통합하고 비교한다.

  • 어떤 리소스에 대해서도 의미적이고 기술적인 정보를 연관시킨다.

  • 웹 서비스의 자동화를 위해 웹에 세부 정보를 첨가시킨다.

 

시맨틱 웹을 실현하기 위한 다양한 접근 방법이 제시되었다. 하지만 HTML을 기반으로 한 현재의 웹을 개선하는 기본 취지에서 보면 시맨틱 웹을 달성하기 위해 웹 프로토콜과 같은 하위 레벨의 개념을 정의하고 이 하위레벨을 이용하여 다음 레벨의 개념을 정의하는 계층구조(layered structure)를 설정하는 것이 일반적인 연구 방향이다. 시맨틱 웹의 계층구조는 <그림 1>과 같다.


##########0*



이 계층구조에서 보면 가장 하위 레벨에서 웹 프로토콜에서 자원을 지칭하기 위한 주소지정(addressing) 방법인 URI가 밑받침되고 이를 기반으로 XML과 Namespace, RDF와 RDF 스키마, 온톨로지의 순서로 연구가 진행되고 있으며 그 위의 계층인 Logic에 대해서는 인공지능의 추론연구를 밑받침으로 일부 연구가 시작되었다. 또한 보다 더 상위 계층인 Proof와 Trust는 시맨틱 웹 정보의 신뢰성과 보안에 관한 내용으로서 아직 개념 정도만 얘기되고 있으며 차후 연구과제로 제시되고 있다. 본 논문에서는 이러한 시맨틱 웹의 주요 개념 중에서 현재까지 연구가 진행된 XML, RDF, 온톨로지 등의 필요성과 시맨틱 웹에서의 역할을 주로 기술하고자 한다.



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

XML은 SGML의 subset으로 구성된 마크업 언어로서 시맨틱 웹이라는 개념과는 별개로 HTML의 비구조성을 극복하기 위해 이전부터 제시되었던 것이다. HTML에 비해서 XML은 잘 정의된 구조화 문서(well-structured documents)를 작성할 수 있도록 해준다. 즉, 요소(element)라고 불리는 시작 태그와 종료 태그가 반드시 쌍으로 존재해야 한다는 것과 중첩 구조가 반드시 지켜져야 한다는 등의 제약조건이 반드시 만족되어야 한다. 시맨틱 웹과 관련된 XML의 역할은 이러한 구조화된 문서의 생성을 이끌어낸다는 것도 있지만 태그의 이름을 사용자가 자유롭게 정의할 수 있기 때문에 의미정보를 나타낼 수 있는 태그 이름을 사용할 수 있다는 것이 더 비중을 차지한다. [2] 예를 들어 다음과 같은 XML 문서는 간단한 메모의 작성을 표현하기 위한 것으로서 태그의 이름을 보면 메모를 보낸 사람(from), 메모를 받는 사람(to), 제목(heading), 메모내용(body) 등의 의미를 파악할 수 있다.

##########1*


하지만 이러한 XML 표현 방법이 시맨틱 웹을 달성하기에는 부족한 점이 많으며 이에 대한 몇 가지 이유를 다음에 요약하였다.

  • 서로 다른 사람이 같은 내용의 문서를 작성할 때 같은 의미를 뜻하면서도 다른 이름을 사용하여 태그를 정의할 수 있다. 예를 들면, 위의 예에서 메모의 제목을 <heading>으로 하였지만 같은 의미의 <subject>라는 다른 태그를 이용할 수도 있다. 따라서 상호운용성(interoperability)을 위해서는 이 두 태그 이름이 같은 의미를 가진다는 것을 따로 표현해야 한다. 이것이 바로 스키마 또는 온톨로지의 필요성이다. 온톨로지가 잘 정의되지 않은 경우에는 문서의 공유나 확장이 어려울 수 있다.

  • 같은 내용에 대해서도 여러 가지 구조를 가진 XML 문서를 사용할 수 있다. 예를 들면, 위의 메모 내용 중에서 날짜를 연월일로 구분해서 표현하면 <그림 3>과 같은 구조가 된다. 이 두 가지 문서의 내용은 같은 것이지만 이것을 에이전트 프로그램이 파악하기는 매우 어렵다.

##########2*
 

3. 시맨틱 웹에서의 RDF의 역할


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


  • 리소스 발견(resource discovery): 보다 정확한 검색 엔진의 성능을 제공

  • 문서 분류(cataloging): 특정 웹 페이지나 디지털 라이브러리의 내용과 관계기술

  • 지능형 소프트웨어 에이전트(intelligent software agent): 지식 공유와 교환 가능

  • 기타: 문서내용 등급표시(content rating)이나 사용자의 개인선호도 표현 등에 사용


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

##########3*


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

RDF 스키마는 특성에 대한 정의나 사용상의 제약 사항을 기술한 것이다. 따라서 RDF의 의미는 이 스키마를 통해서 표현된다고 보면 된다. 스키마는 사전과 비슷한 개념으로 이해하면 되는데 RDF 문을 구성하는 단어(term)를 정의하고 그 단어들에 대한 세부적인 의미를 기술하고 있다. 온톨로지는 RDF 스키마와 유사하지만 좀 더 일반적이고 확장된 개념이다. 온톨로지의 시맨틱 웹에서의 역할은 다음 절에서 기술한다.

 

 

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


온톨로지에 대한 정의는 여러 가지가 있지만 Gruber는 온톨로지를 “공유된 개념화(shared conceptualization)에 대한 정형화되고 명시적인 명세(formal and explicit specification)”라고 정의하였다. [4] 이 정의를 세부적으로 살펴보면 다음과 같은 네 가지 용어가 복합되어 있다는 것을 알 수 있다.


  • 개념화(Conceptualization): 사람들이 사물에 대해 생각하는 바를 추상화한 모델이다. 대개는

                                           특정한 분야에 국한시켜 논의된다.

  • 명시적 명세(Explicit specification): 개념의 타입이나 사용상의 제약 조건들이 명시적으로 정의

                                           된다.

  • 정형화된(Formal): 온톨로지는 프로그램이 이해할 수 있어야 하며, 여러 단계의 정형화가 존재

                                           할 수 있다.

  • 공유된(Shared): 온톨로지는 합의된 지식을 나타내므로 어느 개인에게만 국한되는 것이 아니라

                                           그룹 구성원이 모두 동의하는 개념이다.


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

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

온톨로지를 표현하기 위해 스키마와 구문구조 등을 정의한 언어가 온톨로지 언어(ontology language)이며 현재 DAML+OIL, OWL, Ontolingua 같은 온톨로지 언어가 정의되었다. 이 중에서 W3C에서 표준안으로 제시한 DAML+OIL은 웹 리소스에 대한 시맨틱 마크업 언어이며 W3C의 RDF와 RDF 스키마 표준에 기반을 두고 이들을 확장한 프레임 기반의 온톨로지 표현 언어이다. [5] 기본적으로 DAML+OIL로 표현된 온톨로지는 크게 클래스 요소(class element)와 특성 요소(property element)로 구성된다. <그림 5>는 DAML+OIL로 표현된 온톨로지의 한 예로서 Male과 Female이 Animal의 서브클래스이며, Animal은 hasParent와 hasFather의 특성을 갖는다는 것을 정의한다.

##########4*



5. 시맨틱 웹 응용


시맨틱 웹의 응용은 에이전트 기반의 웹 서비스 제공과 Annotation이나 Authoring 등과 같은 유용한 응용 프로그램의 개발로 요약된다. [6] 대표적으로 현재 연구되거나 개발된 몇 가지 시맨틱 웹 응용 사례를 살펴본다.

Annotation은 시맨틱 웹을 가장 쉽게 응용할 수 있는 매커니즘이다. Annotation은 이미 존재하는 웹 페이지에 대해 추가적인 설명을 덧붙여서 다시 웹에 publish하는 것으로 주로 정보 검색의 정확도를 높이는 데 크게 기여할 수 있다. [7] 이러한 annotation을 가능하게 해주는 툴로서는 OntoMat-Annotizer, SHOE [8], Annotea, Annozilla, COHSE Annotator 등이 있다.

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

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

이 외에도 주로 지능형 플랫폼이 요구되는 e-비즈니스 분야, 고객관리 분야, 바이오 정보 분야, 의료 분야 등에서 시맨틱 웹을 이용한 응용 서비스 개발에 관심을 기울이고 있다.

 


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


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

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

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

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

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

시맨틱 웹에 대해서 가장 활발한 연구를 하는 기관은 웹 표준화 단체인 W3C라고 할 수 있다. 원래 W3C는 웹과 관련된 언어나 프로토콜, 소프트웨어, 툴과 같은 상호운용적인 기술(interoperable technologies)을 개발하는 기관이며 주로 표준화 작업에 중점을 두고 있다. 시맨틱 웹에 대한 노력은 주로 RDF와 온톨로지에 대한 표준을 정의하는 방향으로 이루어지고 있으며 RDF Interest Group, RDF Core Working Group, Web Ontology Working Group 등 소위원회를 통해 세부적인 사항을 결정하고 있다.

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

아직까지 국내에서 시맨틱 웹의 연구가 많이 활성화되지 않은 것은 새롭게 부상하기 때문에 잘 알려지지 않은 분야라는 점도 있고, 시맨틱 웹의 필요성을 절감할 수 있는 killer application의 개발이 아직 이루어지지 않는 것도 하나의 이유라고 할 수 있다. 시맨틱 웹 관련 워크샵이나 프로젝트 모임 등에서 연구소나 업체에서 시맨틱 웹의 응용 사례를 발표하기도 하였지만 아직은 연구 수준의 응용이고 시맨틱 웹의 개념을 테스트하기 위한 시도 정도라고 볼 수 있다. 따라서 시맨틱 웹의 발전에 있어서 가장 중요한 것은 적절한 규모의 응용을 찾아 구현하고 그 효용성을 보여주는 것이다.

2003년 들어서 정부차원에서 시맨틱 웹의 중요성을 인식한 보도 자료들이 일부 나오고 있으며 이제는 대학뿐 아니라 연구소나 기업들 중에도 그 효용성을 긍정적으로 받아들이는 곳이 다수 나타나고 있다. 정보통신부는 앞으로 3년간 142억원을 들여 시맨틱 웹과 지식처리엔진 등 지능형 e-비즈니스 플랫폼 기술을 개발한다고 밝혔고, 이 지능형 e-비즈니스 플랫폼 기술이 지금의 전자거래처리시스템을 지능화, 자동화한 차세대 기술로 ERP, e-Marketplace, SCM 등 기존 e-비즈니스 시스템에 적용할 경우 생산성을 향상시키고 거래비용을 획기적으로 절감해줄 수 있을 것으로 기대한다.


참고문헌


[1] Berners-Lee, T., Hendler, J. and Lassila, O., "The Semantic Web", Scientific American, 2001.

[2] Decker, S., Melnik, S., van Harmelen, F., Fensel, D., Klein, M., Broekstra, J., Erdmann, M. and Horrocks, I., "The Semantic Web: the roles of XML and RDF", IEEE Internet Computing, Vol. 4, No. 5, pp.63-73, 2000.

[3] Lassila, O., "Web metadata: a matter of semantics", IEEE Internet Computing, Vol. 2, No. 4, pp.30-37, 1998.

[4] Gruber, T., "A translation approach to portable ontologies", Knowledge Acquisition, Vol. 5, No. 2, pp.199-220, 1993.

[5] McGuiness, D., Fikes, R., Hendler, J. and Stein, L., "DAML+OIL: an ontology language for the Semantic Web", IEEE Intelligent Systems, Vol. 17, No. 5, pp. 72-80, 2002.

[6] McIlraith, S., Son, T. and Honglei, Z., "Semantic Web services", IEEE Intelligent Systems, Vol. 16, No. 2, pp.46-53, 2001.

[7] Euzenat, J., "Eight questions about Semantic Web annotations", IEEE Intelligent Systems, Vol. 17, No. 2, pp.55-62, 2002.

[8] Heflin, J., Hendler, J. and Luke, S., "SHOE: a knowledge representation language for Internet applications", tech. report CS-TR-4078. Dept. of Computer Science, Univ. of Maryland at College Park, 1999.

[9] Swartz, A., "MusicBrainz: a semantic Web service", IEEE Intelligent Systems, Vol. 17, No. 1, pp.76-77, 2002.

[10] Cost, R., Finin, T., Joshi, A., Yun, P., Nicholas, C., Soboroff, I., Chen, H., Kagal, L., Perich, F., Youyong, Z. and Tolia, S., "ITtalks: a case study in the Semantic Web and DAML+OIL", IEEE Intelligent Systems, Vol. 17, No. 1, pp.40-47, 2002.

[11] Hendler. J., "Agents and the Semantic Web", IEEE Intelligent Systems, Vol. 16, No. 2, pp.30-37, 2001.

[12] Euzenat, J., "Research challenges and perspectives of the Semantic Web", IEEE Intelligent Systems, Vol. 17, No. 5, pp.86-88, 2002.

[13] Gomez-Perez, A. and Corcho, O., "Ontology languages for the Semantic Web", IEEE Intelligent Systems, Vol. 17, No. 1, pp.54-60, 2002.


=======================================================================
출처 : 한양대학교 CSE

신고
document.write("");
Posted by 사우람


티스토리 툴바