시맨틱 웹 사이트 계획하기

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 토론 영어원문  제안 및 의견 피드백

난이도 : 초급

Rob Crowther, 웹 개발자, Freelance

2008 년 5 월 13 일

시맨틱 웹은 사용자에게 좀 더 똑똑한 검색 결과를 제공하고 사이트 소유주에게는 방문객이 정말로 원하는 내용을 찾도록 만들어 방문자 숫자를 늘일 기회를 제공합니다. 하지만 이런 장점은 마법처럼 저절로 생겨나지 않습니다. 이 기사는 이렇게 새롭게 등장한 기회를 제대로 활용하기 위해 정보 아키텍처와 일반적인 하부 조직이라는 양쪽 측면을 모두 다룹니다.

이 기사는 여러분의 웹을 시맨틱 웹의 일부로 만들기 위해 필요한 지식을 다룬다. 이 기사는 시맨틱 웹이 풀려고 시도하는 문제부터 논의하기 시작하며, 계속해서 RDF(Resource Description Framework), OWL(Web Ontology Language), SPARQL(SPARQL Protocol and RDF Query Language) 같은 관련 기술 설명을 진행한다. 그리고 시맨틱 웹이 현존하는 웹 위에 어떤 식으로 놓여있는지 살펴본다. 마지막으로 새로운 웹 사이트를 계획할 때 알아야 하는 몇 가지 주의점을 다루고, 시맨틱 웹의 일부가 되기 위해 현존하는 웹 사이트를 활성화하기 위한 RDF나 마이크로포맷과 같은 기술 활용법을 구체적인 예를 들어 소개한다.

시맨틱 웹 소개

월드 와이드 웹은 인간이 지금까지 만든 가장 큰 단일 정보 보고다. 불행하게 정보 관리에 컴퓨터를 사용함에도 불구하고 대다수 정보는 컴퓨터가 아니라 사람만 이해할 수 있다. 컴퓨터는 브라우저로 사람에게 보여주기 위해 HTML 문서 구문을 활용하지만 웹 컴퓨터는 문서 내용, 다시 말해 의미를 이해하지 못한다.

자주 사용되는 약어 API: application programming interface HTML: Hypertext Markup Language URI: Uniform Resource Identifier W3C: World Wide Web Consortium XML: Extensible Markup Language

시맨틱 웹은 팀 버너스 리가 주창한 미래 웹의 비전이다. 비록 꿈은 여전히 현실화되지 못했지만 이제 웹 사이트에서 여러 시맨틱 웹 기술을 활용하도록 RDF, OWL, SPARQL 등 충분한 토대가 갖춰지기 시작했다. 시맨틱 웹의 목표는 웹의 방대한 정보를 드러내어 컴퓨터가 자동으로 해석하도록 만드는 데 있다.

웹은 원래 문서로 시작했다. 웹 브라우저에서 링크를 누르기만 하면 브라우저가 웹 서버에 문서를 보내달라고 요청하고, 서버에서 받은 결과를 여러분에게 보여준다. 문서는 다음 일주일에 걸친 일정표이거나 친구에게서 온 전자편지일지도 모른다. 웹 브라우저는 무슨 내용인지 전혀 신경 쓰지 않으며, 단순히 페이지를 표시하기 위한 내부 규칙만을 따른다. 페이지에 실려있는 정보 해석은 여러분 몫이다.

자료 구조화는 자료에 부가가치를 더한다. 일정한 구조를 따르면 다양한 방식으로 활용이 가능하다. 웹 2.0 조류의 일부로 웹 사이트를 둘러싸고 나온 API 개화에 힘입어, 오늘날 구조화된 자료에 대한 요구가 커지는 현실을 확인할 수 있다. API는 구조화된 자료이며, 다양한 사이트에서 뽑아온 구조화된 자료는 매시업을 가능하게 만든다. 매시업 이면에 숨은 아이디어에 따르면, 웹에 존재하는 다양한 사이트에서 자료를 뽑아와 통합된 방식으로 결합해 출력할 때 구성 요소를 조합한 결과가 원본 정보를 넘어서 부가가치를 더해준다.

시맨틱 웹이 풀고자 하는 동일한 문제를 해결하려는 목적으로 사람들은 부지런히 개별 API를 만들고 있다. 웹 내용을 공개하면 공통점이 없는 다양한 웹 사이트 자료를 결합해 새로운 가치를 추구할 수 있다. 여기서 자신만의 API를 만들어서 유지하는 대신, 이미 존재하는 시맨틱 웹 기반 구조를 완벽하게 이용하도록 웹 사이트를 구축할 수 있다. 웹 사이트 자체가 API라면, 개발과 유지보수에 들어가는 비용을 줄일 수 있다. 비슷하게 자료를 끌어오기를 원하는 모든 웹 사이트를 위한 개별 해법을 찾는 대신, 시맨틱 웹 기술에 기반을 둔 해법 하나만 구현해 다양한 웹 사이트에서 상호 호환이 가능하게 만들 수 있다. 심지어 개발을 시작하기 전에 인지조차 하지 못했던 웹 사이트를 포함해서 말이다.

위로

시맨틱 웹 기술 개괄

시맨틱 웹 기술은 계층 구조로 되어 있으며, 각 층은 아래 쪽 층에서 제공하는 기능에 의존하거나 확장하는 방식을 따른다. 종종 시맨틱 웹이 독자적인 기술이라고 알려지는 경우도 있지만, 시맨틱 웹은 현존하는 웹을 대신할 기술이 아니라 확장하고 개선하는 기술이다.

그림 1을 살펴보면, 시맨틱 웹의 기본 층은 HTTP와 URI다. 이 두 기술은 일반적으로 '시맨틱 웹'이 아니라 '웹' 기술이지만, 이런 웹 기본 위에서 모든 가능한 시맨틱 웹 기술이 존재한다. 시맨틱 웹에서 URI는 명사, HTTP는 동사다. GET, PUT, POST는 물론이고 인증과 보안 부문에서 광범위하게 검증된 기술이 HTTP에 따라나온다.

RDF(Resource Description Framework)는 시맨틱 웹의 핵심 기술이다. RDF는 관계를 기술하는 문법이다. RDF 트리플은 주제, 술어(또는 동사), 객체라는 세 가지 구성요소를 포함한다. 각각은 웹에서 URI를 빌어 자원으로 표현된다. 이는 무작위 XML 문서에서 자료를 기술한다는 이상주의에서 벗어나 현실주의에 가깝다. XML(Listing 1)에서 관계를 단순하게 표현하는 방식을 RDF 트리플(Listing 2)과 비교하기 바란다.

                
<author>
    <uri>page</uri>
    <name>Rob</name>
</author>

<person name="Rob">
    <work>page</work>
</person>

<document href="http://www.example.org/test/page" author="Rob" />

Listing 2는 RDF 트리플을 보여준다.

                
<page> <author> <Rob> .

Listing 1에서 보여준 관계는 상당히 간단한 문장인 'Rob이 page의 저자다'임에도 불구하고 XML에서 여러 가지 방식으로 표현이 가능하다. 이를 XML로 표현한 내용을 읽은 다음에 가능한 모든 관계를 유도하는 소프트웨어 작성은 매우 어려워보인다. 하지만 RDF는 단지 한 가지 방법으로만 관계를 표현하므로 일반적인 파서 제작이 가능해진다.

시맨틱 웹 초기 시절에는, 내용 제공자가 RDF로 내용을 만들어 조만간 엄청난 자료가 배포되리라는 기대를 했다. 불행하게도, RDF로 표현한 XML 문서가 불필요하게 복잡하게 보여서, 전파는 더뎠다. N3(Notation3)와 Turtle(Terse RDF Triple Language) 같은 좀 더 간결한 RDF 표현법이 나왔지만, 관성을 극복하기에는 역부족이었다(N3와 Turtle 정보는 참고자료를 참조하자). 문제를 풀어낼 해법은 마이크로포맷 접근 방법이 제시했다. 마이크로포맷을 사용하면, 의미 값을 표준 HTML 구성요소와 속성 패턴을 일관성있게 사용하면서도 현존하는 HTML 내용에 의미를 추가할 수 있다. 마이크로포맷은 연락 정보나 일정 항목과 같이 제한적인 공통 자료 항목에 사용된다. W3C에서 만든 유사품은 RDFa로 XHTML에 RDF 자료를 내장한다. RDFa 구현은 마이크로포맷보다 좀 더 복잡한데, 훨씬 더 일반적이다. RDF로 표현이 가능한 모든 내용은 RDFa를 사용해 XHTML 문서에 추가할 수 있다. 이런 기법을 통해 현존하는 웹 자료를 출발점으로 시맨틱 웹이 퍼져나갈 수 있다.

물론 RDFa를 사용해 XHTML 문서에 내장된 RDF는 RDF를 입력으로 요구하는 대다수 시맨틱 웹 도구에 적합하지 않다. RDFa 내용이 존재한다는 사실을 인식해 여기서 RDF를 꺼내는 자동화된 방법이 필요하다. 이렇게 하기 위한 W3C 해법은 GRDDL(Gleaning Resource Descriptions from Dialects of Languages)이다. 우선 XSL 변환을 통해 현존하는 XHTML을 RDF로 바꾼다. 그리고 나서 직접 참조나 프로파일과 네임스페이스 문서를 통한 간접 참조로 GRDDL 변환과 연계한다.

RDF로 모호하지 않게 의미를 표현하는 작업은 좋지만, 심지어 모든 사람이 RDF를 따를지라도 여러 사이트에서 만든 RDF가 어떤 식으로 관계를 맺는지 모른다면 효용성이 떨어진다. Listing 2에 제시한 RDF 트리플은 서술부로 'author' 관계를 표현하는데, 의미가 사람인 여러분에게는 와닿을지 몰라도 컴퓨터 입장에서는 여전히 도움을 필요로 한다. 여러분 사이트에서 저자 관계를 표현했다면, 컴퓨터가 동일한 관계를 가정할 수 있을까? 여러분이 RDF 트리플로 'writer' 관계를 표현한다면? 여기서 필요한 내용은 공통 어휘로 표현하는 방법이며, 이런 방법을 통해 내가 말하는 'author'와 당신이 말하는 'author'가 같거나 'author'와 'writer'가 비슷하다고 말할 수 있다. 시맨틱 웹에서 이런 문제는 온톨로지로 해결하며, W3C 표준에서는 온톨로지 표현을 위해 OWL(Web Ontology Language)을 만들었다. OWL은 독자적으로 다루기에도 벅찬 광범위한 주제이며, 여러분은 이 기사에서 응용 분야에만 관심이 있기에, 세부 사항은 여기서 다루지 않으니 참고자료를 참조하기 바란다.

일단 RDF로 몇몇 자료를 만들었고 온톨로지로 자료 사이 관계를 결정했다면, 이런 자료에서 유용한 정보를 꺼내기 위한 방법이 필요하다. ('스파클'이라고 부르는) SPARQL(Simple Protocol and RDF Query Language)은 RDF 자료에 대해 질의를 표현하는 SQL과 비슷한 구문이며, 질의 자체도 RDF 자료처럼 보이고 RDF 자료처럼 동작한다. SPARQL에 깔린 이론적 틀은 패턴 매칭이며, 공통점이 없는 사이트에서 얻은 자료를 웹 상에서 유연하게 다루도록 설계되어 있다. 예를 들어, 문장 일치를 옵션으로 기술할 수 있으므로 비정형 자료를 질의할 때 SQL보다 뛰어나다. 비정형 자료는 제대로 정의된 단일 SQL 데이터베이스와 비교해 예측이 어렵고 안정적이지 못한 구조를 담고 있는데, 다양한 웹 사이트로부터 꺼내어 결합한 자료를 찾아내기를 기대하는 경우에 제격이다.

위로

시맨틱 웹 사이트 계획 과정에서 알아야 할 지식

이미 살펴본 바와 같이, 다음 번에 뛰어난 웹 2.0 사이트를 생성한다면, 웹 사이트를 위한 독자적인 API를 대신해 시맨틱 웹 기술을 포용하여 웹 사이트를 API로 변환하도록 계획을 세움으로써 시간을 절약할 수 있다. 시맨틱 웹 접근 방법은 자유로운 API와 비슷한 기능을 제공한다. 일반적으로 API는 일반 상태에서 비구조적인 웹 사이트로부터 XML이나 JSON 형식을 사용해서 구조적인 자료를 얻어내는 방법이다. 이런 방식에는 양면이 있다. 사람을 대상으로 하는 웹 페이지를 만들고 여기서 컴퓨터가 자동 처리를 위한 구조화된 정보를 끌어내도록 API를 추가해야 하기 때문이다. 하지만 이렇게 하려면 추가 작업이 필요한데, API 사용을 활성화하려면 문서화하고 유지보수하고 웹 사이트에서 제공하는 새로운 기능과 동기화하도록 지원해야 한다. 시맨틱 웹 접근 방법을 사용한다면, 웹 사이트가 바로 구조화된 자료이므로, 별도 구현이 필요없다. 사용자는 자동화된 처리를 위한 다른 시맨틱 웹 도구를 활용할 수도 있다.

이렇게 하려면 계획 과정에서 필요한 몇 가지 고려 사항이 있다. API를 사용할 경우 전달을 원하는 정보의 각 항목에 맞춰 독자적인 자료 형식을 자유롭게 정의할 수 있으며, 시맨틱 웹을 사용한다면 이와 비슷하게 독자적인 온톨로지를 정의할 수 있다. 온톨로지 설계는 어려운 작업이므로, 경험이 부족한 상태에서 제대로 된 설계를 이끌어내기란 무척 어렵기에 계획 중인 자료 유형에 적합한 방대한 자료 집합이 이미 존재하는지 확인해야 한다. 이는 다음 절에서 다룬다. API를 설계할 때 또한 개념적인 조직 구성용 객체 모형을 고려해 개발자들이 항목 집합이나 항목 자체를 얻는 시점과 항목이 속한 집합을 구분하는 방법을 파악하도록 도와줘야 한다. 시맨틱 웹 사이트에서 이런 설계 기법은 일부 온톨로지 선택으로 결정이 가능하지만 URI 체계로도 가능하다. 뒤에서 API 일부로 URI를 활용 가능하게 만드는 접근 방법을 살펴보기로 하자.

마지막으로 한마디 덧붙이자면 현존하는 웹 사이트에 대해 GRDDL, RDFa, 마이크로포맷을 활용해 내용을 갱신한다면 시맨틱 웹에서 얻는 장점을 그대로 가져올 수 있다.

위로

현존하는 온톨로지 문맥에서 자료 평가

시맨틱 웹에서 좀 더 복잡한 부분은 자료에 일치하는 온톨로지 설계다. 올바른 온톨로지에 도달해야 시맨틱 웹 프로젝트 구현을 성공리에 마치게 된다. 다행히, 많은 온톨로지가 이미 나와있다. 표 1에 몇 가지 온톨로지를 정리했다.

많은 온톨로지는 기술, 환경 과학, 화학, 언어학과 같은 전문 분야에 국한되어 있다. 하지만 이런 전문적인 온톨로지는 앞서 표로 정리한 분야보다 적용 가능한 웹 사이트 수가 적다. 여러분 자료 중 상당수는 표 1에서 정리한 온톨로지가 다루는 분야 중 적어도 하나에는 일치할 가능성이 높다. 이런 경우에 계획 단계에서 기존 온톨로지를 사용할 수 있다.

위로

시맨틱 URI 체계 선택

웹 사이트가 API라면, URI는 프로그래머가 자료에 접근하는 메서드다. 이렇기 때문에 의미있고, 간결하고, 일관성이 있는 구조가 중요하며, 미리 URI에 대해 생각할 필요가 있다. 모든 서비스를 시작한 다음에 잦은 변경이 일어나면 민폐를 끼치기 때문이다. 또한 RDF 트리플 구성 요소가 일반적으로 URI라는 사실을 기억해야 한다. URI를 바꾸면 해당 웹 사이트를 참조하는 대다수 기존 RDF가 못쓰게 된다.

웹 초기에, URI 구조가 웹 서버에 있는 파일 구성에 영향을 미쳤다. 제품 집합 중에서 특정 위젯 형식을 판매했다면, URI는 http://www.mysite.com/products/gadgets/widget.html과 비슷한 형태가 된다.

이런 접근 방법의 장점은 상대적으로 의미가 명확하다는 사실이다. doodad라는 제품을 팔았다면 이 제품을 찾기 위한 URI는 http://www.anothersite.com/products/gadgets/doodad.html과 비슷한 형태를 기대한다.

위젯과 doodad 사이의 관계는 상당히 명쾌하다. 이렇게 하는 경우에 생기는 주요 문제점은 유연성 부족이다. 즉, 범주화된 계층이 고정되어 있다.

웹이 발전함에 따라, 동적으로 페이지를 생성하는 사이트가 일반화되었다. 하지만 이런 사이트가 유연성을 제공하는 대신 구조는 더 이상 특정 파일 형식에 얽매이지 않게 되었고, URI로 표현되는 시맨틱 정보량은 감소했다. 질의 문자열을 통해 다소 암호처럼 보이는 정보를 사용해서 페이지를 기술하기 때문이다. 예를 들어, 위젯 URI는 http://www.mysite.com/inventory.cgi?pid=12345, doodad URI는 http://www.mysite.com/inventory.cgi?pid=67890와 비슷한 형태가 된다.

이런 식으로 URI가 바뀌면 갑자기 URI에 담긴 시맨틱 의미가 사라져버린다. 앞서 동적 URI로 표현한 두 제품이 동일 범주에 들어가는지 명확하지 않다. 시간이 흘러감에 따라, CMS(Content Management System)와 웹 개발 프레임워크가 이런 문제점을 해결하기 시작했다. 이제 동적 페이지의 유연성을 유지하면서 의미적으로 구조화된 URI를 지정하는 작업이 한결 수월해졌다. 이렇게 된 이유는 URI가 서버에 존재하는 물리적인 파일을 가리키는 대신 다양한 위치에 존재하는 스크립트나 페이지가 전달할 내용을 가리키도록 바뀌었기 때문이다. 이런 시류는 루비 온 레일즈 프레임워크에서 시작되었다. 루비 온 레일즈는 라우트(URL을 특정 컨트롤러나 액션으로 사상하는 규칙)를 통해 URI를 지정한다. CMS 패키지에서, 이런 기능은 일반적으로 아파치에서 제공하는 mod_rewrite(또는 다른 웹 서버에서 유사 기능)에 의존하며, 종종 "검색 엔진에 친밀한 URI"나 비슷한 문구로 표현된다. 사이트를 위한 CMS나 개발 프레임워크를 선택할 때, 이런 기능을 고려해서 검토하기 바란다.

마지막 한마디. 가능하다면 URI에서 파일 이름 확장자(.html이나 .cgi 같은)를 제거하자. 파일 이름 확장자는 사용자에 아무런 의미도 주지 못하는 정보이면서도 장기적인 관점에서 보면 실제로 문제를 일으킨다. 웹 사이트를 바꿔서 CGI 스크립트 대신에 PHP를 사용한다면, 진짜 똑같은 내용을 제공하는 URI가 완전히 달라져버린다. 이는 URI의 의미론적 가치도 희석하고, 구글 랭킹에도 나쁜 영향을 미친다. 좀 더 의미론적으로 뛰어난 방법으로 HTTP 헤더를 활용해서 내용 협상을 벌인다. http://www.mysite.com/products/gadgets/widget 같은 URI를 고려해보자.

웹 브라우저는 일반적으로 Accept HTTP 헤더를 사용해서 선호하는 내용 유형을 지정한다. 이런 요청이 들어오면, 웹 서버는 헤더를 점검해서 text/html이 옵션 중 하나인지 살펴본 다음에 HTML 페이지를 반환한다. RDF를 원하는 매시업 응용 프로그램이 있다면, HTTP 요청에서 Accept 헤더는 application/rdf+xml을 포함해야 하며, 웹 서버는 동일한 URI에서 (이번에는 HTML이 아니라) RDF 버전으로 페이지를 제공한다.

현재까지 이런 내용 협상 기능은 많은 패키지형 CMS 제품이 지원하지 않지만, 오래지 않아 파일 확장자 없이 URI를 사용하도록 대다수 CMS 제품군이 바뀔 가능성이 높으므로 URI 체계를 뒤집어 엎지 않고서도 장래에 이런 기능을 추가할 수 있다.

위로

현존하는 시맨틱 추가 도구 활용

웹 사이트 기반 구조에 시맨틱 웹을 완전히 포용하거나 아니면 단순히 현존하는 자료를 좀 더 유용하게 만들기를 원하거나에 상관없이 웹 사이트에 현존하는 내용에 구조를 추가하는 여러 가지 기회가 존재한다. 이는 마이크로포맷, RDFa, GRDDL과 같은 기술 영역이다. 표 2는 구조화된 자료로서 쉽게 마크업이 가능한 좀 더 공통적인 정보 유형을 정리했다.

구조화된 마크업을 여러분의 페이지에 추가하는 작업은 상당히 단순하다. 아래에 소개할 Listing 3과 4는 각각 RDF vCard에 필요한 추가적인 마크업을 포함하지 않은 경우와 포함한 경우를 망라하는 연락 정보를 담은 HTML 코드 일부를 보여준다.

                
<div class="contactinfo">
  Rob Crowther. Web hacker
  at
  <a href="http://example.org">
    Example.org
  </a>.
  You can contact me
  <a href="mailto:robertc@example.org">
    via e-mail
  </a> or on my work phone at 0123 456789.
</div>

Listing 4는 RDF vCard를 위해 추가적으로 필요한 마크업으로 표현한 연락처 정보를 보여준다.

                
<div xmlns:contact="http://www.w3.org/2001/vcard-rdf/3.0#" class="contactinfo"  
                                     about="http://example.org/staff/robertc">
  <span property="contact:fn">Rob Crowther</span>.
  <span property="contact:title">Web hacker</span>
  at
  <a rel="contact:org" href="http://example.org">
    Example.org
  </a>.
  You can contact me
  <a rel="contact:email" href="mailto:robertc@example.org">
    via e-mail
  </a>
  or on my 
  <span property="contact:tel">
    <span property="contact:type">work</span>
    phone at
    <span property="contact:value">0123 456789</span>
  </span>.
</div>

Listing 4에서, 엘리먼트를 확장해서 의미론적으로 중요한 텍스트 비트와 의미하는 바를 알려주기 위해 속성을 구분한다. 네임스페이스 "contact"를 추가해 RDF VCard 용어집에 연결한다. 다음으로 이 엘리먼트가 URI http://example.org/staff/robertc가 표현하는 자원에 대한 내용임을 지정한다. 그리고 나서 링크 관계를 위한 rel 속성과 링크가 아닌 관계를 위한 property 속성을 사용해 메타자료를 추가한다. 유일하게 조금 복잡한 부분은 전화번호인데, 유형과 숫자를 지정할 필요가 있기 때문이다. 이렇게 하려면, tel 엘리먼트 내부에 type과 value 엘리먼트를 중첩시켜야 한다. 이런 구조체를 더함으로써 사용자가 마우스 클릭 한번으로 주소록에 세부 사항을 추가할 수 있다.

자동화된 처리 방법은 각기 다른 구조화된 양식을 사용한다. 예를 들어, 테크노라티는 rel-tag 마이크로포맷을 사용해서 광범위한 블로그 포스트를 분류한다. Listing 5에 제시한 rel-tag는 rel 속성을 활용하는 링크일 뿐이다. 중요한 부분은 마지막 / 뒤에 나오는 URI의 마지막 비트다. 이는 (표준 URI 인코딩 관례를 따라 공백을 더하기 기호로 표현한) 태그다.

                
<a href="http://technorati.com/tag/semantic+web" rel="tag">
  Semantic Web
</a>

Listing 5에서 제공한 코드를 포함한 시맨틱 웹에 관련한 블로그 글을 포스팅했다면, 테크노라티에 새로운 포스트를 올렸다고 알려준다(많은 블로그 소프트웨어는 이런 작업을 자동으로 진행하도록 설정되어 있다). 그러면 정보 수집기가 포스트 글을 색인해 동일한 태그를 달고 있는 다른 포스트와 함께 태그 엘리먼트가 가리키는 페이지 요약을 추가한다(그림 2 참조).

위로

결론

이 기사에서, 시맨틱 웹 기술은 현재 절찬리에 각 웹 사이트에서 사용하는 방식인 독자적인 API 제공과 비교해서 표준적이고 일관성 있는 방식을 따르는 구조화된 자료의 필요성을 부각시켰다. 시맨틱 웹 기술은 현존하는 웹 구성 요소인 HTTP와 URI를 토대로 상위 층에 부가가치를 추가한다. 우선 RDF를 사용해서 모호하지 않은 관계로 표현하고, 다음으로 OWL 기반 온톨로지로 의미를 공유하고, 최종적으로 SPARQL을 사용해서 분산 웹에서 지식을 질의한다. 이 기사는 또한 현존하는 온톨로지를 활용해 자료가 무엇인지를 정의하고 시맨틱 URI 체계를 활용해 웹 사이트가 API가 되도록 만들어준다. 마지막으로 현존하는 웹 사이트 내용을 RDFa와 마이크로포맷을 토대로 GRDDL 서비스를 사용해 페이지에서 RDF를 자동으로 추출하도록 판올림하는 방법을 다룬다.

비록 팀 버너스-리의 시맨틱 웹은 아직 완전히 개화되지 않았지만, 여러 해에 걸친 생각과 노력 끝에 오늘날 사람들이 직면한 실질적인 문제를 풀어낼 해법이라는 과실을 거두기 시작했다. 웹 2.0에서 불어온 강력한 협업 분위기는 웹에서 표준적이며 의미론적으로 인코딩된 자료에 대한 요구 사항을 이끌어냈다. 계획을 잘 세워 요구 사항을 충족하는 데 도움을 주는 시맨틱 웹 도구를 제대로 활용하자.

참고자료

• 최고의 매시업—웹 서비스와 시맨틱 웹(Nicholas Chase, 한국 developerWorks, 2007년 4월): 6부로 구성된 튜토리얼로 시맨틱 웹 기술을 구체적으로 설명한다.
  
  
• Introduction to Jena: Use RDF models in your Java applications with the Jena Semantic Web Framework(Philip McCarthy, developerWorks, 2004년 6월): 자바 응용 프로그램에서 RDF 자료 모델을 활용하기 위해 Jena 시맨틱 웹 툴킷 활용 방법을 설명한다.
  
  
• Programmable Web: 새로운 웹 2.0 API와 매시업에 대한 최신 소식을 놓치지 말자.
  
  
• The Structured Web - A Primer: 구조화된 자료의 가치를 소개하는 개론을 읽어보자.
  
  
• W3C's RDF Primer: RDF 기초와 효율적인 사용법을 익히자.
  
  
• A Semantic Web Primer for Object-Oriented Software Developers: OOP 관점에서 RDF 스키마, OWL와 같은 온톨로지 활용법을 읽어보자.
  
  
• W3C's OWL Overview: 사람뿐만이 아니라 정보 처리를 위해 OWL이 응용 프로그램에 무엇을 해주는지 설명하는 글이다.
  
  
• SPARQL Query Language for RDF 명세: RDF를 위한 질의 언어 구문과 의미론을 살펴보자.
  
  
• Notation3: RDF XML 구문의 대안으로 나온 간편하고 읽기 쉬운 특성을 제공하는 N3에 대한 글이다.
  
  
• Terse RDF Triple Language: 간단하고 자연스러운 텍스트 형식으로 RDF 그래프를 만드는 RDF용 언어인 터틀을 살펴보자. 이 글은 일반적인 활용 패턴과 자료 유형을 요약하고 있다. 터틀은 현존하는 N 트리플, N3 형식, SPARQL 패턴 구문과 호환이 가능하다.
  
  
• Cool URIs for the Semantic Web: RDF와 시맨틱 웹 사이를 연결하는 효율적인 URI에 대한 지침을 읽어보자.
  
  
• University of Southampton Department of Electronics and Computer Science: 운영중인 시맨틱 웹 사이트를 살펴보자.
  
  
• RDFa 또는 Microformats: 웹 페이지에 시맨틱 정보를 포함하자.
  
  
• IBM XML 인증: XML과 관련 기술 분야에서 IBM 인증 개발자가 되는 방법을 설명한다.
  
  
• XML 기술 라이브러리: 기사와 팁, 튜토리얼, 표준, IBM 레드북 등 다양한 기술 자료를 제공한다.
  
  
• developerWorks 기술 행사와 웹 캐스트: 기술 자료를 놓치지 말자.
  
  
• IBM developerWorks XML 영역: XML과 시맨틱 웹에 대한 자료를 제공한다.
  
  
• 온라인 기술 서점: 기술 부문에 대한 서적을 검색하자.
  
  

• IBM 평가판 소프트웨어: developerWorks에서 직접 내려 받아 다음번 프로젝트에 활용하자.
  
  

• 포럼에 참여하기.
  
  
• XML 포럼: 여러 XML 관련 토론에 참가하자.
  
  
• developerWorks XML 영역: 생각을 공유하기: 이 글을 읽은 다음에 의견과 생각을 포럼에 올리자. XML 영역 관리자가 여러분의 글을 중재해서 올려줄 것이다.
  
  
• developerWorks 블로그: 블로그를 읽어보고 developerWorks 공동체에 참가하자.

필자소개

		Rob Crowther는 런던에서 웹 개발자로 활약하고 있다. Crowther는 웹 표준에 관심이 많으며, 블로그인 http://www.boogdesign.com/b2evo/에 종종 글을 올린다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로