내용 보증은 할 수 없으며, 반드시 웹 사이트의 정식 문서를 참조하기 바란다. 또 저작권에 관해서는 본 문서에 포함되는

W3C 책임, 등록상표, 문서 사용과 소프트웨어 계약에 관한 규칙이 적용된다.

RDF 입문서(RDF Primer)

W3C 제안권고 2003년 12월 15일(W3C Proposed Recommendation 15 December 2003)

This version:: http://www.w3.org/TR/2003/PR-rdf-primer-20031215/
Latest version:: http://www.w3.org/TR/rdf-primer/
Previous version:: http://www.w3.org/TR/2003/WD-rdf-primer-20031010/
Editors:: Frank Manola, fmanola@acm.org; Eric Miller, W3C, em@w3.org
Series Editor:: Brian McBride, Hewlett-Packard Laboratories, bwm@hplb.hpl.hp.com

자원기술구조(Resource Description Framework: RDF)는 월드 와이드 웹(World Wide Web)에 있는 자원에 관한 정보를 표현하기 위한 언어이다. 이 입문서는 RDF를 효과적으로 사용하는 데 필요한 기초지식을 이용자에게 제공하기 위해 고안된 것이다. 이 문서에서는 RDF의 기본개념을 소개하고, RDF의 XML 구문을 기술하고 있다. 또한 RDF 어휘기술언어(Vocabulary Description Language)를 사용하여 RDF 어휘를 정의하는 방법을 설명하고 있으며, RDF를 도입한 일부 어플리케이션을 간략하게 소개하고 있다. 아울러 RDF와 관련된 기타 규격문서의 내용과 목적도 소개하고 있다.

이 절에서는 발행 당시의 이 문서의 위상을 설명하고 있다. 다른 문서가 이 문서를 대치할 수도 있다. 현행 W3C 발간물 목록과 이 기술보고서의 최신 개정에 관해서는 http://www.w3.org/TR/의 W3C technical reports index에서 찾아 볼 수 있다.

이 문서를 제안권고사항(Proposed Recommendation)으로 출판하게 된 것이 W3C 회원에 의한 승인을 의미하는 것은 아니다. 이 문서는 초안으로서, 언제라도 다른

문서로 갱신되거나 대체 또는 폐기될 수 있다. 따라서 이 문서를 ‘진행 중인 연구’ 이외의 문서로 인용하는 것은 적절하지 못하다.

이 문서의 초기 버전에 표현된 디자인을 폭넓게 검토하였으며, 그래서 실무진의 공인된 기술상의 요구사항(chartered technical requirements)을 충족하고 있다. 실무진은 접수된 모든 의견(all comments received)을 검토하였으며, 필요에 따라 내용을 변경하였다. 많은 구현사례들이 보고 되었으며, 그 중에는 규격에서 정한 모든 특성을 포함한 사례도 있었다. 두 번째 최종 검토용 실무초안(Second Last Call Working Draft) 이후부터 이 문서에 반영된 변경내용은 변경로그(change log)에 상세히 기술되어 있다.

W3C 자문위원회 대표들에게 검토의견 요청서에 기술된 대로, 정식 검토의견을 웹 형식을 통하여 제시하도록 현재 요청하고 있다. 다른 의견은 팀 전용 리스트(Team-only list)인, w3t-semweb-review@w3.org로 제출하면 된다. 일반인들은 www-rdf-comments@w3.org (archive)로 의견을 보내면 되며, 관련 기술에 관한 일반 토의에 참여하기 위해서는 www-rdf-interest@w3.org (archive)에 접속하면 된다. 검토기간은 2004년 1월 19일까지 연장되었다.

목 차

부 록

자원기술구조(Resource Description Framework: RDF)는 월드 와이드 웹(World Wide Web)에서 자원에 관한 정보를 표현하기 위한 언어이다. RDF는 특히 웹 페이지의 표제와 저자, 갱신일자를 포함하여 웹 문서의 저작권과 계약정보, 또는 일부 공유자원에 대한 접근가능일자 등, 웹 자원에 관한 메타데이터를 표현하기 위한 것이다. 그러나 “웹 자원”이라는 개념을 일반화함으로써, 비록 웹에서 직접 검색되지는 않더라도 웹에서 식별되는 사물에 관한 정보를 표현하기 위해서도 RDF를 사용할 수 있다. 그 예로는 온라인 쇼핑 사이트에서 구매할 수 있는 상품에 관한 정보(예를 들어 제품규격이나 가격, 재고정보)나 정보전달을 위한 웹 이용자의 선호도에 관한 사항 등이 포함된다.

RDF는 이러한 정보를 사람들에게 단지 제시하기 위한 것이 아니라 어플리케이션으로 처리하기 위한 것이다. RDF는 의미의 손상 없이 이러한 정보를 어플리케이션 상호간에 교환할 수 있도록 표현하기 위한 공통의 틀을 제공한다. RDF는 공통의 틀이기 때문에 어플리케이션 설계자는 공통의 RDF 파서와 처리도구를 쉽게 구할 수 있다. 상이한 어플리케이션 간에 정보를 교환하는 능력은 그 정보를 맨 처음 생성한 어플리케이션이 아닌 다른 어플리케이션에서도 그 정보를 이용할 수 있다는 것을 의미한다.

RDF는 웹 식별기호(Uniform Resource Identifiers 또는 URIs라고 하는)를 사용하여 사물을 식별하고, 아울러 간단한 성질과 성질 값으로 자원을 기술한다는 생각에 토대를 두고 있다. 이를 통해서 RDF에서는 자원에 관한 간단한 선언문을 그 자원을 표현한 노드와 호(아크), 그리고 이들 자원의 성질과 값으로 구성된 그래프로 표현할 수 있다. 가능한 한 이 논의를 좀 더 구체적으로 전개하기 위해서, “이메일 주소가 em@w3.org이고, 직함이 Dr.인 Eric Miller는 http://www.w3.org/People/EM/contact#me로 식별되는 사람이다”라고 하는 일단의 선언문을 <그림 1>의 RDF 그래프로 표현할 수 있다.

<그림 1>은 RDF에서 URI를 사용하여 다음과 같은 사항을 식별하고 있음을 보여주고 있다:

• 개인, 예를 들어 Eric Miller는 http://www.w3.org/People/EM/contact#me로 식별되고 있다.

• 사물의 종류, 예를 들어 사람은 http://www.w3.org/2000/10/swap/pim/contact#Person으로 식별되고 있다.

• 사물의 성질, 예를 들어 메일박스는http://www.w3.org/2000/10/swap/pim/contact#mailbox로 식별되고 있다.

• 이들 성질의 값, 예를 들어 메일박스 성질의 값으로 mailto:em@w3.org (RDF에서는 성질 값으로 “Eric Miller"와 같은 문자열은 물론, 정수와 날짜와 같은 기타 데이터타입의 값도 사용한다).

아울러 RDF에서는 이러한 그래프를 기록하고 교환하기 위하여 XML에 기반한 구문(RDF/XML이라고 한다)도 제공하고 있다. 예 1은 <그림 1>의 그래프와 대응해서 RDF/XML로 작성된 RDF의 일부이다.

이 RDF/XML 구문에는 mailbox와 fullName(약어형식으로)과 같은 성질과 더불어 이들 각 성질의 값으로 em@w3.org과 Eric Miller도 포함되어 있으며, 아울러 URI도 포함되어 있음을 주목할 필요가 있다.

HTML과 같이 이 RDF/XML 구문은 기계로 처리할 수 있으며, URI를 통하여 웹상의 각 정보를 연결할 수 있다. 그러나 종래의 하이퍼텍스트와는 달리 RDF URI는 웹상에서 직접 검색할 수 없는 것까지도 포함해서(Eric Miller와 같은 사람), 식별할 수 있는 어떤 것이라도 지시할 수 있다. 결과적으로 웹 페이지와 같은 사물을 기술하는 것 이외에, RDF는 자동차나 회사, 사람, 뉴스 이벤트 같은 것도 기술할 수 있다. 이밖에 RDF 성질 자체는 URI를 가지고 있기 때문에 연결된 개개의 사물 간에 존재하는 관계를 정확하게 식별할 수 있다.

이 입문서는 RDF를 소개하고, 기존의 RDF 어플리케이션 중 일부를 기술하여, RDF의 특징과 사용법을 정보시스템 설계자와 어플리케이션 개발자가 이해할 수 있도록 지원하는데 그 목적이 있다. 특히 이 입문서는 다음과 같은 질문에 대한 해답을 제공하기 위하여 쓰여진 것이다:

• RDF 정보를 어떻게 작성하고, 접근할 수 있으며, 처리하는가?

이 입문서는 규범적인 문서가 아니며, 따라서 RDF에 대한 정의적 규격서가 아니라는 점이다. 본서에 포함된 예와 기타 설명 자료는 RDF에 대한 이해를 돕기 위한 것이며, 따라서 항상 본서가 정의적이거나 완전한 해답을 제공하는 것은 아니다. 정의적이고 완전한 해답을 필요로 하는 경우에는 RDF 규격서 중 관련된 규범적 내용을 참고해야 한다. 이 과정을 지원하기 위해 이 입문서에서는 완전한 RDF 규격에서 이들 기타 문서가 지닌 역할을 기술하고 있으며, 검토과정 중 적절한 위치에서 규범적인 규격서의 관련 부분으로 지시하는 연결점을 제공하고 있다.

아울러 지적할 사항은 이들 RDF 문서는 기 간행된 RDF 규격서인 자원기술구조 모형 및 구문 규격서(Resource Description Framework Model and Syntax Specification [RDF-MS])와 자원기술구조 스키마 규격서 1.0(Resource Description Framework Schema Specification 1.0 [RDF-S])을 갱신하여 그 의미를 분명하게 제시하고 있다는 점이다. 이에 따라 용어와 구문, 개념 중 일부를 변경하였다. 이 입문서에서는 위에서 글머리 기호를 사용하여 인용한 RDF 문서목록에 포함된 새로운 RDF 규격을 반영하고 있다. 따라서 기존의 규격서, 그리고 이들 자료에 기초한 초기의 자습서, 개론 성격의 논문과 친숙한 이용자들은 현행 규격서와 기존의 문서 간에 차이가 있다는 점을 알아야 한다. 기존의 RDF 규격서와 관련하여 제기된 문제와 현재의 규격서에서 그 해결방안이 어떤 것인지를 알고 싶은 경우에는 RDF 문제에 대한 추적 문서(RDF Issue Tracking [RDFISSUE])를 참고할 수 있다.

RDF는 웹 페이지와 같은 웹 자원에 관한 선언문을 작성하기 위한 간단한 방법을 제공하기 위한 것이다. 이 절에서는 RDF에서 이러한 능력을 제공하는 방식의 배경이 되는 기본적인 개념을 기술하고 있다 (이러한 개념을 기술한 규범적인 규격서는 RDF 개념과 요약 구문 (RDF Concepts and Abstract Syntax [RDF-CONCEPTS])이다.

John Smith라고 하는 이름을 가진 사람이 하나의 특정한 웹 페이지를 작성하였다는 사실을 표현하고 싶은 경우를 가정하자. 이 사실을 영어와 같은 자연어로 직접적으로 진술하는 방법은 다음과 같은 간단한 선언문의 형식으로 표현하는 것이다:

http://www.example.org/index.html has a creator whose value is John Smith

어떤 사물의 성질을 기술하기 위하여 이 선언문 중 일부를 굵은 글자로 표시하였는데, 다음과 같은 여러 가지 사물을 명명하거나 식별하기 위한 방법이 필요하기 때문이다:

• 선언문이 기술하는 사물의 특수한 성질(이 경우에는 creator)

• 선언문이 말하는 것은 선언문이 기술하고 있는 사물에 대한 이 성질의 값(누가 creator인지)이다.

이 선언문에서는 웹 페이지를 식별하기 위하여 이 웹 페이지의 URL(Uniform Resource Locator)을 사용하였다. 이밖에 "creator"라는 단어를 사용하여 그 성질을 식별하고 있으며, "John Smith"라는 두개의 단어를 사용하여 이 성질의 값인 사물(사람)을 식별하고 있다.

이 웹 페이지를 식별하기 위하여 URL을 사용하고, 그 성질과 값을 식별하기 위하여 단어(혹은 기타 표현)를 사용한, 동일한 일반형식의 영어 문장을 추가로 작성함으로써 이 웹 페이지의 다른 성질을 기술할 수 있다. 예를 들어 다음과 같은 선언문을 추가하여 이 웹 페이지의 작성일자와 이 페이지에 사용된 언어를 기술할 수 있다:

http://www.example.org/index.html
        has a creation-date whose value is August 16,
        1999

http://www.example.org/index.html has a
        language whose value is English

RDF에서는 기술대상인 사물은 성질(properties)을 가지고 있고, 이 성질은 값을 가지며, 위에서 언급한 바와 같이 이들 성질과 값을 명시한 선언문을 작성해서 자원을 기술할 수 있다는 생각에 기초하고 있다. RDF에서는 이 선언문의 각 부분을 지칭할 때 특수한 용어를 사용하고 있다. 특히 선언문에서 제시하고자 하는 사물을 식별하는 부분을 주어(subject)라고 한다(이 예에서는 웹 페이지). 이 선언문에서 구체적으로 제시된 이 주어의 성질이나 특성을 제시하는 부분을 술어(predicate)라고 하고 (이 예에서는 creator, creation-date, language 등), 이 성질의 값을 제시하는 부분을 목적어(object)라고 한다. 따라서 이 선언문을 영어로 작성하면 다음과 같다:

http://www.example.org/index.html has a creator whose value is John Smith

그런데 비록 영어가 (영어권에서는) 사람들 사이의 의사교환용으로 우수하지만, RDF는 기계로 처리할 수 있는 선언문을 작성하기 위한 것이다. 이 같은 선언문을 기계로 적절히 처리할 수 있도록 작성하기 위해서는 다음과 같은 두 가지 일이 필요하다:

• 다른 누군가가 웹에서 사용할 가능성이 있는 유사하게 보이는 식별기호와 혼동되지 않으면서 선언문에 포함된 주어와 술어, 목적어를 식별할 수 있는 기계처리가 가능한 식별기호체계

• 이러한 선언문을 표현하고, 기계 상호간에 이 선언문을 교환할 수 있는 기계처리가 가능한 언어

다행히 현재의 웹 구조에서는 필요로 하는 이 두 가지 기능을 모두 갖추고 있다.

앞에서 예시한 바와 같이, 웹에서는 URL이라고 하는 한 가지 형식의 식별기호를 이미 제공하고 있다. 처음 예에서 URL은 John Smith가 작성한 웹 페이지를 식별하기 위해 사용되었다. URL은 자원에 대한 주된 접근방식을 표현함으로써(본질적으로는 자원의 네트워크상의 “위치”) 웹 자원을 식별하는 문자열이다. 그러나 중요한 점은 웹 페이지와는 달리 네트워크 주소나 URL을 가지고 있지 않은 여러 가지 사물에 관한 정보를 수록할 수도 있다는 것이다.

웹에서는 이러한 목적으로 이보다 더 일반형식의 식별기호인 Uniform Resource Identifier (URI)를 제공하고 있다. URL은 하나의 특수한 유형의 URI이다. 여러 사람이나 기관이 독자적으로 URI를 만들 수 있고, 또 이 URI를 사용하여 사물을 식별할 수 있는 성질을 모든 URI는 공유하고 있다. 그러나 URI는 네트워크 주소를 가진 사물을 식별하거나 또는 다른 컴퓨터의 기타 접근기법을 사용하는 것으로 한정되어 있지 않다. 실제로 선언문에서 지시할 필요가 있는 어떤 것이라도 URI를 만들어 지시할 수 있다. 여기에는 다음과 같은 것들이 포함된다:

• 전자문서나 화상, 서비스 (예를 들면 "today's weather report for Los Angeles") 등이나 일단의 기타 자원과 같이 네트워크 접근이 가능한 사물

• 인간이나 단체, 도서관의 제본도서 등과 같이 네트워크 접근이 불가능한 사물

• “저작자”라는 개념과 같이 물리적으로 존재하지 않는 추상적 개념

이러한 범용성으로 인해 RDF에서는 선언문에 포함된 주어와 술어, 목적어를 식별하기 위한 토대로 URI를 사용하고 있다. 더 정확하게 표현하면 RDF에서는 URI 참조 [URIS]를 사용한다. URI 참조(또는 URIref)는 하나의 URI로서, 그 말미에 선택사항인 단편 식별기호(fragment identifier)가 부기되어 있다.

예를 들면 URI 참조인 <http://www.example.org/index.html#section2>는 <http://www.example.org/index.html>이라는 URI와 ("#" 문자로 분리된) Section2라는 단편 식별기호로 구성되어 있다. RDF URIrefs는 유니코드 ([UNICODE]) 문자를 포함할 수 있으며 ([RDF-CONCEPTS]를 보라), 여러 언어가 URIref에 반영되도록 허용하고 있다. RDF에서는 URI 참조로 식별되는 것이라면 어떤 것이라도 자원으로 정의하고 있으며, 따라서 URI참조를 사용함으로써 실질적으로 어떤 사물이라도 RDF에서 기술할 수 있고, 동시에 이들 사물간의 관계도 표현할 수 있다. URIref와 단편 식별기호에 대해서는 부록 A와 RDF 개념 ([RDF-CONCEPTS])에서 더 상세하게 설명하고 있다.

기계로 처리할 수 있는 방식으로 RDF 선언문을 표현하기 위해서 RDF에서는 Extensible Markup Language [XML]를 사용하고 있다. XML은 누구라도 자신의 문서형식을 설계하고 그 형식으로 문서를 작성할 수 있도록 고안된 것이다. RDF에서는 RDF 정보를 표현하고, 이 정보를 기계 상호간에 교환하기 위하여 RDF/XML이라고 하는 특수한 XML 마크업 언어를 정의하고 있다. RDF/XML의 예는 제1절에 제시되어 있다. 이 예(예 1)에서는 Eric Miller와 Dr.라는 텍스트 컨텐츠를 한정하기 위하여 <contact:fullName>과 <contact:personalTitle>과 같은 태그를 각각 사용하였다. 이들 태그를 사용하게 되면 그 태그가 무엇을 의미하는지를 알 수 있고, 그렇게 작성된 프로그램이 해당 컨텐츠를 적절하게 해석할 수 있다. XML 내용과 (특정한 예외는 있지만) 태그 모두 유니코드 ([UNICODE]) 문자를 포함할 수 있으며, 여러 가지 언어로 된 정보를 직접 표현할 수 있다. 부록 B에서는 XML에 관한 배경을 전반적으로 상세하게 제공하고 있다. RDF에 사용된 이 특수한 RDF/XML 구문에 대해서는 제3절에서 보다 상세하게 설명하고 있으며, RDF 구문(<a href="#ref-rdf-syntax">[rdf-syntax]</a>)에 규범적으로 정의되어있다.

2.2 The RDF Model

2.1절에서는 RDF의 기본선언문이라는 개념과 RDF 선언문에서 지시된 사물을 식별하기 위하여 URI 참조를 사용한다는 생각, 그리고 RDF 선언문을 기계로 처리 가능한 방식으로 표현하기 위한 RDF/XML을 소개하였다. 이 절에서는 이와 같은 배경을 가지고 RDF에서 자원에 관한 선언문을 작성하기 위하여 어떻게 URI를 사용하는가를 설명하고 있다. 서론에서 지적한 바와 같이 RDF는 자원에 관한 단순한 선언문을 표현한다는 생각에 기초하고 있으며, 여기서 각 선언문은 주어와 술어, 목적어로 구성되어 있다. 다음과 같이 영어로 작성된 문장이 있다고 하자:

could be represented by an RDF statement having:

a subject http://www.example.org/index.html
a predicate http://purl.org/dc/elements/1.1/creator
and an object http://www.example.org/staffid/85740

RDF에서는 이 문장을 다음과 같은 RDF 선언문으로 표현할 수 있다:

"creator"와 "John Smith"라는 단어를 사용하는 대신, 처음 선언문의 주어뿐만 아니라 술어와 목적어를 식별하기 위하여 각각 URIref를 어떻게 사용하였는가에 유의할 필요가 있다 (이와 같은 방법으로 URIref를 사용하였을 때의 효과에 대해서는 이 절 후반부에서 다시 설명하고 있다).

RDF에서는 그래프의 노드와 호(아크)로 선언문을 모델화하고 있다. RDF의 그래프 모델은 RDF 개념([RDF-CONCEPTS])에 정의되어 있다. 여기서 정의한 표기방식에 따르면 선언문은 다음과 같이 표현된다.

따라서 위의 RDF 선언문을 <그림 2>와 같은 그래프로 표현할 수 있다.

일단의 선언문은 상응되는 일단의 노드와 호로 표현된다. 따라서 다음과 같이 영문으로 된 선언문을 RDF 그래프로 추가로 표현하는 경우에는 <그림3>의 그래프를 사용할 수 있다(적절한 URIref를 사용하여 "creation-date"와 "language" 성질을 지정할 수 있다).

http://www.example.org/index.html 
  has a creation-date whose value is August 16, 1999

<그림3>에서는 특정한 종류의 성질 값을 표현하기 위하여 RDF 선언문의 목적어가 URIref거나 혹은 문자열로 표현된 상수 값(리터럴이라고 한다) 중 하나일 수 있음을 보여주고 있다. (술어 http://purl.org/dc/elements/1.1/language의 경우, 리터럴은 영어에 대한 두 자리 국제표준부호이다.) 리터럴은 RDF 선언문에서 주어나 술어로서는 사용될 수 없다. RDF 그래프를 그릴 때 URIref인 노드는 타원으로 표시되며, 반대로 리터럴인 노드는 4각형으로 표시된다(본문에서 예시로 사용된 단순한 문자열 리터럴을 일반 리터럴이라고 하고, 2.4절에서 소개할 유형화된 리터럴(typed literals)과는 구분된다. RDF 선언문에 사용될 수 있는 여러 종류의 리터럴에 대해서는 RDF 개념 ([RDF-CONCEPTS])에서 정의하고 있다. 일반 리터럴과 유형화된 리터럴 모두 유니코드 ([UNICODE]) 문자를 포함할 수 있으며, 여러 언어로부터의 정보를 직접 표현할 수 있다).

이상의 것들을 논할 때 그래프로 표현하는 것이 불편할 때도 있고, 따라서 선언문을 작성하는 또 다른 방법으로서 트리플(triple)이 사용되기도 한다. 이 트리플 표기방식에서는 그래프의 각 선언문이 주어, 술어, 목적어의 순서로 된 간단한 트리플로 표현된다. 예를 들어 <그림3>에 있는 세 개의 선언문을 다음과 같은 트리플로 작성할 수 있다.

<http://www.example.org/index.html><http://purl.org/dc/elements/1.1/creator> <http://www.example.org/staffid/85740> .
<http://www.example.org/index.html><http://www.example.org/terms/creation-date> "August 16, 1999" .

<http://www.example.org/index.html><http://www.example.org/terms/language> "en" .

각 트리플은 그래프에서 하나의 호에 대응되고, 호의 시작노드와 종료노드(선언문의 주어와 목적어)로 완결된다. 작성된 그래프와는 달리(그러나 처음 선언문과 같이) 트리플 표기에서 노드는 그 노드가 출현하는 각 선언문에서 독립적으로 식별되어야 한다는 것이다.

따라서 예를 들어 http://www.example.org/index.html은 이 그래프의 트리플 표현에서 세 번 출현하게 되지만(각 프리플에서 한번씩), 작성된 그래프에서는 단 한번만 표현된다. 그러나 트리플은 작성된 그래프와 정확하게 동일한 정보를 표현하며, 중요한 점은 RDF의 기본은 선언문의 그래프 모델(graph model)이라는 점이다. 그래프를 표현하거나 그리기 위하여 사용된 표기법은 부차적인 것이다.

트리플을 완전하게 표기하기 위해서는 꺽쇠괄호 속에 URI 참조를 완전하게 작성해야 하는데, 위의 예에서 제시된 바와 같이 이 URI 참조는 아주 긴 행이 될 수 있다. 편의상 본 입문서에서는 트리플을 작성할 때 단축형을 사용하였다 (기타 RDF 규격서에서도 이와 동일한 단축형이 사용되고 있다). 이 단축형에서는 꺽쇠괄호를 사용하지 않고, XML의 한정된 이름(또는 QName)을 완전한 URI 참조에 대한 단축형으로 대치하게 된다(QName에 대해서는 부록 B에서 더 구체적으로 설명하고 있다). QName은 이름공간 URI에 배정된 접두사를 포함하고 있고 그 다음에 반점(:)이 오고, 그 다음에 로컬명(local name)이 온다. 이 접두사에 배정된 이름공간 URI에 로컬명을 부기함으로써 QName으로부터 완전형 URIref를 구축하게 된다. 따라서 예를 들어 QName 접두사인 foo를 이름공간 URI인 http://example.org/somewhere/에 배정하게 되면 QName foo:bar는 URIref인 http://example.org/somewhere/bar의 단축형이 된다. 또 다음에서 정의한 바와 같이 본 입문서에 사용된 예시에서도 “널리 알려진” 다수의 QName 접두사를 사용하게 될 것이다(매번 이들 접두사를 명시적으로 규정하지 않고).

다음 예시에서 "example"의 접두사인 ex:가 여러 가지 변형된 형식으로 필요에 따라 사용되고 있다. 예를 들면 다음과 같다.

prefix exterms:, namespace URI: http://www.example.org/terms/ (예시 기관이 사용한 용어용),

prefix exstaff:, namespace URI: http://www.example.org/staffid/ (예시 기관의 직원 식별기호용),

prefix ex2:, namespace URI: http://www.domain2.example.org/ (두 번째 예시 기관용) 등

이 새로운 단축형을 사용하여 앞에 제시된 트리플 세트를 다음과 같이 작성할 수 있다.

RDF에서는 선언문에서 사물을 지칭하기 위하여 단어 대신 URIref를 사용하기 때문에 RDF에서는 일련의 URIref(특히 특정한 목적으로 사용하기 위한 일련의 URIref)를 어휘(vocabulary)라고 부른다. 대개 이러한 어휘에 속한 URIref는 공통의 접두사를 사용하는 일련의 QName으로 표현될 수 있도록 조직된다. 즉 어휘에 포함된 모든 용어에 대해 하나의 공통된 이름공간 URIref를 선정하게 되는데, 대개는 그 어휘를 정의하는 사람의 제어아래 URIref가 놓이게 된다.

이 공통의 URIref 말미에 개개의 로컬명을 덧붙여 기술함으로써 이 어휘에 포함된 URIref를 구축하게 된다. 이렇게 하여 공통의 접두사를 가진 일련의 URIref를 형성하게 된다. 예컨대 앞에서 예시한 바와 같이 example.com과 같은 기관은 "creation-date"나 "product"와 같이 사업상 사용하는 용어에 대하여 접두사 http://www.example.org/terms/로 시작되는 URIref로 구성된 어휘를 정의할 수 있으며, 그리고 해당 기관의 직원을 식별하기 위하여 http://www.example.org/staffid/로 시작되는 또 다른 어휘의 URIref를 정의할 수 있다. RDF에서는 이와 동일한 방법을 사용하여 RDF에서 특수한 의미를 가진 용어에 대하여 독자적인 어휘를 정의하고 있다. 이 RDF 어휘에 있는 URIref는 모두 http://www.w3.org/1999/02/22-rdf-syntax-ns#로 시작되며, 통상적으로 QName 접두사인 rdf:와 연결되어 있다. RDF 어휘기술언어(RDF Vocabulary Description Language: 제5절에 기술되어 있다)는 통상적으로는 QName 접두사인 rdfs:와 연결되며 http://www.w3.org/2000/01/

rdf-schema#로 시작되는 URIref를 가진 일련의 용어를 추가로 정의하고 있다(여기서 특정한 QName 접두사는 흔히 이와 같은 방식으로 일련의 용어와 연결되어 공통으로 사용되며, 때로는 QName 접두사 자체가 그 어휘의 명칭으로 사용된다. 예를 들어 누군가가 "the rdfs: vocabulary"라고 할 수도 있다).

공통의 URI 접두사를 사용하게 되면 관련된 일련의 용어에 대한 URIref를 편리하게 조직할 수 있다. 그러나 이것은 단지 하나의 약정일 뿐이다. RDF 모델에서는 단지 완전형 URIref만을 인식하며, 따라서 RDF 모델은 URIref의 “내부를 보거나”, URIref 구조에 관하여 아무런 지식도 사용하지 않는다. 특히 RDF에서는 URIref가 단지 선행하는 공통의 접두사를 가지고 있다는 것 때문에 URIref 상호간에 어떤 관계가 있다고 가정하지 않는다(더 구체적인 것은 부록 A를 참고하기 바란다). 더욱이 선행접두사를 달리한 URIref가 동일한 어휘의 일부로 취급될 수 없다고 하는 것은 아무것도 없다. 특정 기관이나 과정, 도구 등은 얼마든지 다른 어휘에서 URIref를 가져와 그 자신의 어휘의 일부로 사용함으로써, 자신에게 중요한 어휘를 정의할 수 있다.

이밖에 때로는 어떤 기관에서 어휘의 이름공간 URIref를 그 어휘에 관한 추가 정보를 제공하는 웹 자원의 URL로 사용할 것이다. 예를 들어 앞서 지적한 바와 같이, 본 입문서의 예시에서는 이름공간 URIref인 http://purl.org/dc/elements

/1.1/과 관련하여 QName 접두사인 dc:를 사용하게 될 것이다. 실제로 이것은 6.1절에서 다루고 있는 더블린 코어 어휘를 지시하고 있다. 웹 브라우저에서 이 이름공간 URIref에 접근하게 되면 더블린 코어 어휘에 관한 부가적인 정보를 검색하게 될 것이다(특히 RDF 스키마). 그렇지만 이것 역시 하나의 약정일 뿐이다. RDF에서는 이름공간 URI가 검색 가능한 웹 자원을 식별한다고 전제하지 않는다(추가 설명은 부록 B를 참고하기 바란다).

본서의 나머지 부분에서는 RDF 자체에서 사용하기 위해 정의된 URIref 세트와 example.com에서 해당 직원을 식별하기 위해 정의된 URIref 세트와 같이, 어떤 특정한 목적으로 정의된 일련의 URIref를 지칭할 때 어휘(vocabulary)라는 용어를 사용할 것이다. 이름공간이라는 용어는 특별히 XML 이름공간의 구문상의 개념을 지칭할 때에만 사용될 것이다(혹은 QName의 접두사에 배정된 URI를 기술할 때).

RDF 그래프에는 서로 다른 어휘에 속한 URIref를 자유스럽게 섞어 넣을 수 있다. 예를 들어 <그림3>의 그래프에서는 exterms:, exstaff:, dc: 어휘의 URIref를 사용하고 있다. 아울러 RDF에서는 동일한 자원을 기술하기 위하여 특정한 URIref를 술어로 사용하는 선언문이 얼마나 많이 그래프에 출현할 수 있는지에 대해 아무런 제한을 두지 않고 있다. 예를 들어 만약 자원인 ex:index.html이 John Smith 이외에 다수의 직원들의 협력으로 작성된 것이라면 example.org은 다음과 같은 선언문으로 작성될 것이다.

RDF 선언문에 관한 이들 예에서는 사물을 식별하기 위한 RDF의 기본방식으로 URIref를 사용할 때의 장점의 일부를 보여주고 있다. 예컨대 첫 번째 선언문에서는 이 웹 페이지의 저자를 "John Smith"라는 문자열로 식별하는 대신, 이 사람에게 http://www.example.org/staffid/85740 이라는 URIref를 배정하였다(이 사람의 사원번호에 기초한 URIref를 사용하여). 이 경우 URIref를 사용하였을 때의 장점은 이 선언문의 주어를 훨씬 더 정확하게 식별할 수 있다는 것이다. 즉 이 웹 페이지의 저자는 "John Smith"라는 문자열도 아니고 또한 John Smith라는 이름을 가진 수천 명 중의 어느 한 사람도 아닌, 이 URIref와 관련된 John Smith라는 특정한 사람이라는 점이다(URIref를 작성한 사람은 누구라도 이 관계를 정의한다). 더욱이 John Smith를 지시하는 URIref가 있기 때문에 이 사람은 완전한 자원이며, 단순히 John의 URIref를 포함한 RDF 선언문을 주어로 추가함으로써 이 사람에 대한 부가적 정보를 수록할 수 있다. 예를 들면 <그림 4>에는 John의 이름과 나이를 나타내는 부차적 선언문이 일부 포함되어 있음을 볼 수 있다.

RDF는 RDF 선언문에서 URIref를 술어(predicate)로 사용하고 있음을 이들 예에서도 볼 수 있다. 즉 성질을 식별하기 위하여 "creator"나 "name"과 같은 문자열(혹은 단어)을 사용하는 대신, RDF에서는 URIref를 사용한다. 성질을 식별하기 위하여 URIref를 사용하는 것은 여러 가지 이유에서 중요하다. 첫째, URIref를 사용하게 되면 다른 누군가가 사용할 가능성이 있는 성질과 자신이 사용하고 있는 성질 간을 구별할 수 있다. 그렇지 않으면 이 상이한 성질이 동일한 문자열로 식별될 가능성이 있다. 예를 들어 <그림 4>의 example.org에서는 어떤 특정인의 완전명을 표현하기 위해 문자열 리터럴로 작성된 "name"을 사용하고 있지만 (즉 "John Smith"), 또 다른 어떤 사람이 이와 다른 것(예를 들면, 프로그램 텍스트 중에서 변인명과 같이)을 표현하기 위해 의도적으로 "name"을 사용할 수도 있다. 웹상에서 "name"을 성질 식별기호로 인식하는 프로그램(혹은 복수의 정보원에서 데이터를 통합한 프로그램)은 이러한 용법상의 차이를 반드시 구분할 수 있는 것은 아니다. 그런데 만약 example.org에서 "name" 성질로 http://www.example.org/terms/name을 작성하고, 또 다른 사람이 자신의 이름을 http://www.domain2.example.org/genealogy/terms/name으로 작성하였다면 분명한 사실은 별개의 성질이 관련되어 있다는 점이다 (비록 프로그램은 별개의 의미임을 자동으로 판단하지는 못하지만). 아울러 성질을 식별하기 위하여 URIref를 사용하게 되면 그 성질을 자원 자체로 취급할 수 있다. 성질이 자원이기 때문에 단지 그 성질의 URIref를 주어로 갖는 RDF 선언문을 추가함으로써 그 성질에 관한 부가적 정보를 기록할 수 있다 (예를 들어, example.org에서 "name"이 무엇을 의미하는가를 영문으로 기술함으로써).

RDF 선언문에서 URIref를 주어와 술어, 목적어로 사용하게 되면 웹상에서 공유할 수 있는 어휘의 개발과 이용을 지원하게 된다. 왜냐하면 사람들이 사물을 기술할 때 다른 사람이 이미 사용한 어휘를 찾아서 사용할 수 있고, 이는 이들 개념에 대한 공통적 이해를 반영하기 때문이다. 예를 들어 다음과 같은 트리플에서

술어인 dc:creator를 URIref로 완전히 전개하게 되면 더블린 코어 메타데이터 속성 세트(6.1절에서 더 상세하게 설명하고 있다)의 "creator" 속성을 분명하게 지시(참조)하게 된다. 더블린 코어 메타데이터 속성 집합은 모든 종류의 정보를 기술하기 위해 폭 넓게 사용되고 있는 일련의 속성(성질) 집합이다. 이 트리플을 작성한 사람은 이 웹 페이지(http://www.example.org/index.html로 식별되는)와 이 페이지의 저자(http://www.example.org/staffid/85740로 식별되는 특정 개인)와의 관계는 정확하게 http://purl.org/dc/elements/1.1/creator로 식별되는 개념이라는 점을 효과적으로 말하게 된다. 더블린 코어 어휘에 익숙한 사람이나 dc:creator가 무엇을 의미하는지 아는 사람은 (예컨대 웹상에서 이 요소의 정의를 찾아봄으로써) 이 관계가 의미하는 바를 알게 될 것이다. 게다가 이러한 이해를 토대로 사람들은 술어인 dc:creator를 포함하고 있는 트리플을 처리할 때 그 의미대로 작동하도록 프로그램을 작성할 수 있다.

물론이지만 이를 위해서는 사물을 지시하기 위해 리터럴 대신 URIref의 일반적 사용을 증대시켜야 한다. 예를 들어 John Smith와 creator와 같은 문자열 리터럴 대신 exstaff:85740과 dc:creator와 같은 URIref를 사용하는 것이다. 그렇다고 해서 RDF에서 URIref를 사용함으로써 모든 식별상의 문제를 해결하지는 못한다. 왜냐하면 예를 들어 동일한 사물을 지시하기 위해 사람들은 여전히 서로 다른 URIref를 사용할 수 있기 때문이다. 이런 이유로 다른 어휘와 의미가 중복될 수 있는 새로운 용어를 작성하는 대신, 가능하면 기존의 어휘(더블린 코어와 같은)에 속한 용어를 사용하는 것은 좋은 생각이다. 6절에서 설명한 어플리케이션으로 예시된 바와 같이, 특정한 어플리케이션 분야에서 사용하기 위한 적절한 어휘는 항상 개발되고 있다. 그런데 비록 동의어가 생성되는 경우라도 이처럼 상이한 URIref가 공통으로 접근 가능한 “웹 공간”에서 사용되고 있다는 사실로 인해, 이들 상이한 참조 중에서 동일한 것을 식별하고, 아울러 공통의 참조를 사용하는 방향으로 이행(migrate)하는 기회를 제공하고 있다.

이밖에 RDF 선언문에 사용된(앞의 예에 사용된 dc:creator와 같은) 용어와 관련해서 RDF 자체가 가지는 의미와 그리고 이들 용어와 관련해서 사람들(혹은 이들이 작성한 프로그램)이 부차적으로 그 용어와 관련하여 외부적으로 정의한 (externally-defined) 의미 간의 차이를 구분하는 것이 중요하다. 하나의 언어로서 RDF는 주어와 술어, 목적어의 트리플로 구성된 그래프 구문, rdf: 어휘에 포함된 URIref와 관련된 특정한 의미, 그리고 나중에 기술될 특정한 기타 개념들만을 직접 정의하고 있다. 이러한 것들은 [RDF-CONCEPTS]와 [RDF-SEMANTICS]에서 규범적으로 정의되어 있다. 그러나 RDF에서는 dc:creator와 같이 RDF 선언문에 사용될 수 있는 기타 어휘에 속한 용어에 대해서는 그 의미를 정의하지 않고 있다. 어휘에서 정의된 URIref에 특수한 의미를 부여함으로써 RDF 외부에서 특수한 어휘를 작성할 수 있다. 이 어휘에 속한 URIref를 RDF 선언문에 사용하게 되면 이들 어휘에 친숙한 사람들이나 이들 어휘를 처리하기 위해 작성된 RDF 어플리케이션에 이들 용어와 관련된 특수한 의미를 전달할 수 있으며, 특별히 이들 어휘를 처리하기 위해 특별히 작성되지 않은 임의의 RDF 어플리케이션에 그 의미를 전달하는 것이 아니라는 점이다.

이것은 더블린 코어 어휘에서 dc:creator의 특수한 정의를 사람들이 이해하고 있다는 점을 근거로 하거나 또는 "creator"라는 단어의 출현을 URIref인 dc:creator의 일부로 관련시켰을 때의 의미에 기초한 것이다. 그러나 임의의 RDF 어플리케이션이 관련되어 있는 한, 그리고 이미 정해진 어떤 의미가 관련되어 있는 한, 이 트리플은 대개 다음과 같은 것이 될 것이다.

이와 마찬가지로 웹에서 볼 수 있는 dc:creator의 의미를 기술한 어떤 자연언어 텍스트도 임의의 어플리케이션이 직접 사용할 수 있는 아무런 부차적 의미도 제공하지 않고 있다.

물론이지만 비록 특정한 어플리케이션에서 어떤 특수한 의미를 URIref로 연관시킬 수는 없을지라도 특정 어휘의 URIref를 RDF 선언문에 사용할 수 있다.

예를 들어 위의 표현이 RDF 선언문이고, ed:dsfbups이 술어라는 것 등을 일반 RDF 소프트웨어가 인식하게 될 것이다. 이 RDF 소프트웨어는 어휘 개발자들이 ed:dsfbups와 같은 URIref와 연관시켰을 수도 있는 어떤 특수한 의미를 단지 트리플과 연계하지는 않을 것이다. 더욱이 비록 그렇게 작성되지 않은 RDF 어플리케이션에서는 그 의미에 접근할 수 없을 지라도, 특정 어휘에 대한 이해에 기반하여 사람들은 그 어휘에 속한 URIref에 배정된 특수한 의미에 따라 움직이도록 RDF 어플리케이션을 작성할 수 있다.

이 모든 것의 결과로 RDF는 어플리케이션에서 훨씬 쉽게 처리할 수 있는 선언문을 작성하는 방법을 제공하고 있다. 앞서 지적한 바와 같이 현재 어플리케이션이 이러한 선언문을 실제로 “이해”하지 못하는 것은, 바로 ‘3만5천불 이상의 급여를 받는 직원 중에서 이름을 선택하라’(SELECT NAME FROM EMPLOYEE WHERE SALARY > 35000)와 같은 질의를 처리할 때 "employee"나 "salary"와 같은 용어를 데이터베이스 시스템이 “이해”하지 못하는 것과 같은 것이다. 그렇지만 어플리케이션을 적절하게 작성하게 되면 마치 데이터베이스 시스템과 그 어플리케이션이 "employee"와 "payroll"을 이해하지는 못하지만 인사정보와 급여정보를 유용하게 처리하는 것과 마찬가지로, 어플리케이션이 실제로 그 선언문을 이해하고 있는 것과 같은 방식으로 RDF 선언문을 처리할 수 있다. 예를 들면 이용자가 웹에서 모든 서평을 검색하고 각 문헌에 대해 평균 순위를 부여할 수 있다. 그리고나서 이 이용자는 이 정보를 다시 웹에 올려놓을 수 있다. 또 다른 웹 사이트에서는 도서 순위에 대한 이 평균 리스트를 취하여 “최상위로 평가된 10개의 문헌”(Top Ten Highest Rated Books)이라는 페이지를 작성할 수 있다. 여기서 순위와 관련하여 공유하고 있는 어휘의 이용가능성(availability)과 용법, 그리고 이 순위에 해당되는 문헌을 식별하는 일단의 URIref를 사용함으로써 개개인이 문헌에 대해 상호 이해할 수 있고 점점 더 강력해진(추가로 내용이 보완됨에 따라) “정보기지”를 웹상에 구축할 수 있게 되는 것이다. 매일 웹상에서 수천 개의 주제와 관련하여 작성되는 방대한 양의 정보에 대해 이와 동일한 원리가 적용된다.

RDF 선언문은 정보를 수록하는데 있어서 다음과 같은 면에서 여러 다른 형식과 유사하다.

• 데이터처리시스템에서 자원을 기술한 간단한 레코드나 목록의 엔트리

그리고 이들 형식의 정보는 RDF 선언문으로 취급될 수 있어서, RDF를 사용하여 여러 정보원의 데이터를 통합할 수 있다.

사물에 관해 기록되는 정보의 유형이 지금까지 예시한 단순한 RDF 선언문 형태로 분명하게 제시할 수 있는 것만이라면 일은 아주 간단할 것이다. 그렇지만 현실 세계의 대부분의 데이터는 적어도 표면상으로는 그보다 훨씬 더 복잡한 구조를 가지고 있다. 예를 들어 첫 번째 예에서 웹 페이지의 작성일자는 일반 리터럴을 그 값으로 지닌 하나의 exterms:creation-date라는 성질로 기록되었다. 그런데 exterms:creation-date 성질의 값을 월, 일, 년과 같은 독립된 정보로 기록할 필요가 있다고 생각해 보자. 혹은 John Smith의 개인정보인 경우, John의 주소를 기술한다고 생각해 보자. 전체 주소는 일반 리터럴로서 다음과 같은 트리플로 기술할 수 있을 것이다.

그런데 John의 주소를 거리와 도시, 주, 우편번호 등, 각기 별개로 구성된 구조로 기록해야 하는 경우를 생각해 보자. 이것을 RDF에서는 어떻게 표현할 것인가?

이와 같이 구조화된 정보는 기술 대상인 통합된 대상(John Smith의 주소와 같이)으로 취급되어 RDF에서 하나의 자원으로 표현되고, 그리고 나서 이 새로운 자원에 관한 선언문을 작성하게 된다. 따라서 RDF 그래프에서는 John Smith의 주소를 그 구성부분으로 나누기 위하여 새로운 노드를 만들어 John Smith의 주소라는 개념을 표현하며, 이 주소를 식별하기 위하여 새로운 URIref를 만들게 된다. 예를 들어 http://www.example.org/addressid/85740 (exaddressid :85740로 단축된)가 그 경우이다. 그리고 나서 부차적 정보를 표현하기 위하여 이 노드를 주어로 한 RDF 선언문(부차적 호와 노드)을 작성할 수 있으며, 그 결과 <그림 5>의 그래프를 작성할 수 있다.

이처럼 RDF에서 구조화된 정보를 표현하는 방법에서는 John의 주소와 같이 통합된 개념을 표현하기 위하여 exaddressid:85740과 같은 다수의 “중간” URIref를 생성하게 된다. 이들 개념은 특정 그래프의 외부에서는 직접 참조할 필요가 없기 때문에 “범용”(universal) 식별기호를 필요로 하지 않는다. 더욱이 <그림 5>의 일단의 선언문을 표현한 그래프를 그릴 때 "John Smith의 주소"를 식별하기 위해 배정된 URIref는 실제로 불필요한데, 그 까닭은 이 그래프를 바로 <그림 6>과 같이 쉽게 표현할 수 있기 때문이다.

<그림 6>은 RDF 그래프로서는 아주 완벽한 것인데, "John Smith의 주소"라는 개념을 나타내기 위하여 URIref가 없는 노드를 사용하고 있다. 이 공백노드는 URIref를 사용하지 않고 그래프를 작성하기 위한 것인데, 이 노드 자체가 그래프의 여러 상이한 부분 간에 존재하는 필연적인 연계관계를 제공하기 때문이다([RDF-MS]에서는 이 공백노드를 무명 자원(anonymous resources)이라고 하였다). 그러나 이 그래프를 트리플로 표현하기 위해서는 이 노드에 대하여 일정한 형식을 지닌 분명한 식별기호가 필요하다. 이를 제시하기 위해서 <그림 6>에 제시된 내용에 대응되는 트리플을 작성하게 되면 다음과 같은 것이 될 것이다.

여기서 ???는 공백노드의 존재를 의미한다. 복잡한 그래프에서는 복수의 공백노드를 포함할 수 있기 때문에 그래프를 트리플로 표현할 때 이들 상이한 공백노드 간을 구분하는 방법도 필요하다. 따라서 트리플에서 공백노드의 존재를 제시하기 위하여 _:name 형식의 공백노드 식별기호를 사용한다. 예를 들어 이 예에서 공백노드 식별기호인 _:johnaddress를 사용하여 공백노드를 지시하고 있고, 이 경우 결과로 생기는 트리플은 다음과 같다.

그래프를 트리플로 표현할 때, 그래프의 개개의 공백노드에 서로 다른 공백노드 식별기호를 부여한다. URIref와 리터럴과는 달리, 공백노드 식별기호는 RDF 그래프의 실제 구성요소로 취급되지 않는다(이것은 <그림 6>의 그래프를 보면 알 수 있는데, 공백노드는 공백노드 식별기호를 가지지 않는다는 점에 유의할 필요가 있다). 공백노드 식별기호는 그래프를 트리플 형식으로 표현할 때 단지 그래프의 공백노드를 표현하는 하나의 방법일 뿐이다(그리고 공백노드 상호간을 구분한다). 아울러 공백노드 식별기호는 하나의 그래프를 표현한 트리플 내에서만 의미를 지닌다(동일한 수의 공백노드를 지닌 두개의 상이한 그래프에서 이들 공백노드를 구분하기 위하여 동일한 공백노드 식별기호를 독립적으로 사용할 수 있으며, 서로 다른 그래프에서 동일한 공백노드 식별기호를 가진 공백노드는 같은 것이라고 생각하는 것은 옳지 않다). 만약 그래프의 노드를 그래프 외부에서 참조할 필요가 있는 경우에는 이를 식별하기 위하여 URIref를 배정해야 한다. 마지막으로 공백노드 식별기호는 RDF 그래프를 트리플 형식으로 표현할 때 호(아크)가 아닌 (공백) 노드를 표현한 것이기 때문에, 공백노드 식별기호는 트리플에서 주어나 목적어로 한번만 출현할 수 있으며, 공백노드 식별기호는 트리플에서 술어로서는 사용되지 않는다.

이 절 첫 머리에서 지적한 바와 같이, 기술대상인 통합된 대상을 하나의 독립된 자원으로 취급하고, 그리고 나서 이 새로운 자원에 관련된 선언문을 작성함으로써, John Smith의 주소와 같은 통합된 구조를 표현할 수 있다.

이 예는 RDF의 중요한 측면을 시사하고 있는데, RDF에서는 이항(binary) 관계만을 직접적으로 표현한다. 예를 들어 John Smith와 이 사람의 주소를 표현한 리터럴 간의 관계와 같은 것이다. John과 그의 주소를 구성하는 각 요소(components) 집단 간의 관계를 표현하는 것은 John과 거리, 시, 주, 우편번호 등의 구성요소간의 n 항(n 방향) 관계를 다루는 것과 관련되어 있다(이 경우 n=5). 이러한 구조를 RDF에서 직접 표현하기 위해서는(예를 들어 주소를 거리, 시, 주, 우편번호와 같은 일단의 구성요소로 이루어진 것으로 취급하여) 이 n 항 관계를 일단의 독립된 이항관계로 분해해야 한다. 공백노드는 이를 위한 한 가지 방법을 제공하게 된다. 각각의 n항 관계에 대하여 관계를 지닌 것 중 하나를 관계의 주어로 선정하고(이 경우에는 John), 그리고 공백노드를 만들어 관계를 가진 나머지를 표현한다(이 경우 John의 주소). 그리고 나서 관계에 참여한 나머지 것들(이 예에서는 시와 같은 것)을 공백노드로 표현된 새로운 자원의 독립된 성질로 표현하게 된다.

아울러 공백노드는 URI가 없는 자원에 관한 선언문을 아주 정확하게 작성할 수 있는 방법을 제공하지만, URI를 가진 다른 자원과의 관계를 통하여 기술된다. 예를 들어 Jane Smith라는 사람에 관한 선언문을 작성한다고 할 때, 이 사람의 이메일 주소에 기초한 URI, 예컨대 mailto:jane@example.org를 이 여성의 URI로 사용하는 것은 아주 자연스러워 보인다. 그러나 이러한 접근방법은 문제를 야기할 수 있다. 예를 들어 Jane 자신에 관해서는 물론(예를 들어, 그녀의 현주소) Jane의 메일박스(예를 들어, 메일박스가 위치한 서버)에 관한 정보를 기록할 필요가 있을 수 있고, 그래서 이 사람의 이메일 주소에 기초하여 Jane에 대한 URIref를 사용하는 것은 기술대상이 Jane인지 아니면 그녀의 메일박스인지를 알기 어렵게 만든다. 예컨대 http://www.example.com/와 같은 회사의 웹 페이지 URL을 그 회사 자체의 URL로 사용할 때에도 똑 같은 문제가 발생하게 된다. 다시 지적하지만 회사에 관한 정보는 물론이고, 웹 페이지 자체에 관한 정보를 기록할 필요가 있을 수 있고(이 웹 페이지를 누가 언제 작성하였는지에 관한 정보), 이 때 이 두 가지 경우에 http://www.example.com/를 식별기호로 사용하는 것은 이 중에 어느 것이 진짜 주어인지를 알기 어렵게 만든다.

Jane의 메일박스(mailbox)를 Jane 대신 사용하는 것은 실제로 정확하지 않다는 점이 근본적인 문제이다. 즉 Jane과 그녀의 메일박스는 동일한 것이 아니며, 따라서 이들은 각기 달리 식별되어야 한다. Jane 자신이 URI를 가지고 있지 않은 경우, 공백노드를 사용하게 되면 이 상황을 더 정확하게 모델링할 수 있게 된다. Jane을 공백노드로 표현할 수 있고, exterms:mailbox라는 성질과 이 성질 값으로 URIref인 mailto:jane@example.org를 가진 선언문의 주어로 이 공백노드를 사용하는 것이다. 아울러 다음 트리플에서 보는 바와 같이, 이 공백노드를 exterms:Person 이라는 값을 가진 rdf:type 성질로 기술할 수 있고(type은 다음 절에서 더 상세하게 다룬다), 다시 "Jane Smith"라는 값을 지닌 exterms:name 성질을 부여할 수 있으며, 그리고 기타 유용한 기술정보를 기술할 수 있다:

(mailto:jane@example.org가 첫번째 트리플에서 꺾쇠괄호 안에 기재된 점에 유의하기 바란다. 이것은 mailto:jane@example.org는 QName 축약이 아니라 mailto URI 체계에서 완전한 URIref이고, 완전한 URIref는 트리플 표기에서 반드시 꺾쇠괄호 안에 기재되어야 하기 때문이다.)

이 트리플은 “exterms:Person 이라는 타입의 자원이 있고, 이 사람의 전자메일박스는 mailto:jane@example.org이며, 이 사람의 이름은 Jane Smith 등”임을 정확하게 말하고 있다. 즉 이 공백노드는 “자원이 있다”라는 의미로 해석된다. 따라서 공백노드를 주어로 가진 선언문은 그 자원의 특성에 관한 정보를 제공하게 된다.

실제로 이와 같은 경우에 URIref 대신 공백노드를 사용해도 이와 같은 종류의 정보를 취급하는 방식에는 큰 변화가 없다. 예를 들어 이메일 주소를 통해 example.org에 있는 어떤 사람을 고유하게 식별할 수 있는 경우(특히 이 주소를 재사용할 가능성이 없는 경우), 비록 이 이메일 주소가 그 사람의 URI가 아니더라도 그 사실을 이용하여 복수의 정보원으로부터 그 인물에 관한 정보와 연결될 수 있을 것이다. 이 경우 만약 하나의 문헌을 기술한 웹에서 저자의 연락처 정보를 mailto:jane@example.org로 제시한 RDF구문을 발견한 경우, 이 새로운 정보를 위에 예시한 트리플 세트와 조합하여 그 저자명은 Jane Smith라고 결론짓는 것이 합리적일 것이다. 이 말의 요점은 “이 문헌의 저자는 mailto:jane@example.org이다”라고 말하는 것은 일반적으로 “이 문헌의 저자는 mailto:jane@example.org라는 메일박스를 가진 어떤 사람이다”라는 것을 간략하게 표현한 것이라는 점이다. 공백노드를 사용하여 이와 같이 “누군가”를 표현하는 것은 실세계의 상황을 보다 더 정확하게 표현하는 방법에 지나지 않는다. (우연하게도 일부 RDF 기반 스키마 언어에서는 특정한 성질은 그 성질이 기술하는 자원의 고유한 식별기호(unique identifier)라는 것을 구체적으로 명시할 수 있다. 이것은 <a href="#richerschemas">5.5절</a>에서 더 구체적으로 다루고 있다).

이와 같은 방식으로 공백노드를 사용하게 되면 부적절한 상황에서 리터럴의 사용을 피할 수도 있다. 예를 들어 Jane이라는 저자를 식별할 수 있는 URIref가 없는 Jane의 책을 기술하는 경우, 출판사는 다음과 같이 기술할 수 있다(출판사 자체의 ex2terms: 어휘를 사용하여):

그러나 이 책의 저자는 실제로 "Jane Smith"라는 문자열이 아니라 그 이름(name)이 Jane Smith라는 사람이라는 점이다. 출판사는 공백노드를 사용하여 이와 동일한 정보를 다음과 같이 더 정확하게 표현할 수 있다.

이것은 근본적으로 “자원 ex2terms:book78354는 타입 ex2terms:Book에 관한 것이고, 이 자원의 저자는 타입 ex2terms:Person의 자원이고, 그 이름은 Jane Smith이다”임을 말하는 것이다. 물론이지만 이와 같은 특수한 경우, 이 자원의 저자에 대하여 외부에서 참조할 수 있도록 출판사는 이들 저자를 식별하기 위한 공백노드를 사용하는 대신, 이들 저자에게 출판사 자체의 URIref를 부여할 수도 있다.

마지막으로 Jane의 나이를 26살로 제시한 위의 예에서는 성질 값이 때로는 단순하게 표현될 수 있으나 실제로는 복잡할 수 있음을 보여주고 있다. 이 경우 Jane의 나이는 실제로 26살이지만 단위정보(연도)는 분명하게 제시되지 않고 있다. 이러한 정보는 이 성질 값에 접근하는 사람이라면 누구라도 사용된 단위를 이해한다고 가정할 수 있는 상황에서는 대개 생략된다. 그렇지만 웹이라는 폭넓은 상황에서 보면 이러한 가정이 일반적인 현상이라고는 보기 어렵다. 예를 들어 미국 사이트에서는 파운드로 무게를 표현하지만 미국 이외의 국가에서 기술한 데이터에 접근한 사람은 무게가 킬로미터로 제시되었을 것으로 생각할 수 있다. 일반적으로 단위와 이와 유사한 정보를 분명하게 표현하기 위해 신중하게 고려할 필요가 있다. 이러한 정보를 구조적인 값으로 표현하기 위한 RDF 자질과 더불어, 이러한 정보를 표현하기 위한 기타 기법을 설명한 4.4절에서 이 문제는 더 구체적으로 검토될 것이다.

2.4 유형화된 리터럴(Literals)

앞 절에서는 일반 리터럴로 표현된 성질 값을 이들 리터럴의 각 부분을 표현하기 위한 구조화된 값으로 분석해야 하는 상황을 다루는 방법에 관해 설명하였다.

다시 말해 웹 페이지의 작성일자를 기록할 때 exterms:creation-date라는 하나의 성질과 이 성질 값으로 하나의 일반 리터럴을 기록하는 대신, 유형화된 이 방법을 사용함으로써 이와 동일한 값을 표현하기 위하여 각기 별개의 일반 리터럴을 사용하는 것으로 월, 일, 년 등 독립된 정보로 구성된 구조로 이 값을 표현하게 된다. 그러나 비록 성질 값이 숫자(예를 들어 year나 age 성질의 값)나 다른 어떤 종류의 특정한 값인 경우에도, 지금까지 RDF 선언문에서 목적어 역할을 하는 모든 상수 값은 이러한 일반(유형화되지 않은) 리터럴로 표현되었다.

예를 들어 <그림 4>에서는 John Smith에 관한 정보를 기록한 RDF 그래프를 보여주고 있다. 이 그래프에는 <그림 7>에서 보는 바와 같이, John Smith의 exterms:age 성질의 값으로 일반 리터럴 “27”을 기재하고 있다.

이 경우 가상의 기관인 example.org에서는 “27”을 문자 “2” 다음에 문자 “7”이 오는 문자열로 해석하지 않고, 아마도 숫자로 해석했을 것이다(왜냐하면 이 리터럴은 “age” 성질의 값을 표현하고 있기 때문이다). 그러나 <그림 7>의 그래프에서는 “27”을 숫자로 해석해야 한다고 명시적으로 제시한 정보는 아무 것도 없다. 이와 마찬가지로 example.org는 “27”을 8진법의 23(twenty three)으로 해석하지 않고 아마도 27이라는 10진(decimal) 숫자로 해석되도록 의도했을 것이다. 그러나 다시 한번 지적하지만 이러한 사실을 명시적으로 지시하는 정보는 <그림 7>의 그래프에는 없다. 특정한 어플리케이션은 exterms:age 성질의 값을 십진 숫자로 해석해야 한다는 것을 이해하면서 작성되기도 할 것이다. 그러나 이것이 의미하는 것은 다음과 같다. 즉 RDF를 적절히 해석하기 위해서는 RDF 그래프에 명시적으로 제시되지 않는 정보에 의존하게 되며, 따라서 이 RDF를 해석하는데 필요한 다른 어플리케이션에서 반드시 이용할 수 없는 정보에 의존하게 된다는 것을 의미한다.

프로그래밍 언어나 데이터베이스 시스템에서 흔히 사용되는 방식은 데이터타입(datatype)을 리터럴과 연계하여 리터럴을 해석하는 방법에 관한 이러한 부차적 정보를 제공하는 것이다. 이 경우 데이터타입은 십진 숫자나 정수와 같은 것이다. 따라서 데이터타입을 이해하는 어플리케이션은 "10"이라는 리터럴이 숫자 10(ten)을 표현한 것인지, 숫자 2(two)를 표현한 것인지 혹은 “1” 다음에 “0”으로 구성된 문자열인지를 알게 되는 데, 이것은 지정된 데이터타입이 정수인지, 이진수인지, 문자열인지에 따라 결정된다(예를 들어 데이터타입 정수년(integerYears)과 같이, 더 구체적인 데이터타입은 2.3절 말미에서 지적한 단위정보를 포함하기 위해 사용될 수도 있다. 그렇지만 이 입문서에서는 이러한 개념을 상세하게 다루지 않았다). RDF에서는 유형화된 리터럴을 사용하여 이와 같은 정보를 제공하게 된다.

RDF의 유형화된 리터럴은 문자열을 특정한 데이터타입을 식별하는 URIref와 짝지음으로써 만들어진다. 이렇게 하게 되면 이 한 쌍을 리터럴로 갖는 하나의 리터럴 노드가 RDF 그래프에서 만들어진다. 유형화된 리터럴이 표현하는 값은 지정된 데이터타입을 지정된 문자열과 연계한 값이다. 예를 들면 유형화된 리터럴을 사용하게 되면 John Smith의 나이는 다음과 같은 트리플을 사용하여 정수 27로 기술될 수 있다:

혹은 긴 URI를 쓰는 대신 QName 간략기법을 사용하면 다음과 같다:

이와 마찬가지로 웹 페이지에 관한 정보를 기술한 <그림3>의 그래프에서는 이 페이지의 exterms:creation-date 성질의 값이 일반 리터럴인 "August 16, 1999"로 기재되었다. 그러나 유형화된 리터럴을 사용하게 되면 이 웹 페이지의 작성일자를 August 16, 1999로 분명하게 기술할 수 있고, 이를 트리플로 표현하면 다음과 같다:

일반적인 프로그래밍 언어와 데이터베이스 시스템과 달리, RDF에서는 정수와 실수, 문자열, 날짜와 같은, 독자적으로 미리 정의한 데이터타입 세트를 가지고 있지 않다. 그 대신 RDF의 유형화된 리터럴은 단순히 특정 리터럴에 대하여 그것을 해석하는데 어떤 데이터타입이 사용되어야 하는지를 명시적으로 제시하는 방법을 제공하고 있다. 유형화된 리터럴에 사용된 데이터타입은 RDF 외부에서 정의되며, 이들은 데이터타입 URI로 식별된다(한 가지 예외사항은 XML 컨텐츠를 리터럴의 값으로 표현하기 위하여 RDF에서는 미리 정의된 데이터타입을 URIref인 rdf:XMLLiteral로 정의하고 있다. 이 데이터타입은 [RDF-CONCEPTS]에 정의되어 있으며, 그 용법은 4.5절에 제시되어 있다). 예를 들어 <그림 8>과 <그림 9>의 예에서는 XML 스키마 2부: 데이터타입(XML Schema Part 2: Datatypes [XML-SCHEMA2])에서 정의한 XML 스키마 데이터타입에서 온 데이터타입 integer와 date를 사용하고 있다. 이 방법을 사용할 때의 장점은 상이한 정보원에서 오는 정보를 그 정보원들과 RDF 원래의 데이터타입 세트 간에 타입을 변환하지 않고도 RDF에서 직접 표현할 수 있는 융통성을 부여한다는 점이다(상이한 데이터타입 세트를 가진 시스템 간에 정보를 교환할 때는 여전히 타입 변환이 필요하지만, RDF에서는 RDF 원래의 데이터타입 세트 간에 추가적인 변환작업을 필요로 하지 않는다).

RDF 데이터타입 개념은 RDF 개념과 간략 구문(RDF Concepts and Abstract Syntax [RDF-CONCEPTS])에 기술된 바와 같이, XML 스키마 데이터타입(XML Schema datatypes [XML-SCHEMA2])의 개념 틀에 토대를 두고 있다. 이 개념 틀에서는 데이터타입을 다음과 같이 구성된 것으로 정의하고 있다:

• 데이터타입의 리터럴이 표현하고자 하는 값 공간(value space)이라고 하는 일련의 값. 예를 들어 XML 스키마 데이터타입 xsd:date의 경우, 이 값의 세트는 일련의 날짜이다.

• 데이터타입이 그 값을 표현하기 위해 사용하는 어휘공간(lexical space)이라고 하는 일련의 문자열. 이 일련의 문자열은 이 데이터타입의 리터럴을 표현하기 위해 어떤 문자열이 적법하게 사용될 수 있는지를 결정한다. 예를 들어 데이터타입 xsd:date는 1999-08-16 형태를 이와 같은 종류의 리터럴을 표현하는 적법한 방식이라고 정의하고 있다(즉 August 16, 1999과 같은 형태를 취하지 않고).RDF-개념 [RDF-CONCEPTS]에서 정의된 바와 같이, 데이터타입의 어휘공간은 유니코드[UNICODE] 문자열 세트로서, 여러 언어로 된 정보를 직접 표현할 수 있다.

• 어휘 공간에서 값 공간까지의 어휘 대 값 매핑(lexical-to-value mapping). 이것은 어휘공간의 특정한 문자열이 이 특정 데이터타입에 대해 표현하는 값을 결정한다. 예를 들어 데이터타입 xsd:date에 대한 어휘 대 값을 매핑하게 되면 이 데이터타입에서 1999-08-16 이라는 문자열은 August 16, 1999이라는 날짜를 표현하게 된다. 동일한 문자열이 상이한 데이터타입에서는 상이한 값을 표현할 수 있기 때문에 이 어휘 대 값 매핑이 하나의 요소가 된다.

모든 데이터타입이 RDF에서 사용하기에 적절한 것은 아니다. 데이터타입이 RDF에서 적절하게 사용되려면 방금 설명한 개념 틀을 따라야 한다. 이것이 기본적으로 의미하는 것은 특정 문자열인 데이터타입은 그 문자열이 그 데이터타입의 어휘공간에 존재하는지의 여부를 분명하게 정의해야 하고, 또 문자열의 값 공간에서 그 문자열이 어떤 값을 표현하는지를 분명하게 정의해야 한다는 점이다. 예를 들어 xsd:string, xsd:boolean, xsd:date와 같은 기본적인 XML 스키마 데이터타입은 RDF에 사용하기에 적절하다. 그러나 미리 정의된 XML 스키마 데이터타입 중 일부는 RDF에 사용하기에 적절치 못하다. 예를 들어 xsd:duration은 체계적으로 정의된 값 공간을 가지고 있지 않으며, xsd:QName은 XML 문서 문맥을 포함하도록 요구하고 있다. 현재 RDF에서 사용하기에 적절하거나 부적절한 XML 스키마 데이터타입의 리스트는 [RDF-SEMANTICS]에 제시되어 있다.

유형화된 특정 리터럴이 표현하는 값은 유형화된 리터럴의 데이터타입으로 정의되기 때문에, 그리고 rdf:XMLLiteral을 제외하고는 RDF에서는 어떤 데이터타입도 정의하지 않기 때문에, RDF 그래프로 제시된 유형화된 리터럴의 실제 해석(예를 들어 유형화된 리터럴이 의미하는 값을 결정하는 것)은 RDF뿐만 아니라 유형화된 리터털의 데이터타입도 함께 정확하게 처리할 수 있도록 작성된 소프트웨어에 의해서 수행되어야 한다. 사실상 이 소프트웨어는 RDF뿐만 아니라 미리 정의된 어휘의 일부인 데이터타입도 포함한 확장 언어를 처리할 수 있도록 작성되어야만 한다. 이것은 어떤 데이터타입이 일반적으로 RDF 소프트웨어에서 이용 가능한가의 문제를 야기한다. 일반적으로 RDF에서 사용하기에 적절한 것으로 [RDF-SEMANTICS]에 제시된 XML 스키마 데이터타입이 RDF에서 “최우선”의 위상을 가지고 있다. 이미 지적한 바와 같이 <그림 8>과 <그림 9>로 제시된 예에서는 이러한 XML 스키마 데이터타입을 일부 사용하였으며, 이 입문서에서도 다른 대부분의 유형화된 리터럴의 예로 이들 데이터타입을 사용할 것이다(한 가지 지적할 사항은 XML 스키마 데이터타입에서는 그 데이터타입을 지시하는데 사용할 수 있는 URIref를 이미 배정하였으며, 이들 데이터타입은 [XML-SCHEMA2]에 제시되어 있다). 이들 XML 스키마 데이터타입은 다른 데이터타입과 달리 취급되지는 않지만 가장 널리 사용될 것으로 예상되며, 따라서 상이한 소프트웨어 간에 상호운용성이 가장 높을 것으로 믿어진다. 결과적으로 대부분의 RDF 소프트웨어도 이러한 데이터타입을 처리할 수 있도록 작성되리라 예상된다. 그러나 이미 지적한 바와 같이 RDF와 함께 사용하기에 적절하다고 판단되었다는 전제 하에, 다른 데이터타입 세트도 처리할 수 있는 RDF 소프트웨어를 작성할 수도 있다.

일반적으로 RDF 소프트웨어는 그 소프트웨어에서 처리하도록 작성되지 않은 데이터타입에 대한 참조를 포함한 RDF 데이터를 처리하기 위해 사용될 수도 있는데, 이 경우 이 소프트웨어가 처리할 수 없는 것들이 있을 수 있다. 그 중 하나는 rdf:XMLLiteral를 예외로 하고, RDF 자체는 데이터타입을 식별하는 URIref를 정의하지 않는다. 결과적으로 특정한 URIref를 인식할 수 있도록 작성되지 않은 RDF 소프트웨어는 유형화된 리터럴로 작성된 URIref가 실제로 데이터타입을 식별하는지를 판단할 수 없게 된다. 더욱이 비록 URIref가 데이터타입을 식별한다고 해도 RDF 자체는 그 데이터타입과 특정한 리터럴을 짝으로 연결함에 있어 그 타당성을 밝히지 않고 있다. 해당되는 특정 데이터타입을 정확하게 처리할 수 있도록 작성된 소프트웨어에 의해서만 이 타당성을 결정할 수 있다.

예를 들어 유형화된 리터럴을 트리플로 제시하면 다음과 같다:

<그림 10>에 나타난 유형화된 리터럴은 유효한 RDF이긴 하지만 xsd:integer 데이터타입과 관련된 한에서는 확실히 잘못된 것이다. 왜냐하면 "pumpkin"은 xsd:integer의 어휘공간에 존재하는 것으로 정의되지 않았기 때문이다. xsd:integer 데이터타입을 처리하도록 작성되지 않은 RDF 소프트웨어는 이러한 오류를 인식할 수 없을 것이다.

그러나 RDF의 유형화된 리터럴을 적절히 사용하게 되면 리터럴 값이 의도한 해석에 관해 더 많은 정보를 제공하게 되며, 따라서 어플리케이션 상호간에 보다 효과적인 정보교환 수단으로 RDF 선언문을 사용할 수 있다.

전반적으로 보아 RDF는 기본적으로 단순하다. 즉 URIref로 식별되는 사물에 관한 선언문으로 해석되는 노드-와-호로 연결된 도표이다. 이 절에서는 이러한 개념을 소개하고 있다. 앞서 지적한 바와 같이 이들 개념을 설명하고 있는 규범적(즉 최종적) RDF 규격서는 RDF 개념과 간략 구문(RDF Concepts and Abstract Syntax[RDF-CONCEPTS])인데, 더 구체적인 정보를 필요로 하는 경우에는 이들 자료를 참고할 필요가 있다. 이들 개념에 대한 공식적인 의미는 (규범적) RDF 의미론(RDF Semantics[RDF-SEMANTICS])이라는 문서에 정의되어 있다.

그런데 지금까지 논의한 RDF 선언문을 사용하여 사물을 기술하기 위한 기초적인 기법 이외에, 사람이나 기관도 이러한 선언문에서 사용하고 싶은 어휘(용어)를 기술하는 방법을 필요로 한다는 것도 분명해졌다. 특히 다음과 같은 것들을 기술하기 위해 어휘를 필요로 하고 있다:

• 이들 성질과 관련하여 선언문의 주어나 목적어로 작용할 수 있는 사물의 타입을 기술하기 위하여 (ex:age 성질의 값은 항상 xsd:integer가 되도록 지정하는 것과 같이)

RDF에 대한 기본 개념에 대한 추가적인 배경정보와 웹 정보를 기술하기 위한 일반 언어를 제공하는데 있어서 RDF가 하는 역할은 [WEBDATA]에서 볼 수 있다. RDF는 개념 그래프와 논리기반 지식표현, 프레임, 관계형 데이터베이스를 포함해서 지식표현과 인공지능, 데이터 관리 분야의 개념에 기초하여 작성된다. 이들 주제에 관한 배경정보의 정보원이 될 수 있는 것으로는 [SOWA], [CG], [KIF], [HAYES], [LUGER], [GRAY]가 포함된다.

제2절에서 설명한 바와 같이 RDF의 개념모델은 그래프이다. RDF에서는 RDF 그래프를 작성하고 교환하기 위하여 RDF/XML이라고 하는 XML 구문을 제공하고 있다. 단축표기로서의 역할을 하는 트리플과 달리 RDF/XML은 RDF를 작성하기 위한 규범적인 구문이다. RDF/XML은 RDF/XML Syntax Specification[rdf-syntax]에 정의되어 있다. 이 절에서는 이 RDF/XML을 다룬다.

RDF/XML 구문의 배경을 이루는 기본 개념을 이미 제시한 예 중에서 일부를 사용하여 예시할 수 있다. 영어로 된 선언문을 예로 들어보자:

http://www.example.org/index.html has a creation-date whose value is August 16, 1999

creation-date 성질에 URIref를 배정한 다음, 이 하나의 선언문에 대한 RDF 그래프는 <그림 11>과 같다:

(이 예에서는 date의 값으로 유형화된 리터럴을 사용하지 않았음을 유의할 필요가 있다. RDF/XML에서 유형화된 리터럴을 표현하는 방법은 이 절 후반부에서 다룰 것이다).

예 2에서는 <그림 11>의 그래프에 대응되는 RDF/XML 구문을 보여주고 있다.

(행번호는 이 예를 설명하는데 도움을 주기 위해 붙인 것이다).

이것은 부수적인 업무를 많이 필요로 하는 것처럼 보인다. 이 XML의 각 부분을 차례대로 검토함으로써 무엇이 진행되고 있는지를 이해하는 것이 훨씬 쉬울 것이다 (XML에 대한 간략한 소개는 부록 B에 제시되어 있다).

1행의 <?xml version="1.0"?>은 XML 선언부(XML declaration)로서, 다음의 컨텐츠가 XML이고 XML의 어느 버전이 사용되었는지를 나타낸다.

2행에서는 rdf:RDF 요소를 시작하고 있다. 이것은 다음에 오는 XML 컨텐츠(이 행에서 시작하여 7행의 </rdf:RDF>로 끝난다)가 RDF를 표현하기 위한 것임을 의미한다. 같은 행의 rdf:RDF 다음에는 rdf:RDF 시작태그의 xmlns 속성으로 표현된 XML 이름공간 선언부가 온다. 이 선언부에서는 이 컨텐츠에서 rdf:라는 접두어를 가진 모든 태그는 URIref http://www.w3.org/1999/02/

22-rdf-syntax-ns#로 식별되는 이름공간의 일부라는 점을 명시한 것이다. http://www.w3.org/1999/02/22-rdf-syntax-ns#라는 문자열로 시작되는 URIref는 RDF 어휘에 있는 용어에 대해 사용된다.

3행에서는 또 다른 XML 이름공간 선언부를 명기하면서 이번에는 접두사 exterms:을 사용하였다. 이것은 rdf:RDF 요소의 또 다른 xmlns 속성으로 표현되어 있고, 이름공간 URIref http://www.example.org/terms/가 접두사 exterms:와 연결된다는 것을 명시한 것이다. http://www.example.org/terms/라는 문자열로 시작되는 URIref는 예로 든 기관인 example.org에서 정의한 어휘의 용어에 대해 사용된다. 3행의 마지막에 있는 ">"는 rdf:RDF 시작태그의 끝을 표시한 것이다. 1행에서 3행까지는 이것이 RDF/XML 컨텐츠이고, 아울러 RDF/XML 컨텐츠에서 사용된 이름공간을 식별하기 위해 필요한 일반적인 “관리” 용 정보이다.

4행에서 6행까지는 <그림 11>에 제시된 특정 선언문에 대한 RDF/XML을 제시하고 있다. 어떤 RDF 선언문에 관해 확실하게 말하는 방법은 이 선언문이 기술(description)이며, 이 선언문의 주어에 관한(about) 것이며 (이 경우 http://www.example.org/index.html에 관하여), 이것이 RDF/XML에서 선언문을 표현하는 방식이라고 말하는 것이다. 4행의 rdf:Description 시작태그는 자원의 기술(description)의 시작임을 알리는 것이며, rdf:about 속성을 사용하여 주어인 자원의 URIref를 지정함으로써 그 선언문이 무엇에 관한(선언문의 주어) 자원인지를 식별하게 된다. 5행에서는 선언문의 술어와 목적어를 표현하기 위하여 QName인 exterms:creation-date를 태그로 한 성질 요소(property element)를 제시한 것이다. 로컬명인 creation-date를 exterms:의 URIref에 추가해서 접두사(http://www.example.org/terms/)가 선언문의 술어 URIref인 http://www.example.org/terms/creation-date를 만들 수 있도록 QName인 exterms:creation-date를 선택하였다. 이 성질요소의 컨텐츠는 선언문의 목적어로서, 일반 리터럴인 August 19, 1999(주어인 자원의 creation-date 성질의 값) 이다. 이 성질요소는 이를 포괄하는 rdf:Description 요소 내에 포함되어, rdf:Description 요소의 rdf:about 속성으로 지정된 자원에 이 성질이 적용되고 있음을 제시한 것이다. 6행은 이 특정한 rdf:Description 요소의 끝을 나타낸 것이다.

마지막으로 7행은 2행에서 시작된 rdf:RDF 요소의 끝을 나타낸다. Rdf:RDF 요소를 사용하여 RDF/XML 컨텐츠를 포함하는 것은 XML이 맥락에 따라 RDF/XML로 식별될 수 있는 상황에서는 선택적으로 사용된다. 이것은 [RDF-SYNTAX]에서 더욱 상세히 다루고 있다. 그러나 어떤 경우에든 rdf:RDF 요소를 제공하는 데에 손상을 주지 않으며, 입문서의 예에서는 일반적으로 (항상 그런 것은 아니나) 그 요소를 제공할 것이다.

예 2에서는 RDF 그래프를 XML 요소와 속성, 요소 컨텐츠, 속성 값으로 부호화하기 위하여 RDF/XML에서 사용한 기본개념을 예시하고 있다. 술어 URIref(일부 노드와 함께)는 XML QName으로 작성되는데, 이 QName은 부록 B에서 설명한 바와 같이, 이름공간으로 한정된 요소나 속성을 의미하는 로컬명(local name)과 함께 이름공간 URI를 의미하는 간략한 접두사(prefix)로 구성되어 있다. 이 쌍(이름공간 URIref와 로컬명)을 선택하게 되면 이들을 연결하게 되어 원래의 노드나 술어 URIref를 만들게 된다. 주어 노드의 URIref는 XML 속성 값으로 작성된다(목적어 노드의 URIref도 때로는 속성 값으로 작성되기도 한다). 리터럴 노드(이것은 항상 목적어 노드이다)는 요소 텍스트 컨텐츠나 속성 값이 된다(이들 선택사항 가운데 대부분이 본서의 후반부에 설명되어 있으며, 전체 선택사항에 대해서는[RDF-SYNTAX]에서 설명하고 있다).

복수의 선언문으로 구성된 RDF 그래프에서 각 선언문을 별도로 표현하기 위하여 예 2의 4-6행과 비슷한 RDF/XML을 사용해서 RDF/XML로 표현할 수 있다. 예를 들면 다음 두 개의 선언문을 작성하는 경우:

예 3은 예2와 동일한데, 다만 두 번째 선언문을 표현하기 위하여 두 번째 rdf:Description 요소(8-10행에)가 추가되었다(아울러 이 선언문에 추가로 사용된 이름공간을 식별하기 위하여 이름공간 선언부가 3행에 추가되었다). 추가된 각 선언문에 대해 별도의 rdf:Description 요소를 사용하는 방식으로, 원하는 수만큼의 추가 선언문을 작성할 수 있다. 예 3에서 보는 바와 같이, 일단 XML과 이름공간 선언부를 작성하는 업무를 처리하고 나면, RDF/XML에 추가되는 각각의 RDF 선언문을 작성하는 것은 쉬우면서 그다지 복잡하지도 않다.

RDF/XML 구문에서는 쉽게 작성할 수 있도록 공통으로 사용되는 여러 가지 약어를 제공하고 있다. 예를 들어 자원인 ex:index.html이 여러 선언문의 주어로 되어 있는 예 3에서와 같이, 동일한 자원을 다수의 성질과 값으로 동시에 기술하는 것이 보통이다. 이와 같은 사례를 처리하기 위하여 RDF/XML에서는 주어인 자원을 식별하는 rdf:Description 요소 내에 이들 성질을 표현하는 다수의 성질 요소를 전입할 수 있다. 예를 들면 http://www.example.org/index.html에 관하여 다음과 같은 일단의 선언문을 표현하는 경우,

앞의 두개의 예와 비교해 보면 예 4에서는 dc:creator 성질 요소가 추가되었다 (8행에). 게다가 각 선언문에 대해 별도의 rdf:Description 요소를 작성하는 대신, http://www.example.org/index.html를 주어로 인식하는 하나의 rdf:Description 요소 내에 이 주어를 지닌 세 개의 성질에 대한 성질 요소를 전입하였다.

아울러 8행에서는 새로운 형식의 성질 요소를 도입하고 있다. 7행의 dc:language 요소는 예 2에 사용된 exterms:creation-date 요소와 유사하다. 이 두 개의 요소는 일반 리터럴을 성질 값으로 가진 성질을 표현한 것으로, 그 성질명에 대응되는 시작태그와 종료태그 안에 리터럴을 싸서 이들 요소를 표현하게 된다.

그러나 8행의 dc:creator 요소는 리터럴이 아닌 다른 자원(another resource)을 값으로 지닌 성질을 표현한 것이다. 만약 이 자원의 URIref를 다른 요소의 리터럴 값과 동일한 방식으로 시작태그와 종료태그 사이의 일반 리터럴로 기재한 경우에는 이 dc:creator 요소의 값은 URIref로 해석되는 그 리터럴로 식별되는 자원이 아니라 http://www.example.org/staffid/85740이라는 문자열임을 말한다. 이러한 차이를 제시하기 위하여 XML에서는 공백요소 태그(empty-element tag: 별도의 종료태그가 없다)를 사용하여 dc:creator 요소를 작성하며, 이 공백요소 내의 rdf:resource 속성을 사용하여 그 성질 값을 작성하게 된다. rdf:resource 속성은 성질 요소의 값이 URIref로 식별되는 다른 자원임을 의미한다. URIref가 속성 값(value)으로 사용되기 때문에, 요소와 속성 명(names)을 작성할 때처럼 URIref를 QName으로 축약하지 않고 URIref 전체를 다 기재하도록(절대 URIref나 상대 URIref로) RDF/XML에서는 요구하고 있다(절대 URIref와 상대 URIref에 대해서는 부록 A에서 설명하고 있다).

예 4의 RDF/XML이 간략형(abbreviation)이라는 것을 이해하는 것이 중요하다. 각 선언문을 별도로 작성한 예 5의 RDF/XML에서는 이와 동일한 RDF 그래프를 정확하게 기술하고 있다(<그림 12>의 그래프):

다음 절에서는 RDF/XML의 간략형을 몇 가지 추가로 기술하게 될 것이다. 사용할 수 있는 간략형에 대한 상세한 기술은 [rdf-syntax]를 참고할 필요가 있다.

또 RDF/XML에서는 URIref가 없는 노드, 즉 2.3에서 설명한 바와 같은 공백노드(blank node)를 포함한 그래프도 표현할 수 있다. 예를 들어 ([rdf-syntax]에서 취한) <그림 13>에서 “'http://www.w3.org/TR/rdf-syntax-grammar'라는 문서는 'RDF/XML Syntax Specification (Revised)'이라는 표제와 편자가 있고, 편자의 이름은 'Dave Beckett'이며, 홈페이지는 'http://purl.org/net /dajobe/'이다”라는 그래프를 보여주고 있다:

이 그림은 2.3절에서 설명한 개념을 예시한 것으로, URIref는 없으나 다른 정보로 기술될 수 있는 어떤 것을 표현하기 위하여 공백 노드를 사용하는 것이다. 이 경우 공백노드는 이 문서의 편자인 사람을 표현하고 있고, 그 사람은 그의 이름과 홈페이지로 기술되어 있다.

RDF/XML에서는 공백노드가 포함된 그래프를 여러 가지 방법으로 표현한다. 이 방법에 대해서는 [rdf-syntax]에서 모두 설명하고 있다. 여기서 제시한 것은 가장 직접적인 방법으로서, 개개의 공백노드에 공백노드 식별기호(blank node identifier)를 부여하는 것이다. 공백노드 식별기호는 특정한 RDF/XML 문서 내에 있는 공백노드를 식별하는 역할을 하지만 URIref와는 달리, 배정된 문서 외부에서는 알 수가 없다. 공백노드는 공백노드 식별기호를 값으로 가진 rdf:nodeID 속성을 사용하여 RDF/XML에서 지시된다. 그렇지 않은 경우라면 여기에는 자원의 URIref가 제시된다. 특히 rdf:about 속성 대신, rdf:nodeID 속성을 가진 rdf:Description 요소를 사용하여 공백노드를 주어(subject)로 가진 선언문을 RDF/XML에서 작성할 수 있다. 마찬가지로 공백노드를 목적어(object)로 가진 선언문을 작성하기 위해서는 rdf:resource 속성 대신 rdf:nodeID 속성을 가진 성질 요소를 사용하여 작성할 수 있다. 예 6에서는 <그림 13>에 대응되는 RDF/XML을 예시하고 있다:

예 6의 9행에서는 공백노드 식별기호인 abc가 여러 선언문의 주어로서의 공백노드를 식별하기 위해 사용되었으며, 7행에서는 그 공백노드가 특정 자원의 exterms:editor 성질의 값임을 제시하기 위해 사용되었다. [rdf-syntax]에서 설명하고 있는 기타 접근방식에 비해서 공백노드 식별기호를 사용할 때의 장점은 공백노드 식별기호를 사용하게 되면 동일한 RDF/XML 문서의 여러 곳에서 동일한 공백노드를 지시할 수 있다는 점이다.

마지막으로 2.4절에서 설명한 유형화된 리터럴(typed literals)을 지금까지의 예에서 사용해 온 일반 리터럴 대신 성질 값으로 사용할 수 있다. 유형화된 리터럴은 그 리터럴을 포함하고 있는 성질 요소에 데이터타입 URIref를 명시한 rdf:datatype 속성을 추가함으로써 RDF/XML에서 표현할 수 있다.

예를 들어 exterms:creation-date 성질에 대하여 일반 리터럴 대신 유형화된 리터럴을 사용하기 위하여 예 2의 선언문을 변경하게 되면 다음과 같은 트리플로 표현할 수 있다.

예 7의 5행에서는 데이터타입을 명시하기 위하여 rdf:datatype 속성을 exterms:creation-date 성질 요소의 시작태그에 추가함으로써, 유형화된 리터럴을 exterms:creation-date 성질 요소의 값으로 제시하였다. 이 속성 값은 데이터타입의 URIref이며, 이 경우 XML 스키마 date 데이터타입의 URIref이다. 이것은 속성 값이기 때문에 트리플에서 사용된 QName 단축형인 xsd:date를 사용하는 대신, 이 URIref를 완전하게 기재해야 한다. 따라서 이 데이터타입에 적절한 리터럴를 이 요소의 컨텐츠로 기재할 수 있으며, 이 경우 리터럴은 1999-08-16로서, 이것은 XML 스키마 date 데이터타입에서 1999년 8월 16일을 리터럴로 표현한 것이다.

본서의 나머지 부분에 사용된 예에서는 리터럴 값을 어떻게 해석할 것인가에 관하여 더 많은 정보를 제공한다는 점에서 유형화된 리터럴의 값을 강조하기 위하여 일반(비유형화된) 리터럴 대신 적절한 데이터타입의 유형화된 리터럴을 사용할 것이다. (예외적으로 이들 어플리케이션에서의 용법을 정확하게 반영하기 위하여, 현재 유형화된 리터럴을 사용하지 않는 실제 어플리케이션에서 취한 예에서는 일반 리터럴을 여전히 사용할 것이다). RDF/XML에서 일반 리터럴과 유형화된 리터럴(그리고 특수한 예외사항으로서 태그)은 다양한 언어로 작성된 정보를 직접 표현할 수 있도록 유니코드 [UNICODE] 문자를 포함할 수 있다.

유형화된 리터럴을 사용하기 위해서는 유형화된 리터럴을 값으로 가진 각 요소에 대한 데이터타입을 식별할 수 있는 URIref를 가진 rdf:datatype 속성을 작성할 필요가 있음을 예 7에서 볼 수 있다. 앞서 지적한 바와 같이 RDF/XML에서는 속성 값으로 사용된 URIref를 QName과 같이 단축하지 않고 완전하게 작성하도록 요구하고 있다. 이러한 경우, 가독성을 개선하기 위해 URIref에 대해 단축기능을 추가로 제공함으로써 XML 개체(entities)를 RDF/XML에 사용할 수 있다. XML 개체선언은 기본적으로 이름과 문자열을 연계하고 있다. XML 문서 내의 어딘가에 개체명이 사용된 경우, XML 처리기는 이 개체명을 대응되는 문자열로 대치하게 된다. 예를 들어 ENTITY 선언부(RDF/XML 문서의 첫 머리에서 DOCTYPE 선언부의 일부로 명시된)가 다음과 같은 경우,

는 개체 xsd가 XML 스키마 데이터타입에 대한 이름공간 URIref를 표현하는 문자열이라고 정의한다. 이 선언을 통하여 XML 문서의 어딘가에서 완전한 이름공간 URIref를 개체 참조(entity reference)인 &xsd;로 축약하게 된다. 이 단축형을 사용함으로써 예 7을 예 8과 같이 작성할 수도 있다:

RDF 입문서(RDF Primer)

W3C 제안권고 2003년 12월 15일(W3C Proposed Recommendation 15 December 2003)

초록

이 문서의 상위

목 차

부 록

1. 서 론

2. 자원에 관한 선언문 작성

2.1 기본개념

2.2 The RDF Model

2.3 구조화된 성질 값과 공백 노드

2.4 유형화된 리터럴(Literals)

2.5 개념 요약

3. RDF의 XML 구문 : RDF/XML

3.1 기본원칙