본문 바로가기
온톨로지

[펌] RDF

by 사우람 2010. 7. 12.
이 문서는
Resource Description Framework
(RDF) Model and Syntax Specification
W3C Recommendation 22 February 1999
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
의 한국어 번역입니다.

이 문서에는 한국어 번역상의 오류가 있을 수 있습니다.
내용에 대한 보증은 하지 않기 때문에 반드시 W3C 웹사이트의 정식 문서를 참조하기 바랍니다.
또 저작권에 관해서는 본 문서에 포함되어 있는 기술에 덧붙여 이들도 반드시 참조하기 바랍니다.

Copyright ⓒ1998,1999,2000 W3C (MIT, INRIA, Keio), All Rights Reserved.
W3C 책임, 등록상표, 문서 사용과 소프트웨어 계약에 관한 규칙이 적용된다.

##########0*

REC-rdf-syntax-19990222

 

Resource Description Framework
(RDF) Model and Syntax Specification

W3C Recommendation 22 February 1999

##########1*
This Version:
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
Newest Version:
http://www.w3.org/TR/REC-rdf-syntax
Editors:
Ora Lassila <ora.lassila@research.nokia.com>, Nokia Research Center
Ralph R. Swick <swick@w3.org>, World Wide Web Consortium

Document Status

Copyright © 1997,1998,1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

본 문서의 위상

이 문서는 W3C 회원과 기타 이해 관계에 있는 단체에 의해 재검토되었으며, W3C 권고사항으로 디렉터에 의해 승인되었다. 이것은 안정된 문서이며 참고자료로 사용되거나 다른 문서에서 규범적인 참고문헌으로 인용될 수 있다. 이 권고사항을 작성함에 있어 W3C의 역할은 명세서에 관심을 끌어들이는 일과 이 권고사항의 광범위한 확산을 촉진하는 일이다. 이를 통해 웹의 기능성과 상호 운용성을 높이는 것이다.

이 명세서 중에 확인된 오류 리스트는 http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/errata에서 볼 수 있다.

이 명세서에 관한 의견은 <www-rdf-comments@w3.org>으로 보내주기 바란다. 공개된 의견 자료는 http://www.w3.org/Archives/Public/www-rdf-comments에서 볼 수 있다.

목차

  1. 서론
  2. 기본적인 RDF
  3. 용기(容器)
  4. 문에 관한 문
  5. RDF에 대한 공식 모델
  6. RDF에 대한 공식 문법
  7. 예
  8. 감사의 말
  9. 부록 A: 용어집
  10. 부록 B: RDF의 이동
  11. 부록 C: 사용법에 관한 설명
  12. 부록 D: 참고문헌
  13. 부록 E: 이전 버전과 달라진 점

1. 서론

World Wide Web은 원래 인간이 사용하기 위해 작성된 것이며, 비록 이 웹에 있는 모든 것을 기계가 읽을 수 있긴 하지만 이 데이터를 기계가 이해할 수는 없는 것이다. 웹에서 모든 것을 자동화하는 것은 대단히 어렵고, 그리고 웹이 포함하고 있는 정보량이 많기 때문에 수작업으로 이것을 관리하는 것은 불가능하다. 여기서 제시한 해결책은 웹에 수록된 데이터를 기술하기 위해 메타데이터를 사용하는 것이다. 메타데이터는 "데이터에 관한 데이터"(예를 들면 도서관 목록은 출판물을 기술하고 있기 때문에 메타데이터이다), 혹은 특별히 이 명세서에서는 "웹자원을 기술한 데이터"의 의미를 가진다. "데이터"와 "메타데이터" 간의 구분은 절대적인 것이 아니다. 그것은 특정 어플리케이션에서 처음 고안한 구분이며, 대부분 동일 자원이 동시에 두 가지 방식으로 해석될 수 있다.

Resource Description Framework(RDF)는 메타데이터를 처리하기 위한 기초이며, 웹에서 기계가 이해할 수 있는 정보를 교환하는 어플리케이션 간에 상호 운용성을 제공한다. RDF는 웹 자원의 자동 처리를 가능케 하는데 대단히 편리하다. RDF는 다양한 응용영역에서 사용될 수 있다. 예를 들면 (1) 자원탐색영역에서 개선된 검색엔진능력을 제공하며, (2) 목록분야에서 특정 웹사이트나 웹 페이지, 디지털 도서관에서 이용 가능한 컨텐츠나 컨텐츠 관계를 기술하며, (3) 지식의 공유와 교환을 촉진하기 위한 지적인 소프트웨어 에이전트에서, (4) 내용 평가영역에서, (5) 논리적으로 단일 "문서"를 표현한 페이지 전체를 기술하는 분야에서, (6) 웹 페이지의 지적재산권을 기술하는 영역에서, (7) 웹사이트의 개인정책과 함께 이용자의 개인 선호도를 표현하는 영역 등이다. 디지털 서명(署名)이 포함된 RDF는 전자상거래, 협력, 기타 어플리케이션에 대한 "신뢰의 웹"을 구축하는 데에 관건이 될 것이다.

이 문서는 독립적으로 개발된 웹 서버와 클라이언트의 상호 운용성을 최대한 지원하기 위한 방법으로, RDF 메타데이터를 코딩하고 이송하기 위한 구문과 함께 RDF 메타데이터를 표현하기 위한 모델을 제시하고 있다. 여기에 제시된 구문은 Extensible Markup Language [XML]를 사용한다. RDF의 목표 중 하나는 표준화되고 상호 운용성 있는 방식으로, XML에 기초한 데이터에 의미를 지정하도록 하는 것이다. RDF와 XML은 상호 보완적이다. 즉 RDF는 메타데이터의 모델이며, 단지 참조를 통해 이송과 파일 축적에서 필요로 하는 코딩에 관한 여러 문제를 단지 언급한 것이다(국제화, 문자세트 등과 같은). 이런 문제에 대해 RDF는 XML의 지원에 의존하고 있다. 아울러 이 XML 구문은 RDF에 대한 가능한 구문 중 단지 하나라는 점이며, 따라서 동일한 RDF 데이터 모델을 표현하기 위해 대안의 방안이 있을 수 있다는 점을 이해하는 것이 중요하다.

RDF의 포괄적인 목표는 특정 어플리케이션 영역에 관한 어떤 가정도 하지 않으며, 또 어느 어플리케이션 영역의 의미도(전제로서) 정의하지 않으면서, 자원을 기술하기 위한 방식을 정의한 것이다. 이 방식의 정의는 영역과 중립적이어야 하며, 또 이 방식은 어느 영역에 관한 정보를 기술하기에 적절해야 한다.

이 명세서에 다른 문서가 추가될 것이며, 이를 통해 RDF 프레임워크는 완성되게 될 것이다. 가장 중요한 것은 메타데이터의 정의를 용이하게 하기 위해 RDF는 다수의 객체지향 프로그래밍과 모델링 시스템과 아주 유사한 클래스 시스템을 가지게 될 것이다. 클래스의 집합(일반적으로 특정 목적이나 영역을 위해 저작된)을 스키마라고 한다. 클래스는 계층적으로 조직되고, 하위클래스의 구체화를 통해 확장성을 제공한다. 이와 같이 기존의 스키마와 약간 다른 스키마를 작성하기 위해 "일부러 다시 만들" 필요 없이, 기본 스키마에 수정내용을 단지 추가하면 된다. 스키마의 공유를 통해 RDF는 메타데이터의 정의의 재사용 가능성을 지원하게 된다. RDF의 추가 확장성으로 인해, 메타데이터를 처리하는 에이전트는 친숙하지 않은 스키마의 기원을 추적하여 이미 알고 있는 스키마에 돌아갈 수 있으며, 원래는 처리하도록 설계되지 않은 메타데이터에 대해 의미 있는 동작을 수행할 수 있다. 아울러 RDF의 공유가능성과 확장성으로 인해 메타데이터 작성자는 다른 작성자에 의해 만들어진 작업을 이용하여 자신의 데이터에 여러 가지 관점을 부여할 수 있고, 여러 정의를 "복합"하여, 다양한 유산(상속)을 사용할 수 있게 된다. 추가해서 다수의 자원(예를 들면 상이한 유형의 메타데이터를 "끼워 넣어서")에 포함된 다수의 스키마에 기초한 RDF 사례 데이터를 작성할 수 있다. 스키마 자체가 RDF에 쓰여질 수도 있다. 이 명세서와 짝을 이루고 있는 [RDFSchema]에서 RDF 스키마를 기술하기 위한 속성과 클래스가 하나의 세트로 기술되어 있다.

메타데이터의 표기와 이송에 관해 다수 영역이 기본 원칙에 참여하고 동의한 결과, RDF는 여러 상이한 정보원으로부터 영향을 받았다. 주된 영향력을 미친 분야는 HTML 메타데이터와 PICS 형태로 된 웹 표준 분야 자체와 도서관 분야, SGML 그리고 이보다 더 중요한 XML 형태로 된 구조화된 문서분야, 그리고 지식표현(KR) 분야 등이다. 이밖에 RDF 설계에 기여한 여러 기술영역도 해당된다. 여기에는 객체지향 프로그래밍과 모델링 언어는 물론 데이터베이스가 포함된다. RDF는 지식표현 분야에서 나온 것이지만 RDF는 추론기제를 규정하지 않는다는 점에서 지식표현 분야에 정통한 이용자는 유의할 필요가 있다. RDF는 단순한 프레임 시스템이라고 특징지을 수 있다. 추론기제는 이 프레임 시스템의 정점에 구축될 수 있다.

2. 기본적인 RDF

2.1. 기본적인 RDF 모델

RDF의 기초는 지정된 특성과 그 값을 표현하기 위한 모델이다. RDF 모델은 다양한 데이터 표현분야에서 확립된 원칙에 따라 표현된다. RDF 특성은 자원의 속성이라고 생각할 수 있고, 이런 점에서 전통적인 속성-값에 해당된다. 아울러 RDF 특성은 자원간의 관계를 표현하며 따라서 RDF 모델은 엔티티-관계(ER) 그림과 유사할 수 있다 (더 정확히 표현하면, 그 자체로 RDF 데이터 모델의 사례인 RDF 스키마는 ER 그림이다). 객체지향 설계용어로 표현하면 자원은 객체에 대응되고, 특성은 사례 변수에 대응된다.

RDF 데이터 모델은 RDF 표현의 의미를 나타내는 구문 중립적인 방법이다. 데이터 모델 표기는 의미의 등가성을 평가하기 위해 사용된다. 만약 이들 데이터 모델 표현이 동일한 경우라면, 그리고 그 경우에는 두 개의 RDF 표현은 등가이다. 이러한 등가성의 정의를 통해 RDF표현에서 의미의 변경 없이 구문을 어느 정도 변경할 수 있다. (용어열 비교 문제에 관한 추가 논의에 대해서는 제6장을 참조할 것).

기본적인 데이터 모델은 세 개의 객체 유형으로 구성된다:

자원 RDF 형식으로 기술되는 모든 것을 자원이라고 한다. 예컨대 HTML 문서인 "http://www.w3.org/Overview.html"과 같이, 자원은 웹 페이지 전체일 수 있다. 또 문서자원에 포함된 특정한 HTML 요소나 XML 요소와 같이, 자원은 웹 페이지의 일부일 수 있다. 아울러 웹사이트 전체와 같이 자원은 페이지 전체의 집합일 수 있다. 또 자원은 인쇄본과 같이 웹을 통해 직접 접근할 수 없는 객체일 수도 있다. 자원에는 항상 URL과 선택요소인 앵커 ID가 합쳐져서 이름이 부여된다 ([URI] 참조). 어떤 것이라도 URI를 가질 수 있으며, URI의 확장성으로 인해 생각할 수 있는 어 떤 개체에 대해서도 식별기호를 부여할 수 있다.
특성 특성은 자원을 기술하기 위해 사용된 특정한 관점, 특징, 속성, 관계이다. 각 특성은 특정한 의미를 가지며, 허용되는 값, 특성이 기술하는 자원의 유형, 다른 특성과의 관계를 정의한다. 이 문서에서는 특성의 특징을 표현하는 방법에 대해서는 언급하지 않는다 (그런 정보는 RDF 스키마 명세서를 참조하기 바란다).
문(스테이트먼트) 특정 자원과 지정된 특성, 그리고 그 특성의 값을 RDF 문이라고 한다. 문을 구성하는 이들 세 부분을 각각 주부(subject)와 술부(predicate), 객체(object)라고 한다. 문의 객체(즉 특성 값)는 다른 자원일 수 있고, 혹은 리터럴일 수 있다. 즉 자원(URI로 지정된)이거나 단순히 용어열이거나 XML에서 정의된 기타 기본적인 데이터유형일 수 있다. RDF 용어로 말하면, 리터럴은 XML 마크업인 내용을 가질 수 있으나 RDF 프로세서에 의해 더 이상 평가되지 않는다. 리터럴에서 마크업을 표현하는 방법에서 약간의 구문상의 제한사항이 있다. 2.2.1장을 참조할 것.

2.1.1. 예

자원은 자원식별기호(resource identifier)에 의해 식별된다. 자원식별기호는 임의의 앵커 ID를 결합한 URI이다(2.2.1장 참조). 이 장의 목적 상 특성은 하나의 이름으로 나타내었다.

간단한 예로서 다음 문장을 생각해 보자:

Ora Lassila는 자원 http://www.w3.org/Home/Lassila 의 작성자이다.

이 문장은 다음과 같은 부분을 포함하고 있다:

 Subject (Resource)   http://www.w3.org/Home/Lassila 
 Predicate (Property)   Creator
 Object (literal)   "Ora Lassila"

이 문서에 방향 그래프와 레이블을 부여하여 RDF 문을 그림으로 도시할 수 있다("노드와 아크 도표"라고도 한다). 이 도표에서 노드(타원형으로 그려진)는 자원을 표현한 것이고, 아크는 이름이 부여된 특성을 표현한 것이다. 문자열 리터럴을 표현한 노드는 직사각형으로 표현된다. 따라서 위의 문장을 다음과 같은 그림으로 표현할 수 있다:

##########1*D

그림 1: 단순한 노드와 아크 도표

주: 화살표의 방향이 중요하다. 아크는 항상 주부에서 시작하여 문의 객체를 지시한다. 위의 단순한 그림은 "http://www.w3.org/Home/Lassila는 작성자 Ora Lassila 를 포함하고 있다", 혹은 일반적으로 "<subject>는 <predicate> <object>를 가진다"라고 읽을 수 있다.

이제 이 자원의 작성자의 특성에 관해 무언가를 말하고자 하는 경우를 생각해 보자. 산문으로 표현하면 이와 같은 문장은 다음과 같이 될 것이다:

Ora Lassila라는 이름을 가진 개인의 전자메일은<lassila@w3.org>이고, http://www.w3.org/Home/Lassila의 작성자이다.

이 문장의 의도는 작성자(Creator)의 특성 값을 구조화된 개체로 하는 데 있다. RDF에서 이러한 개체는 다른 자원으로 표현된다. 위의 문장에서는 그 자원에 이름을 부여하지 않고 있어서, 이 자원은 이름이 없고 그래서 아래 그림과 같이 이를 공백의 타원형으로 표현하고 있다.

##########2*D

그림 2: 구조화된 값을 가진 특성

주: 앞의 주에서 읽은 것과 대응해서, 이 그림은 "http://www.w3.org/Home/Lassila는 어떤 작성자를 가지고 있고 그 이름은 Ora Lassila이며 lassila@w3.org이라는 전자메일을 가지고 있다"라고 읽을 수 있다.

앞의 예의 구조화된 개체는 고유한 식별기호를 부여받을 수도 있다. 식별기호를 선정하는 것은 응용 데이터베이스 설계자에 의해 이루어진다. 예를 계속하면, "사람"이라는 자원에 대한 고유한 식별기호로 직원번호를 사용한 경우를 예상할 수 있다. 따라서 각 직원에 대해 고유한 key(조직에서 정의된)로서의 역할을 하는 URI는 http://www.w3.org/staffId/85740와 비슷하게 될 것이다. 이제 이 두 문장을 기술하면 다음과 같다:

직원번호 id 85740로 지시되는 사람의 이름은 Ora Lassila이고, 전자메일 주소는 lassila@w3.org이다. 자원인 http://www.w3.org/Home/Lassila는 이 개인에 의해 작성된 것이다.

이들 문장에 대한 RDF 모델은 다음과 같다:

##########3*D

그림 3: 식별기호를 가진 구조화된 값

이 그림은 앞의 그림과 동일한데, 다만 이름을 부여하지 않았던 자원에 대해 URI가 추가되었을 뿐임을 유의할 필요가 있다. 이 모델을 검색하는 이차적인 어플리케이션의 관점에서 보면, 하나의 단일 문장으로 제시된 문과 복수의 독립된 문장으로 제시된 문간의 차이를 발견할 수 없다. 그러나 어떤 응용 프로그램에서는 이러한 구분이 필요할 수 있고, RDF에서는 이를 지원하고 있다. 더 구체적인 사항은 4장, 문에 관한 문을 참고하기 바란다.

2.2. 기본적인 RDF 구문

RDF 데이터 모델은 메타데이터를 정의하고 이용하기 위한 추상적이고 개념적인 틀을 제공한다. 이 메타데이터를 작성하고 교환하기 위한 목적으로도 구체적인 구문이 필요하다. 이 RDF 명세서에서는 이러한 교환용 구문으로 확장 가능한 마크업 언어[XML] 코딩을 사용한다. 아울러 RDF에서는 특성을 정의한 스키마와 각 특성을 정확하게 연결하기 위해 XML의 이름공간 기능을 필요로 한다; 2.2.3장 스키마와 이름공간을 참조하기 바란다.

이 문서에서 구문 기술은 필수 RDF 구문요소를 기술하기 위해 [XML]의 6장, 표기법에서 정의된 것과 같이, 확장된 배커스-나우어 형(Extended Backus-Naur Form) 기호법을 사용한다. 여기서 EBNF는 육안으로 판독할 수 있도록 축약되고, 특히 "rdf"보다 더 정확한 BNF 기호법인 "'<' NSprefix ':...'" 대신 이탤릭체 "rdf"는 가변적인 이름공간 접두사를 표현하는데 사용된다. 종료태그에 있는 특성과 유형명은 이에 대응되는 시작태그의 이름과 정확히 일치해야 한다는 조건은 XML 규칙을 통해 암시되고 있다. XML의 모든 구문상의 유연성도 역시 묵시적으로 포함되어 있다; 예를 들면 공백 규칙, 단일 인용부호(')나 이중 인용부호("), 문자 에스케이프, 대소문자 구분, 언어 태깅 등이다.

이 명세서에서는 RDF 데이터 모델 사례를 코딩하기 위해 두 개의 XML 구문을 정의하고 있다. 연속구문은 데이터 모델의 완전한 능력을 바로 표준형식으로 표현한 것이다. 축약구문은 데이터 모델의 하위세트를 표현하기 위해 아주 간결한 형식을 제시하는 부차적인 개념을 포함하고 있다. RDF 해석기는 완전한 연속구문과 축약구문 두 가지 모두를 실행할 수 있다. 결과적으로 메타데이터 작성자는 이 두 가지를 자유롭게 혼용할 수 있다.

2.2.1. 기본적인 연속구문

하나의 RDF 문이 단독으로 출현하는 일은 거의 없으며, 대부분 자원의 여러 가지 특성과 함께 제시되는 것이 보통이다. RDF XML 구문은 동일 자원에 대한 다수의 문을 Description 요소에 통합하여 이를 쉽게 수용할 수 있도록 설계되었다. 기술 요소는 about 속성에서 각 문이 적용되는 자원에 이름을 부여한다. 만약 자원이 존재하지 않는 경우(즉 자원의 식별기호가 부여되지 않은 경우), Description 요소는 ID 속성을 사용하여 그 자원에 식별기호를 제공할 수 있다.

기본적인 RDF 연속구문은 다음과 같은 형식을 취한다:

  [1] RDF            ::= ['<rdf:RDF>'] description* ['</rdf:RDF>']
  [2] description    ::= '<rdf:Description' idAboutAttr? '>' propertyElt*
                         '</rdf:Description>'
  [3] idAboutAttr    ::= idAttr | aboutAttr
  [4] aboutAttr      ::= 'about="' URI-reference '"'
  [5] idAttr         ::= 'ID="' IDsymbol '"'
  [6] propertyElt    ::= '<' propName '>' value '</' propName '>'
                       | '<' propName resourceAttr '/>'
  [7] propName       ::= Qname
  [8] value          ::= description | string
  [9] resourceAttr   ::= 'resource="' URI-reference '"'
 [10] Qname          ::= [ NSprefix ':' ] name
 [11] URI-reference  ::= string, interpreted per [URI]
 [12] IDsymbol       ::= (any legal XML name symbol)
 [13] name           ::= (any legal XML name symbol)
 [14] NSprefix       ::= (any legal XML namespace prefix)
 [15] string         ::= (any XML text, with "<", ">", and "&" escaped)

RDF 요소는 XML 문서간의 경계를 구분하는 단순한 용기로서, 문서의 내용을 RDF 데이터 모델의 사례로 분명하게 매핑하기 위한 의도이다. 만약 어플리케이션의 문맥을 통해 그 내용이 RDF라는 것을 알 수 있다면 RDF 요소는 선택사항이다.

Description은 모델 사례에 있는 문을 작성하기 위한 나머지 요소를 포함한다. Description 요소는 단순히 기술대상 자원을 확인할 수 있는 장소라고 생각할 수 있다(기본적인 RDF 구문의 목적상). 일반적으로 자원에 관해서는 복수의 문이 있게 되고; Description은 다수의 문에 대해 단 한번 자원명을 제시하는 방식을 사용한다.

about 속성이 Description과 함께 명시될 때 Description에 있는 문은 about에서 결정된 식별기호를 가진 자원을 지시한다. about 속성의 값은 [URI]의 4장에 제시된 URI-참조로 해석된다. 그 대응되는 자원식별기호는 [URI]에 의해 지정된 것과 같이 절대형식에 URI-참조를 변환하여 얻게 된다. 만약 단편식별기호가 URI-참조에 포함된 경우 자원식별기호는 이를 포함하는 자원에 대응되는 단편 id 내부에 의해 식별되는 자원의 하위구성요소만을 참조한다 ([Dexter94]에 있는 앵커 참조). 그 밖의 경우 식별기호는 URI로 명시된 전체 자원을 참조한다. about 속성이 없는 Description 요소는 새로운 자원을 표현한 것이다. 그러한 자원은 인식할 수 있는 URI를 갖지 않은 어떤 물리적 자원에 대한 대치물이거나 프락시일 수 있다. Description 요소의 ID 속성 값은, 만약 존재하는 경우라면, 이러한 "인라인" 자원의 앵커 id 이다.

만약 별도의 Description이나 특성 값이 인라인 자원을 참조할 필요가 있는 경우, 그 자원의 ID 값을 그 자체의 about 속성에 사용할 수 있다. 이 ID 속성은 새로운 자원의 작성을 의미하고, about 속성은 기존의 자원을 참조한다. 따라서 ID나 about 중 하나를 Description에 명시할 수 있지만 이 두 가지를 동일한 요소에 함께 사용할 수는 없다. 각각의 ID 속성 값은 단일 문서에서 복수의 ID 속성으로 출현해서는 안된다.

하나의 Description이 동일한 특성명으로 복수의 propertyElt 요소를 포함할 수 있다. 이 propertyElt 요소 각각은 그림에 하나의 아크를 추가하게 된다. 이 그림의 해석은 스키마 설계자에 의해서 정의된다.

propertyElt 중에서 resource 속성은 어떤 다른 자원이 이 속성 값인지를 명시한다; 즉 문의 객체가 리터럴이 아니라 URI로 식별되는 다른 자원이다. 객체의 자원식별기호는 about 속성을 얻기 위해 앞에서 설명한 바와 같이, resource 속성 URI-참조를 변환하여 확보된다. string은 체계적인 XML이어야 하는데, 만약 string이 적법한 XML 규칙을 위반하거나 마크업과 같이 보이는 문자열(즉 "<"과 "&")을 포함하고 있는 경우라면 매커니즘을 인용하고, 그리고 에스케이핑하는 일반적인 XML 컨텐츠를 사용할 수 있다. 마크업이 RDF에 의해 해석되지 않는 경우 마크업을 포함한 적법한 XML 컨텐츠를 가진 특성 값을 지정하기 위한 추가 구문에 대해서는 6장을 참조하기 바란다.

특성명은 스키마와 연결되어야만 한다. 이것은 특성 정의를 이와 대응되는 RDF 스키마와 분명하게 연결하기 위해 요소명을 이름공간 접두사로 한정하거나 혹은 [NAMESPACES]에서 명시된 바와 같이 디폴트 이름공간을 선언함으로써 특성명과 스키마의 결합이 이루어진다.

2.1.1장의 예문

Ora Lassila는 자원 http://www.w3.org/Home/Lassila의 작성자이다.

는 RDF/XML에서 다음과 같이 표현된다: 

<rdf:RDF>
  <rdf:Description about="http://www.w3.org/Home/Lassila">
    <s:Creator>Ora Lassila</s:Creator>
  </rdf:Description>
</rdf:RDF>

여기서 이름공간 접두사 's'는 이 RDF 식의 저자가 선택한 특정한 이름공간 접두사를 참조하며, 다음과 같이 XML 이름공간선언에서 정의된다. 

  xmlns:s="http://description.org/schema/"

이 이름공간선언은 일반적으로 rdf:RDF 요소에서 XML 속성으로 포함되지만 특정한 Description 요소와 함께 포함될 수 있으며, 심지어는 개개의 propertyElt 식에도 포함될 수 있다. 이름공간선언에서 이름공간명 URI는 이 메타데이터 저자가 Creator 특성의 사용을 정의하기 위해 사용한 특정 스키마에 대한 전역적이고 고유한 식별기호이다. 다른 스키마도 Creator라는 이름을 가진 특성을 정의할 수 있으며, 이 두 개의 특성을 각각의 스키마 식별기호를 통해 구분할 수 있다. 일반적으로 스키마는 다수의 특성을 정의한다는 점에 유의할 필요가 있다. 단일 이름공간선언으로 대량의 특성 어휘를 사용할 수 있다.

위의 기술을 포함한 완전한 XML 문서는 다음과 같게 될 것이다: 

<?xml version="1.0"?>
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:s="http://description.org/schema/">
  <rdf:Description about="http://www.w3.org/Home/Lassila">
    <s:Creator>Ora Lassila</s:Creator>
  </rdf:Description>
</rdf:RDF>

RDF 이름공간 자체에 대해 [NAMESPACES]에서 정의된 디폴트 이름공간구문을 사용하면 이 문서를 다음과 같이 표현할 수도 있다: 

<?xml version="1.0"?>
<RDF
  xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:s="http://description.org/schema/">
  <Description about="http://www.w3.org/Home/Lassila">
    <s:Creator>Ora Lassila</s:Creator>
  </Description>
</RDF>

더욱이 이름공간선언은 개개의 Description 요소와 연결될 수 있으며, 심지어 다음과 같이 개개의 propertyElt와도 연결될 수 있다: 

<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <Description about="http://www.w3.org/Home/Lassila">
    <s:Creator xmlns:s="http://description.org/schema/">Ora Lassila</s:Creator>
  </Description>
</RDF>

XML 이름공간선언을 잘 정리할 수 있으면 앞의 예를 다시 더 요약할 수 있다: 

<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <Description about="http://www.w3.org/Home/Lassila">
    <Creator xmlns="http://description.org/schema/">Ora Lassila</Creator>
  </Description>
</RDF>

그러나 RDF/XML 코딩을 손으로 작성하거나 일반 텍스트 편집기로 편집하는 경우에는 이와 같이 고도로 요약된 표현은 사용하지 않는 것이 좋다. 비록 분명하기는 하지만, 접두사를 일관되게 사용할 때보다 오류의 가능성이 크다. 다른 문서에 삽입되어야 할 RDF/XML 단편은 그 단편이 사용한 모든 이름공간을 선언할 필요가 있고, 그래서 그 단편이 완전히 독립적일 수 있다. 읽기 쉽도록 하기 위해서, 이 장의 나머지에서 소개한 예에서는 설명의 대상인 특정한 사항을 흐리지 않도록 하기 위해 이름공간 선언을 생략하고 있다.

2.2.2. 기본적인 축약 구문

연속구문은 RDF 모델의 구조를 가장 분명하게 제시하지만 때로는 더 간결한 XML 형식을 사용하는 것이 바람직하다. RDF의 축약 구문은 이를 위한 것이다. 또 다른 장점으로서, 이 축약 구문은 체계적으로 구조화된 XML DTD에 따른 문서를 RDF 모델로 직접 해석할 수 있다.

세 가지 약어 형식이 기본적인 연속 구문에서 정의된다. 첫 번째는 Description에서 반복되지 않는 특성에 적용되는 것으로, 여기서 이들 특성의 값이 문자인 경우이다. 이 경우 특성은 Description 요소의 XML 속성으로 표현된다. 따라서 앞의 예는 다음과 같이 표현된다: 

<rdf:RDF>
  <rdf:Description about="http://www.w3.org/Home/Lassila"
		   s:Creator="Ora Lassila" />
</rdf:RDF>

일단 Creator 특성이 XML 속성 형식으로 작성되고 나면 Description 요소는 다른 어떤 내용도 가지지 않기 때문에, XML 공백 요소 구문을 사용하여 Description 종료태그를 생략한다는 점에 유의할 필요가 있다.

여기에 약어 형식을 사용한 또 다른 예가 있다:

<rdf:RDF>
  <rdf:Description about="http://www.w3.org">
    <s:Publisher>World Wide Web Consortium</s:Publisher>
    <s:Title>W3C Home Page</s:Title>
    <s:Date>1998-10-03T02:27</s:Date>
  </rdf:Description>
</rdf:RDF>

은 RDF의 목적에 따라 다음과 대등한 것이다.

<rdf:RDF>
  <rdf:Description about="http://www.w3.org"
       s:Publisher="World Wide Web Consortium"
       s:Title="W3C Home Page"
       s:Date="1998-10-03T02:27"/>
</rdf:RDF>

이 두 개의 RDF 식은 비록 동일한 것이지만 다른 처리 엔진에 의해 달리 취급될 수 있음을 유의할 필요가 있다. 특히 이 두 식이 하나의 HTML 문서에 내장되면 RDF를 인식하지 못하는 브라우저의 디폴트 동작은 첫 번째 경우에는 속성 값을 디스플레이 하게 되고, 두 번째 경우에는 아무런 텍스트도 디스플레이 하지 않는다(혹은 기껏해야 공백 문자).

두 번째 RDF 축약 형식은 전입된 Description 요소에서 작용한다. 이 축약형식은 문의 객체가 다른 자원이고, 그리고 이 두 번째 자원에 대해 인라인으로 제시된 특성 값이 문자열인 경우, 특정한 문에서 사용될 수 있다. 이 경우 XML 요소명을 XML 속성으로 유사한 변환이 이루어지고, 전입된 Description에 있는 자원의 특성은 그 Description이 포함된 propertyElt 요소의 XML 속성으로 쓰여질 수 있다.

2.1.1장의 두 번째 예문

The individual referred to by employee id 85740 is named Ora Lassila and has the email address lassila@w3.org. The resource http://www.w3.org/Home/Lassila was created by this individual.

이것을 분명한 연속구문 형식을 써서 RDF/XML로 표현하면 다음과 같다.

<rdf:RDF>
  <rdf:Description about="http://www.w3.org/Home/Lassila">
    <s:Creator rdf:resource="http://www.w3.org/staffId/85740"/>
  </rdf:Description>

  <rdf:Description about="http://www.w3.org/staffId/85740">
    <v:Name>Ora Lassila</v:Name>
    <v:Email>lassila@w3.org</v:Email>
  </rdf:Description>
</rdf:RDF>

이 형식은 두 개의 독립된 자원이 기술되어 있음을 읽는 사람에게 분명하게 제시하지만 두 번째 자원이 첫 번째 description에 사용되어 있어 분명하지 못하다. 읽는 사람에게 더 분명한 관계를 제시하기 위해서는 이와 동일한 식을 다음과 같은 방법으로 쓸 수 있다. 다만 기계에 있어서는 아무런 차이도 없음을 유의할 필요가 있다: 

<rdf:RDF>
  <rdf:Description about="http://www.w3.org/Home/Lassila">
    <s:Creator>
      <rdf:Description about="http://www.w3.org/staffId/85740">
	<v:Name>Ora Lassila</v:Name>
	<v:Email>lassila@w3.org</v:Email>
      </rdf:Description>
    </s:Creator>
  </rdf:Description>
</rdf:RDF>

두 번째 기본적인 축약구문을 사용하게 되면, 내부 Description 요소와 여기에 포함된 특성 표현을 Creator 요소의 속성으로 쓸 수 있다: 

<rdf:RDF>
  <rdf:Description about="http://www.w3.org/Home/Lassila">
    <s:Creator rdf:resource="http://www.w3.org/staffId/85740"
       v:Name="Ora Lassila"
       v:Email="lassila@w3.org" />
  </rdf:Description>
</rdf:RDF>

이 축약형식을 사용할 때, URI에 의해 명명된 자원이 두 가지 경우에서 Creator 특성 값이 되는 것과 같이 전입된 Description 요소의 about 속성은 propertyElt 요소의 자원속성이 된다. 위에 제시한 세 가지 형식 중 어는 것을 RDF 소스에 사용할 것인지의 여부는 전적으로 작성자에게 달려 있다. 이들 모두는 동일한 내부 RDF 모델을 작성하게 된다.

주의: 이 문서의 나머지를 연구한 관찰력이 뛰어난 사람이라면 문의 특수한 구문상의 분류를 유지하기 위해 Description 요소에 의해 어떤 부차적 관계가 표현되어 있다는 것을 알 수 있을 것이다. 결과적으로 위의 세 가지 형식은 중요하지 않은 방식에서는 이 장에서 다루는 내용과 약간 다르다. 이러한 차이는 4장에서 설명한 바와 같이 고차원의 문을 작성할 때에만 중요하게 된다.

세 번째 기본 축약 구문은 type 특성을 포함한 Description 요소의 일반적인 경우에 적용된다 (4.1장의 type 의미를 참조할 것). 이 경우 type 특성 값에 대응되는 스키마에서 정의된 자원유형은 요소명으로 직접 사용될 수 있다. 예컨대 앞서의 RDF 단편을 사용하여 http://www.w3.org/staffId/85740라는 자원이 인물의 사례라는 사실을 추가하고자 한다면 이것을 완전한 연속 구문으로 다음과 같이 작성할 수 있다: 

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:s="http://description.org/schema/">
  <rdf:Description about="http://www.w3.org/Home/Lassila">
    <s:Creator>
      <rdf:Description about="http://www.w3.org/staffId/85740">
	<rdf:type resource="http://description.org/schema/Person"/>
	<v:Name>Ora Lassila</v:Name>
	<v:Email>lassila@w3.org</v:Email>
      </rdf:Description>
    </s:Creator>
  </rdf:Description>
</rdf:RDF>
그리고 이 세 번째 축약 형식은 다음과 같게 된다: 
<rdf:RDF>
  <rdf:Description about="http://www.w3.org/Home/Lassila">
    <s:Creator>
      <s:Person about="http://www.w3.org/staffId/85740">
	<v:Name>Ora Lassila</v:Name>
	<v:Email>lassila@w3.org</v:Email>
      </s:Person>
    </s:Creator>
  </rdf:Description>
</rdf:RDF>

기본적인 축약 구문에 대한 EBNF는 다음과 같은 방식으로 기본적인 연속구문에 대한 문법 인 프로덕션 [2]와 [6]을 대치하게 된다: 

  [2a] description    ::= '<rdf:Description' idAboutAttr? propAttr* '/>'
                        | '<rdf:Description' idAboutAttr? propAttr* '>'
                              propertyElt* '</rdf:Description>'
                        | typedNode
  [6a] propertyElt    ::= '<' propName '>' value '</' propName '>'
                        | '<' propName resourceAttr? propAttr* '/>'
  [16] propAttr       ::= propName '="' string '"'
                          (with embedded quotes escaped)
  [17] typedNode      ::= '<' typeName idAboutAttr? propAttr* '/>'
                        | '<' typeName idAboutAttr? propAttr* '>'
                              property* '</' typeName '>'

2.2.3.스키마와 이름공간

자연언어로 문장을 작성할 때 특정한 의미를 전달하는 단어를 사용한다. 그 의미는 문을 이해하는데 중요하고, RDF의 어플리케이션인 경우 의도하는 바대로 정확한 처리를 하기 위해서 대단히 중요하다. Creator, approvedBy, Copyright 등과 같이 사용된 용어를 동일한 의미로 이해하는 것은 작성자나 이용자 양쪽 모두에게 중요하며, 그렇지 않으면 혼란을 줄 수 있다. World Wide Web과 같이 지구적인 차원의 미디어에서 "creatorship"과 같은 개념에 대한 문화적 이해를 공유하는 것만으로는 불충분하고, 가능하면 정확하도록 주의해야 한다.

RDF에서 의미는 스키마에 대한 참조를 통해 표현된다. 따라서 스키마를 일종의 사전이라고 생각할 수 있다. 스키마는 RDF 문에 사용되는 용어를 정의하고, 이들 용어에 특정한 의미를 부여한다. 다양한 스키마 형식이 RDF에 사용될 수 있는데, 여기에는 RDF를 사용하여 자동업무를 지원하는 특정한 특성을 지닌 별도의 문서[RDFSchema]에서 정의된 특수 형식이 포함된다.

스키마는 특성에 대한 정의와 사용상의 제한점이 문서화되는 곳이다. 독립되고 그리고 흔히 충돌될 수 있는 동일 용어의 정의간의 혼란을 피하기 위해, RDF에서는 XML 이름공간 기능을 사용한다. 이름공간은 문맥에서 단어의 특수한 용법을 의도하는 정의가 수록된 사전(스키마)과 단순히 연결하는 방식을 제시한 것이다. RDF에서 문에 사용된 각 술부는 정확히 하나의 이름공간, 즉 스키마로 식별되어야 한다. 그러나 Description 요소는 다수의 스키마로부터의 술부를 가진 문을 포함할 수 있다. 복수의 스키마를 사용한 RDF Description의 예는 7장에 제시되어 있다.

2.3.제한된 특성 값

대개 특성 값은 그 값의 "일부"로 생각되는 부차적인 문맥 정보를 지닌 어떤 것이다. 다시 말해 특성 값을 한정할 필요가 있다. 그러한 한정의 예는 계량단위나 특수하게 한정된 어휘, 혹은 기타 해설 등에 이름을 부여하는 것을 포함된다. 어떤 용법에서는 한정어 없이 특성 값을 사용하는 것이 적당하다. 예컨대 "그 연필 값은 75센트"라는 문에서는 단지 "그 연필 값은 75"라고 해도 충분할 수 있다.

RDF 모델에서 한정된 특성 값은 단지 구조화된 값의 또 다른 사례이다. 최초의 문의 객체는 이 구조화된 값이며, 한정은 이 공통 자원에 대한 추가 특성이다. 한정되는 주된 값은 이 공통 자원의 value 특성 값으로 제시된다. value 특성의 용법에 관한 예는 7.3장 비-이항관계를 참조하기 바란다.

3. 용기

흔히 자원의 집합을 참조할 필요가 있다. 예컨대 복수의 인물이 저술한 저작을 말하거나, 수강중인 학생 명단, 혹은 패키지 중의 소프트웨어 모듈 리스트 등이다. RDF 용기는 이러한 자원이나 리터럴 리스트를 유지하기 위해 사용된다.

3.1. 용기 모델

RDF에서는 세 가지 유형의 용기 객체를 정의하고 있다.

Bag 자원이나 리터럴의 체계화되지 않은 리스트이다. Bag은 하나의 특성이 복수의값을 가지고 있고, 그 값을 제시하는 순서는 중요하지 않다는 것을 선언할 때 사용된다. Bag은 part를 처리하는 순서가 문제시되지 않는 경우 그 part 번호의 리스트를 제시하는데 사용될 수 있다. 중복되는 값이 허용된다.
Sequence 자원이나 리터럴의 체계화된 리스트이다. Sequence는 하나의 특성이 복수의 값을 가지고 있고 그 값의 순서가 중요하다는 것을 선언할 때 사용된다. 예컨대 Sequence는 값의 자모순 체계를 유지하고자 할 때 사용된다. 중복되는 값이 허용된다.
Alternative   자원 리스트 혹은 특성의 (단일) 값에 대한 또 다른 대안의 값을 표현하는 리터럴리스트이다. Alternative를 사용하여 저작의 표제에 대한 다른 언어로 된 번역표제를 제공할 수 있으며, 혹은 자원을 탐색할 수 있는 인터넷 미러 사이트에 대한 리스트를 제공할 수 있다. 특성 값으로 Alternative 집합을 사용하는 어플리케이션은 필요에 따라 그 리스트에서 어떤 하나의 항목을 선택할 수 있다.
주의: Bag과 Sequence의 정의에서는 분명히 중복되는 값을 인정하고 있다. RDF 에서는 중복되는 값을 가지지 않은 Bag인 Set의 코어개념을 정의하지 않는다. 왜냐하면 RDF 코어는 이러한 제약조건을 위반하는 경우, 강제 기법을 규정하지 않기 때문이다. RDF 코어에 부여된 앞으로의 과제에서 이러한 기능을 정의할 수 있을 것이다.

자원의 집합을 표현하기 위해 RDF에서는 특정 집합(객체 모델링 용어로 표현하면 집합의 사례)을 식별하는 추가 자원을 사용한다. 이 자원은 위에서 정의된 용기객체유형 중 하나의 사례로 선언되어야 한다. 아래에 정의된 type 특성은 이러한 선언을 하기 위해 사용된다. 이 container 자원과 집합에 속한 자원간의 성원관계는 이러한 목적을 위해 분명하게 정의된 일련의 특성에 의해 정의된다. 이들 성원 특성은 단순히 "_1", "_2", "_3"으로 명명된다. container 자원은 성원 특성과 type 특성 이외에 다른 특성을 가질 수 있다. 그러한 추가되는 문(스테이트먼트)이 용기를 기술한다. 성원 각각에 대한 문에 관한 사항은 3.3장의 분산된 지시대상을 참조하기 바란다.

용기의 일반적인 용법은 특성 값으로 사용된다. 이런 방식으로 사용되면 그 문은 그 용기에 있는 성원의 수와 무관하게, 여전히 하나의 단일 문 객체를 가지며, 용기 자원 자체는 문의 객체이다.

예컨대 다음과 같은 문장이 있다.

6.001 과정의 학생은 Amy, Tim, John, Mary, Sue이다.

RDF 모델은 다음과 같다.

##########4*D

그림 4: 단순 Bag 용기

Bag 용기는 동일 type의 반복된 특성과 같은 것이 아니다. 그 차이에 대해서는 3.5장을 참고하기 바란다. 저자는 사례에 따라 어느 것(반복된 특성 문이나 Bag)이 사용하기에 더 적합한지를 결정할 필요가 있다.

다음과 같은 문장이 있다.

X11에 대한 소스 코드는 ftp.x.org, ftp.cs.purdue.edu, 혹은 ftp.eu.net에서 볼 수 있다.

이를 RDF 모델로 제시하면 다음과 같다.

##########5*D

그림 5: 단순 Alternative 용기

Alternative 용기는 언어 태깅과 흔히 관련되어 사용된다. 다수의 언어로 번역된 저작은 상이한 언어 각각을 수록하고 있는 Alternative 용기를 지시하는 Title 특성을 가질 수 있다.

3.2. 용기 구문(container syntax)

RDF의 용기 구문은 다음과 같은 형식을 취한다:

 [18] container       ::= sequence | bag | alternative
 [19] sequence        ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>'
 [20] bag             ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>'
 [21] alternative     ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>'
 [22] member          ::= referencedItem | inlineItem
 [23] referencedItem  ::= '<rdf:li' resourceAttr '/>'
 [24] inlineItem      ::= '<rdf:li>' value '</rdf:li>'

용기는 Description이 사용되는 곳이라면 어디에서도 사용이 가능하다.

 [1a] RDF             ::= '<rdf:RDF>' obj* '</rdf:RDF>'
 [8a] value           ::= obj | string
 [25] obj             ::= description | container

RDF/XML은 각 성원에 번호를 분명하게 부여하는 것을 방지하기 위해 li를 convenience 요소로 사용하고 있음에 유의할 필요가 있다. 이 li 요소는 필요에 따라 특성 _1, _2 등을 부여한다. 요소명 li는 HTML의 "list item"이라는 용어에 대한 조기성으로 인해 선정된 것이다.

Alt 용기는 최소한 하나의 성원을 가져야 한다. 이 성원은 특성 _1에 의해 식별되며 디폴트이거나 우선하는 값이다.

주의: RDF 스키마 명세서[RDFSCHEMA]에서도 이러한 용기 유형의 부차적 하위 클래스를 선언하는 기법을 정의하고 있다. 이 경우 production[18]은 이들 선언된 하위클래스의 이름을 포함하기 위해 확장된다. 속성형식에 리터럴 값을 작성하기 위한 구문도 있는데, 6장에서 완전한 문법을 참조하기 바란다.

3.2.1. 예

다음 문장에 대한 모델

6.001 과정을 수강하는 학생은 Amy, Tim, John, Mary, Sue이다.

은 RDF/XML로 표현하면 다음과 같다.

<rdf:RDF>
  <rdf:Description about="http://mycollege.edu/courses/6.001">
    <s:students>
      <rdf:Bag>
	<rdf:li resource="http://mycollege.edu/students/Amy"/>
	<rdf:li resource="http://mycollege.edu/students/Tim"/>
	<rdf:li resource="http://mycollege.edu/students/John"/>
	<rdf:li resource="http://mycollege.edu/students/Mary"/>
	<rdf:li resource="http://mycollege.edu/students/Sue"/>
      </rdf:Bag>
    </s:students>
  </rdf:Description>
</rdf:RDF>

이 경우 학생이라는 특성(property) 값이 하나의 Bag으로 표현되기 때문에 각 학생의 URI에 대해 여기서 제시한 순서는 중요하지 않다.

다음과 같은 문장은

X11에 대한 소스 코드는 ftp.x.org, ftp.cs.purdue.edu, 혹은 ftp.eu.net에서 볼 수 있다.

이를 RDF/XML로 표현하면 다음과 같다.

<rdf:RDF>
  <rdf:Description about="http://x.org/packages/X11">
    <s:DistributionSite>
      <rdf:Alt>
	<rdf:li resource="ftp://ftp.x.org"/>
	<rdf:li resource="ftp://ftp.cs.purdue.edu"/>
	<rdf:li resource="ftp://ftp.eu.net"/>
      </rdf:Alt>
    </s:DistributionSite>
  </rdf:Description>
</rdf:RDF>

여기서 DistributionSite에 대한 용기 값으로 제시된 항목 중 어느 것이라도 다른 항목을 고려하지 않고 수용될 수 있는 값이다.

3.3. 분산된 지시대상: 용기의 성원에 관한 문

용기 구조는 문에 관한 문제를 일으키고 있다. 즉 문이 집서를 지시하는 경우, 그 문이 어떤 '것'을 기술하고 있는가? 다시 말해서 그 문이 지시하는 것이 어떤 객체인가 하는 것이다. 그 문이 용기 자체를 기술하고 있는가, 아니면 그 용기의 성원을 기술하고 있는가? 기술의 대상인 객체(XML 구문에서 about 속성으로 지시된)를 RDF에서 지시대상(referent)이라고 한다.

다음 예:

<rdf:Bag ID="pages">
  <rdf:li resource="http://foo.org/foo.html" />
  <rdf:li resource="http://bar.org/bar.html" />
</rdf:Bag>

<rdf:Description about="#pages">
  <s:Creator>Ora Lassila</s:Creator>
</rdf:Description>

이 예에서 "Ora Lassila"는 Bag "pages"의 작성자이다. 그러나 Bag의 성원인 개별 페이지에 관해서는 아무 것도 말하지 않고 있다. Description의 지시대상은 성원이 아니라 그 용기(Bag)이다. 때로는 용기 자체 대신, 그 용기에 수록된 객체(대상) 각각에 대한 문을 작성할 필요도 있다. "Ora Lassila"가 각 페이지의 작성자임을 표현하기 위해 이와 다른 종류의 지시대상은 용기의 성원에 분배될 필요가 있다. RDF에서 이러한 지시대상은 aboutEach 속성을 사용하여 표현된다. 

  [3a] idAboutAttr    ::= idAttr | aboutAttr | aboutEachAttr
  [26] aboutEachAttr  ::= 'aboutEach="' URI-reference '"'

예로서 만약 다음과 같이 표현한다면

<rdf:Description aboutEach="#pages">
  <s:Creator>Ora Lassila</s:Creator>
</rdf:Description>

원하는 의미를 얻을 수 있다. 새로운 지시대상 유형을 분산형 지시대상이라고 한다. 이 분산형 지시대상을 사용하여 RDF Description에서 "구조를 공유할 수 있다". 예컨대 모두 다수의 공통의 문 파트(predicates와 objects)를 가진 몇 개의 Description을 작성하는 경우, 대개 공간을 절약하고 메타데이터를 관리하기 위해, 공통의 파트는 모든 Description 에서 공유될 수 있다. aboutEach 속성 값은 용기이어야 한다. 용기에서 분산형 지시대상을 사용하는 것은 각 성원에 대해 모든 문을 독립적으로 작성하는 것과 동일한 의미를 지닌다.

분산형 지시대상에 관한 분명한 그래프 표현방식은 정의된 바 없다. 그 대신 작성된 문을 통해, 분산형 지시대상은 개개의 용기 성원에 관한 개개의 문으로 확장된다 (내부적으로 모든 문이 개별적으로 작성된 경우와 같이 어떤 질의기능이 작용하는 한, 분산형 지시대상에 관한 정보를 유지하는 것은 자유이다-예를 들면 공간을 절약하기 위해-). 따라서 "foo"와 "bar"라는 자원과 관련하여 위의 예는 다음과 동일하다. 

<rdf:Description about="http://foo.org/foo.html">
  <s:Creator>Ora Lassila</s:Creator>
</rdf:Description>

<rdf:Description about="http://bar.org/bar.html">
  <s:Creator>Ora Lassila</s:Creator>
</rdf:Description>

3.4. URI 형태로 정의된 용기

메타데이터를 아주 빈번하게 사용하는 것 중의 하나는 "내 웹사이트에 있는 모든 페이지", 혹은 "내 웹사이트에서 이 분기에 있는 모든 페이지"에 관해 문을 작성하는 것이다. 대개의 경우 개개의 자원을 분명하게 리스트로 작성하고 이 자원을 용기의 성원으로 식별하는 것은 비현실적이고 바람직한 일도 아니다. 따라서 RDF에서는 두 번째 분산형 지시대상 유형을 가지고 있다. 이 두 번째 분산형 지시대상 유형은 Bag의 사례를 표현한 간략 구문으로서, 이 Bag의 성원은 정의상 특정한 용어열로 시작되는 자원식별기호를 가진 모든 자원이다: 

  [26a] aboutEachAttr  ::= 'aboutEach="' URI-reference '"'
                         | 'aboutEachPrefix="' string '"'

aboutEachPrefix 속성은 그 속성 값으로 제시된 문자열로 시작되고, 완전히 변환된 자원식별기호를 가진 모든 자원을 성원으로 가진 Bag임을 선언한다. aboutEachPrefix 속성을 지닌 Description에서의 문은 이 Bag의 각 성원에 개별적으로 적용된다.

예를 들어 http://foo.org/doc/page1와 http://foo.org/doc/page2 라는 두 개의 자원이 있다면 이들 각각은 저작권 특성을 가지고 있다고 할 수 있다. 

<rdf:Description aboutEachPrefix="http://foo.org/doc">
  <s:Copyright>© 1998, The Foo Organization</s:Copyright>
</rdf:Description>

만약 그 문자열로 시작되는 URI를 가진 두 개의 자원만이 있는 경우라면 위의 내용은 다음의 두 가지 중 어느 것과도 동일하게 된다. 

<rdf:Description about="http://foo.org/doc/page1">
  <s:Copyright>© 1998, The Foo Organization</s:Copyright>
</rdf:Description>
<rdf:Description about="http://foo.org/doc/page2">
  <s:Copyright>© 1998, The Foo Organization</s:Copyright>
</rdf:Description>

그리고

<rdf:Description aboutEach="#docpages">
  <s:Copyright>© 1998, The Foo Organization</s:Copyright>
</rdf:Description>
<rdf:Bag ID="docpages">
  <rdf:li resource="http://foo.org/doc/page1"/>
  <rdf:li resource="http://foo.org/doc/page2"/>
</rdf:Bag>

3.5. 용기와 반복되는 성질과의 관계

자원은 동일한 술부(예를 들면 동일한 특성을 사용하여)를 가진 다수의 문을 가질 수 있다(즉 동일한 성질을 사용하여). 이것은 다수의 성원을 포함한 용기를 객체로 하여 단일 문을 가지는 것과는 같지 않다. 어떤 특정 환경에서 어떤 방식을 사용할 것인지의 선택은 부분적으로는 스키마 설계자에 의해 결정되고, 다른 한편으로는 특정한 RDF 문을 작성하는 사람에 의해 결정된다.

작가와 그 출판물간의 관계에 관한 사례를 검토해 보자. 다음과 같은 문장을 보자.

Sue는 "Anthology of Time", "Zoological Reasoning", "Gravitational Reflections"을 썼다.

즉, 동일 저자에 의해 각기 독립적으로 쓰여진 세 개의 자원이 있다.

##########6*D

그림 6: 반복된 특성

이 예에서 보면, 동일인에 의해 쓰여졌다는 것 이외에 출판물간의 관계에 대해서는 아무런 언급도 없다.

반대로 다음과 같은 문장을 보자.

Fred, Wilma, Dino위원회는 그 결정을 승인하였다.

이 문장을 통해 전반적으로 세 명의 위원이 특정한 방식으로 투표했음을 알 수 있다. 각 위원이 그 사항에 대해 찬성 투표를 했는지에 대해서는 반드시 언급하지 않고 있다. 이 문장은 각 위원들의 표결 결과를 말하고 있기 때문에, 이를 각 위원별로 세 개의 독립된 approvedBy 문으로 모델화하는 것은 옳지 않을 수 있다. 오히려 위원들의 신원을 포함한 Bag을 객체로 하여 하나의 approvedBy 문으로 이 문장을 모델하는 것이 좋다:

##########7*D

그림 7: 종합 의견을 제시하기 위한 Bag의 사용

Bag을 사용할 것인지 아니면 반복된 특성을 사용하여 표현할 것인지의 선택은 스키마를 고려한 다음, 메타데이터를 작성하는 사람에 의해 결정된다. 예컨대 만약 위에서 예로 든 출판물에서, 이들 출판물이 완전한 세트인 경우라고 한다면 스키마에서는 이러한 목적으로 publications이라는 특성을 포함할 수 있을 것이다. publications 특성 값은 Sue의 모든 저작을 나열한 Bag이 될 것이다.

4. 문에 관한 문

웹 자원에 대한 문을 작성하고 이에 덧붙여 RDF는 다른 RDF 문에 관한 문을 작성하는데 사용될 수 있다. 이것을 고차원의 문이라고 한다. 다른 문에 관한 문을 작성하기 위해서는 원래의 문에 대한 모델을 실제로 구축해야 한다. 이 모델은 추가되는 특성을 첨가할 수 있는 새로운 자원이다.

4.1. 모델링 문

문은 자원에 대해 만들어진다. 문 모델은 모델화된 문에 관한 새로운 문(고차원의 문)을 작성하기 위해 필요한 자원이다.

예컨대 다음 문장을 보자.

Ora Lassila은 자원 http://www.w3.org/Home/Lassila의 작성자이다.

RDF는 이 문장을 사실로 취급한다. 만약 이 대신 다음과 같은 문장에서,

Ralph Swick는 Ora Lassila가 자원 http://www.w3.org/Home/Lassila의 작성자라고 말하고 있다.

그런데 자원인 http://www.w3.org/Home/Lassila에 대해서는 아무런 언급도 하지 않았다. 그 대신 Ralph가 작성한 문에 관한 사실을 표현하였다. 이 사실을 RDF에서 표현하기 위해서는 원래의 문을 네 개의 특성을 가진 자원으로 모델화해야 한다. 이 과정을 지식표현 영역에서는 공식적으로 구체화라고 한다. 문의 모델을 구체화된 문이라고 한다.

문을 모델화하기 위해 RDF에서는 다음과 같은 특성을 정의한다:

subject subject 특성은 모델화된 문에 의해 기술되는 자원을 식별한다. 즉 subject 특성의 값은 원래의 문이 작성된 자원이다(예에서 http://www.w3.org/Home/Lassila).
predicate   predicate 특성은 모델화된 문의 원래의 특성을 식별한다. predicate 특성 값은 원래의 문에서 특정한 특성을 표현한 자원이다(예에서 creator).
object object 특성은 모델화된 문의 특성 값을 식별한다. object 특성의 값은 원래의 문에 있는 object이다(예에서 "Ora Lassila").
type    type 특성 값은 새로운 자원의 type을 기술한다. 모든 구체화된 문은 RDF:Statement의 사례이다. 즉 구체화된 문은 그 객체인 RDF:Statement를 가진 type 특성을 가진다. 3장 "용기"에서 보는 바와 같이, 이 type 특성은 어떤 자원의 type을 일반적으로 선언할 때에도 흔히 사용된다.

위의 네 가지 특성을 가진 새로운 자원은 원래의 문을 표현하며, 다른 문의 객체로 사용되며, 또 그에 대한 추가 문을 작성할 수 있다. 이 네 가지 특성을 가진 자원은 원래의 문을 대치하는 것이 아니라 그 문의 모델이다. 문과 그와 대응되는 구체화된 문은 RDF 도표에서 독립적으로 존재하며, 어느 쪽도 다른 쪽이 없어도 제시될 수 있다. 대응되는 구체화된 문이 제시되었는지의 여부와 무관하게, RDF 도표는 문이 그래프로 표현되는 경우, 그리고 그 경우에만 문에 제시된 사실을 포함한다고 할 수 있다.

위의 예를 모델화하기 위해, 적절한 값(이 경우 "Ralph Swick")을 가진 구체화된 문(예컨대 "attributedTo")에 다른 특성을 추가할 수 있다. 기초 수준의 RDF/XML 구문을 사용하여 이를 다음과 같이 작성할 수 있다. 

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:a="http://description.org/schema/">
  <rdf:Description>
    <rdf:subject resource="http://www.w3.org/Home/Lassila" />
    <rdf:predicate resource="http://description.org/schema/Creator" />
    <rdf:object>Ora Lassila</rdf:object>
    <rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement" />
    <a:attributedTo>Ralph Swick</a:attributedTo>
  </rdf:Description>
</rdf:RDF>

그림 8은 이를 그래프 형식으로 표현한 것이다. 구문상으로 보면 이것은 오히려 함축적이다. 4.2장에서 문에 관한 문을 작성하는 간략 형식을 제시하고 있다.

##########8*D

그림 8: 구체화된 문의 표현

아울러 구체화는 Description 요소에 의해 묵시적으로 제시된 문의 그룹핑을 모델에서 분명히 표현하기 위해 필요하다. RDF 그래프 모델은 Description에 대해 특수한 구조를 필요로 하지 않는다. 왜냐하면 Description은 실제로 문의 집합이며, Bag 용기는 일련의 문이 동일한(구문상) Description에서 왔음을 지시하는 데에 사용된다. Description에 포함된 각 문은 구체화되고, 구체화된 개개의 문은 그 Description을 표현한 Bag의 성원이다. 예로서 RDF 단편은, 

<rdf:RDF>
  <rdf:Description about="http://www.w3.org/Home/Lassila" bagID="D_001">
    <s:Creator>Ora Lassila</s:Creator>
    <s:Title>Ora's Home Page</s:Title>
  </rdf:Description>
</rdf:RDF>

그림 9에 제시된 그림이 될 것이다.

##########9*D

그림 9: 문 그룹핑을 표현하기 위한 Bag의 사용

이 새로운 속성인 bagID에 유의할 필요가 있다. 이 속성은 용기 자원의 자원 id를 지정하고 있다. 

  [2b] description    ::= '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '/>'
                        | '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '>'
                              propertyElt* '</rdf:Description>'
  [27] bagIDAttr      ::= 'bagID="' IDsymbol '"'

BagID와 ID를 혼동해서는 안된다. ID는 그 특성이 Description에서 상세하게 전개되는 인라인 자원을 지정한다. BagID는 그 성원이 다른 자원에 관한 구체화된 문인 용기 자원을 지정한다. Description은 BagID 속성과 ID 속성 두 가지를 가질 수 있다.

4.2. 문에 관한 문에 대한 구문상의 간략형

Description에 bagID를 첨부하게 되면 그 Description의 구체화된 문의 Bag을 모델에 포함하는 결과를 가져온다. 그래서 문에 관한 문을 작성할 때 이것을 구문상 간략형으로 사용할 수 있다. 예컨대 Ora가 http://www.w3.org/Home/Lassila의 저자라는 것을 Ralph가 말하였고, 아울러 그는 그 자원의 표제가 "Ora'의 홈 페이지"라고 하였다면 위의 예에 이를 간단히 첨가할 수 있다. 

<rdf:Description aboutEach="#D_001">
  <a:attributedTo>Ralph Swick</a:attributedTo>
</rdf:Description>

이 간략형의 예는 그림 8의 예에서 표현되지 않은 추가 사실을 모델에 포함하고 있음을 유의할 필요가 있다. 이 간략 기법은 Ralph의 문에 관한 사실과 Ora의 홈페이지에 관한 사실을 표현하고 있다.

##########10*D

그림 10: 문에 관한 문 표현

고차원의 문과 구체화에 관한 공식적인 처리에 대해서는 이 명세서의 5장을 참고하기 바란다.

5. RDF에 대한 공식 모델

이 명세서에서는 데이터 모델을 3-튜플(트리플), 그래프, XML이라는 세 가지 방식으로 표현하고 있다. 이들 표현은 대등한 의미를 가진다. 이 명세서에 사용된 표현간의 매핑은 실행에 사용된 내부 표현을 어떤 방식으로도 제한할 의도는 아니다.

RDF 데이터 모델은 다음과 같이 공식적으로 정의된다:

  1. 자원이라는 세트가 있다.
  2. 리터럴이라는 세트가 있다.
  3. 특성이라는 자원의 하위세트가 있다.
  4. 스테이트먼트라는 세트가 있고, 이 스테이트먼트의 각 요소는

    {pred, sub, obj}

    라는 트리플 형식을 취한다.
    여기서 pred는 특성(특성의 성원), sub는 자원(자원의 성원), obj는 자원이나 리터럴(리터럴의 일부)이다.

일련의 문(문의 성원)를 방향 그래프로 볼 수 있다. 각 자원과 리터럴은 정점(vertex)이고, 트리플{p, s, o}은 s로부터 o로의 아크이며 p로 구분된다. 이것을 그림으로 도시하면 그림 11과 같다.

##########11*D

그림 11: 단순 문 그래프 템플릿

이것을 다음 중 하나로 해석할 수 있다.

o는 s에 대한 p의 값이다.

혹은 (왼쪽에서 오른쪽으로)

s는 o와 같은 값을 가진 특성 p를 가지고 있다.

혹은 심지어

s의 p는 o 이다.

예컨대,

자원 http://www.w3.org/Home/Lassila의 작성자는 Ora Lassila이다.

라는 문장은 다음과 같은 그림으로 표현될 수 있다:

##########12*D

그림 12: 단순 문 그래프

그리고 대응되는 트리플(문의 성원)은 다음과 같다.

{creator, [http://www.w3.org/Home/Lassila], "Ora Lassila"}

여기서 기호 [I]은 URI I에 의해 식별되는 자원을 의미하고, 인용부호는 리터럴을 의미한다.

트리플을 사용하여 문이 어떻게 구체화되는 가를 설명할 수 있다(4장의 서론에서와 같이).

특정한 문

{creator, [http://www.w3.org/Home/Lassila], "Ora Lassila"}

를 보면, 다음과 같이 새로운 자원 X로 이 문의 구체성을 표현할 수 있다.

{type, [X], [RDF:Statement]}
{predicate, [X], [creator]}
{subject, [X], [http://www.w3.org/Home/Lassila]}
{object, [X], "Ora Lassila"}

RDF 프로세서의 관점에서 보면, 사실(즉, 문)은 문의 성원인 트리플이다. 따라서 원래의 문은 비록 구체화됨에도 불구하고 이 사실을 그대로 유지한다. 왜냐하면 원래의 문을 표현한 트리플이 문에 남기 때문이다. 단지 네 개의 트리플을 추가하였다.

"type"으로 명명된 특성은 기초적인 유형화(typing)를 제공하기 위해 정의된다. type의 공식적인 정의는 다음과 같다:

  1. RDF:type이라는 특성 요소가 있다.
  2. {RDF:type, sub, obj} 형식의 문 성원은 다음을 충족시켜야 한다. 즉 sub와 obj는 자원의 성원이어야 한다는 점이다. [RDFSchema]는 type 사용에 제한사항을 추가한다.

더욱이 구체화의 형식적인 사양은 다음과 같다:

  1. RDF:Statement라는 특성에 포함되지 않는 자원요소가 있다.
  2. RDF:predicate, RDF:subject, RDF:object라는 세 개의 특성 요소가 있다.
  3. 문의 트리플{pred, sub, obj}의 구체화는 구체화된 트리플과 다음과 같이 문의 s1, s2, s3, s4 요소를 표현하는 자원의 r 요소이다.

    s1: {RDF:predicate, r, pred}
    s2: {RDF:subject, r, subj}
    s3: {RDF:object, r, obj}
    s4: {RDF:type, r, [RDF:Statement]}

위의 정의에서 자원 r을 구체화된 문이라고 한다. 자원이 구체화된 문을 표현할 때, 즉 자원이 RDF:Statement 값을 가진 RDF:type 특성을 가지게 되면 그 자원은 정확히 하나의 RDF:subject 특성과 하나의 RDF:object 특성, 하나의 RDF:predicate 특성을 가져야 한다.

3장에서 기술한 바와 같이, 흔히 자원의 집합이나 리터털을 표현할 필요가 있다. 예컨대 특성(property)이 체계화된 일련의 값을 가지고 있음을 제시하는 경우이다. RDF에서는 세 가지 종류의 집합을 정의하고 있다. 즉 체계화된 리스트인 Sequence, 체계화되지 않은 리스트인 Bag, 그리고 특성 (단일) 값에 대한 대체 값을 표현하는 리스트인 Alternative가 그것이다.

이 세 가지 집합 유형은 공식적으로 다음과 같이 정의된다:

  1. RDF:Seq와 RDF:Bag, RDF:Alt라고 하는 특성에 포함되지 않는 자원의 세 가지 요소가 있다.
  2. Ord라고 하는 서수(1, 2, 3, ...)에 대응되는 특성의 하위세트가 있다. 이 Ord의 요소를 RDF:_1, RDF:_2, RDF:_3, ... 로 지시한다.

집합 c를 표현하기 위해 트리플({RDF:type, c, t})을 작성한다. 여기서 t는 RDF:Seq, RDF:Bag, RDF:Alt라는 세 가지 집합 유형 중 하나를 의미한다. {RDF:_1, c, r1}, ..., {RDF:_n, c, rn}, ...과 같은 나머지 트리플은 집합의 성원인 rn을 각각 지시한다. 단일 집합 자원에 대해서는 술부가 단지 Ord의 어떤 특정 요소인 하나의 트리플이 있으며, Ord의 그 요소는 RDF:_1으로 시작하여 연속적으로 사용되어야 한다. RDF:Alt 집합 유형의 사례인 자원에 대해서는 술부가 RDF:_1인 하나의 트리플이 정확히 있어야 하며, 이 트리플은 대체 자원에 대한 초기 값이다(즉 최소한 하나의 대체 자원이 있어야 한다).

6. RDF에 대한 공식 문법

RDF에 대한 완전한 BNF는 앞장에서부터 여기에 다시 제시하였다. 공식 모델로 문법을 정확하게 해석한 것도 동시에 제시하고 있다. XML로부터 상속받은 구문상의 특징은 여기에 다시 거론하지 않았다. 이 특징은 적법한 제한사항을 포함하고 있으며, 속성 주변의 공백 및 속성 값에 사용되는 작은따옴표(' ')와 큰따옴표(" ")의 용법은 물론 '='등의 용법을 포함하고 있다. 이 장에서는 RDF/XML 구문을 읽고 해석하는 도구를 개발하기 위한 실행자를 위한 것이다.

다음에 사용된 "SHOULD", "MUST", "MUST NOT"와 같은 키워드는 RFC 2119[RFC2119]에 기술된 바와 같이 해석된다. 그러나 판독을 위해 이들 단어는 이 명세서에서 모두 대문자를 사용하지 않았다. 

  [6.1] RDF            ::= ['<rdf:RDF>'] obj* ['</rdf:RDF>']
  [6.2] obj            ::= description | container
  [6.3] description    ::= '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '/>'
                         | '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '>'
                                propertyElt* '</rdf:Description>'
                         | typedNode
  [6.4] container      ::= sequence | bag | alternative
  [6.5] idAboutAttr    ::= idAttr | aboutAttr | aboutEachAttr
  [6.6] idAttr         ::= ' ID="' IDsymbol '"'
  [6.7] aboutAttr      ::= ' about="' URI-reference '"'
  [6.8] aboutEachAttr  ::= ' aboutEach="' URI-reference '"'
                         | ' aboutEachPrefix="' string '"'
  [6.9] bagIdAttr      ::= ' bagID="' IDsymbol '"'
 [6.10] propAttr       ::= typeAttr
                         | propName '="' string '"' (with embedded quotes escaped)
 [6.11] typeAttr       ::= ' type="' URI-reference '"'
 [6.12] propertyElt    ::= '<' propName idAttr? '>' value '</' propName '>'
                         | '<' propName idAttr? parseLiteral '>'
                               literal '</' propName '>'
                         | '<' propName idAttr? parseResource '>'
                               propertyElt* '</' propName '>'
                         | '<' propName idRefAttr? bagIdAttr? propAttr* '/>'
 [6.13] typedNode      ::= '<' typeName idAboutAttr? bagIdAttr? propAttr* '/>'
                         | '<' typeName idAboutAttr? bagIdAttr? propAttr* '>'
                               propertyElt* '</' typeName '>'
 [6.14] propName       ::= Qname
 [6.15] typeName       ::= Qname
 [6.16] idRefAttr      ::= idAttr | resourceAttr
 [6.17] value          ::= obj | string
 [6.18] resourceAttr   ::= ' resource="' URI-reference '"'
 [6.19] Qname          ::= [ NSprefix ':' ] name
 [6.20] URI-reference  ::= string, interpreted per [URI]
 [6.21] IDsymbol       ::= (any legal XML name symbol)
 [6.22] name           ::= (any legal XML name symbol)
 [6.23] NSprefix       ::= (any legal XML namespace prefix)
 [6.24] string         ::= (any XML text, with "<", ">", and "&" escaped)
 [6.25] sequence       ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>'
                         | '<rdf:Seq' idAttr? memberAttr* '/>'
 [6.26] bag            ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>'
                         | '<rdf:Bag' idAttr? memberAttr* '/>'
 [6.27] alternative    ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>'
                         | '<rdf:Alt' idAttr? memberAttr? '/>'
 [6.28] member         ::= referencedItem | inlineItem
 [6.29] referencedItem ::= '<rdf:li' resourceAttr '/>'
 [6.30] inlineItem     ::= '<rdf:li' '>' value </rdf:li>'
                         | '<rdf:li' parseLiteral '>' literal </rdf:li>'
                         | '<rdf:li' parseResource '>' propertyElt* </rdf:li>'
 [6.31] memberAttr     ::= ' rdf:_n="' string '"' (where n is an integer)
 [6.32] parseLiteral   ::= ' parseType="Literal"'
 [6.33] parseResource  ::= ' parseType="Resource"'
 [6.34] literal        ::= (any well-formed XML)

이 명세서에 정의된 특성과 클래스에 대한 공식적인 이름공간명은 http://www.w3.org/1999/02/22-rdf-syntax-ns#이다. RDF 프로세서가 "http://www.w3.org/TR/REC-rdf-syntax"라는 용어열로 시작되는 이름공간명에서 선언된 XML 요소나 속성명을 만나게 되고, 그리고 이 프로세서가 그 이름의 의미를 인식하지 못하게 되면, 그 프로세서는 요소의 내용을 포함하여 요소명이나 속성명을 인식하지 못하는 전체 XML 요소를 스킵하게 된다 (즉 아무런 튜플도 생성하지 않는다).

Description 요소에 의해 포함된 각 propertyElt E는 트리플{p,r,v}을 생성하게 된다. 그것은 다음과 같다.

  1. p는 E의 이름공간-적절한 태그명(일반식별기호)을 확장한 것이다. 이 확장은 적절한 이름의 LocalPart를 이름공간선언에 제시된 이름공간명과 연결함으로써 생성된다.
  2. r은
    • 식별기호가 Description의 about 속성 값으로 제시된 자원이거나,
    • 식별기호가 Description의 ID 속성 값인 새로운 자원이다. 만약 이 값이 제시된 경우, 그 밖의 새로운 자원은 식별기호를 가지지 않는다.
  3. 만약 E가 공백 요소(내용이 없는)이면, v는 식별기호가 E의 자원 속성으로 제시된 자원이다. 만약 E의 컨텐츠가 XML 마크업을 포함하지 않거나 parseType="Literal"이 E의 시작태그에 명시된 경우, v는 E의 컨텐츠(리터럴)이다. 그렇지 않으면 E의 컨텐츠는 다른 Description이거나 용기이어야 하고, v는 그 Description이나 용기의 ID(대개 묵시적으로)나 about으로 명명된 자원이다.

parseType 속성은 요소 컨텐츠의 해석을 변화시킨다. 이 parseType 속성은 'Literal'이나 'Resource' 중 하나의 값을 가져야 한다. 이 값은 대소문자의 차이를 식별한다. 'Literal'이라는 값은 요소의 컨텐츠를 RDF/XML 리터럴로 취급되도록 명시한다. 즉 그 컨텐츠는 RDF 프로세서에 의해 번역되어서는 안된다는 것이다. 값 'Resource'는 요소의 컨텐츠를 마치 Description 요소의 컨텐츠로 취급해야 한다는 것을 명시한 것이다. parseType의 기타 값은 장차 RDF에서 명세하기 위해 유보되어 있다. RDF 1.0에서 기타 값은 'Literal'과 동일하게 취급되어야 한다. 모든 경우 parseType 속성을 가진 요소의 컨텐츠는 XML체계에 따라야 한다. 나아가 parseType="Resource" 속성을 가진 요소의 컨텐츠는 Description 요소의 컨텐츠를 위한 생성규칙과 일치해야 한다.

RDF 모델과 구문 실무단은 parseType='Literal' 기법이 XML 마크업을 값으로 가진 RDF 문을 표현하기 위한 조건에 대한 최소 수준의 해결수단으로 인식하고 있다. 공백의 표준화와 같은 XML의 부차적 복잡성은 아직 분명하게 정의되지 않고 있다. W3C의 앞으로의 과제는 XML에 기초한 모든 어플리케이션에서 이러한 문제를 일관된 방식으로 해결하는 것이다. RDF의 앞으로의 버전에서 이 일을 계승하게 될 것이고, 장차 어플리케이션의 경험을 통해 얻는 통찰력으로 이를 확장할 수 있을 것이다.

RDF 문이 출현하는 문서의 기본 URI를 사용하여 [URI]로 지정된 절대 형식에 대해 URI-참조를 처음으로 분해함으로써 URI-참조는 자원 식별기호로 분해된다. 만약 단편 식별기호가 URI-참조에 포함된 경우, 자원식별기호는 단지 포함하는 자원의 하위 구성요소만을 지시하게 되고, 이 하위 구성요소는 대응되는 anchor id에 의해 내부적으로 수록하는 자원으로 식별되며, 하위 구성요소의 범위는 수록하는 자원의 컨텐츠 유형과 관련하여 단편 식별기호에 의해 정의된다. 그 밖의 경우 자원식별기호는 URI에 의해 명시된 전체 항목을 지시한다.

주의: 비록 URI에서 비ASCII 문자는 [URI]에 의해 인정되지 않지만, [XML]은 확장된 URI 구문에서 불필요한 비호환성을 피하기 위한 규정을 명시하고 있다. RDF의 구현자는 더 이상의 비호환성을 방지하고, 시스템 식별기호에 대해 XML 규정을 사용하도록 권유받고 있다. 즉 URI에서 비ASCII 문자는 하나 이상의 바이트로 UTF-8에서 표현되고, 이들 바이트는 URI 에스케이핑 기법으로 에스케이프된다 (즉 각 바이트를 %HH로 변환하는 것으로, 여기서 HH는 그 바이트 값의 16진수이다).

Description 요소 자체는 Bag 자원의 사례를 나타낸다. 이 Bag의 성원은 그 Description의 각 문을 구체화한 것과 대응되는 자원이다. 만약 bagID 속성이 지정된 경우라면 그 값이 이 Bag의 식별기호이며, 기타 Bag은 이름이 없게된다.

about이 Description에 명시된 경우, Description의 문은 그 about에서 명명된 자원을 지시한다. about 속성이 없는 Description 요소는 인라인 자원을 표현한다. 이 인라인 자원은 자원 식별기호를 가진다. 이 식별기호는 RDF 문을 포함한 문서의 기본 URI 값과, 만약 있다면 여기에 Description 요소의 ID 속성 값과 동일한 anchor id를 결합하여 구성된다. 별도의 Description이나 특성 값이 인라인 자원을 지시하는 경우, about 속성에 있는 ID 값을 사용하게 된다. 기타 Description이 구체화된 문에 대응되는 자원의 Bag을 지시하는 경우, about 속성의 bagID 값을 사용하게 된다. ID나 about 중 어느 하나가 Description에 명시될 수 있지만 동일 요소에 이 두 가지를 동시에 사용할 수는 없다. 각 ID와 bagID 속성에 대한 값은 문서 내에서 해당 속성 하나에만 사용되어야 하며, 단일 문서 내에서 ID와 bagID에 동일한 값을 사용해서도 안된다.

aboutEach가 Description에 명시된 경우, 이 Description에 있는 문은 aboutEach로 명명된 용기의 각 성원을 지시한다. 위에서 설명한 바와 같이 포함된 개개의 propertyElt E에 의해 표현된 트리플{p,r,v}은 그 용기의 성원인 각 r에 대해 중복된다.

aboutEachPrefix가 Description에 명시된 경우, 이 Description에 있는 문은 무명의 Bag 용기의 각 성원을 지시한다. 이 Bag 용기의 성원은 aboutEachPrefix의 값으로 제시된 문자열로 시작되는 절대형식의 자원식별기호를 가진 모든 자원이다. 절대형식의 자원식별기호는 [URI]의 5.2장 절대형식에 대한 상관참조분석 알고리즘에 따라 URI를 분석하여 만들어진다. 위에서 설명한 바와 같이 포함된 각 propertyElt E로 표현된 트리플 {p,r,v}은 용기의 성원인 각 r에 대해 중복된다.

Seq, Bag, Alt은 각기 Sequence, Bag, Alternative 용기자원유형의 사례를 나타낸다. 트리플 {RDF:type,c,t}이 작성되는데, 여기서 c는 집합자원, t는 RDF:Seq, RDF:Bag 혹은 RDF:Alt 중 하나를 의미한다. 집합의 성원은 li로 표현된다. 각 li 요소 E는 collection의 한 성원과 대응되고 결과적으로 트리플 {p,c,v}이 작성된다: 여기서,

  1. p는 각 용기에서 "RDF:_1"으로 시작되는 각 성원의 어휘표현(XML) 순서에 따라 연속적으로 부여된다.
  2. c는 집합자원이다. 만약 ID 속성이 제시된 경우, 이 속성은 c에 대한 URI 단편 식별기호를 제공한다.
  3. (위의 규칙 3과 동일) 만약 E가 공백 요소(아무 컨텐츠가 없는)이면, v는 E의 자원 속성으로 제시된 자원식별기호를 가진 자원이다. 만약 E의 컨텐츠가 XML 마크업을 포함하지 않거나, 혹은 parseType="Literal"이 E의 시작태그에 명시된 경우이면 v 는 E(리터럴)의 컨텐츠이다. 그 이외의 경우, E의 컨텐츠는 다른 Description이거나 용기여야 하며, v는 그 ID(대개 묵시적으로)에 의해 명명된 자원이거나, 그 Description이나 용기의 about으로 명명된 자원이다.

URI는 (분해 후) 목표 자원, 즉 Description이 적용되는 자원이거나 용기에 포함된 자원을 식별한다. Description 요소 상의 bagID 속성과 용기 요소 상의 ID 속성은 Description이나 용기를 다른 Description을 통해 참조하도록 한다. 용기 요소 상의 ID는 property 요소에 있는 자원 속성에 사용된 이름으로서, 집합을 그 property의 값으로 한다.

propertyElt (production [6.12])에서 자원 속성으로 사용된 URI는 그 문의 객체(즉 이 property의 값)인 자원을 식별한다(분해 후). ID 속성 값이 명시된 경우, 이 값은 그 문의 구체화를 표현한 자원의 식별기호이다. 만약 RDF식(즉 RDF/XML 마크업을 가진 컨텐츠)이 특성 값으로 명시된 경우, 그 대상은 포함된 Description의 about 속성으로 제시된 자원이거나, 포함된 Description이나 용기 자원의 ID이다. 용어열은 체계화된 XML을 따라야 하며, 만약 그 용어열이 체계화된 규칙에 위반되는 문자를 포함한 경우("<" 와 "&"), 혹은 마크업과 유사한 문자를 포함한 경우에는 일반적인 XML 컨텐츠 인용법과 에스케이프 기법을 사용할 수 있다. 속성 parseType="Literal"은 요소 컨텐츠가 RDF 리터럴임을 명시한다. 이 컨텐츠의 일부인 어떤 마크업도 RDF에서 해석되지 않고, 리터럴의 일부로 포함된다.

특성 정의를 대응되는 스키마와 분명하게 연결하기 위해 특성명을 항상 이름공간 접두사로 한정하도록 권고하고 있다.

XML에서 정의된 바와 같이, RDF 문자열의 문자 레퍼토리는 ISO/IEC 10646 이다[ISO10646]. XML 문서에 있거나 기타 RDF 데이터 모델에 표현되었거나 관계없이, 실제 RDF 문자열은 ISO/IEC 10646를 직접 코딩하거나, ISO/IEC 10646으로 매핑할 수 있는 코딩을 통해 축적될 수 있다. 언어 태그를 부여하는 것은 용어열 값의 일부이며, RDF 용어열에 포함된 일련의 문자에 적용되며, 데이터 모델에서 분명히 표현되지 않는다.

만약 용어열이 ISO/IEC 10646의 표현과 일치하는 경우, 두 개의 RDF 용어열은 동일한 것으로 취급된다. 각 RDF 어플리케이션에서 사용될 때, 다음과 같은 '일치'의 정의 중 하나를 명시해야 한다.

  1. 두 개의 표현은 동일하다. 혹은
  2. 두 개의 표현은 Unicode 표준[Unicode]에서 정의된 것과 규범상 동일하다.
주의: W3C I18N WG에서는 현재 용어열의 동일성을 확인하기 위한 정의를 작성하고 있다. 이 정의는 Unicode 표준에 따른 규범적 등가성과 그리고 종래의 통일성 표준화의 원리에 기초하는 것이 아마도 가장 바람직할 것이다. RDF 이용자는 규범적 등가성을 이용한 어떤 특정 어플리케이션과 일치하는가에 의지해서는 안되고, 제시될 정의에 따라 자신의 데이터를 표준형식으로 표현하도록 확인하는 노력이 필요하다.

이 명세서는 마크업을 포함한 리터럴간의 등가성을 결정하는 기법에 대해서는 언급하지 않고 있으며, 그러한 기법이 존재하는지에 대한 보장도 시도하지 않고 있다.

xml:lang 속성은 언어와 특성 값을 연결하기 위해 [XML]에 의해 정의된 대로 사용될 수 있다. xml:lang에 대한 특정한 데이터 모델 표현은 없으며(즉 데이터 모델에 어떤 트리플도 추가하지 않는다), 리터럴의 언어는 RDF에서 리터럴의 일부로 취급된다. 어플리케이션에서는 용어열의 언어를 태그하는 것을 무시해도 좋다. 모든 RDF 어플리케이션은 리터럴에서 언어를 태그로 부여하는 것이 중요한지의 여부를 명시해야 한다. 즉 용어열 매칭이나 기타 처리 과정에서 언어를 고려할지의 여부를 명시해야 한다.

"xmlns"라는 이름으로 시작되는 속성은 이름공간선언이며, 데이터 모델에서 트리플을 표현하지 않는다. 이와 같은 이름공간선언에 대한 특정한 데이터 모델 표현방식은 없다.

개개의 특성과 값은 production[6.3]에 의해 XML 속성으로 표현되며, production[6.10]은production[6.12]에 따라 대응하는 Description의 XML 컨텐츠로 표현된 것과 동일한 특성 값과 대등하다. 특히 Description으로 명시된 개개의 XML 속성 A는 속성 ID, about, aboutEach, aboutEachPrefix, bagID, xml:lang 이외의 태그로 시작하며, 혹은 문자 xmlns로 시작되는 어떤 속성은 결과적으로 트리플{p,r,v}을 작성하게 된다. 여기서:

  1. p는 A의 이름공간-한정된 속성명을 확장한 것이다. 이 확장은 한정된 이름의 LocalPart와 함께 이름공간선언에 제시된 이름공간명을 연결하여 작성되며, 그리고 나서 이 URI를 [URI]의 5.2장 절대형식에 대한 상관참조분석 알고리즘에 따라 분해한다.
  2. r은 식별기호가 about 속성 값으로 제시된 자원으로서, 위에서 명시한 방식에 따라 분해하거나, 혹은 Description의 ID 속성 값으로 anchor id가 제시되거나, 혹은 aboutEach나 aboutEachPrefix 속성으로 명시된 집합의 성원이다.
  3. v는 A(리터럴)의 속성 값이다.

문법적으로 보면, production[6.11]은 단지 propName production [6.10]의 특수한 사례에 불과하다. type 속성의 값은 URI-참조로 해석되고, 자원 속성 값과 동일한 방식으로 확장된다. [6.11]를 사용하는 것은 자원 속성과 요소(property)명을 함께 한 rdf:type을 사용하는 것과 동일하다.

typedNode 형식(production [6.13])을 사용하여 특정 유형의 자원 사례를 표현할 수 있으며 이들 자원을 더 전개할 수 있다. typedNode에서 production[6.13]에 의해 표현된 Description은 동일한 ID와 bagID, 그리고 about 속성과 여기에 그 Description에 있는 부차적 type 특성이 부가되어 production [6.3]으로 표현된 Description과 대등하다. 이 Description에서 type 특성의 값은 typedNode의 typeName에 대응되는 완전히 확장되고 분해된 URI로 제시된 식별기호를 가진 자원이다. 특히 typedNode는 트리플{RDF:type,n,t}을 표현하는데, 여기서 n은 about 속성 값(분해 후)으로 제시된 식별기호를 가진 자원이거나, 혹은 typedNode 요소의 ID 속성 값으로 제시된 anchor id를 가진 자원이며, t는 이름공간-한정된 태그명을 확장한 것이다. typedNode 속성과 컨텐츠의 나머지는 위의 Description 요소에서와 같이 취급된다.

productions [6.10]과 [6.12]에 의해 공백 XML 요소 E 내에서 XML 속성 형식으로 표현된 특성과 값은 E의 컨텐츠가 되는 단일 Description 요소 D의 XML 컨텐츠로 명시된 동일한 특성과 값과 등가이다. D의 지시대상은 production [6.17], [6.2], [6.3]에 따라 E의 XML 요소명으로 식별된 특성 값이다. 특히 ID, 자원, bagID, xml:lang 이외의 속성 명세를 포함하고 있는 각 propertyElt 시작태그나, xmlns 문자로 시작하는 속성은 결과적으로 트리플 {p,r1,r2}, {pa1,r2,va1}, ..., {pan,r2,van}을 작성하게 된다. 여기서

  1. p는 이름공간-한정된 태그명의 확장이다.
  2. r1은 이 propertyElt식을 포함한 요소에 의해 지시되는 자원이다.
  3. r2는 자원속성이 제시된 경우 이 자원속성에 의해 명명된 자원이거나 새로운 자원이다. 만약 ID 속성이 제시된 경우, 이것이 이 새로운 자원의 식별기호이다.
  4. pa1 ... pan은 이름공간-한정된 속성명의 확장이다.
  5. va1 ... van은 대응되는 속성 값이다.

만약 bagID 속성 값이 명시된 경우라면, 이것은 Description D에 대응되는 Bag에 대한 식별기호이다. 그 밖의 경우 Bag은 무명이다.

7. 예

다음 예는 위에서 설명한 RDF의 특징을 다시 예시한 것이다.

7.1. 공유값

단일 자원은 복수의 특성 값이 될 수 있다. 즉 단일 자원이 복수의 문의 대상일 수 있고, 따라서 복수의 아크로 지시될 수 있다. 예컨대 하나의 웹 페이지가 여러 문서 간에 공유될 수 있고, 따라서 "sitemap"에서 복수로 참조될 수 있다. 혹은 동일 자원이 두 개의 상이한(체계상) 순서로 제시될 수 있다.

일단 발행년으로 배열되고 이를 다시 주제의 자모순으로 저장된 한 저자의 전집을 명시하는 경우를 예상해 보자:

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> 
  <Seq ID="JSPapersByDate"> 
    <li resource="http://www.dogworld.com/Aug96.doc"/> 
    <li resource="http://www.webnuts.net/Jan97.html"/> 
    <li resource="http://www.carchat.com/Sept97.html"/> 
  </Seq>
  <Seq ID="JSPapersBySubj"> 
    <li resource="http://www.carchat.com/Sept97.html"/> 
    <li resource="http://www.dogworld.com/Aug96.doc"/> 
    <li resource="http://www.webnuts.net/Jan97.html"/> 
  </Seq> 
</RDF>

이 XML 예도 이름공간 접두사를 생략하기 위해 디폴트 이름공간 선언구문을 사용하고 있다.

##########13*D

그림 13: 두 가지 순서간의 공유값

7.2. 통합

통합을 구체적으로 예시하기 위해, 두 명의 저자를 자모순으로 명시한 문서를 예로 보자. 표제는 웹 상의 대등한 위치에 상이한 두 가지 언어로 명시되어 있다: 

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/metadata/dublin_core#"> 
  <rdf:Description about="http://www.foo.com/cool.html"> 
    <dc:Creator>
      <rdf:Seq ID="CreatorsAlphabeticalBySurname">
	<rdf:li>Mary Andrew</rdf:li>
	<rdf:li>Jacky Crystal</rdf:li>
      </rdf:Seq>
    </dc:Creator>

    <dc:Identifier>
      <rdf:Bag ID="MirroredSites"> 
	<rdf:li rdf:resource="http://www.foo.com.au/cool.html"/>
	<rdf:li rdf:resource="http://www.foo.com.it/cool.html"/>
      </rdf:Bag>
    </dc:Identifier>

    <dc:Title>
      <rdf:Alt>
	<rdf:li xml:lang="en">The Coolest Web Page</rdf:li>
	<rdf:li xml:lang="it">Il Pagio di Web Fuba</rdf:li>
      </rdf:Alt>
    </dc:Title>
  </rdf:Description> 
</rdf:RDF>

이 예는 모두 세 가지 유형의 전집을 사용하였음을 보여주고 있다. 저자의 순서는 중요하게 취급되어, 이를 표현하기 위해 Sequence 용기가 사용되었다. 웹 상의 위치는 대등하고, 순서는 중요하지 않기 때문에 Bag을 사용하였다. 이 문서는 하나의 표제만을 가지고 있고 이 표제는 두 개의 상이한 언어로 제시되어 있어, Alternatives 용기를 사용하였다.

주의: 대개의 경우, 선택 가능한 다양한 언어 중에서 우선하는 언어를 선정하는 것은 어렵다. 모든 언어는 엄밀히 말해서 대등한 것으로 취급된다. 이 경우 기술하는 사람은 Alt 용기 대신 Bag을 사용해야 한다.

7.3. 비-이진관계

RDF 데이터 모델은 기본적으로 이진관계만을 지원한다. 즉 문은 두 자원간의 관계를 명시한다. 다음 예에서 단지 이진관계를 사용하여 RDF에서 상위 arity 관계를 표현하기 위한 권장방법을 제시하고 있다. 권장방법은 이 자원의 추가 특성이 나머지 관계를 제시하고 있는 상황에서 중간 자원을 사용하는 것이다. 예컨대 John Smith의 최신 논문 중 문헌정보학이라는 주제를 생각해 보자. 이 논문을 범주화하기 위해 문헌정보학에 대해 듀이십진분류기호를 사용할 수 있다. 듀이십진기호는 단일 주제 범주표와는 거리가 있기 때문에 분류체계관계를 유지하기 위해서는 주제 특성 값으로 사용된 추가 자원을 식별하고, 사용된 범주표를 식별하는 추가 특성으로 이 자원을 해석한다. 2.3장에서 명시한 바와 같이 RDF 핵심은 주된 관계의 중요한 값을 표현하기 위해 값 특성을 포함한다. 그 결과 다음과 같은 그림을 얻을 수 있을 것이다:

##########14* D

그림 14: 3개의 관계

이를 다음과 같이 변환할 수 있다:

<RDF
  xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/metadata/dublin_core#"
  xmlns:l="http://mycorp.com/schemas/my-schema#">
  <Description about="http://www.webnuts.net/Jan97.html"> 
    <dc:Subject
      rdf:value="020 - Library Science"
      l:Classification="Dewey Decimal Code"/>
  </Description>
</RDF>
주의: 위의 예에서 두 개의 이름공간선언이 동일한 이름공간에 존재하고 있다. 이것은 디폴트 이름공간이 선언될 때 흔히 필요한 것으로, 위의 dc:Subject 요소에 있는 rdf:value 속성을 가진 경우와 같이, 이를 통해 요소의 이름공간으로부터 오지 않는 속성을 명시할 수 있다.

이와 같은 상위 arity 능력을 공통으로 사용하는 것은 측정 단위를 취급할 때이다. 사람의 체중은 단순히 "200"이라고 할 수 없고, 여기에 사용한 측정단위도 포함된다. 이 경우 파운드나 킬로미터 중 하나를 사용할 수 있다. John Smith가 단순히 키가 큰 신사라는 것 이상의 사실을 기록하기 위해서는 arc를 추가하여 관계를 사용할 수 있다.

##########15* D

그림 15: 3가지 관계로서의 측정단위

이것을 다음과 같이 변환할 수 있다:

<RDF
  xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:n="http://www.nist.gov/units/">
  <Description about="John_Smith">
    <n:weight rdf:parseType="Resource">
      <rdf:value>200</rdf:value>
      <n:units rdf:resource="http://www.nist.gov/units/Pounds"/>
    </n:weight>
  </Description>
</RDF>

"Pounds"라는 자원은 NIST 스키마와 http://www.nist.gov/units/Pounds라는 URI와 함께 정의된다.

7.4. 더블린코어 메타데이터

더블린코어 메타데이터는 도서관의 카드목록과 유사한 방식으로 전자자원의 탐색을 용이하도록 설계된 것이다. 이들 예는 더블린코어 Initiative에서 정의한 어휘를 사용하여 RDF에서 일련의 자원을 간단하게 기술한 예이다. 주의: 여기에 제시한 특정 더블린코어 RDF 어휘는 공인된 것이 아니다. 공식적인 것은 더블린코어 Initiative를 참조하기 바란다.

여기서는 더블린코어 특성을 사용하여 웹사이트의 홈페이지를 기술한 것이다: 

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/metadata/dublin_core#">
  <rdf:Description about="http://www.dlib.org">
    <dc:Title>D-Lib Program - Research in Digital Libraries</dc:Title>
    <dc:Description>The D-Lib program supports the community of people
     with research interests in digital libraries and electronic
     publishing.</dc:Description>
    <dc:Publisher>Corporation For National Research Initiatives</dc:Publisher>
    <dc:Date>1995-01-07</dc:Date>
    <dc:Subject>
      <rdf:Bag>
	<rdf:li>Research; statistical methods</rdf:li>
	<rdf:li>Education, research, related topics</rdf:li>
	<rdf:li>Library use Studies</rdf:li>
      </rdf:Bag>
    </dc:Subject>
    <dc:Type>World Wide Web Home Page</dc:Type>
    <dc:Format>text/html</dc:Format>
    <dc:Language>en</dc:Language>
  </rdf:Description>
</rdf:RDF>

두 번째 예는 간행된 학술지에 관한 것이다. 

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/metadata/dublin_core#"
  xmlns:dcq="http://purl.org/metadata/dublin_core_qualifiers#">
  <rdf:Description about="http://www.dlib.org/dlib/may98/05contents.html">
    <dc:Title>DLIB Magazine - The Magazine for Digital Library Research
      - May 1998</dc:Title>
    <dc:Description>D-LIB magazine is a monthly compilation of
     contributed stories, commentary, and briefings.</dc:Description>
    <dc:Contributor rdf:parseType="Resource">
      <dcq:AgentType
	rdf:resource="http://purl.org/metadata/dublin_core_qualifiers#Editor"/>
      <rdf:value>Amy Friedlander</rdf:value>
    </dc:Contributor>
    <dc:Publisher>Corporation for National Research Initiatives</dc:Publisher>
    <dc:Date>1998-01-05</dc:Date>
    <dc:Type>electronic journal</dc:Type>
    <dc:Subject>
      <rdf:Bag>
	<rdf:li>library use studies</rdf:li>
	<rdf:li>magazines and newspapers</rdf:li>
      </rdf:Bag>
    </dc:Subject>
    <dc:Format>text/html</dc:Format>
    <dc:Identifier>urn:issn:1082-9873</dc:Identifier>
    <dc:Relation rdf:parseType="Resource">
      <dcq:RelationType
	rdf:resource="http://purl.org/metadata/dublin_core_qualifiers#IsPartOf"/>
      <rdf:value resource="http://www.dlib.org"/>
    </dc:Relation>
  </rdf:Description>
</rdf:RDF>

세 번째 예는 앞의 예에서 참조된 학술지에 수록된 특정 논문에 관한 것이다. 

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/metadata/dublin_core#"
  xmlns:dcq="http://purl.org/metadata/dublin_core_qualifiers#">
  <rdf:Description about=
  "http://www.dlib.org/dlib/may98/miller/05miller.html">
    <dc:Title>An Introduction to the Resource Description Framework</dc:Title>
    <dc:Creator>Eric J. Miller</dc:Creator>
    <dc:Description>The Resource Description Framework (RDF) is an
     infrastructure that enables the encoding, exchange and reuse of
     structured metadata. rdf is an application of xml that imposes needed
     structural constraints to provide unambiguous methods of expressing
     semantics. rdf additionally provides a means for publishing both
     human-readable and machine-processable vocabularies designed to
     encourage the reuse and extension of metadata semantics among
     disparate information communities. the structural constraints rdf
     imposes to support the consistent encoding and exchange of
     standardized metadata provides for the interchangeability of separate
     packages of metadata defined by different resource description
     communities. </dc:Description>
    <dc:Publisher>Corporation for National Research Initiatives</dc:Publisher>
    <dc:Subject>
      <rdf:Bag>
	<rdf:li>machine-readable catalog record formats</rdf:li>
	<rdf:li>applications of computer file organization and
	 access methods</rdf:li>
      </rdf:Bag>
    </dc:Subject>
    <dc:Rights>Copyright @ 1998 Eric Miller</dc:Rights>
    <dc:Type>Electronic Document</dc:Type>
    <dc:Format>text/html</dc:Format>
    <dc:Language>en</dc:Language>
    <dc:Relation rdf:parseType="Resource">
      <dcq:RelationType
	rdf:resource="http://purl.org/metadata/dublin_core_qualifiers#IsPartOf"/>
      <rdf:value resource="http://www.dlib.org/dlib/may98/05contents.html"/>
    </dc:Relation>
  </rdf:Description>
</rdf:RDF>
주의: 스키마 개발자는 XML 이름공간으로 한정된 이름 약어에 대응되는 구문을 사용하기 위해 특정 특성 값을 선언할 수 있다. 이 한정된 이름을 특성 값 내부에 사용하지 않도록 충고하는 바이다. 한정된 이름을 사용하게 되면 장차 XML 데이터 입력 기법과 호환되지 않을 수 있다. 더욱이 XML 1.0의 특징을 완전히 정통한 사람이라면 이와 유사한 약어기법이 이용자 정의 개체에도 존재하고 있다는 것을 인정하게 될 것이다. 아울러 이용자 정의 개체를 포함하지 않는 미래의 XML 하위세트를 정의하기 위한 제안이 이루어지고 있기 때문에 개체의 용법에 의존하지 않기를 권고한다.

7.5. 마크업을 포함한 값

특성 값이 XML 마크업을 포함한 리터털일 때, 다음 구문을 사용하여 RDF 해석기가 마크업을 해석하지 않고 단지 그 값의 일부로 유지하도록 신호를 보내는데 사용될 수 있다. 그 결과의 값에 대한 상세한 표현은 여기에 제시하지 않았다.

다음 예에서 Title 특성의 값은 어떤 MATHML 마크업을 포함한 리터럴이다. 

<rdf:Description
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/metadata/dublin_core#"
  xmlns="http://www.w3.org/TR/REC-mathml"
  rdf:about="http://mycorp.com/papers/NobelPaper1">

  <dc:Title rdf:parseType="Literal">
    Ramifications of
       <apply>
      <power/>
      <apply>
	<plus/>
	<ci>a</ci>
	<ci>b</ci>
      </apply>
      <cn>2</cn>
    </apply>
    to World Peace
  </dc:Title>
  <dc:Creator>David Hume</dc:Creator>
</rdf:Description>

7.6. PICS 레이블

Platform for Internet Content Selection(PICS)은 웹 페이지와 기타 자료의 내용에 관한 기술을 교환하기 위해 W3C에서 권고하는 사항이다. PICS는 RDF의 전신으로서, PICS 레이블로 표현될 수 있는 어떤 것도 표현할 수 있는 RDF의 분명한 전제조건이다.

이것은 PICS 레이블을 RDF 형식으로 표현하는 방법에 관한 예이다. PICS 자체를 RDF의 어플리케이션으로 다시 명시하는 일은 RDF 명세서를 완성한 다음 후속될 수 있다. 따라서 다음 예는 장차 PICS 스키마에서 사용할 공인된 예로 취급되어서는 안된다. 이 예는 직접 [PICS]로부터 취한 것이다. PICS 평가서비스기술은 RDF 스키마와 정확히 유사하다는 점에 유의할 필요가 있다. 이 평가서비스기술파일에 기술된 범주는 RDF 모델의 특성과 대등하다. 

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:pics="http://www.w3.org/TR/xxxx/WD-PICS-labels#"
  xmlns:gcf="http://www.gcf.org/v2.5">
  <rdf:Description about="http://www.w3.org/PICS/Overview.html" bagID="L01"
    gcf:suds="0.5"
    gcf:density="0"
    gcf:color.hue="1"/>

  <rdf:Description about="http://www.w3.org/PICS/Underview.html" bagID="L02"
    gcf:subject="2"
    gcf:density="1"
    gcf:color.hue="1"/>

  <rdf:Description aboutEach="#L01"
    pics:by="John Doe"
    pics:on="1994.11.05T08:15-0500"
    pics:until="1995.12.31T23:59-0000"/>

  <rdf:Description aboutEach="#L02"
    pics:by="Jane Doe"
    pics:on="1994.11.05T08:15-0500"
    pics:until="1995.12.31T23:59-0000"/>
</rdf:RDF>

PICS 레이블 옵션은 개개의(평가) 문을 지시하며, 그러한 문이 공급되는 용기를 지시하는 것이 아니라는 사실을 지시하기 위해 aboutEach를 사용하고 있음을 유의할 필요가 있다.

[PICS]는 동시에 일반 레이블이라고 하는 type을 정의하고 있다. PICS의 일반 레이블은 웹사이트의 특정 부분에 포함된 각 페이지에 적용되는 레이블이다.

다음은 aboutEachPrefix 콜랙션 구축기를 사용하여, PICS 일반 레이블을 RDF로 작성하는 방법에 관한 예이다. 이 예는 [PICS]의 부록 B에 있는 "일반 질문" 예에서 취한 것이다: 

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:pics="http://www.w3.org/TR/xxxx/WD-PICS-labels#"
  xmlns:ages="http://www.ages.org/our-service/v1.0/">
  <rdf:Description aboutEachPrefix="http://www.w3.org/WWW/" bagID="L03"
    ages:age="11"/>

  <rdf:Description aboutEach="#L03"
    pics:by="abaird@w3.org"/>
</rdf:RDF>

값 "11"을 가진 특성 age는 "http://www.w3.org/WWW/"라는 용어열로 시작하는 URI를 가진 모든 자원에 출현한다. 이러한 문("[I]의 나이는 11") 각각에 대응되는 구체화된 문에서는 "abaird@w3.org"이 이 문의 작성 책임을 지고 있다는 것을 알리는 특성을 가지고 있다.

7.7. HTML 내에서 RDF에 대한 컨텐츠 숨기기

이용자 agent가 HTML recommendations for error handling in invalid documents에 따를 때, 체계적인 XML로 된 RDF는 HTML 문서에 직접 포함하기에 적절하다. RDF 단편이 HTML 문서에 통합될 때, 일부 브라우저는 노출된 용어열 내용을 제시하게 된다. 노출된 용어열 내용은 하나의 태그를 종료시키는 ">"와 다음 태그의 시작인 "<" 사이에 오는 모든 것이 해당된다. 일반적으로 행의 끝을 표현한 문자를 포함해서 복수의 연속적인 여백 문자가 단일 공간으로 제시된다.

흔히 RDF 축약 구문을 사용하여 XML 속성 형식에 있는 용어열인 특성 값을 기록하게 되며, 노출된 내용으로 단지 공백을 남기게 된다. 예컨대 7.4장의 더블린코어 예의 첫 번째 부분은 다음과 같이 기술될 수 있다: 

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/metadata/dublin_core#">
  <rdf:Description about="http://www.dlib.org"
    dc:Title="D-Lib Program - Research in Digital Libraries"
    dc:Description="The D-Lib program supports the community of people
     with research interests in digital libraries and electronic
     publishing."
    dc:Publisher="Corporation For National Research Initiatives"
    dc:Date="1995-01-07"/>
</rdf:RDF>

노출된 내용을 피하기 위해 재작성하는 것은 아주 일반적인 경우에 적절하다. 한가지 일반적이지만 불분명한 경우는 용기의 기술이다. 7.2장의 예의 첫 부분을 보자: 

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/metadata/dublin_core#"> 
  <rdf:Description about="http://www.foo.com/cool.html"> 
    <dc:Creator>
      <rdf:Seq ID="CreatorsAlphabeticalBySurname">
	<rdf:li>Mary Andrew</rdf:li>
	<rdf:li>Jacky Crystal</rdf:li>
      </rdf:Seq>
    </dc:Creator>
  </rdf:Description> 
</rdf:RDF>

이 내용을 노출되지 않은 내용으로 재작성하기 위해서 다음 형식을 사용한다: 

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/metadata/dublin_core#"> 
  <rdf:Description about="http://www.foo.com/cool.html"> 
    <dc:Creator>
      <rdf:Seq ID="CreatorsAlphabeticalBySurname"
	rdf:_1="Mary Andrew"
	rdf:_2="Jacky Crystal"/>
    </dc:Creator>
  </rdf:Description> 
</rdf:RDF>

여기서 li 요소는 XML 규칙에 따라 속성으로 사용될 수 없음을 유의할 필요가 있다. 이 규칙에서는 하나의 태그에 동일한 속성명이 복수로 출현하는 것을 금지하고 있다. 따라서 분명한 RDF Ord 성질을 사용하며, 실제로는 수작업으로 li 요소를 확장하게 된다.

그 자신을 기술하고 있는 RDF 메타데이터를 포함한 완전한 HTML 문서는 다음과 같다: 

<html>
<head>
  <rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/metadata/dublin_core#"> 
    <rdf:Description about=""> 
      <dc:Creator>
	<rdf:Seq ID="CreatorsAlphabeticalBySurname"
	  rdf:_1="Mary Andrew"
	  rdf:_2="Jacky Crystal"/>
      </dc:Creator>
    </rdf:Description> 
  </rdf:RDF>
</head>
<body>
<P>This is a fine document.</P>
</body>
</html>

위의 HTML 문서는 HTML 3.2를 따르고 있는 모든 브라우저에 수용되어야 하며, 그 다음에 단지 "이것은 훌륭한 문서이다"라는 문자만을 제공해야 한다.

8. 감사의 말

이 명세서는 W3C RDF 모델과 구문 작업단에서 제작된 것이다. 이 작업단은 무엇보다도 Online Computer Library Center의 Eric Miller와 IBM의 Bob Schloss의 지도로 진행되었다. 이 작업단을 괘도에 올려 지속적으로 활동할 수 있도록 애쓴 Eric과 Bob 두 분의 부단한 노력에 대해 감사드린다. 특히 이러한 노력에서 이들과 우리를 지원해 준 OCLC, IBM, Nokia에 감사드린다.

이 명세서를 설계하고, 제안을 검토하고, 조언하고, 여러 초안을 수정해서, 최종적으로 합의에 도달할 수 있도록 지원해 주신 실무진 여러분은 다음과 같다: Ron Daniel (DATAFUSION), Renato Iannella (DSTC), Tsuyoshi SAKATA (DVL), Murray Maloney (Grif), Bob Schloss (IBM), Naohiko URAMOTO (IBM), Bill Roberts (KnowledgeCite), Arthur van Hoff (Marimba), Charles Frankston (Microsoft), Andrew Layman (Microsoft), Chris McConnell (Microsoft), Jean Paoli (Microsoft), R.V. Guha (Netscape), Ora Lassila (Nokia), Ralph LeVan (OCLC), Eric Miller (OCLC), Charles Wicksteed (Reuters), Misha Wolf (Reuters), Wei Song (SISU), Lauren Wood (SoftQuad), Tim Bray (Textuality), Paul Resnick (University of Michigan), Tim Berners-Lee (W3C), Dan Connolly (W3C), Jim Miller (W3C, emeritus), Ralph Swick (W3C). Dan Brickley (UK Bristol) joined the RDF Schema activity and brought us lots of sage advice in the final stages of this work. Martin Dürst (W3C) reviewed several working drafts and made a number of suggestions for improvement on behalf of the W3C Internationalization Working Group. Janne Saarela (W3C) performed a priceless service by creating a 'clean room' implementation from our working drafts.

이 문서는 이 실무단의 공동사업이다. 편자들은 이 명세서를 작성하고 마무리할 수 있도록 지원해 주신 실무단에 깊이 감사드린다.

부록 A: 용어해설

다음은 다양한 수준의 직관적 의미와 정확한 의미로 이 명세서에 사용된 용어이다. 여기에 제시한 요약 정의는 안내서용으로만 제시된 것으로 규범적인 것은 아니다. 필요하다면 정확한 정의를 제시하고 있는 문서의 소재도 함께 제시하고 있다.

Arc(아크)
특성을 그래프 형식으로 표현한 것으로, 특히 방향 그래프에서 간선.
Attribute(속성)
대상의 특성. 6장에서 이 용어는 특정한 XML 구문 개념을 지시하며, XML 태그의 name="value" 부분.
Element(요소)
이 명세서에서 사용된 바와 같이, 이 용어는 특정한 XML 구문 개념을 지시한다. 즉 대응되는 XML 시작태그와 종료태그 사이의 재료.
Literal(리터럴)
RDF로 표현된 가장 원시적인 값 유형으로서, 일반적으로 문자열이다. 리터럴의 내용은 RDF 자체에서 해석되지 않으며, 그리고 부차적인 XML 마크업을 포함할 수 있다. RDF 모델에서는 리터럴을 문의 주제로 인정하지 않고 있다는 점에서 자원과 구분된다.
Node(노드)
그래프 형식으로 자원이나 리터럴을 표현한 것. 특히 방향 그래프에서 정점.
Property(특성)
다른 자원을 기술하는데 사용되는 정의된 의미를 지닌 특정한 속성. 특정 자원에 대한 특성과 그 특성의 값이 그 자원에 관한 문이 된다. 특성은 이 특성으로 기술되는 자원의 유형과 함께 특성이 허용되는 특성 값을 정의할 수 있다.
Resource(자원)
사람이나 책과 같은 물리적 대상, 혹은 색깔이나 색깔을 가진 사물과 같은 개념적 대상을 표현하는 추상적 대상. 웹 페이지는 대개 물리적 대상으로 취급되지만 물리적 대상과 개념적이거나 추상적인 대상간의 구분은 RDF에서 중요하지 않다. 자원은 큰 대상의 구성요소일 수도 있다. 예를 들면 자원은 특정한 사람의 왼쪽 팔이나 문서의 특정 문단을 표현할 수 있다. 이 명세서에 사용된 바와 같이, 자원이라는 용어는 만약 URI가 단편(앵커) id를 포함하지 않은 경우, 대상 전체를 지시하며, 혹은 그 단편이나 앵커 id로 명명된 특정한 하위단위를 지시한다.
Statement(문)
특정 자원, 특정 특성(속성)에 이름을 부여하는 특수한 문법을 따른 표현으로서, 해당 자원에 대한 해당 특성 값을 부여한다. 특히 여기에서 RDF 문은 이 문서에서 명시된 RDF/XML 문법을 사용한 문이다.
Triple(트리플)
특성과 자원식별기호, 특성 값의 순서로 구성되고, RDF에서 사용되는 문의 표현.

부록 B: RDF의 이동

Description은 다음 4가지 방법 중 하나로 기술되는 자원과 관련되어 있다.

  1. Description은 자원 속에 포함될 수 있다(즉 HTML에서 "embedded").
  2. Description은 자원 외부에 있을 수 있다. 그러나 자원을 복귀시키는 과정과 같이 동일한 검색과정에서 전송기법으로 제공될 수 있다(즉 HTTP GET이나 HEAD를 통한 "along-with").
  3. Description은 다른 자원을 포함하여(즉 HTTP GET"을 사용한 "service bureau") 자원과 독립적으로 검색될 수 있다.
  4. Description은 자원을 포함할 수 있다(즉 RDF 자체에서 "wrapped").

모든 자원이 모든 연결기법을 지원하지는 않고 있다. 특히 여러 종류의 자원은 내장을 지원하지 않고 있으며, 단지 특정 종류의 자원만이 내장될 수 있다.

RDF 스키마를 사람이나 기계가 이해할 수 있도록 기술하게 되면 스키마 URI를 참조하지 않고 내용을 통해 이 기술에 접근할 수 있다. 만약 기계가 스키마를 이해할 수 있다면 필요로 하는 스키마에 명명된 특성의 의미를 어플리케이션이 일부 학습할 수 있을 것이다. RDF 스키마의 논리와 구문은 별도의 문서에 기술되어 있다[RDFSchema].

RDF식을 HTML 문서에 내장하기 위해 권고된 기법은 예 7.7에서와 같이 단지 RDF 인라인을 삽입하는 것이다. 이렇게 하게 되면, 결과로 생기는 문서가 HTML 4.0까지를 포함하고 있는 HTML 명세서와 호환성이 없게 된다. 그러나 W3C에서는 HTML 명세서가 이를 지원할 수 있도록 전개되리라 기대하고 있다. HTML 4.0을 포함해서, HTML 명세서와 호환성을 가지는 브라우저와 관련하여 이 기법을 적용하였을 때 두 가지 실질적인 문제가 있을 수 있다. 이 경우 대안은 저자를 통해 입수할 수 있다. [XMLinHTML]을 참고하기 바란다. 여러 다양한 환경에서 적절한 대안을 선택하는 것은 저자에게 달려 있다.

  1. 일부 HTML 2.0 브라우저는 <HEAD>에 있는 첫 번째 RDF 요소 바로 앞에 </HEAD> 태그를 상정하고 있다.

    아주 오래된 브라우저에 관심을 가진 저자는 모든 RDF식을 문서 head의 말미에 둘 수 있다.

  2. HTML 4.0을 포함하여 모든 명세서와 호환되는 모든 HTML 브라우저는 XML 요소(즉 production [6.12])로 표현된 RDF 특성 값에 있는 어떤 내용도 제시할 수 있다.

    RDF 내용을 낡은 브라우저에 제시하는 것을 방지하고자 하는 저자는 특성 값을 속성으로 이동하기 위해 축약구문(propAttr form)을 사용할 수 있다. 모든 특성이 이 방식으로 표현될 수는 없다.

위에 제시한 여러 대안 중 어느 것도 저자가 원하는 능력을 제공하지 못하는 경우, RDF식을 HTML 문서 외부에 두고, HTML <LINK> 요소로 연결할 수 있다. 이러한 목적을 위해 권고되는 관계유형은 REL="meta"이다. 

  <LINK rel="meta" href="mydocMetadata.DC.RDF">

부록 C: 용법에 관한 주기

C.1. 특성명

RDF 연속구문과 축약구문에서는 코딩을 위해 XML을 사용한다. XML 요소와 속성은 대소문자의 차이를 구분하기 때문에 RDF 특성 명도 역시 대소문자의 차이를 구분한다. 이 명세서에서는 정당한 XML의 이름 이외에 특성 명을 위해 어떤 특정한 형식도 필요로 하지 않는다. 그 자체의 식별기호를 위해 RDF에서는 모든 특성 명을 "InterCap style" 규칙에 따라 적용해 왔다. 즉 특성 명의 첫 번째 문자와 그 단어의 나머지 문자는 소문자로 한다. 예컨대 subject와 같다. 특성 명이 단어의 합성 혹은 단어의 단편인 경우, 그 단어는 각 단어의 첫 번째 문자(첫 번째 단어 이외에)를 대문자로 하여 첫 번째 문자와 연결하고, 기타 부차적인 구두점은 사용하지 않는다. 예컨대 subClassOf과 같다.

C.2. 이름공간 URIs

RDF에서는 모든 특성에 대해 전역적으로 고유한 식별기호를 사용하도록 제안된 XML 이름공간 기법을 사용하고 있다. 게다가 이름공간명은 대응되는 RDF 스키마에 대한 식별기호의 역할을 한다. 이름공간명은 [URI]의 5.2장 절대형식에 대한 상관참조 변환에서 제시된 알고리즘에 따라 절대형식으로 변환된다. RDF 프로세서는 스키마 내용에 접근하기 위해 스키마 URI를 사용할 것을 기대하고 있다. 이 명세서는 그 URI에서 제공되는 내용에 관해서는 어떤 추가 조건도 부여하지 않으며, (만약 있다면) 더욱이 스키마의 단편이나 대치형식을 확보하기 위해 URI를 수정해서도 안된다.

부록 D: 참고문헌

[Dexter94]
F. Halasz and M. Schwarz. The Dexter Hypertext Reference Model. Communications of the ACM, 37(2):30--39, February 1994. Edited by K. Grønbæck and R. Trigg. http://www.acm.org/pubs/citations/journals/cacm/1994-37-2/p30-halasz/
[HTML]
HTML 4.0 Specification, Raggett, Le Hors, Jacobs eds, World Wide Web Consortium Recommendation; http://www.w3.org/TR/REC-html40
[ISO10646]
ISO/IEC 10646. The applicable version of this standard is defined in the XML specification [XML].
[NAMESPACES]
Namespaces in XML; Bray, Hollander, Layman eds, World Wide Web Consortium Recommendation; http://www.w3.org/TR/1999/REC-xml-names-19990114.
[PICS]
PICS Label Distribution Label Syntax and Communication Protocols, Version 1.1, W3C Recommendation 31-October-96; http://www.w3.org/TR/REC-PICS-labels.
[RDFSchema]
Resource Description Framework (RDF) Schemas; Brickley, Guha, Layman eds., World Wide Web Consortium Working Draft; http://www.w3.org/TR/1998/WD-rdf-schema
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels; S. Bradner, March 1997; RFC2119.
[Unicode]
The Unicode Standard. The applicable version of this standard is the version defined by the XML specification [XML].
[URI]
Uniform Resource Identifiers (URI): Generic Syntax; Berners-Lee, Fielding, Masinter, Internet Draft Standard August, 1998; RFC2396.
[XML]
Extensible Markup Language (XML) 1.0; World Wide Web Consortium Recommendation; http://www.w3.org/TR/REC-xml.
[XMLinHTML]
XML in HTML Meeting Report; Connolly, Wood eds.; World Wide Web Consortium Note; http://www.w3.org/TR/NOTE-xh.

부록 E: 수정사항

Proposed Recommendation이 발행된 이후 약간의 인쇄상의 변경이 있었다. 이전 버전에서 확인된 오류는 발행 시점에서 수정되었다. 아울러 6장 마지막 단락에 작지만 분명히 수정한 부분이 있다.

Ora Lassila <ora.lassila@research.nokia.com>
Ralph R. Swick <swick@w3.org>

개정내력:
1999년 2월 17일: W3C 권고사항으로 발간 준비
1999년 1월 5일: W3C Proposed Recommendation으로 발행
1998년 12월 16일: Proposed Recommendation으로 의도한 최종안
1998년 10월 30일: 최종 검토의견 수용, parseType추가, I18N 어순 조정
1998년 10월 8일: 최종 검토, 부록 E에 변경사항 이동, 최종 검토요구로 발간
1998년 10월 7일: 장차 교정을 위한 약간의 스키마 URI 공간 확보, rdf:value 추가
1998년 10월 2일: 주요한 재명명; 문, 술부, 주부, 객체
1998년 9월 4일: instanceOf -> type, higher-arity 관계모델 수정, 노드 식별기호 추가
1998년 8월 19일: Ord 특성 명에 '_' 추가
1998년 8월 12일: 새로운 XML 이름공간선언 구문 갱신. 7장에 내용 추가
1998년 7월 20일: 다수의 오식 수정. 3차 공개 초안
1998년 7월 15일: 평가의견 수용 및 오식 수정. 특성 명의 첫 글자를 소문자로 변경
1998년 6월 15일: 대부분 재작성, 재조직
1998년 2월 16일: 편집 수정, 두 번째 공개 배포 준비
1998년 2월 6일: 편집 수정, 일부 예 개정
1998년 1월 11일: 다수 요소의 재명명 및 삭제
1997년 11월 14일: 특히 단언에 관한 추가 정리
1997년 11월 3일: 2차 공개 배포 준비
1997년 10월 2일: 1차 공개안
1997년 10월 1일: 1차 공개 배포 준비
1997년 8월 1일: 실무단에 초고 제출

최근 개정일시: $Date: 1999/02/24 14:45:07 $

'온톨로지' 카테고리의 다른 글

[펌] 메타데이터 레지스트리  (0) 2010.07.12
[펌] topic map?  (0) 2010.07.12
[펌] RDF Research  (0) 2010.07.12
[펌] OWL  (0) 2010.07.12
[펌] [인포메이션 아키텍처 # Review] 9장. 시소러스, 통제 어휘집과 메타데이터  (0) 2010.07.12

관련글

티스토리툴바