소식 : http://www.w3.org/News/2008#item114
RDFa Primer
http://www.w3.org/TR/2008/WD-xhtml-rdfa-primer-20080620/
RDFa in XHTML: Syntax and Processing
http://www.w3.org/TR/2008/CR-rdfa-syntax-20080620/
Semantic Web은 과연 어떤 분야에 적용할 수 있을까요? 개인적인 생각으로는 Semantic Web은 구조화된 웹이라는 변화속에서 거의 모든 다양한 분야에 스며들어갈 것이라고 생각합니다. 요즘 이러한 Semantic Web이 실제로 많은 도움을 줄 수 있는 분야를 찾던 차에, 마침 '검색'이라는 분야에 관심이 생겨, 관련내용을 잠시 살펴보았습니다. 그래서 이번 글에서는 검색이라는 분야에 Semantic Web이 적용될때의 가능성에 대해서 알아보겠습니다. (개인적으로 검색에 대해서는 기초적인 수준의 이해조차 부족합니다 ^^; 부족한 점, 틀린 점이 있으면 따끔히 지적해주세요)
현재의 정보검색은 근본적으로, 구조화되지 않은 데이터(Unstructured Data)속에서 정보를 효율적으로 찾는데 초점을 맞추고 있습니다. 본질적으로 현재의 웹이 비구조적인 형태를 띄고 있기 때문에 당연한 접근방법이기도 합니다. 웹 문서(Document)들의 구조를 한번 살펴보세요. 우리가 찾고자 하는 정보에 비하면, 문서 자체에 대해 기술하는 정보는 정말 미약한 수준입니다. 따라서, 현재까지의 정보검색도 기본적으로 빈도-정확도 중심의 접근법을 벗어나지 못하고 있는 것일테구요.
아래는, 하니가모님이 만드신 Text Retrieval and Mining이란 자료에 나온, 정보 검색의 아키텍쳐 다이어그램입니다.
이 다이어그램을 기반으로 이해해보면, 정보검색은 아래의 4가지 요소로 나눠볼 수 있습니다. 하나씩 살펴보며, 각각이 지닌 한계를 알아보겠습니다.
여기서는 문서를 대표하는 단어인 '색인(Index)'이 중심이 됩니다. 하니가모님이 지적하신대로 현재의 색인 모델은, 동음이의어,상위어,연관어등의 개념관계를 반영하지 못합니다. 필요하면 별도의 후처리 작업을 거치게 됩니다.
이 과정에서는 문서와 단어간의 유사도를 계산해 가중치를 매기고, 이를 바탕으로 랭킹을 만들게 됩니다. (여기서 주로 사용되는 TF-IDF 모델에 대한 설명은 이 글을 참조하세요) TF-IDF 모델의 단점이라면, 이 글에서 언급된 것처럼 '문서에 사용자가 언급한 단어가 직접 명시되어 있지 않으면 무용지물'이라는 점이겠지요. 구글의 Page Rank모델등이, 웹 문서 링크간에 나타나는 네트워크적인 속성을 활용했지만(Link Structure) 이런 근본적인 문제를 모두 해결해주지는 못합니다.
사용자는 기본적으로 자신이 원하는 의도를 자세히 표현하지 못합니다. 그러기엔 연상비용의 너무 크기 때문이죠. 따라서 상당히 함축된 형태로 의도를 표현하는 사용자 질의에 대해, 여러가지 접근법이 필요해집니다. 질의를 사전 데이터와 비교해 확장하는 Query Expansion같은것이 좋은 대안 중 하나라고 하겠지요 (하지만, 구축된 DB에 의존하기에, DB구축비용이나 선별이 만만치 않겠지요)
결과 표현은 사실, 조금 다른 문제이긴 합니다. 랭킹을 어떻게 표현할것인가를 넘어서는 다양한 가능성이 존재하는 부분이기도 합니다. 1) 결과를 어떻게 조직하고, 2) 어떻게 표현할것인가를 복합해서 생각해야 하겠지요. 국내에서의 흐름만 보아도 단순히 '통합검색'이라고만 보기에는 더 많은 Factor들이 작용하고 있는 것 같습니다. 일단, 이해를 넓히기 위해서는, 시루님이 공개해주신 웹에서의 정보시각화 현황 - 검색분석 서비스 관점이라는 문서를 참고하시면 좋을것 같네요.
Semantic Web이 과연 무엇이길래, 이러한 정보 검색(Information Retrieval) 분야에 대한 해결책을 제시한다는 걸까요?
이 글에서 언급했던 것 처럼, Semantic Web은 크게 아래의
이라는 두 가지 관점에서 볼 수 있겠습니다. 1은 여태까지의 Web은 거의 구조적이지 못했기에, 기본이 되는 문서와 데이터에 구조를 심자는 것이고 , 2는 그 구조화된 데이터간의 연결을 통한 가능성에 초점을 맞춘 것이지요. 자세한 내용은 이 팀블로그를 통해 계속 접하시게 될겁니다 ^^
자, 그럼 이 글에서는 이런 Semantic Web이 검색 아키텍쳐에서 어떻게 적용가능할까?를 살펴보겠습니다. 다시 한번 정보검색의 4가지 요소를 들여다봐야겠군요
구조화되지 않은 문서 안에서, 최대한 구조라고 할 수 있는 요소들을 추출하고 분석하는 것. 이것이 여태까지 IR(정보검색)이 집중했던 방향이라고 할 수 있겠습니다. 반면, 웹에 조금씩 구조화된 데이터들이 늘어난다면 어떨까요? 그 가능성을 한번 활용해봐야하지 않을까요? 얼마 전 Yahoo가 발표한 Semantic Web을 검색에 도입하겠다는 발표가 바로 이 맥락에서 이해될 수 있습니다. 여태까지는 메타데이터가 황폐하다시피 없어서 웹 문서를 쥐어짜야(!)했지만, 이제는 곳곳에 퍼지고 있는 메타 데이터를 한번 활용해보자는 것이지요. 따라서, 검색의 관점에서는 이런 사용자의 질의 의도에 맞는 메타 데이터군을 선택해서, 좀 더 유의미한 결과들을 찾아낼 수 있게 됩니다.
이런 구조화된 데이터가 언제 쌓이겠느냐구요? Tim Berners Lee가 말한것처럼 일반 웹 페이지로부터 메타데이터를 추출하는 식의 Top Down Approach가 대세일수도 있구요. 컨텐츠 자체에 메타 데이터를 심거나 , 추가하는 RDFa나 Microformat 같은 시도들이 대세가 될 수도 있습니다. 분명한건 변화는 지금 양쪽에서 모두 일어나고 있고, Major Vendor들이 촉각을 세울만큼 진전되어 가고 있다는 점이지요.
빈도에 따른 가중치에, 문서 연결관계 속의 구조라는 양념을 더한 것이 여태까지의 접근 방법이었다면, 여기서 한 걸음 더 나아가면 어떨까요? 1) 문서와 문서 , 문서와 단어, 단어와 단어 사이의 유사도를 파악해 이용해 보는 겁니다. 2) 그리고 이런 유사도 비교에는 기존에 구축해놓은 온톨로지가 상당 부분 이용될 수도 있겠구요. 3) 구조화된 데이터를 이용할 수도 있습니다. 구글의 Social Graph와 같이, 연결관계를 규정해놓은 API들로 인해, 데이터간의 관계가 쉽게 확보된다면, 굳이 문서 차원의 비교가 아니라, 메타데이터에서 유도된 문서들을 찾아도 될테니까요
물론, 이 부분에도 다른 부분처럼 많은 분야의 연구가 있어왔습니다. Data Clustering이나 Document Classification과 같은것은 여러 분야에서 논의되어온 고전적인 주제이니까요. 다만, Semantic Web은 여기에서도 작은 부분 - 온톨로지와 구조화된 데이터-을 통해 새로운 가능성을 제공합니다.
사실, Semantic Web이 많은 가능성을 보이는 부분은 이 부분입니다. 사용자가 '무엇'을 궁금해 한다고 질의를 던질때. 그 '무엇'이 담긴 '의도(Intention)'을 우리는 잘 잡아내지 못하기 때문입니다. 가장 기초적인 동의어, 동음이의어와 같은 문제도 아직 제대로 해결되었다고 볼수는 없는 상황이구요. 질의를 온톨로지와 비교하고, 확장해나가면서, 사용자의 진짜 의도를 찾아내는 것. 어쩌면 이 부분이 검색이 새로운 가능성을 무궁무진하게 펼칠 수 있는 부분이 아니겠냐는 생각을 해봅니다.
얼마전에 서점에 들렸다가 우연히 발견한, 노영희 교수님의 '개념 기반 정보검색 기법(Concept-based Information Retrieval Techniques)'란 책에서는, 사용의 질의를 온톨로지 기반의 지식 베이스(Knowledge Base)와 비교해, 질의 확장(Query Expansion)하는 방법을 제안하고 있습니다. 책을 마저 읽어보아야 겠지만 무척 재미있습니다. 이러한 지식베이스는 어떻게 만드느냐구요? 문헌 정보학이나 자연어처리쪽에서 논의되어온 학습이나 통계에 기반한 다양한 기법이 있다고 하네요. (구글에서 '동적 시소러스'로 검색해보시면 관련된 재밌는 연구들이 여럿 나옵니다) 이래저래 재밌고, 가능성이 숨겨진 부분입니다.
결과를 어떻게 보여주느냐의 문제는 사실, 특정 기술에 국한된 것은 아닙니다. 가장 사용자에게 맞닿아있는 부분이며, 기술이 아닌 사용자 경험이 중요시되는 부분이기도 합니다. 태그 클라우드도, 결과 클러스터링도, 요즘 선보이고 있는 많은 검색 솔루션들이 실험적으로 구축하고 있는 인터페이스들이 어필하는데 실패하는 이유는 '사용자'라는 가장 복잡한 존재와 닿아있기 때문입니다. 그래서, 단순 Text + Ranking List 식의 사용자 경험이 오랫동안 검색 서비스의 (어쩔수 없는)대안이 되어왔는지도 모르겠습니다.
이 부분에 대해서는 정보의 '관계'와 '구조'에 가능성이 있다는 얘기를 거듭할 수 밖에 없겠네요. 일단 야후가 보여주었던 것처럼, 메타 데이터의 종류에 따라, 각기 다른 표현 방법을 사용하는 것도 대안이 될 수도 있겠구요. 파란의 Stars처럼, 정보의 관계에 집중해서, 사용자가 미처 떠올리지 못했던 의도를 '펼쳐'보여줄 수도 있겠습니다. 좀 더 진득한 논의를 기대하셨다면, 실망하셨겠네요. 대신, 정보 시각화쪽으로는 일단 Ben Fry의 Computerational Information Design의 일독을 추천해드립니다.
물론, 아직 두 분야간에는 많은 이견이 존재합니다. IR and SW communities라는 글의 내용처럼, 정보검색분야는 이미 구축한 정형화된 방법론의 틀안에서 개선을 원합니다. IR의 기본 토대는 그대로 두면서, 다른 분야의 성과들을 따져서 하나 둘 도입해보려는 입장이지요. 반면에 Semantic Web과 관련 분야의 연구는, 대체적으로 IR의 작은 분야 하나하나를 겨냥한것이 대부분입니다. 하지만, 점차 연구의 폭을 넓혀가면서 굳이 IR의 기존 방법론에 구애받지 않는 다양한 시도들을 시험해보려고 하고 있는 것이지요.
사실, 학문적인 성과가 아닌, 실제 세상에 얼마나 기여를 할 수 있느냐, 즉 어떤 방향이 더 성공할 수 있느냐? 라고 묻는다면, 딱히 정답은 없는 것 같습니다. 다만, 그만큼 Semantic Web이 바라보고 있는 가능성들이, 다른 분야들의 성과와 맞물려 새로운 가능성을 창출할 수 도 있겠다는 생각을 해보는 것이지요.
분명한 것은 그러한 가능성이 점차 구체화되고, 실현되고 있고, '검색'이라는 분야도 그 흐름을 비껴가지는 않을것이라는 것입니다. 변화의 흐름은 이미 시작되었으니까요.
이 글은 스프링노트에서 작성되었습니다.
오늘은 RDFa에 대해 소개합니다.
시맨틱웹을 만드는데 필요한 것들이 무엇이 있을까 생각해본적이 있습니다. 이 팀블로그가 만들어지면서 이런저런 개념, 기술들을 나열해 봤습니다. 시맨틱웹을 저장, 표현, 검색이라는 큰 카테고리로 만들수 있다면 이번에 소개할 RDFa는 "표현"에 포함되는 내용입니다
그럼 RDF는 뭐지? RDFa는? (저 알파벳a는 머리를 긁고 있는 RDF의 모습이네요. ^^a;; 뭐지?a)
이 글을 읽는 분들은 RDF에 대한 기본 지식은 가지고 계실줄 믿습니다.
저는 RDF를 "웹상에서 활동하는/되어지는 객체들의 표현"이라고 말하고 싶습니다. 또 뜬구름잡는 고질병이 돋았나 하시는 분도 계시겠네요. 그럼 좀더 자세한 설명을 해보도록 하겠습니다. 예를 들어보죠! 요새 글에 태그다는 연습? 많이 해보셨죠? 블로그를 생각하면 뭐가 생각나나요? 헤어진 여자친구, 떼인 돈 이런거 말고, "블로그" 자체 속성을 보면 제목, 글쓴이, 배포날짜, 내용 이런것들을 나열할 수 있습니다. 이런 공통적인 것을 뽑아서 스팩으로 만들어 놓은것이 RSS입니다. RSS스팩을 보면 <item>,<title>,<link>,<category>,<author>,<pubDate>,<description>등의 항목들이 명시화되어 있습니다.
그럼 두번째 예제는 "친구"를 상상해 보세요...와~ 모두들 "이 사람 FOAF얘기할려고하는 구나!" 라고 생각하고 계시죠? 네 맞아요. FOAF은 "친구와 친구관계"를, SIOC은 "포럼"에 대한 표현을 RDF를 이용해 명세화 한 것들입니다. 지웅님께서 올린 "Semantic Vocabulary. 웹에 (쉽게) 의미를 부여하기."를 보시면 RDF를 이용한 Semantic Vocabulary들의 소개를 보실 수 있습니다.
RDFa는 XHTML에서 FOAF, Dublin Core, Creative Commons등과 같은 Structured Data(Semantic Vocabulary)를 표현(연결)하기 위해 만들어진 스팩입니다.
주로 표현계층에서 사용되던 HTML의 엘리먼트에 Semantic Vocabulary엘리먼트들을 속성값으로 추가해줌으로서 브라우저에서 보는 <span>, <div>같은 엘리먼트에 의미정보가 연결되는 것이죠. 이런 점에서 SHOE가 뷰-데이터간의 연결이 결여된 점을 보완하고 있습니다. 눈에 보이는 문자와 의미정보가 그대로 연결되어 있는 셈입니다.
그럼 전통적인? HTML페이지를 보시죠.
[code.1]
맥주 파티를 공지하기 위해 팀블로그를 통해 위와 같은 모임 정보를 올렸습니다.
우리들(사람들)이 위의 정보를 모니터를 통해 받아 보면 어떠한 정보들을 얻어 낼 수 있을까요?
먼저 이벤트에 대한 정보(이름, 장소, 시간)와 시맨틱웹팀블로그에 대한 정보(연락처, 사이트주소)를 얻을수 있습니다. 어떻게요? 우린 글자를 읽어 그 뜻(Semantic)과 문맥(Context)를 이해 하기 때문이지요.
여기서 잠깐! 시맨틱웹이 뭐죠? 많고 많은 정의중에 데이터와 링크에 초점을 맞춘 정의는 이렇습니다. 이씨 아저씨(^^)가 말하길...
"The Semantic Web isn't just about putting data on the web. It is about making links, so that a person or machine can explore the web of data. With linked data, when you have some of it, you can find other, related, data." @Tim-Berners Lee보시면 사람, 기계가 웹에 내포되어 있는 데이터를 찾아(explore)낼 수 있게 하는 링크된 것들이라고 얘기하네요.
기존의 표현(Presentation)에 초점을 맞춘 HTML을 통해서도 사람들은 내포되어 있는 데이터, 행사 - 이름, 행사 - 위치, 행사 - 행위자등의 관계(link)를 찾아 낼 수 있습니다. 하지만 머신에서는 그러한 데이터를 찾아내려하거나 재사용을 하려면 뭔다 다른 다듬질을 필요로 하겠지요.
다시 예제로 돌아가서, 이벤트, 팀블로그에 대한 정보를 RDFa를 이용해 추가적인 다듬질이 필요없이, 데이터간의 연결 링크가 유지되도록 만들어진 XHTML을 살펴봅시다.
[code.2]
상단 <html>엘리먼트의 속성값에 이 페이지에서 사용될 Semantic Vocabulary를 선언하고 있습니다.
이제 본문에서 CURIE형식으로 특정 <p>, <span>등과 같은 엘리먼트에 Semantic Vocabulary를 연결할 수 있습니다.
실제 View와 의미정보를 연결하는 예제입니다. "2011년 3월 20일 오후 5시!!"라는 것은 "cal:dtstart"라는 속성과 연결이 되어 있습니다. 그리고, 그 "cal:dtstart"라는 속성은 "20110320T1700-0500"란 실제 값과 연결이 되어 있습니다.
[code.1]의 HTML가 내포하고 있는 의미정보를 RDFa를 이용해 [code.2]와 같이 명시적으로 의미정보를 연결해 이씨 아저씨가 얘기했던 It is about making links, so that a person or machine can explore the web of data 이 서서히 보여지는게 아닐까 생각해봅니다.
-"Semantic Vocabulary. 웹에 (쉽게) 의미를 부여하기."에 있듯이 많은 스팩들이 만들어지고 있습니다. 이런 스팩들이 나오는 이유가 무었일까요? 제 생각엔 대부분의 사람들이 인정하는 Vocabulary를 만들고 그 의미를 다시 사용할수 있게 하는데 있는것 같습니다. "contact"란 의미를 다른 곳에서 (재)사용해도 언제나 동일하다는 것이죠.
iMail을 통해 들어오는 메일중에 시간정보를 담고 있는 메일을 받아 보게 됩니다. 아래 스크린처럼 메일의 시간을 바로 iCal로 저장하면서 event를 만들수 있습니다.
현재 iCal에서 제공하는 이 기능은 본문의 날짜데이터를 파싱해서 이벤트를 만들어주는 간단한 로직입니다. (한글날짜도 locale만 처리된다면 가능하겠죠) 이제 웹에서 이런 구조화된 데이터를 내 PC에 설치된 어플리케이션과 웹에서 혼용해 사용할 수 있을겁니다.
요즘 블로그나 여타의 사이트에서도 "태그 검색"이란 기능을 거의 제공하고 있습니다. <tag>의 메타정보를 추출한것이지만 <contact:fn>, <contact:email>를 이용해 AAA@mail.com을 사용하는 AAA가 등록한 글들을 검색할 수 있을것입니다.
그 밖에 많은 서비스들이 만들어질 수 있겠지요.
RDFa Use Cases에 보시면 몇개의 시나리오를 더 보실 수 있습니다.
ps. Yahoo의 소식을 듣고 가능한 서비스들을 머리속에 떠오르니 마냥 기분이 좋아졌습니다. 한편으로 팀블로거들도 자극을 받고 있답니다.~ 아자!
-http://www.w3.org/TR/xhtml-rdfa-primer/
-http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080125/
-http://www.w3.org/TR/xhtml-rdfa-scenarios/
--YouTube에 있는 RDFa Intro추가
이 글은 스프링노트에서 작성되었습니다.
요즈음 참 재미난 서비스들 많습니다. 그중에서 이런 많은 웹 서비스들을 도구(application)의 관점에서 본다면, 사용자가 제일 관심을 가지는 건 뭘까요? 재미나 호기심같은 것은 '도구'의 관점에서는 일단 빼기로 하죠 ^^
저는 '정보의 관리'가 가장 우선이 되지 않나 싶습니다. (검색을 하던, 탐색을 하던, SNS로 공유하던, 링크를 북마크하던간에) 내가 가진 또는 새로 얻은 정보를 쉽게 관리할 수 있는 도구. 말만 들어도 흥미로울것 같네요. 하지만 여태까지 그런 도구가 나오지 않았다는것은 , 그것이 매우 어려운 문제였기 때문일것입니다.
이번에 소개하는 Twine은 이런 고민을 덜어보고자 하는 도구입니다. 아직 Private Beta중임에도 불구하고, ReadWriteWeb을 비롯한 업계,매체의 엄청난 관심을 끌고 있지요.
Twine의 기능은 크게 Organize , Share , Discover로 나뉩니다. 아래는 간단한 데모이고, 아래 언급할 자세한 각 기능에 대한 소개는 Twine Overview 페이지를 참고하세요.
정보를 담는 단 하나의 저장소가 되고 싶은 야망? 북마크한 데이터를, Auto-Tagging을 통해 분류하고 관리됩니다.
이렇게 모은 정보를 Social Network를 통해 공유합니다. 특히 'Twine'이라는 이름의 관심사 네트워크(Interest Network)를 즉석에서 만들 수 있지요. 강한 연결(Social Graph)과 약한 연결(Twine) 모두를 통해 정보를 유통시킵니다.
앞서 모든 데이터가, 태그를 비롯한 다양한 메타데이터를 통해 관리된다고 말씀드렸었죠? 다양한 메타데이터를 통한 분류와, 그 면면을 Twine은 십분 활용합니다.
보통 정보를 찾는데 사용하는 3가지 패턴을 모두 제공합니다.
사실, 어찌 보면 Twine은 요즘 나오는 서비스들의 유용함을 모두 갖추고 있다고도 볼 수 있습니다. 꼭 하나 집어서 말할 수 있는 특이점이 있냐구요? 우선은 '정보 관리(Organizing)'을 그 무엇보다 우선에 둔 서비스라는 점이, Twine의 특징이 아닌가 합니다. 좀 더 자세하게 들어가면, 데이터 - 정보 - 사람간의 '관계'를 적극 활용했다는 점이 포인트가 될 수 있겠구요.
인터넷에 돌아다니는 데모를 보면, 이것이 일반대중을 상대로 성공하리라는 예상은 하기 힘듭니다. 어느 정도 학습비용을 감수하고서도 정보관리가 필요한 계층을 위한 서비스가 되겠지요. 하지만, 그 가능성만은 가히 많은 이들의 주목을 받을만한것 같습니다^^
물론 1. Semantic Web의 표준기술을 사용한 점 2. 메타데이터와 그 관계라는 컨셉을 적극 활용한 점도 빼놓아서는 안되겠지요. 이 부분과 관련해서는 이 페이지를 참조하세요.
이 글은 스프링노트에서 작성되었습니다.