Semantic Web 팀블로그

RDFa의 Candidate Recommendation소식

kwangsub — Wed, 25 Jun 2008 14:25:25 +0900

전에 RDFa에 대해 살짝 소개했었지요. RDFa in XHML이 Candidate Recommendation되었습니다.

소식 : 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/

Twine 10분 초대해드립니다.

정지웅 — Tue, 29 Apr 2008 00:39:21 +0900

앞서 소개해드린 바 있는, Twine의 private beta에서 초대 메일을 받게 되었네요. 회원이 되어 초대장을 10장 받게 되었습니다.

자세한 소개는 소나기님의 Twine Overview라는 글을 읽어보시구요. 아직 소규모 서비스라, 눈팅만 하실분보다는 평소에 관심을 가졌던 분, 활발히 참여해주실분이 신청해주시면 좋겠네요.

초대를 원하시는 분은 아래주소로 메일주세요.

Semantic Web이 검색을 만날때

정지웅 — Wed, 26 Mar 2008 10:15:09 +0900

Semantic Web은 과연 어떤 분야에 적용할 수 있을까요? 개인적인 생각으로는 Semantic Web은 구조화된 웹이라는 변화속에서 거의 모든 다양한 분야에 스며들어갈 것이라고 생각합니다. 요즘 이러한 Semantic Web이 실제로 많은 도움을 줄 수 있는 분야를 찾던 차에, 마침 '검색'이라는 분야에 관심이 생겨, 관련내용을 잠시 살펴보았습니다. 그래서 이번 글에서는 검색이라는 분야에 Semantic Web이 적용될때의 가능성에 대해서 알아보겠습니다. (개인적으로 검색에 대해서는 기초적인 수준의 이해조차 부족합니다 ^^; 부족한 점, 틀린 점이 있으면 따끔히 지적해주세요)

정보 검색의 현재

현재의 정보검색은 근본적으로, 구조화되지 않은 데이터(Unstructured Data)속에서 정보를 효율적으로 찾는데 초점을 맞추고 있습니다. 본질적으로 현재의 웹이 비구조적인 형태를 띄고 있기 때문에 당연한 접근방법이기도 합니다. 웹 문서(Document)들의 구조를 한번 살펴보세요. 우리가 찾고자 하는 정보에 비하면, 문서 자체에 대해 기술하는 정보는 정말 미약한 수준입니다. 따라서, 현재까지의 정보검색도 기본적으로 빈도-정확도 중심의 접근법을 벗어나지 못하고 있는 것일테구요.

아래는, 하니가모님이 만드신 Text Retrieval and Mining이란 자료에 나온, 정보 검색의 아키텍쳐 다이어그램입니다.

이 다이어그램을 기반으로 이해해보면, 정보검색은 아래의 4가지 요소로 나눠볼 수 있습니다. 하나씩 살펴보며, 각각이 지닌 한계를 알아보겠습니다.

웹 문서를 분석하고 텍스트 처리를 하는 Text(Document) Analysis

여기서는 문서를 대표하는 단어인 '색인(Index)'이 중심이 됩니다. 하니가모님이 지적하신대로 현재의 색인 모델은, 동음이의어,상위어,연관어등의 개념관계를 반영하지 못합니다. 필요하면 별도의 후처리 작업을 거치게 됩니다.

Text Anaysis에서 구축한 색인(Index)와 질의(Query)간의 상관관계를 분석하고, 적합한 결과를 알려주는 Matching(Ranking)

이 과정에서는 문서와 단어간의 유사도를 계산해 가중치를 매기고, 이를 바탕으로 랭킹을 만들게 됩니다. (여기서 주로 사용되는 TF-IDF 모델에 대한 설명은 이 글을 참조하세요) TF-IDF 모델의 단점이라면, 이 글에서 언급된 것처럼 '문서에 사용자가 언급한 단어가 직접 명시되어 있지 않으면 무용지물'이라는 점이겠지요. 구글의 Page Rank모델등이, 웹 문서 링크간에 나타나는 네트워크적인 속성을 활용했지만(Link Structure) 이런 근본적인 문제를 모두 해결해주지는 못합니다.

사용자의 질의를 분석해서, 원하는 것인지를 분석해내는 Needs(Query) Analysis

사용자는 기본적으로 자신이 원하는 의도를 자세히 표현하지 못합니다. 그러기엔 연상비용의 너무 크기 때문이죠. 따라서 상당히 함축된 형태로 의도를 표현하는 사용자 질의에 대해, 여러가지 접근법이 필요해집니다. 질의를 사전 데이터와 비교해 확장하는 Query Expansion같은것이 좋은 대안 중 하나라고 하겠지요 (하지만, 구축된 DB에 의존하기에, DB구축비용이나 선별이 만만치 않겠지요)

최종적으로 이런 대응된 결과값을 표현해주는 Result Retrieval

결과 표현은 사실, 조금 다른 문제이긴 합니다. 랭킹을 어떻게 표현할것인가를 넘어서는 다양한 가능성이 존재하는 부분이기도 합니다. 1) 결과를 어떻게 조직하고, 2) 어떻게 표현할것인가를 복합해서 생각해야 하겠지요. 국내에서의 흐름만 보아도 단순히 '통합검색'이라고만 보기에는 더 많은 Factor들이 작용하고 있는 것 같습니다. 일단, 이해를 넓히기 위해서는, 시루님이 공개해주신 웹에서의 정보시각화 현황 - 검색분석 서비스 관점이라는 문서를 참고하시면 좋을것 같네요.

Semantic Web이 검색을 만날때

Semantic Web이 과연 무엇이길래, 이러한 정보 검색(Information Retrieval) 분야에 대한 해결책을 제시한다는 걸까요?

Semantic Web이 뭐길래

이 글에서 언급했던 것 처럼, Semantic Web은 크게 아래의

구조화된 데이터 정의 및 구축 (Web Ontology)
그 구조화 데이터간의 연결 (Linked Data)

이라는 두 가지 관점에서 볼 수 있겠습니다. 1은 여태까지의 Web은 거의 구조적이지 못했기에, 기본이 되는 문서와 데이터에 구조를 심자는 것이고 , 2는 그 구조화된 데이터간의 연결을 통한 가능성에 초점을 맞춘 것이지요. 자세한 내용은 이 팀블로그를 통해 계속 접하시게 될겁니다 ^^

Semantic Web이 검색을 만나면?

자, 그럼 이 글에서는 이런 Semantic Web이 검색 아키텍쳐에서 어떻게 적용가능할까?를 살펴보겠습니다. 다시 한번 정보검색의 4가지 요소를 들여다봐야겠군요

Text(Document) Analysis - 구조화된 데이터들을 찾기

구조화되지 않은 문서 안에서, 최대한 구조라고 할 수 있는 요소들을 추출하고 분석하는 것. 이것이 여태까지 IR(정보검색)이 집중했던 방향이라고 할 수 있겠습니다. 반면, 웹에 조금씩 구조화된 데이터들이 늘어난다면 어떨까요? 그 가능성을 한번 활용해봐야하지 않을까요? 얼마 전 Yahoo가 발표한 Semantic Web을 검색에 도입하겠다는 발표가 바로 이 맥락에서 이해될 수 있습니다. 여태까지는 메타데이터가 황폐하다시피 없어서 웹 문서를 쥐어짜야(!)했지만, 이제는 곳곳에 퍼지고 있는 메타 데이터를 한번 활용해보자는 것이지요. 따라서, 검색의 관점에서는 이런 사용자의 질의 의도에 맞는 메타 데이터군을 선택해서, 좀 더 유의미한 결과들을 찾아낼 수 있게 됩니다.

이런 구조화된 데이터가 언제 쌓이겠느냐구요? Tim Berners Lee가 말한것처럼 일반 웹 페이지로부터 메타데이터를 추출하는 식의 Top Down Approach가 대세일수도 있구요. 컨텐츠 자체에 메타 데이터를 심거나 , 추가하는 RDFa나 Microformat 같은 시도들이 대세가 될 수도 있습니다. 분명한건 변화는 지금 양쪽에서 모두 일어나고 있고, Major Vendor들이 촉각을 세울만큼 진전되어 가고 있다는 점이지요.

Matching(Ranking) - 문서 ,단어의 연결과 유사도

빈도에 따른 가중치에, 문서 연결관계 속의 구조라는 양념을 더한 것이 여태까지의 접근 방법이었다면, 여기서 한 걸음 더 나아가면 어떨까요? 1) 문서와 문서 , 문서와 단어, 단어와 단어 사이의 유사도를 파악해 이용해 보는 겁니다. 2) 그리고 이런 유사도 비교에는 기존에 구축해놓은 온톨로지가 상당 부분 이용될 수도 있겠구요. 3) 구조화된 데이터를 이용할 수도 있습니다. 구글의 Social Graph와 같이, 연결관계를 규정해놓은 API들로 인해, 데이터간의 관계가 쉽게 확보된다면, 굳이 문서 차원의 비교가 아니라, 메타데이터에서 유도된 문서들을 찾아도 될테니까요

물론, 이 부분에도 다른 부분처럼 많은 분야의 연구가 있어왔습니다. Data Clustering이나 Document Classification과 같은것은 여러 분야에서 논의되어온 고전적인 주제이니까요. 다만, Semantic Web은 여기에서도 작은 부분 - 온톨로지와 구조화된 데이터-을 통해 새로운 가능성을 제공합니다.

Needs(Query) Analysis

사실, Semantic Web이 많은 가능성을 보이는 부분은 이 부분입니다. 사용자가 '무엇'을 궁금해 한다고 질의를 던질때. 그 '무엇'이 담긴 '의도(Intention)'을 우리는 잘 잡아내지 못하기 때문입니다. 가장 기초적인 동의어, 동음이의어와 같은 문제도 아직 제대로 해결되었다고 볼수는 없는 상황이구요. 질의를 온톨로지와 비교하고, 확장해나가면서, 사용자의 진짜 의도를 찾아내는 것. 어쩌면 이 부분이 검색이 새로운 가능성을 무궁무진하게 펼칠 수 있는 부분이 아니겠냐는 생각을 해봅니다.

얼마전에 서점에 들렸다가 우연히 발견한, 노영희 교수님의 '개념 기반 정보검색 기법(Concept-based Information Retrieval Techniques)'란 책에서는, 사용의 질의를 온톨로지 기반의 지식 베이스(Knowledge Base)와 비교해, 질의 확장(Query Expansion)하는 방법을 제안하고 있습니다. 책을 마저 읽어보아야 겠지만 무척 재미있습니다. 이러한 지식베이스는 어떻게 만드느냐구요? 문헌 정보학이나 자연어처리쪽에서 논의되어온 학습이나 통계에 기반한 다양한 기법이 있다고 하네요. (구글에서 '동적 시소러스'로 검색해보시면 관련된 재밌는 연구들이 여럿 나옵니다) 이래저래 재밌고, 가능성이 숨겨진 부분입니다.

Result Retrieval

결과를 어떻게 보여주느냐의 문제는 사실, 특정 기술에 국한된 것은 아닙니다. 가장 사용자에게 맞닿아있는 부분이며, 기술이 아닌 사용자 경험이 중요시되는 부분이기도 합니다. 태그 클라우드도, 결과 클러스터링도, 요즘 선보이고 있는 많은 검색 솔루션들이 실험적으로 구축하고 있는 인터페이스들이 어필하는데 실패하는 이유는 '사용자'라는 가장 복잡한 존재와 닿아있기 때문입니다. 그래서, 단순 Text + Ranking List 식의 사용자 경험이 오랫동안 검색 서비스의 (어쩔수 없는)대안이 되어왔는지도 모르겠습니다.

이 부분에 대해서는 정보의 '관계'와 '구조'에 가능성이 있다는 얘기를 거듭할 수 밖에 없겠네요. 일단 야후가 보여주었던 것처럼, 메타 데이터의 종류에 따라, 각기 다른 표현 방법을 사용하는 것도 대안이 될 수도 있겠구요. 파란의 Stars처럼, 정보의 관계에 집중해서, 사용자가 미처 떠올리지 못했던 의도를 '펼쳐'보여줄 수도 있겠습니다. 좀 더 진득한 논의를 기대하셨다면, 실망하셨겠네요. 대신, 정보 시각화쪽으로는 일단 Ben Fry의 Computerational Information Design의 일독을 추천해드립니다.

Semantic Web과 검색의 동상이몽

물론, 아직 두 분야간에는 많은 이견이 존재합니다. IR and SW communities라는 글의 내용처럼, 정보검색분야는 이미 구축한 정형화된 방법론의 틀안에서 개선을 원합니다. IR의 기본 토대는 그대로 두면서, 다른 분야의 성과들을 따져서 하나 둘 도입해보려는 입장이지요. 반면에 Semantic Web과 관련 분야의 연구는, 대체적으로 IR의 작은 분야 하나하나를 겨냥한것이 대부분입니다. 하지만, 점차 연구의 폭을 넓혀가면서 굳이 IR의 기존 방법론에 구애받지 않는 다양한 시도들을 시험해보려고 하고 있는 것이지요.

사실, 학문적인 성과가 아닌, 실제 세상에 얼마나 기여를 할 수 있느냐, 즉 어떤 방향이 더 성공할 수 있느냐? 라고 묻는다면, 딱히 정답은 없는 것 같습니다. 다만, 그만큼 Semantic Web이 바라보고 있는 가능성들이, 다른 분야들의 성과와 맞물려 새로운 가능성을 창출할 수 도 있겠다는 생각을 해보는 것이지요.

분명한 것은 그러한 가능성이 점차 구체화되고, 실현되고 있고, '검색'이라는 분야도 그 흐름을 비껴가지는 않을것이라는 것입니다. 변화의 흐름은 이미 시작되었으니까요.

이 글은 스프링노트에서 작성되었습니다.

Annotation이야기(2) - RDFa

kwangsub semantic — Fri, 21 Mar 2008 16:39:30 +0900

오늘은 RDFa에 대해 소개합니다.

시맨틱웹을 만드는데 필요한 것들이 무엇이 있을까 생각해본적이 있습니다. 이 팀블로그가 만들어지면서 이런저런 개념, 기술들을 나열해 봤습니다. 시맨틱웹을 저장, 표현, 검색이라는 큰 카테고리로 만들수 있다면 이번에 소개할 RDFa는 "표현"에 포함되는 내용입니다

#. RDF? RDFa?

- RDF

그럼 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

RDFa는 XHTML에서 FOAF, Dublin Core, Creative Commons등과 같은 Structured Data(Semantic Vocabulary)를 표현(연결)하기 위해 만들어진 스팩입니다.

주로 표현계층에서 사용되던 HTML의 엘리먼트에 Semantic Vocabulary엘리먼트들을 속성값으로 추가해줌으로서 브라우저에서 보는 , <div>같은 엘리먼트에 의미정보가 연결되는 것이죠. 이런 점에서 SHOE가 뷰-데이터간의 연결이 결여된 점을 보완하고 있습니다. 눈에 보이는 문자와 의미정보가 그대로 연결되어 있는 셈입니다.

그럼 전통적인? HTML페이지를 보시죠.

[code.1]

<html>
 <head><title>Semantic Team Blog Beer Party</title></head>
 <body>
 
 2011년 3월 20일, 오후 5시에 시맨틱 팀 블로그에서 맥주파티를 엽니다.
 
 
 행사의 정보는 <a href="http://example.org">이곳</a>을 통해 확인하실 수 있어요!
 문의 사항이 있으시면 <a href="mailto:jo@example.org">email</a>을 통해 연락을 주세요!
 
 </body>
 </html>
 이 예제는 http://www.w3.org/TR/xhtml-rdfa-primer/ 에 나온 예제를 각색했습니다.

시맨틱웹팀블로그에서 2011년에 맥주파티를 벌인다고 하네요. (그때까지 이 블로그가 건재하다면 정말 맥주한잔 해야겠는데요^^).

맥주 파티를 공지하기 위해 팀블로그를 통해 위와 같은 모임 정보를 올렸습니다.

우리들(사람들)이 위의 정보를 모니터를 통해 받아 보면 어떠한 정보들을 얻어 낼 수 있을까요?

먼저 이벤트에 대한 정보(이름, 장소, 시간)와 시맨틱웹팀블로그에 대한 정보(연락처, 사이트주소)를 얻을수 있습니다. 어떻게요? 우린 글자를 읽어 그 뜻(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]

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<html xmlns:cal="http://www.w3.org/2002/12/cal/ical#"
xmlns:contact="http://www.w3.org/2001/vcard-rdf/3.0#">
<head> <title>맥주파티</title> </head>
<body>

 
 2011년 3월 20일 오후 5시!!

시맨틱 블로그 팀에서

"맥주파티"

로 여러분을 초대합니다.



 행사의 정보는 <a rel="contact:org" href="http://semantic.tistory.com">이곳</a>을 통해 확인하실 수 있어요!
 문의 사항이 있으시면 <a rel="contact:email" href="mailto:kwangsub.kim@gmail.com">email</a>을 통해 연락을 주세요!

 Semantic Team Blogger
 김광섭 올림
 
</body>
</html>

상단 <html>엘리먼트의 속성값에 이 페이지에서 사용될 Semantic Vocabulary를 선언하고 있습니다.

이제 본문에서 CURIE형식으로 특정 , 등과 같은 엘리먼트에 Semantic Vocabulary를 연결할 수 있습니다.

실제 View와 의미정보를 연결하는 예제입니다. "2011년 3월 20일 오후 5시!!"라는 것은 "cal:dtstart"라는 속성과 연결이 되어 있습니다. 그리고, 그 "cal:dtstart"라는 속성은 "20110320T1700-0500"란 실제 값과 연결이 되어 있습니다.

2011년 3월 20일 오후 5시!!

[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추가

이 글은 스프링노트에서 작성되었습니다.

Yahoo 가 한발 앞서 갑니다.

heechul — Mon, 17 Mar 2008 20:03:58 +0900

야후가 RDF 나 microformat 을 포함한 시맨틱 웹 표준들을 검색에 적용하겠다는 군요.
더불어서, 외부 개발자들이 해당 데이터를 사용할 수 있게 API 를 제공하겠다고 합니다.

이로 인해, 해당 표준들을 통해서 데이터를 공개하는 사이트들은
야후 검색을 통해 접속의 양과 질, 모두 높아질 것이라고 합니다.

이게, 참 개인적으로 기대하던 방향이고 많은 것들을 말해주는데요.

검색 알고리즘에 추론등, 일반적인 시맨틱 웹의 특징으로
오해되어 왔던 기술들이 얼마나 사용되었는지는 모르겠지만,

기존 검색 알고리즘과 상관없이,
표준을 통해 기술된 데이터를 검색 결과에 보여주고
외부에서 접근할 수 있게 하기만 해도,
시맨틱 웹으로써, 많은 효과를 얻을 수 있다는 것입니다.

음. 아직은 흥분하지 말고 조금 더 공식적인 결과물을 지켜봐야 할 것 같습니다.

원문을 링크 합니다.

http://www.ysearchblog.com/archives/000527.html

Annotation이야기(1) - SHOE

kwangsub semantic — Mon, 17 Mar 2008 18:19:44 +0900

HTML에 대한 정보를 어노테이션하거나 확장하기 위해 만들어졌던 SHOE(Simple HTML Ontology Extensions)를 기억하십니까?

HTML에 추가정보(SHOE Ontology)를 연결하기 위해 연구되었습니다.

SHOE에 대한 자세한 스팩은 해당 사이트에서 보시고, 어떻게 생긴물건인지만 보여주는 예제를 살펴보도록하겠습니다.

http://www.cs.umd.edu/projects/plus/SHOE/html-pages.html

<HTML>
<HEAD>
<META HTTP-EQUIV="SHOE" CONTENT="VERSION=1.0">
<TITLE> My Page </TITLE>
</HEAD>
<BODY>
 Hi, this is my web page.
I am a graduate student and a research assistant.
 Also, I'm 52 years old.
 My name is George Stephanopolous.
 Here is a pointer to my <A
HREF="http://www.cs.umd.edu/smith"> graduate advisor.</A>
 And <A HREF="http://www.cs.umd.edu/papers/paper.ps">
is a paper I recently wrote.
<h3> Brun Hilda </h3>
Brun Hilda is a visiting lecturer here from Germany who doesn't have her
own web page. However, because I am such a nice person, I have agreed
to let part of my web page space belong to her. She is 23.

<INSTANCE KEY="http://www.cs.umd.edu/users/george/">

<USE-ONTOLOGY
ID="cs-dept-ontology"
URL="http://www.cs.umd.edu/projects/plus/SHOE/onts/cs.html"
VERSION="1.0"
PREFIX="cs">

<CATEGORY NAME="cs.GraduateStudent">
<CATEGORY NAME="cs.ResearchAssistant">

<RELATION NAME="cs.name">
<ARG POS=TO VALUE="George Stephanopolous">
</RELATION>
<RELATION NAME="cs.age">
<ARG POS=TO VALUE="52">
</RELATION>
<RELATION NAME="cs.advisor">
<ARG POS=TO VALUE="http://www.cs.umd.edu/users/smith">
</RELATION>

<INSTANCE KEY="http://www.cs.umd.edu/users/george/#BRUNHILDA">

<CATEGORY NAME="cs.Lecturer">

<RELATION NAME= "cs.name">
<ARG POS=TO VALUE="Brun Hilda">
</RELATION>
<RELATION NAME="cs.age">
<ARG POS=TO VALUE="23">
</RELATION>

</INSTANCE>
</INSTANCE>

</BODY>
</HTML>

상단의 코드를 보면 흔히 볼수 있는 HTML을 이용하여 George Stephanopolous 자신을 소개하고 Bun Hilda란 사람을 소개하고 있습니다. 여기까지는 흔히 볼수 있는 HTML문법입니다. 그 다음 하단에는 SHOE(Simple HTML Ontology Extensions)를 이용하여 George Stephanopolous과 Bun Hilda에 대한 정보와 관계를 표현하고 있습니다.

이것이 바로 제가 알고있는 최초 HTML어노테이션표현 기술이었습니다. 기존 마크업언어에 추가정보를 표현하기 위한 개념들을 온톨로지로 만들었고, 그러한 개념들을 SHOE를 이용해 삽입하였던 것이지요. HTML내의 SHOE검색을 통해 의미검색을 수행할수 있는 구조입니다.

데모페이지를 보시면 다음과 같은 어플리케이션을 제공하고 있는데요. 이런 어플리케이션을 통해 의미정보를 표현하고, 검색하게 됩니다.

* Semantic Search
* The Knowledge Annotator
* Exposé
* PIQ (Parka Interface for Queries)
* SHOE Search

위의 어플리케이션을 보면 정말 시맨틱한 질의가 가능하고 검색이 가능할거라 생각됩니다.

하지만, 센스 있는 여러 분들은 위의 결과를 보시면 어떠한 문제가 발생될지 예상하실겁니다. 페이지에 여러 정보들이 있다면 그 정보를 표현하기 위한 자체 SHOE표현 부분이 꽤나 복잡해지고 그 양도 많아지겠지요. 이러한 문제를 접어두고서라도 더 큰문제는 실제 표현하고 있는 마크업데이터(ex. My name is George Stephanopolous.)와 SHOE온톨로지 정보간의 연결(Link)가 결여되어 있다는것이지요. 이 시대(?)에 SHOE Search Engine이 잘 발달해 사용되어 왔다면(실제 SHOE페이지에서 SHOE Search Applet을 제공했으나 현재는 작동하지 않습니다.), HTML페이지가 많은 양의 SHOE개념들을 포함하고 있다면 사용자들은 검색된 결과가 어디에 있는지 찾아봐야 할겁니다. 검색이 되긴 되었는데 어디에 이런 정보들이 표현되고(Markup)있는지 찾아야 하는 것이지요.

그래도 이 시대(?)의 선행자들로 인해 어노테이션 기술이 발전된게 아닐까 생각합니다. 최근 어노테이션에 대한 포스팅을 하나 했었습니다. 오픈마루의 레몬펜과 구글의 노트를 언급했었는데요. 조금 더 바라는 점이 있다면 어노테이션된 정보의 대한 검색이 "일반적"검색을 통해서 이루어 졌으면 하는 바램입니다. 다시 말하면, 오픈마루, 구글을 검색플랫폼(문자열 검색만이 아닌)만을 위한 Structured Data(어노테이션데이터)가 아닌 모든 엔진이 통용할 수 있는 스팩이 제공되었으면 하는 바램이지요. (힘들겠지요. 그래도 OpenSearch.org과 같은 단체들이 조금씩 영향력을 행사할때가 오지 않을까 합니다.)

다음에 소개할 RDFa는 이러한 문제를 보완할수 있는 훌륭한 스팩이라고 생각합니다. (개인적으로 RDFa이 시맨틱웹에 많은 기여를 할것 같은 느낌이 팍팍 오거든요! ^^)

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

[2] http://www.opensearch.org

이 글은 스프링노트에서 작성되었습니다.

Twine - 정보관리도구

정지웅 — Tue, 11 Mar 2008 00:06:47 +0900

요즈음 참 재미난 서비스들 많습니다. 그중에서 이런 많은 웹 서비스들을 도구(application)의 관점에서 본다면, 사용자가 제일 관심을 가지는 건 뭘까요? 재미나 호기심같은 것은 '도구'의 관점에서는 일단 빼기로 하죠 ^^

저는 '정보의 관리'가 가장 우선이 되지 않나 싶습니다. (검색을 하던, 탐색을 하던, SNS로 공유하던, 링크를 북마크하던간에) 내가 가진 또는 새로 얻은 정보를 쉽게 관리할 수 있는 도구. 말만 들어도 흥미로울것 같네요. 하지만 여태까지 그런 도구가 나오지 않았다는것은 , 그것이 매우 어려운 문제였기 때문일것입니다.

이번에 소개하는 Twine은 이런 고민을 덜어보고자 하는 도구입니다. 아직 Private Beta중임에도 불구하고, ReadWriteWeb을 비롯한 업계,매체의 엄청난 관심을 끌고 있지요.

Twine의 기능은 크게 Organize , Share , Discover로 나뉩니다. 아래는 간단한 데모이고, 아래 언급할 자세한 각 기능에 대한 소개는 Twine Overview 페이지를 참고하세요.

Organize

정보를 담는 단 하나의 저장소가 되고 싶은 야망? 북마크한 데이터를, Auto-Tagging을 통해 분류하고 관리됩니다.

이렇게 모은 정보를 Social Network를 통해 공유합니다. 특히 'Twine'이라는 이름의 관심사 네트워크(Interest Network)를 즉석에서 만들 수 있지요. 강한 연결(Social Graph)과 약한 연결(Twine) 모두를 통해 정보를 유통시킵니다.

Discover

앞서 모든 데이터가, 태그를 비롯한 다양한 메타데이터를 통해 관리된다고 말씀드렸었죠? 다양한 메타데이터를 통한 분류와, 그 면면을 Twine은 십분 활용합니다.

검색
탐색
추천

보통 정보를 찾는데 사용하는 3가지 패턴을 모두 제공합니다.

정체가 뭐냐?

사실, 어찌 보면 Twine은 요즘 나오는 서비스들의 유용함을 모두 갖추고 있다고도 볼 수 있습니다. 꼭 하나 집어서 말할 수 있는 특이점이 있냐구요? 우선은 '정보 관리(Organizing)'을 그 무엇보다 우선에 둔 서비스라는 점이, Twine의 특징이 아닌가 합니다. 좀 더 자세하게 들어가면, 데이터 - 정보 - 사람간의 '관계'를 적극 활용했다는 점이 포인트가 될 수 있겠구요.

인터넷에 돌아다니는 데모를 보면, 이것이 일반대중을 상대로 성공하리라는 예상은 하기 힘듭니다. 어느 정도 학습비용을 감수하고서도 정보관리가 필요한 계층을 위한 서비스가 되겠지요. 하지만, 그 가능성만은 가히 많은 이들의 주목을 받을만한것 같습니다^^

물론 1. Semantic Web의 표준기술을 사용한 점 2. 메타데이터와 그 관계라는 컨셉을 적극 활용한 점도 빼놓아서는 안되겠지요. 이 부분과 관련해서는 이 페이지를 참조하세요.

이 글은 스프링노트에서 작성되었습니다.

Semantic + Web 따로 보지 말아줘요~!

정지웅 — Sun, 9 Mar 2008 00:01:34 +0900

얼마전에 재밌는 자료를 하나 접했습니다.

Semantic Web for Dummies (바보도 알 수 있는 시맨틱웹)

2번째 페이지에 아래와 같은 내용이 나옵니다.

XML customised tags, like:

<dog>Nena</dog>

+ RDF relations, in triples, like:

(Nena) (is_dog_of) (Kimiko/Stefan) RDF는 이런 관계를 나타내고

+ Ontologies / hierarchies of concepts, like:

mammal -> canine -> Cotton de Tulear -> Nena 온톨로지는, 개념들간의 계층관계를 나타내며

+ Inference rules like:

If (person) (owns) (dog), then (person) (cares_for) (dog) 추론이라는 건, 결국 이렇게 작동한다라는..

= Semantic Web

맙소사! 이런 관점이야 말로, 우리가 피해야할 전형적인 오류라고 할 수 있습니다. 왜 그런지를 이제부터 논해보죠

지식 표현의 관점 - "Semantic" web

앞서 말한 내용은 맞습니다. 아주 잘 정리해주었네요. 예, 그런데 딱 절반만 맞는 거지요. 이런 논리는 Semantic이라는 부분. 즉, 정보의 의미를 잘 정형화된 데이터 포맷으로 쓰는게 중요하다! 라는 주장을 내세웁니다. 이 논리를 깊이 파고들면, 결국 지식표현(Knowledge Representation)의 관점에 빠져들게 됩니다. 정보를 잘 구성해서, 지식으로 표현하고, 그러면 그 지식이 우리를 이 정보의 홍수속에서 구원해줄거야! 라는... 문제는 많은 사람들이, 이런 지식표현의 관점에 얽매여 있다는 점입니다. 그래서 어떻게 하면, 온톨로지를 "잘" 구축할까 라던지. 데이터 포맷은 어떠야한다는지와 같은 이야기에만 집중하지요. 하지만, 어느 세월에 이 온톨로지를 전부 구축할까요? 사실, Semantic Web의 위력은 'Semantic'이란 관점이 아닌 다른 곳에 있습니다

이제는 지겨운 Semantic Web Layer Cake

웹의 관점 - semantic "Web"

예, Semantic Web은 본디, 우리가 사용하는 World Wide Web을 목적으로 하고 있습니다. 그래서 여기서는 정반대의 가정을 합니다. 데이터를 얼마나 의미있게 기술하느냐는 중요하지 않습니다. 대신, 데이터들이 '공통의 구조'로 이리저리 연결될때의 가능성에 주목을 하고 있지요. RSS나 요즘 화제가 되는 FOAF같은 데이터 형식을 보신 분은 아시겠지만, 정말 단순합니다. 단순한 의미를 미리 약속해놓고, 같이 쓰는 것에 불과하죠. 하지만 그 위력은? 몇 가지 예를 들어보죠.

RSS라는 간단한 포맷을 통해서, 우리는 정보를 자유롭게 구독하고, 필터링할 수 있게 되었구요
FOAF를 통해 표현된 Social한 정보들을 통해, 나와 다른 Social Network 서비스를 이용하는 친구들과도 자유롭게 소통할 수 있게 되었습니다
- 앞서 언급된 Google의 Social Graph API 가 그 좋은 사례이구요
- Spokeo나, FriendFeed같은 서비스들도, 이런 표준 데이터가 확산되면 될수록 더 힘을 얻을 것입니다.
태그는 어떨까요? SCOT , MOAT같은 프로젝트는 , 사람들의 지혜를 모아서 태그와 같은 폭소노미를 더욱 유용하게 쓸수 있다고 말합니다.
- 태그가 모이면 모일수록, 점차 '온톨로지'로 발전해나간다는 것이지요. (나는 단지 태그 몇개만 달았을뿐인데!!)
내 게시판과 니 블로그를 묶으면 재밌어질텐데.. 블로그나 게시판의 내용을 SIOC으로 엮어보세요. 가상 게시판이 뚝딱 탄생합니다 :)

여기서 말씀드린 데이터 포맷들은 하나의 사례에 불과합니다. 꼭 이런게 만능이 아니라, 요런 간단한 형식으로 정의된 데이터들이 이리저리 연결되면 될수록, 무한한 가능성이 생긴다는 이야기죠. 앞의 관점처럼, 멋진 온톨로지를 구축하지 않고, 그저 데이터끼리만 연결해도 이미 멋진 결과물이 나오거든요.

6단계만 거쳐도 모든 사람을 다 만날 수 있는, '연결'이 가진 가능성

따로 보지 말아줘요 - Linked Data

즉, 핵심은 무엇일까요? Tim Berners Lee가 처음에 말했던, Linked Data가 그 해답이라고 할 수있습니다. 정보를 '문서 뭉치(Documents)'가 아니라, 의미있는 URI로 잘게 나누어서 공개하세요. 그리고 그 URI가 가리키는 데이터들이 자유롭게 연결될 수 있도록 하세요. 그런 데이터의 연결. 그것이 바로 Semantic Web으로 가는 열쇠라는 얘기입니다. Semantic 과 Web을 따로 보는 것이 아니라, Web이라는 특수한 환경에서 Semantic을 바라봐야 하는 것이죠.

그럼 이런 Linked Data의 관점에서 Semantic Web을 구축하려면 어떤 규칙을 따라야 할까요? Semantic Web .. in a Nutshell이라는, 이번 글의 화두가 된 글에서는 다음과 같은 지침을 알려주고 있습니다.

Semantic Web 구축에 필요한 5가지

모든 사물을 표현할 수 있는 일관된 작명 방법 (A uniform naming scheme)
1. HTTP URI를 사용하면 되구요
이런 사물간의 관계를 표현할 수 있는 데이터 모델
1. RDF면 충분합니다. RDF에 대해서는 다음 글에 자세히 다루도록 하지요
이 데이터 모델을 통해 정보를 표현할수있는 포맷
1. RDFa, Microformat 같은 형식을 통해 HTML에 직접 그런 정보를 표현할 수도 있구요
2. 어떤 형태의 XML이라도, GRDDL과 같은 기술로, RDF로 변환할 수 있습니다
3. 즉, Semantic Web의 혜택을 얻기 위해, 새로 애플리케이션을 구축할 필요는 없다는 이야기입니다.
이런 데이터들간의 관계를 찾을 수 있는 프로토콜
1. HTTP면 충분하구요
위 조건들을 만족시키위한 도구
1. 아직 Semantic Web을 위한 개발자 도구는 미약하기만 합니다. 아직 API 나 도구모음은 있으되, 편하게 쓸 수 있는 Framework가 없는 실정이라고 할까요? 이런 도구들이 점차 들어나면, 개발자들도 간단한 작업만으로 위 요건에 맞게 애플리케이션을 개발할 수 있을겁니다. ActiveRDF라는 Ruby 기반의 재밌는 프레임워크가 있는데, 나중에 다루기로 하지요

참 쉽죠?

따지고보면, Semantic Web은 그리 어려운 이야기가 아닐지도 모릅니다. 어려운 온톨로지를 몰라도 되구요. 복잡하게 애플리케이션을 새로 작성할 필요도 없습니다.

데이터들이 잘 연결될 수 있게 설계하고
그때 미리 정의된 형식을 조금 가져다 써주면 되는 것이지요

어떻습니까? 참 쉽죠? (Bob Ross 아저씨 톤으로 ^^) 아직 쉽지 않은 이야기라면, 더 쉽게 풀어나가보겠습니다. 바로 그것이 이 팀 블로그의 목적중 하나일테니까요. 데이터가 이러저리 연결되고, 의미없는 문서뭉치가 아닌, 내가 찾고 싶은 데이터를 콕 찝어 찾을 수 있는 세상. 이야기는 이제부터 시작입니다 ^^

나 아직 죽지 않았어~ 기다려봐~ 이야기는 이제부터 진짜 시작이라구~ 후훗~!

이 글은 스프링노트에서 작성되었습니다.

SNS - Spokeo

kwangsub semantic — Wed, 5 Mar 2008 13:52:38 +0900

"내가 올린 사진봤어?"

"어~ 아니! 어디다 올렸는데?"

"내 두번재 블로그에 새로 올렸어"

이런 경우 자주 겪어 보셨죠? Spokeo란 서비스는 친구(email주소나 blog주소)를 찾아 줍니다. 정확히 말해, 친구를 찾아주는게 아니고 친구가 활동하며 만들어낸 Contents를 찾아 줍니다. 물론 공개한 내용이여야 하구요. 공개가 안되었더라도 관계(일촌같은)가 있다면 SNS의 내 계정과 연결이 된 친구글을 import해 올수 있습니다.

예를 들어, 싸이가 API를 제공하고 있다면 내 싸이 계정을 등록하면 내 일촌들의 행적?을 알아 올수 있는거죠.

Nobody knows what you are tracking, not even the friends you track.

누가 날 보고 있는지 모른답니다. 좀 무섭네요. 누군가 나를...:-)

저는 꼼짝달싹 못하게 하는 Social Network사이트라고 생각하는데 이들은 SNS가 아니라고 하네요. :-)

Since Spokeo is a friend tracker and not a social network

우리말로 돌리면 "친구추적기"? :-) 억양이 좀 그렇네요.

사용방법은 간단합니다. email과 비밀번호만으로 등록이 됩니다.

그런 후 친구의 email이나 블로그 주소로 검색을 합니다. 제 email을 적었더니 Google Picasa Web에 있는 공개된 사진들이 모두 나타납니다.

검색결과 오른쪽 상단에 노란박스에 보이시죠? "Add ... to your friends"...

왼쪽 리스트엔 희철님과 지웅님이 친구로 등록되어 있네요. 이제 저들의 행적을 일일이 쫒아 다니지 않아도 됩니다.:-)

사용자 입장에선 RSS구독기를 사용하듯 흘러갑니다. 블로그를 추가 하면 구독기역할을 하구요.

이 모든것들이 벤더들이 Open API를 제공했기 때문에 가능한것이지요

앞서 희철님이 소개한 Google Social Graph에 벤더들의 API가 추가된다면 (꼭 추가가 되지 않는다고 해도 OpenAPI형식으로 제공된다면) Social Network플랫폼은 이런 기능을 기반으로 발전되지 않을까 싶습니다. RSS구독기 역할을 지니면서 feed에 대한 정보뿐만 아니라, 사진, 추천, 위시리스트, 비디오들이 서로 공유가 되겠지요. 내가 본건 친구들도 보고 친구들이 본건 나도 보게되겠지요. 여기에 후에 소개할 RDFa스펙을 이용해 의미정보가 feed에 추가 된다면 그 데이터들의 조합으로 제 3의 서비스가 탄생되지 않을까 싶습니다.

[1]http://www.spokeo.com/

이 글은 스프링노트에서 작성되었습니다.

Google Social Graph API

heechul — Sun, 2 Mar 2008 22:20:21 +0900

#
이번 포스팅에서는 Google 이 최근에 공개한 Social Graph API 에 대해서 살펴보도록 하겠습니다.

Google Social Graph API 는 인터넷을 웹페이지 중심에서 사람 중심으로 볼 수 있도록 도와주는 API입니다. 이는 The Web of Things 포스팅에서 언급했던 웹페이지 중심에서 사물 중심 추상화로의 가장 기초적인 단계라고 해야겠구요.

이 Social Graph API 는 다운 받아서 돌릴 수 있는 라이브러리가 아니라 웹 연결을 통해서 실행해야 하는 API로써, XFN 이나 FOAF 처럼 웹페이지 안에서 의미적으로 표현된 소셜 네트워크를 간단히 조회해볼 수 있도록 만들어줍니다.

XFN 과 FOAF 가 보급되었고, 제가 해당 정보를 공개했다는 가정하에 예를 들면, Social Graph API 를 이용해서 작성한 프로그램에, 제 메일이나 블로그 주소를 넣으면, 제 미투데이와 블로그, 싸이월드 등의 주소가 나오고, 각각의 소셜 네트워크 사이트를 통해 연결된 친구들의 목록이 모두 나오는 겁니다. 저를 지인으로 링크 건 사람들도 모두 나오구요.

개인정보 보호의 측면에서 조금 무섭습니다만, 공개한 정보만이 추출될 수 있는 것이고, 웹페이지 간의 링크가, 한편으로는 신뢰성 높은 정보의 유통을 활성화 시켰다면, 인간 중심의 링크를 확인할 수 있게 만드는 작업도 여러가지 의미와 가능성을 품고 있을 것이라고 봅니다.

Social Graph API 가 어떻게 동작하는지 보시려면, 이 곳 에서 소개된 Flex Social Graph Browser 를 한번 돌려보시고, 예제 페이지도 한번 살펴보시면 됩니다.

#
개인적인 견해로는, Social Graph API 는, 시맨틱 검색을 위한 구글의 겸손하고 실용적인 첫 발자국이라고 생각합니다. 이를 통해서 좀 더 많은 데이터가 XFN 과 FOAF 를 통해서 의미 기반으로 공개될 것입니다. 그리고 그걸 기반으로 Social Graph API 는 더 발전해 나갈 테구요.

구글이 시맨틱 웹 검색 분야에서도 독주를 시작하기 전에, 다른 기업들도 조금 분발해야 할 필요가 있을 것 같습니다. 그런데, 구글은 어떻게 이 수 많은 'Graph' 들을 처리했을까요?

이 곳 을 보시면 힌트가 나오네요. Lecture 5 에서 어떻게 MapReduce 로 대량의 그래프를 처리하는지 다루고 있습니다. 아마 Hadoop 기반의 Social Graph 처리 엔진이나 RDF 처리 엔진이 곧 나오게 되지 않을까요?