으로 작성했을 때 태그만 보고도 ‘이건 제목이구나!’라고 바로 알 수 있습니다. 또한, 검색엔진은 대체로 h1 요소 내의 콘텐츠를 웹문서의 중요한 제목으로 인식하고 인덱스에 포함시킬 확률이 높습니다. 또한 h1 요소 내의 콘텐츠가 제목임을 알 수 있습니다. 이 처럼 의미를 가진 HTML 요소 작성 방식(즉, Semantic Web) 은 SEO에 기여할 수 있는 좋은 방법인 거죠!

한 문장으로 정리하면

시맨틱 웹이란 웹에 존재하는 수많은 웹페이지들에 메타데이터(Metadata)를 부여하여, 기존의 잡다한 데이터 집합이었던 웹페이지를 ‘의미’와 ‘관련성’을 가지는 거대한 데이터베이스로 구축하고자 하는 방상입니다.

HTML 요소는 non-semantic 요소와 semantic 요소로 구분할 수 있습니다.

none-semantic 요소 div, span 등이 있으며 이들 태그는 content에 대하여 어떤 설명도 하지 않습니다.

semantic 요소 for, table, img 등이 있으며 이들 태그는 content의 의미를 명확히 설명합니다.

둘을 분리하고 보니 명확히 Semantic에 대한 이해가 되네요!

시맨틱 웹을 위한 HTML의 태그를 소개합니다. 현재 2021년에는 자연스럽게 사용하고 있지만, 2014년 HTML5가 출시되며 새로운 시맨틱 태그를 출시 했습니다.

header 헤더를 의미합니다.

nav 네비게이션을 의미합니다.

aside 사이드에 위치하는 공간을 의미합니다.

section 본문의 여러 내용(article)을 포함하는 공간을 의미한다.

article 본문의 주내용이 들어가는 공간을 의미합니다.

footer 푸터를 의미합니다.

프론트엔드라면 신경써야하는 시멘틱 요소 사용법! ‘SEO 그걸 개발자인 우리가 신경써야해?’ 라는 생각은 금물이에요. 회사의 비즈니스를 위해 개발단에서 해줄 수 있는 웹 최적화 작업이라고 생각합니다 😎

그렇다면 이제 시멘틱 태그로 HTML을 작성해볼까요? 🧑🏻‍💻

📗 Ref.

poiemaweb.com/html5-semantic-web

ko.wikipedia.org/wiki/%EC%8B%9C%EB%A7%A8%ED%8B%B1_%EC%9B%B9

반응형

시맨틱 웹(Semantic Web)

1. 시맨틱 웹 이란?

시맨틱 웹은 직역하면 의미론적인 웹 이다. 즉, 문서의 의미에 맞게 어플리케이션의 의미에 맞게 구성 된 웹이다.

컴퓨터가 사람을 대신하여 정보를 읽고, 이해하고 가공하여 새로운 정보를 만들어 낼 수 있도록 이해하기 쉬운 의미를 가진 차세대 지능형 웹.

또한 다른 의미로는 정보를 분석하여 그 정보의 관계 속에서 의미론적인 자료들을 추출하여 웹 상에 보여줄 수 있는 웹 이다.

내가 만든 웹사이트, 웹페이지를 검색엔진에 노출시키려 한다.

아래 html 의 2가지 타입의 코드가 있다. 예시 1과 예시 2는 브라우저에서 동일한 외형을 가진다.

두 예시 중 어느 예시가 검색엔진에서 웹 문서의 중요한 제목으로 인식하고 인덱스에 포함시켜 검색엔진에 노출 시키게 될까?

< font size = " 6 " > < b > how to get informations from data < h1 > how to get informations from data

정답은 예시 2 이다.

예시 1의 요소는 의미론적으로 어떤 의미도 가지고 있지 않다. 즉, 의도가 명확하지 않다. 개발자가 의도한 요소의 의미를 명확하게 나타내지 않고 다만 폰트 크기와 볼드체를 지정하는 메타데이터만을 브라우저에게 알리고 있다.

그러나 예시 2의 요소는 header(제목) 중 가장 상위 레벨이라는 의미를 내포하고 있어서 개발자가 의도한 요소의 의미가 명확히 드러나고 있다.이것은 코드의 가독성을 높이고 유지보수를 쉽게한다.

다른 예시를 또 들어보자.

< div > 프론트엔드 병아리 개발자 개스코인 입니다. < p > 프론트엔드 병아리 개발자 개스코인 입니다.

예시 2가 의미가 제대로 전달됨은 물론이다.

프론트엔드 개발자에게 있어서 마크업 구조를 시맨틱 하게 짜는 것은 매우 중요한 요소이다.

물론, 디자인시안 처럼 똑같이 마크업을 짜는 것도 무척 중요하지만 우리는 웹을 그저 시각적 형태로만 볼것이 아니라, 데이터들을 보여주는 것이므로 이러한 마크업을 짤 때, 시맨틱 웹 개념을 생각하며 의미론적으로 마크업 구조를 짜야 하고 태그들을 적절한 상황에 맞게 사용해야 한다.

2. HTML 요소(element)의 2가지 타입

HTML 요소는 non-semantic 요소, semantic 요소로 구분할 수 있다.

non-semantic 요소

div, span 등이 있으며 이들 태그는 content에 대하여 어떤 설명도 하지 않는다. semantic 요소

form, table, img 등이 있으며 이들 태그는 content의 의미를 명확히 설명한다.

3. HTML5 에서 새롭게 추가된 시맨틱 태그들

3-1. HTML5 이전

< body > < div > < h1 > 헤더 < div > < div > < h1 > 제목1 < p > 내용1 < div > < h1 > 제목2 < p > 내용2 < div > < span > 주소

위의 코드를 확인할 수 있듯이 div 태그가 남발되어 있다.

3-2. HTML5 이후

< body > < header > < h1 > 헤더 < nav > < ul > < li > < a href = " # " > Menu -1 < li > < a href = " # " > Menu -2 < li > < a href = " # " > Menu -3 < section > < article > < h1 > 제목1 < p > 내용1 < article > < h1 > 제목2 < p > 내용2 < footer > < address > 주소

새롭게 추가된 시맨틱 태그들을 사용해서 전체 html 구조 및 content 의 의미를 명확히 설명해 주고 있다.

참고하면 좋을 사이트

Best practice of HTML5 Semantic Markup from Toby Yun

출처 1: https://ko.wikipedia.org/wiki/%EC%8B%9C%EB%A7%A8%ED%8B%B1_%EC%9B%B9

출처 2: https://poiemaweb.com/html5-semantic-web

출처 3: https://ideveloper2.tistory.com/164

[IT 상식사전] 시맨틱 웹에 관하여

(출처 : pixabay)

웹이 인간의 방식으로 사고할 수 있을 정도로 진화한다면, 웹은 그 엄청난 정보처리 능력을 바탕으로 신적인 존재가 될 수도 있을 것입니다. 그렇게 되면 웹에 의해 꿈같은 세상이 펼쳐질지, 아니면 웹이라는 초월적 존재가 인간을 지배하는 일이 생길지 누구도 알 수 없습니다. 그렇지만 웹이 탄생한 지 얼마 되지 않아, ‘팀 버너스 리’는 또 다른 웹의 비전을 제시하였습니다.

1991년 유럽입자 물리연구소에서 하이퍼텍스트 기술이 구현된 월드와이드웹을 만든 ‘팀 버너스 리’는 1998년, “사람이 이해하는 정보의 의미를 컴퓨터도 이해하고, 그러한 이해를 바탕으로 정보를 처리하는 웹”이라는 다소 생소한 ‘시맨틱 웹(semantic web)’ 개념을 제안했습니다. 인터넷의 아버지 팀 버너스 리는 거미줄과 같이 얽혀 있는, 자신이 만든 웹을 좀 더 똑똑한 것으로 만들고 싶었습니다. 웹이 처음 나왔을 때 인간의 두뇌를 닮아 있다는 통찰을 느끼게 했던 것을 실제로 구현하고 싶었던 것인데요. 팀 버너스 리 자신은 시맨틱 웹이 훨씬 더 겸허하고 단계적인 표현이라고 하지만, 일반인이나 IT 관련 종사자들은 여기서 더 높아진 웹의 모델을 상상할 수 있었습니다.

시맨틱 웹이란 무엇인가?

시맨틱스(semantics)의 어원은 의미 혹은 의미론을 뜻합니다. 따라서 시맨틱 웹(semanticweb)을 쉽게 설명하면 의미를 이해하는 웹입니다. ‘웹이 인간의 두뇌를 닮은 것이 되기 위해서는 정보를 단지 축적하거나 연결하는 것만이 아닌, 그 의미까지 이해할 수 있어야 한다.’라는 것이 바로 다음 버전의 웹, 의미체계 웹이라고 하는 시맨틱 웹의 목표점입니다.

여기서 의미를 이해한다는 것은 2가지 방식으로 이해할 수 있습니다. 첫 번째는 웹이 인간이 준 데이터를 스스로 이해한다는 의미입니다. 두 번째는 인간이, 컴퓨터와 웹이 의미를 이해할 수 있도록 데이터를 전달하여 웹이 좀 더 효율적으로 정보를 처리한다는 것입니다. 어떤 경우든 마치 인간이 지식과 정보를 이해하는 것처럼 웹이 데이터를 다룰 수 있습니다. 전자는 강한 인공지능(인간과 같이 사고하고 행동하는 컴퓨터 프로그램)의 개념과 통하는데 이것은 아직은 요원한 일이며, 현재는 시맨틱 웹이 후자의 길을 먼저 밟고 있는 상황입니다.

팀 버너스 리가 처음 이야기 꺼냈을 때 많은 사람들은 시맨틱 웹을, 강한 인공지능의 개념으로 생각했기에 어려운 점이 많았습니다. 처음부터 목표가 너무 높았기에 상당한 혼돈의 과정을 거쳐야 했습니다. 하지만 이제는 점차 현실적인 기술들에 천착하며 자리를 잡아가고 있습니다.

이를 바탕으로 시맨틱 웹을 다시 한번 정의해 보겠습니다. 시맨틱 웹은 컴퓨터가 웹 정보의 의미를 스스로 이해, 검색, 추출, 해석, 가공하게 하는 인공 지능을 갖춘 웹입니다. 인터넷의 각종 리소스(웹 문서, 각종 파일, 서비스 등)에 대한 정보와 자원 사이의 관계를 의미 정보(Semanteme, 의미의 최소 단위)로 만들어 컴퓨터가 처리할 수 있는 온톨로지 형태로 표현하고, 이를 처리하도록 한 프레임워크 혹은 기술을 말합니다.

관계의 인드라망

여기서 온톨로지(ontology, 개념 간의 연관 관계)는 무엇일까요? 그것은 시맨틱 웹의 핵심적인 기술로 이야기되고 있습니다. IT에서 온톨로지는 데이터에 대한 모든 의미를 컴퓨터가 이해하고 처리할 수 있는 방식으로 번역하는 기술, 지식, 수단의 총체를 의미합니다.

온톨로지에 대한 예를 하나 들면 컴퓨터에게 어떤 데이터의 관계, 속성을 알려주는 것입니다. 초등학교 선생님의 아래에는 제자들이 있고, 위에는 교장 선생님이 있습니다. 선생님은 남자 혹은 여자이며, 하나의 과정만 운영합니다. 선생님의 가장 대표적인 활동은 강의이며, 교실이라는 장소를 사용합니다. 이렇게 하나의 데이터 자원에 대하여 그와 연관된 관계, 제약사항 등과 같은 다양한 속성을 제공함으로써 의미를 부여하는 것입니다.

(출처 : pixabay)

이와 같이 온톨로지는 시맨틱 웹=의미체계 웹이 가능하도록 컴퓨터에게 데이터의 관계, 한계라는 속성을 가르쳐 데이터의 의미를 알 수 있게 하고, 인간에게 더 유용한 방식으로 처리할 수 있도록 만드는 기술입니다.

어쩌면 인간이 한 대상에 대한 의미를 이해하는 것도 이와 같은 관계에 의한 방식일 것입니다. 불교의 경전에는 이것이 없으면 저것도 없다고 하여 만물이 서로에게 의존하여 존재하는 관계라고 설명하고 있습니다. 즉, 관계에 의해서만 존재가 가능하다는 것입니다.

불교 용어 중에는 인드라망이라는 것이 있는데, 인드라망은 제석천이라는 천신들의 왕이 머무는 궁전 위에 무한하게 펼쳐진 그물, 거미줄(web) 같이 얽힌 그물을 말합니다. 각 그물코에는 구슬이 달려 있는데, 한 구슬에는 모든 그물코의 구슬이 비칩니다. 그리고 모든 구슬의 영상이 담긴 구슬은 또다시 다른 구슬에 비칩니다. 이렇게 서로 무한하게 비치는 구슬의 형상이 인드라망입니다. 컴퓨터 역시 인드라망처럼 한 자원의 의미를 이해하기 위해서는 서로 관계하는 여타 자원들, 그리고 그 자원들과 관계하는 방식에 대한 값을 알아야 할 것입니다.

시맨틱 웹의 현실적 적용과 빅데이터

시맨틱 웹이 현실적으로 적용되고 있는 사례를 보면 아마존, 이베이, 넷플릭스 등에서 활용하고 있는 서비스 사용자의 매매 거래 데이터의 분석, 그리고 태그 등과 같은 메타 데이터가 중요합니다. 거래 데이터를 통한 사용자의 구매 패턴으로 사용자의 동선과 취향을 파악할 수 있고, 메타 데이터를 통해서 의미를 읽어낼 수 있습니다.

메타 데이터라는 것은 메타 인지와 비슷한 것입니다. 우리가 나 자신을 어떤 정보로 얼마나 알고 있는지, 어떤 생각을 하고 있는지에 대한 생각을 메타인지라고 하듯이 메타 데이터는 데이터가 무엇인지를 이야기하는 데이터를 말합니다.

<복학왕>이라는 만화 데이터가 있다면 그 데이터가 언제부터 언제까지 연재되었고, 그 작가가 누구이며, 그 데이터가 스릴러 물인지, 학원 물인지, 로맨스 물인지, 분류는 어떻게 되고, 나아가 그 데이터를 만든 작가의 다른 작품들은 어떻게 되는지 등에 관한 내용입니다. 또한, 매매 데이터를 통한 사용자의 동선 혹은 구매 패턴의 분석을 할 수 있습니다. 이렇게 데이터를 분석하는 것을 데이터 마이닝이라고 합니다.

이렇게 각종 거래 데이터를 비롯한 여러 가지 웹에서의 활동 내역을 취합한 데이터를 분석하는 데이터 마이닝과 메타 데이터를 통해 웹은 마치 데이터의 의미를 이해하는 것처럼 활동할 수 있습니다.

(출처 : pixabay)

이에 따라 초기 단계의 시맨틱 웹은 나의 질문에 대해서 더 정확한 답변을 내줄 수 있고, 내가 말하는 것을 듣고, 내 기분을 생각해서 출근할 옷을 추천해 주거나, 어렸을 적에 듣던 노래를 틀어줄 수도 있을 것입니다. 웹이 친근한 가족, 친구, 혹은 연인처럼 움직이게 되는 것입니다.

이러한 시맨틱 웹의 최근 변화 양상은 빅데이터와 연결 지어 생각할 수 있습니다. 웹에서의 활동이 인간의 보편적인 생활양식으로 자리 잡은 이후 지구촌에서는 천문학적인 데이터가 축적되고 있습니다. 페이스북에서만 하루에 수십억 개의 콘텐츠가 공유되고, 페이스북 서버에서는 수백 테라바이트의 사용자 신규 데이터를 처리하고 있다고 합니다.

지금은 이러한 빅데이터를 데이터 마이닝을 해서 가치 있는 데이터와 가치 없는 데이터를 분류하고, 데이터의 의미와 패턴을 밝혀서 정제된 스마트 데이트를 추출해 내고 있습니다. 스마트 데이터는 분석이 가능한, 정확하고 빠르고 실효성이 있는 데이터입니다. 기업들이 빅데이터를 활용하면서 산업 전 분야에서 많은 비용 절감이 이뤄지고 있고, 고객 자신조차 몰랐던 숨은 취향까지 밝혀내고 있습니다. 빅데이터는 이렇게 시맨틱 웹의 지향을 하나씩 실천하고 있는 중입니다.

단계별로 생각해 보면 시맨틱 웹의 3단계는 온톨로지(초기 시맨틱 웹), 빅데이터, 인공지능(이상적 시맨틱 웹)이 합쳐진 상태라고 말할 수 있습니다. 물론 이것은 편의상의 분류일 뿐, 시기를 떠나서 동시에 서로 영향을 주고받으면서 발전하는 것입니다.

시맨틱 웹의 이상

그렇다면 빅데이터의 주역들은 누구일까요? 페이스북, 유튜브와 같은 SNS, 구글과 같은 검색 포털, 아마존과 같은 전자상거래 업체들 등등입니다.

구글의 창업자 래리 페이지는 유럽 지역 파트너와의 콘퍼런스에서 궁극적인 검색엔진은 세상에 대한 모든 것을 알고 있으며, 무엇이든지 물어보면 정확한 답변을 즉각적으로 제공하는 것이라고 이야기했습니다. 이것은 과거 우리가 상상하던 신에게서나 가능한 일이었습니다. 그는 IT 기술로 형상화된 신의 모습을 구글을 통해 찾았으며, 그것은 래리 페이지 이전에 팀 버너스 리가 먼저 이야기했던 시맨틱 웹의 이상이기도 합니다.

또한, 많은 IT 전문가들은 구글이 현재 개발하고 있는 인공지능이 시맨틱 웹을 바탕으로 인간의 좋은 친구나 비서, 에이전트 역할을 할 것으로 낙관적인 전망을 내놓았습니다. 우리가 휴가지를 결정하면 거기에 필요한 비행기 티켓에서부터 모든 것을 알아서 처리하고, 계절이 바뀌면 우리의 취향에 맞는 옷을 추천하고, 산책을 나갔을 때 근처에 어떤 친구가 있는지도 알려줍니다. 어린 시절 만화책에서나 봤던 일들이 현실로 일어난다는 것입니다.

(출처 : pixabay)

만약 구글의 꿈이 실현된다면 우리는 모든 문제에 대한 답을 구글을 통해서 찾고 모든 의사결정을 구글을 통해서 하게 될 것입니다. 구글 시맨틱 웹이 개발된다면 이러한 생활양식은 더욱 분명하게 우리를 지배할 것입니다. 시간이 좀 더 흐르면 우리는 이런 질문을 할 수도 있을 것입니다.

“과연 우리는 이 새로운 신으로부터 자유로워질 수 있을까?”

정리하자면 시맨틱 웹은 차세대 웹으로 빅 데이터와, 딥러닝과 같은 학습 능력을 갖춘 인공지능의 다양한 기술들과 결합하여 인간에게 편의를 주는 다양한 일을 수행할 수 있을 것으로 전망됩니다. 또한 좀 더 나아가자면 인공지능의 핵심 두뇌 역할을 할 수도 있을 것입니다. 결국 시맨틱 웹의 이상은 인간의 두뇌와 똑같은 작용을 할 수 있는 강력한 능력을 가진 미래형 웹이라고 할 수 있습니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.

[별별 웹 용어] 시멘틱 웹(Semantic Web)이란?

오랜만에 돌아왔습니다! 안녕하세요! 오늘은 ‘시맨틱 웹(Semantic Web)’이라는 개념에 대해서 알아보려고 합니다!

비슷하게 시맨틱 UI(Semantic UI)라는 CSS 프레임워크가 있는데! 서로 관련은 전혀 없구요 ㅋㅋㅋ

그러면! 시작해보죠.

시맨틱 웹이란?

시맨틱 웹(Semantic Web)은 “의미론적인 웹”이라는 뜻으로, 기계가 이해할 수 있는 형태로 제작된 웹을 의미합니다. (물론 사람도 이해할 수 있습니다.) – Wiki 백과

웹 2.0 시대가 시작되면서 사용자들이 생산하는 정보들이 많아지다가 그 양이 너무 많아졌습니다.

우리에게 필요하고 유익한 정보들도 많지만, 불필요한 정보들도 넘쳐나게 되었죠. 이렇게 되면 사람들이 일일이 수 많은 정보들 가운데에 자신이 필요한 정보를 찾아나서야 하는 문제점이 생기게 됩니다.

이러한 문제점을 해결하기 위한 방법이 “시맨틱 웹”이라는 개념이었고, 웹의 창시자 ‘팀 버너스 리(Tim Berners-Lee)’가 제안했습니다. (한국인 아닙니다 ^^ 영국사람)

시맨틱 웹은 기계가 사람을 대신해서 웹 페이지의 정보를 이해하고, 우리에게 필요한 정보만 보여주거나 정보를 가공해서 우리가 필요로 하는 형태로 가공해주는 것을 의미합니다.

그러기 위해서는 기계가 웹 페이지를 이해할 수 있도록 해주어야 합니다.

그런 의미에서 과거의 웹 문서는 많은 정보를 담지 못했습니다.

예를 들어서 웹 사이트에 대한 설명을 넣고 싶었다면, 에 직접 웹사이트에 대한 설명을 넣는것 외에는 방법이 없었습니다. 그런데 태그에 들어간 내용들은 사람들에게 보여주고 싶을 때나 아닐때나 항상 보이게 됩니다.

하지만 지금은 태그를 이용해 다양한 설명과 이미지, 파비콘 등을 지정할 수 있게 되면서 웹 문서에 담을 수 있는 정보들이 늘어났습니다.

시맨틱 웹은 여기에서 한 단계 더 나아간 방식입니다. 웹 문서에 더 많은 정보들을 담을 수 있고, 웹 문서를 크롤링해가는 검색 엔진 로봇들에게 더 많은 정보를 알려줍니다.

예를 들면 이런 방식입니다.

과거에는

1 < div id = "header" > < / div > cs

로 나타냈던 태그를

1 < header > < / header > cs

로 나타내는 것입니다.

차이를 아시겠나요??

로봇은 id가 header라고 적혀 있다고 해서 그 부분이 웹 페이지의 헤더에 해당하는지 알 수 없습니다. 게다가 사람에 따라서는 ‘pageHeader’과 같이 다른 형태로 header id를 작성하는 사람도 있을 수 있습니다.

하지만

라는 태그를 사용해서 웹 사이트의 헤더를 정의해주면 기계도 이 부분이 웹 페이지의 헤더라는 것을 이해할 수 있습니다.

이 외에도

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 < section > < header > < footer > < article > < aside > < nav > < address > < item > < form > < figure > < figcaption > < summary > < time > < mark > < main > < details > cs

등을 사용할 수 있습니다.

시맨틱 태그들을 사용하면 기계들도 이해할 수 있지만, 다른 개발자들도 어디가 메인인지, 네비게이션인지 쉽게 이해할 수 있습니다.

시맨틱 웹은 앞으로 사람만이 인식할 수 있는 범위의 웹페이지가 아니라 기계가 이해할 수 있는 웹페이지의 표준 언어가 되는 것을 목표로 하고 있습니다.

결론

오늘은 간단하게 시맨틱 웹에 대해서 알아봤습니다. 어떠셨나요? 이 외에도 웹 2.0의 등장과 함께 나타난 웹 신기술들이 되게 많습니다! 차차 알아보도록 하죠!

[2탄] 다시 보는 시맨틱 웹 그리고 시맨틱 기술

◎ 연재기사 ◎

▷ 시맨틱 웹 : 기술을 넘어 서비스 플랫폼으로

▷ 검색의 진화, 시맨틱 검색

▷ [1탄] 다시 보는 시맨틱 웹 그리고 시맨틱 기술

▶ [2탄] 다시 보는 시맨틱 웹 그리고 시맨틱 기술

▷ [3탄] 다시 보는 시맨틱 웹 그리고 시맨틱 기술

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

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부에서는 데이터 상호운용과 시맨틱 검색, 시맨틱 소셜 네트워크 분석 등 실질적 상용 사례들을 시맨틱 기술의 가능성을 살펴보기로 하자.

키워드에 대한 정보 시맨틱 웹

다음은 Bing에서 시맨틱 웹 주제에 대한 검색 결과입니다. 필요한 경우 더 읽을 수 있습니다.

이 기사는 인터넷의 다양한 출처에서 편집되었습니다. 이 기사가 유용했기를 바랍니다. 이 기사가 유용하다고 생각되면 공유하십시오. 매우 감사합니다!

사람들이 주제에 대해 자주 검색하는 키워드 시맨틱 웹 소개 (Semantic Web)

• 솔트룩스
• saltlux
• 시맨틱
• 시맨틱검색
• 시맨틱웹
• 온톨로지
• semantic web
• ontology
• DB
• KB
• data base
• knowledge
• knowledge base
• linked
• data
• korea
• web3.0

시맨틱 #웹 #소개 #(Semantic #Web)

YouTube에서 시맨틱 웹 주제의 다른 동영상 보기

주제에 대한 기사를 시청해 주셔서 감사합니다 시맨틱 웹 소개 (Semantic Web) | 시맨틱 웹, 이 기사가 유용하다고 생각되면 공유하십시오, 매우 감사합니다.