RDF 1.2 개념 및 추상 데이터 모델

W3C 후보 권고안 스냅샷

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2026/CR-rdf12-concepts-20260407/
최신 게시 버전:
https://www.w3.org/TR/rdf12-concepts/
최신 편집자 초안:
https://w3c.github.io/rdf-concepts/spec/
이력:
https://www.w3.org/standards/history/rdf12-concepts/
커밋 이력
테스트 스위트:
https://w3c.github.io/rdf-tests/rdf/rdf12/
구현 보고서:
https://w3c.github.io/rdf-tests/rdf/rdf12/reports/
최신 권고안:
https://www.w3.org/TR/rdf11-concepts
편집자:
Gregg Kellogg (2025-09-06까지), 고인을 기리며
Olaf Hartig
Pierre-Antoine Champin
Andy Seaborne
이전 편집자:
Richard Cyganiak (RDF 1.1)
David Wood (RDF 1.1, 의장)
Markus Lanthaler (RDF 1.1)
Graham Klyne (RDF 1.0)
Jeremy J. Carroll (RDF 1.0)
Brian McBride (RDF 1.0, 의장)
피드백:
GitHub w3c/rdf-concepts (풀 리퀘스트, 새 이슈, 열린 이슈)
public-rdf-star-wg@w3.org 제목 줄 [rdf12-concepts] … 메시지 주제 … 사용 (아카이브)

Copyright © 2004-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

초록

Resource Description Framework (RDF)는 웹에서 정보를 표현하기 위한 프레임워크입니다. 이 문서는 모든 RDF 기반 언어와 명세를 연결하는 추상 데이터 모델을 정의합니다. 추상 데이터 모델에는 두 가지 핵심 데이터 구조가 있습니다:

RDF 1.1과 비교할 때, RDF 1.2는 한 RDF 트리플을 다른 트리플의 목적어 위치에서 트리플 항으로 사용할 수 있는 기능을 도입합니다. RDF 1.2는 또한 사용자 에이전트가 표시할 때 초기 텍스트 방향을 지정할 수 있도록 하는 기본 방향 구성요소를 포함하는 방향성이 있는 언어 태그 문자열을 도입합니다. 마지막으로, RDF 1.1에서 RDF 1.2로의 전환을 쉽게 하기 위해, 이 명세는 주어진 데이터 조각에서 사용되는 RDF의 버전을 명시적으로 전달하는 메커니즘을 도입합니다.

이 명세는 RDF 1.2의 핵심 개념과 용어를 도입한 다음, RDF 그래프 내 IRI의 데이터형 지정 및 프래그먼트 식별자 처리에 대해 논의합니다.

이 문서의 상태

이 섹션은 이 문서가 발행된 시점의 상태를 설명합니다. 현재 W3C 간행물 목록과 이 기술 보고서의 최신 개정판은 W3C 표준 및 초안 색인에서 확인할 수 있습니다.

이 문서는 RDF 1.2 문서 모음의 일부입니다. 이는 중심 RDF 1.2 명세이며 핵심 RDF 개념을 정의합니다. 이 문서를 기반으로 작성된 여러 RDF 1.2 명세의 테스트 스위트와 구현 보고서는 각 명세에서 참조된 대로 rdf-tests 저장소의 rdf-tests/rdf/rdf12 아래에서 사용할 수 있습니다.

RDF 1.2 Concepts(이 명세)는 추상 데이터 모델을 설명하며, 소프트웨어에서 직접 구현되는 것이 아니므로 독립적인 테스트 스위트를 갖지 않습니다. 대신, 이는 그 위에 구축되는 명세들에 의해 구현됩니다. 따라서 W3C 후보 권고안 단계를 벗어나기 위해, W3C RDF & SPARQL Working Group은 [RDF12-SEMANTICS] 및 구체적 구문에 대한 최소 하나의 명세(예: [RDF12-N-TRIPLES])가 W3C 후보 권고안 단계에 대한 자체 종료 기준을 충족할 것을 요구합니다.

RDF 1.2 Concepts는 [RDF11-CONCEPTS]에 대한 업데이트이며, 이는 다시 [RDF-CONCEPTS-20040210]에 대한 업데이트였습니다.

이 문서는 RDF & SPARQL Working Group에 의해 권고안 절차를 사용하여 후보 권고안 스냅샷으로 발행되었습니다.

후보 권고안으로 발행되었다고 해서 W3C와 그 회원들의 승인을 의미하지는 않습니다. 후보 권고안 스냅샷은 광범위한 검토를 받았으며, 구현 경험을 수집하려는 목적을 가지고, Working Group 구성원들로부터 구현에 대한 로열티 없는 라이선스 약속을 받은 상태입니다.

이 예정된 권고안에 대한 향후 업데이트에는 새 기능이 포함될 수 있습니다.

이 후보 권고안은 2026년 5월 5일보다 이른 시점에 권고안으로 진행될 것으로 예상되지 않습니다.

이 문서는 W3C 특허 정책에 따라 운영되는 그룹에 의해 작성되었습니다. W3C는 그룹의 산출물과 관련하여 이루어진 모든 특허 공개의 공개 목록을 유지합니다. 해당 페이지에는 특허를 공개하기 위한 지침도 포함되어 있습니다. 자신이 실제로 알고 있는 특허가 필수 청구항을 포함한다고 믿는 개인은 W3C 특허 정책의 섹션 6에 따라 해당 정보를 공개해야 합니다.

이 문서는 2025년 8월 18일 W3C Process Document의 적용을 받습니다.

1. 소개

이 섹션은 비규범적입니다.

Resource Description Framework(RDF)는 웹에서 정보를 표현하기 위한 프레임워크입니다.

이 문서는 모든 RDF 기반 언어와 명세를 연결하는 추상 데이터 모델을 정의하며, 여기에는 다음이 포함됩니다:

1.1 그래프 기반 추상 데이터 모델

추상 데이터 모델의 핵심 구조는 트리플의 집합이며, 각 트리플은 주어, 술어 및 목적어로 구성됩니다. 이러한 트리플의 집합을 RDF 그래프라고 합니다. RDF 그래프는 노드 및 방향성 호 다이어그램으로 시각화할 수 있으며, 여기서 각 트리플은 노드-호-노드 연결로 표현됩니다.

그림 1 두 개의 노드(Subject 및 Object)와 이를 연결하는 호(Predicate)가 있는 RDF 그래프.

RDF 그래프에 있을 수 있는 노드에는 네 종류가 있습니다: IRI, 리터럴, 빈 노드 및 트리플 항.

이 정의에 따르면, 하나의 항이 여러 트리플에 나타날 때 이들은 단순히 같은 항의 여러 출현입니다. 예를 들어, 두 개의 트리플을 포함하는 그래프에서(여기서는 일반적인 집합 및 튜플 표기법으로 표현하고, 추상 이름을 서로 다른 항으로 사용): 

{ (R1, P1, R3),
  (R2, P2, R3) }

항 R3는 두 번 사용된 동일한 하나의 항이며, 총 다섯 개의 항이 있습니다. 이는 2차원 그래프 다이어그램에서 더 쉽게 나타낼 수 있으며, 하나의 단일 노드는 레이블이 붙은 호를 사용하여 여러 다른 노드에서 또는 여러 다른 노드로 단순히 연결될 수 있습니다.

그림 2 세 개의 노드(R1, R2 및 R3)와 두 개의 호(P1 및 P2)가 있는 RDF 그래프이며, 각 호는 각각 R1 및 R2를 R3에 연결합니다.

이 추상 데이터 모델은 1.9 RDF 문서 및 구문에서 설명한 대로 동일한 구조를 보존하면서 다양한 방식으로 인코딩될 수 있습니다.

참고

1.2 리소스와 문장

모든 IRI 또는 리터럴은 세계 안의 어떤 것(“논의의 우주”)을 지시합니다. 이러한 것들을 리소스라고 합니다. 무엇이든 리소스가 될 수 있으며, 물리적 사물, 문서, 추상 개념, 숫자 및 문자열을 포함합니다. 이 용어는 RDF 1.2 Semantics [RDF12-SEMANTICS]에서 사용되는 “엔터티”와 동의어입니다. IRI가 지시하는 리소스는 그 지시 대상이라고 하며, 리터럴이 지시하는 리소스는 그 리터럴 값이라고 합니다. 리터럴은 문자열, 숫자, 날짜와 같은 가능한 값의 범위를 정의하는 데이터형을 가집니다. 특수한 종류의 리터럴 — 언어 태그 문자열 및 방향성이 있는 언어 태그 문자열 — 은 각각 자연어의 평문 문자열과 초기 텍스트 방향을 포함하는 자연어의 평문 문자열을 지시합니다.

RDF 트리플을 단언한다는 것은 술어가 나타내는 어떤 관계가 주어와 목적어가 지시하는 리소스 사이에 성립함을 말합니다 (아래에서 설명하듯이, 모든 트리플이 단언되는 것은 아닙니다). RDF 트리플에 대응하는 이 문장은 RDF 문장으로 알려져 있습니다. 술어 자체는 IRI이며 속성을 지시합니다. 즉, 이진 관계로 생각할 수 있는 리소스입니다. (두 개보다 많은 엔터티를 포함하는 관계는 RDF에서 간접적으로 표현될 수만 있습니다 [SWBP-N-ARYRELATIONS].)

IRI 및 리터럴과 달리, 빈 노드는 특정 리소스를 식별하지 않습니다. 빈 노드를 포함하는 문장은 주어진 관계를 가진 어떤 것이 존재함을 말하지만, 그것을 명시적으로 이름 붙이지는 않습니다.

1.3 IRI의 지시 대상

IRI가 지시하는 리소스는 그 지시 대상이라고도 합니다. XSD 데이터형을 식별하는 것처럼 특정한 의미를 가진 일부 IRI의 경우, 지시 대상은 이 명세에 의해 고정됩니다. 다른 모든 IRI에 대해서는, 주어진 IRI가 정확히 무엇을 지시하는지가 이 명세에 의해 정의되지 않습니다. 다른 명세가 IRI 지시 대상을 고정하거나, 어떤 IRI의 지시 대상이 될 수 있는 것에 다른 제약을 적용할 수 있습니다.

IRI의 지시 대상을 결정하기 위한 지침은 Architecture of the World Wide Web, Volume One [WEBARCH] 및 Cool URIs for the Semantic Web [COOLURIS] 같은 다른 문서에서 제공됩니다. 매우 간단하고 비형식적이며 부분적인 설명은 다음과 같습니다:

웹 아키텍처에서 IRI의 가장 중요한 특징은 그것들이 역참조될 수 있으며, 따라서 원격 서버와의 상호작용을 위한 시작점으로 기능할 수 있다는 점일 것입니다. 이 명세는 그러한 상호작용을 다루지 않습니다. 이는 상호작용 모델을 정의하지 않습니다. 이 명세는 IRI를 리소스를 설명하는 그래프 데이터 모델 내의 전역적으로 고유한 식별자로만 다룹니다. 그러나 이러한 상호작용은 Linked Data Design Issues [LINKED-DATA]의 개념에 중요하며, 이는 RDF 추상 구문과 구체적 RDF 구문을 사용합니다. 후자는 직렬화 형식이라고도 합니다.

1.4 RDF 어휘 및 네임스페이스 IRI

RDF 어휘는 RDF 그래프에서 사용하기 위한 IRI의 컬렉션입니다. 예를 들어, [RDF12-SCHEMA]에 문서화된 IRI들은 RDF Schema 어휘입니다. RDF Schema 자체도 추가 RDF 어휘를 정의하고 문서화하는 데 사용될 수 있습니다. 이러한 일부 어휘는 RDF 1.2 Primer [RDF12-PRIMER]에 언급되어 있습니다.

RDF 어휘의 IRI는 종종 네임스페이스 IRI라고 알려진 공통 부분 문자열로 시작합니다. 일부 네임스페이스 IRI는 관례상 네임스페이스 접두사라고 알려진 짧은 이름과 연결됩니다.

이 명세에서 사용되는 일부 네임스페이스 접두사와 IRI
네임스페이스 접두사 네임스페이스 IRI RDF 어휘
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# RDF 내장 어휘 [RDF12-SCHEMA]
rdfs http://www.w3.org/2000/01/rdf-schema# RDF Schema 어휘 [RDF12-SCHEMA]
xsd http://www.w3.org/2001/XMLSchema# RDF 호환 XSD 타입

일부 직렬화 형식에서는 임의의 네임스페이스 접두사를 일부 네임스페이스 IRI와 연결하고, 해당 네임스페이스 접두사를 사용하여 이러한 네임스페이스 IRI 중 하나로 시작하는 IRI를 축약함으로써 가독성을 향상시키는 것이 일반적입니다. 예를 들어, 위 표의 접두사 매핑을 기반으로, IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral은 rdf:XMLLiteral로 축약될 수 있습니다. 그러나 그러한 축약형은 IRI로 직접 처리되도록 의도된 것이 아니며, IRI가 예상되는 구문적 문맥에서 사용되어서는 안 됩니다. 또한 네임스페이스 IRI와 네임스페이스 접두사는 RDF 추상 데이터 모델의 형식적인 부분이 아닙니다. 그것들은 IRI를 축약하기 위한 구문적 편의에 불과합니다. 처리를 위해서는 각 네임스페이스 접두사를 해당 네임스페이스 IRI로 대체하여 실제 IRI를 재구성합니다.

“네임스페이스”라는 용어 자체는 RDF의 문맥에서 잘 정의된 의미를 갖지 않지만, 때때로 비형식적으로 “네임스페이스 IRI” 또는 “RDF 어휘”를 의미하는 데 사용됩니다.

1.5 트리플 항과 구체화

트리플 항은 다른 트리플 안에서 RDF 항으로 사용되는 RDF 트리플입니다. RDF 트리플이므로, 이는 명제를 지시합니다.

구체화 트리플은 술어가 rdf:reifies이고 목적어가 트리플 항인 트리플입니다. 그 트리플의 주어는 구체화자라고 하며, 다른 트리플의 주어 또는 목적어가 될 수 있습니다.

구체화자는 트리플 항의 명제와 관련된 다양한 것을 지시할 수 있습니다. 예를 들어 명제가 성립한다는 문장이나 믿음 등입니다. 추가 문장에서는 트리플 항이 아니라 구체화자가 사용될 것으로 예상됩니다. 이 섹션은 이러한 일반적인 사용법을 간략히 설명합니다. 더 많은 예시는 RDF 1.2 Primer [RDF12-PRIMER]를 참조하십시오.

예를 들어, 다음 다이어그램은 트리플 항의 구체화 트리플과, 주어로서 구체화자를 포함하는 트리플을 함께 나타냅니다. 후자는 이 구체화자를 :Bob이 제기한 주장으로 설명하며, 구체화된 트리플 항이 지시하는 명제가 성립한다고 말합니다. 다시 말해, :Bob은 :Alice의 성이 "Liddell"이라고 주장합니다.

그림 3 구체화자로부터 트리플 항(단언되지 않았으며 회색 점선 호로 표시됨)을 참조하는 구체화 트리플과, 이 구체화자를 설명하는 트리플을 포함하는 RDF 그래프.

이 예에서 트리플 항이 지시하는 명제(즉, :Alice의 성이 "Liddell"이라는 명제)는 참이라고 주장되지 않습니다. 그것은 트리플 항으로 사용된 트리플이 RDF 그래프에서 단언된 트리플이기도 한 경우에만 성립합니다. 그림에서처럼 단언되지 않은 트리플 항을 사용하면 단언되지 않은 문장에 대한 문장을 만들 수 있습니다. 예를 들어, :Alice의 성이 실제로 "Liddell"인지 확실하지 않은 경우입니다.

다음은 그림 3에 표시된 그래프의 변형입니다. 이는 단언된 트리플이 구체화 트리플의 트리플 항 목적어에 대응하는 그래프를 나타냅니다. 이 경우, 이 예시들에 표시된 것처럼 구체화자를 주어로 포함하는 트리플의 부분집합을 트리플 주석이라고 합니다.

그림 4 구체화 트리플의 트리플 항이 단언된 트리플에 대응하는 트리플 주석을 포함하는 RDF 그래프. 단언된 트리플 때문에 이 다이어그램은 명제를 사실로 나타내며, 이는 그 관계가 성립함을 의미합니다.

Turtle [RDF12-TURTLE] 같은 구체적 구문은 구체화 트리플과 트리플 주석을 더 간결하게 지정하기 위한 축약 표현을 제공할 수 있습니다.

마지막으로, 트리플 항에 나타나는 RDF 항은 지시가 그래프의 단언된 트리플에 나타날 때와 동일합니다. 예를 들어, 트리플 항의 :Alice 항과 단언된 트리플의 :Alice는 둘 다 동일한 리소스를 지시합니다. 이러한 이유로 트리플 항은 투명하다고 말합니다.

참고

이미 언급했듯이, 구체화자는 광범위한 사용 사례를 위해 제공됩니다: 어떤 명제가 참이라는 문장 또는 믿음, 그 명제가 참인 상황, 그 명제가 참이 되도록 만든 사건 등입니다. 이러한 다양성 때문에 rdf:reifies 속성의 의미는 의도적으로 일반적입니다.

같은 추상 명제와 관련된 여러 개의 서로 다른 구체화자가 있을 수 있습니다. 예를 들어 출처가 다른 문장이나, 특성이 다른 상황입니다. 하나의 구체화자가 여러 개의 서로 다른 명제를 구체화하는 데 사용될 수도 있으며, 예컨대 같은 상황이 서로 다른 명제에서 비롯될 수 있다는 사실을 표현할 수 있습니다.

구체화된 명제가 반드시 성립할 필요는 없기 때문에, 단언 여부와 관계없이 다른 문장과 모순되는 단언되지 않은 문장을 포함하여 어떤 종류의 문장에 대해서도 문장을 만들 수 있습니다.

1.6 RDF와 시간에 따른 변화

RDF 추상 데이터 모델은 무시간적입니다: RDF 그래프는 정보의 정적인 스냅샷입니다.

그러나 RDF 그래프는 적절한 어휘 항이 주어지면 사건 및 다른 엔터티의 시간적 측면에 대한 정보를 표현할 수 있습니다.

RDF 그래프는 수학적 집합으로 정의되므로, RDF 그래프에 트리플을 추가하거나 제거하면 다른 RDF 그래프가 됩니다.

우리는 비형식적으로 RDF 소스라는 용어를 사용하여 RDF 그래프의 지속적이지만 변경 가능한 소스 또는 컨테이너를 가리킵니다. RDF 소스는 시간이 지남에 따라 변경될 수 있는 상태를 가진다고 말할 수 있는 리소스입니다. 상태의 스냅샷은 RDF 그래프로 표현될 수 있습니다. 예를 들어, RDF를 포함하는 표현을 가진 모든 웹 문서는 RDF 소스로 간주될 수 있습니다. 모든 리소스와 마찬가지로 RDF 소스는 IRI로 이름 붙일 수 있으며 따라서 다른 RDF 그래프에서 설명될 수 있습니다.

직관적으로 말하면, 논의의 우주에서의 변화는 다음과 같은 방식으로 반영될 수 있습니다:

1.7 여러 RDF 그래프로 작업하기

RDF 그래프는 트리플의 집합이므로 쉽게 결합될 수 있으며, 여러 소스의 데이터를 사용하는 것을 지원합니다. 그럼에도 때로는 내용을 분리한 상태로 유지하면서 여러 RDF 그래프로 작업하는 것이 바람직합니다. RDF 데이터셋은 이 요구를 지원합니다.

RDF 데이터셋은 RDF 그래프의 컬렉션입니다. 이 그래프들 중 하나를 제외한 모든 그래프는 관련된 IRI 또는 빈 노드를 가집니다. 이들은 이름 있는 그래프라고 하며, IRI 또는 빈 노드는 그래프 이름이라고 합니다. 나머지 그래프는 관련된 IRI를 갖지 않으며, RDF 데이터셋의 기본 그래프라고 합니다.

RDF 데이터셋에는 많은 가능한 용도가 있습니다. 그중 하나는 여러 RDF 소스의 스냅샷을 보관하는 것입니다.

1.8 동등성, 함의 및 불일치

RDF 트리플은 두 엔터티 사이의 관계를 설명하는 단순한 논리 표현인 명제를 지시합니다. 단언된 트리플은 해당 명제가 참이라는 주장입니다. RDF 그래프는 그 단언된 트리플이 제기하는 모든 주장의 논리적 AND(합성곱)입니다. RDF 트리플 및 RDF 그래프의 이러한 의미에 대한 정확한 세부 사항은 RDF 1.2 Semantics [RDF12-SEMANTICS]의 주제이며, 이는 RDF 그래프 사이에 다음 관계를 산출합니다:

함의
RDF 그래프 A가 다른 RDF 그래프 B를 함의한다는 것은 A를 참으로 만드는 세계의 모든 가능한 배치가 B도 참으로 만든다는 뜻입니다. A가 B를 함의할 때, A의 참이 추정되거나 입증되면 B의 참이 확립됩니다.
동등성
두 RDF 그래프 A와 B는 세계에 대해 동일한 주장을 한다면 동등합니다. A가 B와 동등한 것은 A가 B를 함의하고 B가 A를 함의하는 경우에, 그리고 오직 그 경우에만 성립합니다.
불일치
RDF 그래프가 내부 모순을 포함하면 불일치합니다. 그 표현을 참으로 만들 수 있는 세계의 가능한 배치는 없습니다.

함의 체제 [RDF12-SEMANTICS]는 이러한 관계가 성립하게 하는 정확한 조건을 정의하는 명세입니다. RDF 자체는 함의, 동등성 및 불일치의 일부 기본 사례만 인식합니다. 다른 명세들, 예를 들어 RDF 1.2 Schema [RDF12-SCHEMA]와 OWL 2 [OWL2-OVERVIEW]는 더 강력한 함의 체제를 추가하며, 일부 도메인별 어휘도 마찬가지입니다.

이 명세는 구현이 함의 체제에 의해 정의된 논리적 관계를 어떻게 사용하는지 제한하지 않습니다. 구현은 불일치를 감지할 수도 있고 감지하지 않을 수도 있으며, 함의된 정보의 전부, 일부 또는 아무것도 사용자에게 제공하지 않을 수 있습니다.

1.9 RDF 문서 및 구문

RDF 문서는 RDF 그래프 또는 RDF 데이터셋을 구체적 RDF 구문으로 인코딩하는 문서입니다. 예를 들어 N-Triples [RDF12-N-TRIPLES], Turtle [RDF12-TURTLE], RDFa [RDFA-CORE], JSON-LD [JSON-LD11] 또는 TriG [RDF12-TRIG]와 같습니다. RDF 문서는 RDF 그래프와 RDF 데이터셋을 시스템 간에 교환할 수 있게 합니다.

구체적 RDF 구문은 같은 RDF 그래프 또는 RDF 데이터셋을 인코딩하는 다양한 방법을 제공할 수 있습니다. 예를 들어 네임스페이스 접두사, IRI 참조, 빈 노드 식별자, 및 트리플의 다른 순서 사용을 통해서입니다. 이러한 측면은 RDF 문서로 작업하는 편의성에 큰 영향을 줄 수 있지만, 그 의미에는 중요하지 않습니다.

구체적 RDF 구문의 기반은 추상 데이터 모델의 구조이며, 이를 추상 구문이라고 합니다. 다음 두 표에 요약되어 있습니다.

RDF 그래프의 추상 구문
생성 다음으로 정의됨
RDF 그래프 0개 이상의 트리플의 집합
트리플 주어, 술어, 그리고 목적어의 3-튜플
주어 IRI 또는 빈 노드
술어 IRI
목적어 IRI 또는 빈 노드 또는 리터럴 또는 트리플

RDF 데이터셋의 추상 구문
생성 다음으로 정의됨
RDF 데이터셋 기본 그래프와 0개 이상의 이름 있는 그래프의 집합으로 이루어진 쌍
기본 그래프 RDF 그래프
이름 있는 그래프 그래프 이름과 RDF 그래프의 쌍
그래프 이름 IRI 또는 빈 노드

1.10 RDF 버전 알림

RDF 파서가 지원되지 않는 RDF 버전에 대해 가능한 한 이른 시점에 오류를 내거나 경고할 수 있도록, RDF 직렬화 형식은 미디어 타입 매개변수, 형식별 구문 내 버전 알림, 또는 둘 모두를 통해 버전을 지정할 수 있도록 할 것으로 예상됩니다.

버전이 미디어 타입 매개변수와 구문 모두에 표시되는 경우, 둘은 동일할 것으로 예상됩니다. 서로 다르면, 파서는 미디어 타입 매개변수의 버전을 사용하고 불일치에 대한 경고를 낼 수 있습니다.

이전 파서와 가능한 한 폭넓은 호환성을 유지하기 위해, RDF 1.2 전용 기능을 사용하는 RDF 문서만 그 버전을 알리도록 권장됩니다(즉, RDF 1.2 전용 기능을 사용하지 않는 RDF 문서의 경우 버전 알림은 권장되지 않습니다).

Content-Type 헤더를 사용하여 HTTP 응답에서 버전을 알리려면, 서버는 다음 예시 응답에 표시된 것처럼 version 매개변수를 사용할 것으로 예상됩니다. 

HTTP/1.1 200 OK
Content-Type: text/turtle; version=1.2
Location: http://example.com/document.ttl

서버는 또한 형식이 인라인 버전 알림을 지원하는 경우 인라인으로 버전을 알릴 것으로 예상됩니다 (예: RDF 1.2 Turtle [RDF12-TURTLE]).

HTTP 서버에서 RDF 문서를 요청할 때, 클라이언트는 Accept 요청 헤더에 version 매개변수를 포함하여, 다음 예시 요청에 표시된 것처럼 콘텐츠 협상 [WEBARCH] 중에 이를 사용할 수 있습니다. 

GET /document.ttl HTTP/1.1
Host: example.com
Accept: text/turtle; version=1.2

섹션 2.1 버전 레이블은 version 매개변수 및 구체적 RDF 구문에서 사용할 버전 레이블을 정의합니다.

참고

HTTP 콘텐츠 협상은 권고적이므로, 문서를 받는 클라이언트는 요청된 미디어 타입의 문서이지만 요청한 것과 다른 version을 가질 수 있는 문서를 적절히 처리할 준비가 되어 있어야 합니다. 클라이언트는 2.1.1 서버 고려사항에서 논의한 것처럼 스스로 콘텐츠를 적절한 버전으로 다운그레이드하는 것을 고려할 수 있습니다.

2. 적합성

비규범으로 표시된 섹션뿐 아니라, 이 명세의 모든 저작 지침, 다이어그램, 예시 및 참고는 비규범적입니다. 이 명세의 그 밖의 모든 것은 규범적입니다.

이 문서에서 핵심 단어 MAY, MUST, MUST NOT, RECOMMENDED, SHOULD, 그리고 SHOULD NOT은 여기에 표시된 것처럼 모두 대문자로 나타나는 경우에, 그리고 오직 그 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 합니다.

이 명세인 RDF 1.2 Concepts and Abstract Data Model은 다른 명세에서 사용하기 위한 추상 데이터 모델 및 관련 어휘를 정의합니다. 예를 들어 구체적 RDF 구문, API 명세 및 질의 언어가 있습니다. 구현은 RDF 1.2 Concepts and Abstract Data Model에 직접 적합할 수는 없지만, 여기에서 정의된 용어를 규범적으로 참조하는 그러한 다른 명세에 적합할 수 있습니다.

이 명세는 두 가지 적합성 수준을 설정합니다:

2.1 버전 레이블

버전 레이블은 RDF 데이터에 대한 구문 및 의미론 적합성을 식별하는 문자열입니다.

버전 레이블
버전 레이블 구문 의미론
"1.2" RDF 1.2 구문 RDF 1.2 Semantics
"1.2-basic" 트리플 항이 없는 RDF 1.2 구문 RDF 1.2 Semantics
"1.1" 버전 지시문 사용을 제외한 RDF 1.1 구문 RDF 1.1 Semantics

버전 "1.1"에 적합한 데이터는 버전 "1.2-basic"의 데이터로서 유효하며, 버전 "1.2-basic"에 적합한 데이터는 버전 "1.2"의 데이터로서 유효합니다. 버전 "1.1"에 적합한 데이터는 RDF 1.1 Semantics 아래와 RDF 1.2 Semantics 아래에서 동일한 의미론을 가집니다.

"1.2"를 "1.2-basic"으로 인코딩하는 세부 사항은 RDF 1.2 Interoperability를 참조하십시오.

인라인 버전 알림을 지원하는 직렬화의 경우, 버전 알림은 문서의 이른 위치에서 이루어지는 것이 SHOULD이며, 확실히 해당 버전에 의존하는 어떤 기능을 직렬화하기 전에 이루어져야 합니다.

2.1.1 서버 고려사항

이 섹션은 비규범적입니다.

요청된 버전과 호환되지 않는 기능을 사용하는 그래프 또는 데이터셋을 직렬화할 때, 서버는 다음과 같은 여러 대안을 고려할 수 있습니다:

  1. RDF 1.2 Interoperability에서 정의한 기본 인코딩 같은 알고리즘을 사용하여 트리플 항을 제거합니다 (버전 "1.2"에서 "1.2-basic"으로 다운그레이드).
  2. 방향성이 있는 언어 태그 문자열을 [JSON-LD11]에 정의된 것처럼 i18n 네임스페이스를 사용하는 데이터형 IRI를 가진 리터럴로 대체합니다 (버전 "1.2" 또는 "1.2-basic"에서 "1.1"로 다운그레이드).
  3. 406 "Not Acceptable"을 반환합니다.
  4. 요청된 버전을 무시하고 네이티브 표현을 반환합니다.
참고

여기서의 제안은 견고성 원칙 (Postel의 법칙으로도 알려짐)을 따르는 것입니다: 서버는 자신이 보내는 것에는 보수적이고, 자신이 받아들이는 것에는 관대해야 합니다.

2.1.2 클라이언트 고려사항

이 섹션은 비규범적입니다.

문서에 (HTTP 헤더 또는 내부적으로) 명시된 version이 없으면, 시스템은 버전이 "1.2"라고 가정할 수 있으며, 이는 계속해서 모든 이전 RDF 버전을 지원합니다.

버전이 충돌하는 문서를 파싱할 때, 또는 지원되지 않는 버전을 사용하는 문서를 파싱할 때, 파서는 다음 중 어느 것이든 할 수 있습니다:

  • 버전 지시문을 무시합니다.
  • 오류를 발생시키고 중단합니다.
  • 경고를 발행하고 트리플을 무시합니다.
  • 구조를 파싱하고 선언된 버전과 일치하는 트리플만 방출합니다.

2.2 RDF의 문자열

RDF는 문자열 값의 기본 표현으로 Unicode [Unicode]를 사용합니다. 이 명세와 관련 명세에서 RDF 문자열이라는 용어, 또는 단순히 문자열이라는 용어는, 0개 이상의 Unicode 코드 포인트의 순서 있는 시퀀스를 설명하는 데 사용되며, 이들은 Unicode 스칼라 값입니다. Unicode 스칼라 값은 서로게이트 코드 포인트를 포함하지 않습니다. 대부분의 구체적 RDF 구문은 UTF-8 문자 인코딩 [RFC3629]의 사용을 요구하며, 특정 비문자 값을 표현하기 위해 \u0000 또는 \U00000000 형식을 사용한다는 점에 유의하십시오.

문자열은 동일한 코드 포인트 시퀀스로 구성되어 있으면 다른 문자열과 동일합니다. 구현은 같은 Unicode 문자 인코딩 (UTF-8 또는 UTF-16)을 사용하는 두 문자열의 코드 유닛을 비교하여, 문자열을 Unicode 코드 포인트 시퀀스로 디코딩하지 않고도 문자열 동일성을 결정할 수 MAY 있습니다.

3. RDF 그래프

RDF 그래프는 RDF 트리플의 집합입니다.

RDF 트리플이 RDF 그래프의 원소인 경우, 해당 RDF 그래프 안에서 단언된 것이라고도 합니다.

3.1 트리플

RDF 트리플 (종종 단순히 "트리플"이라고 함)은 다음과 같이 귀납적으로 정의되는 3-튜플입니다:

RDF 트리플의 세 구성요소(s, p, o)는 각각 트리플의 주어, 술어 및 목적어라고 합니다.

참고

트리플의 정의는 재귀적입니다. 즉, 트리플 자체가 또 다른 트리플인 목적어 구성요소를 가질 수 있습니다. 그러나 이 정의에 따르면 트리플의 순환은 생성될 수 없습니다.

RDF 그래프의 노드 집합은 그 그래프의 단언된 트리플의 주어와 목적어의 집합입니다. 술어 IRI가 같은 그래프에서 노드로도 나타날 수 있습니다.

트리플 동일성: 두 트리플 (s, p, o)와 (s', p', o')는 다음 세 조건이 모두 성립하는 경우에, 그리고 오직 그 경우에만 서로 동일합니다(같은 RDF 트리플입니다).

3.2 RDF 항

IRI, 리터럴, 빈 노드, 그리고 트리플 항은 통칭하여 RDF 항이라고 합니다.

IRI, 리터럴 및 빈 노드는 기본 RDF 항이라고 합니다.

RDF 항 동일성: 두 RDF 항 t와 t'는 다음 네 조건 중 하나가 성립하는 경우에, 그리고 오직 그 경우에만 동일합니다(같은 RDF 항입니다):

참고

RDF 트리플 t에 나타나는 RDF 항의 집합은 다음과 같이 귀납적으로 정의됩니다:

확장하여, RDF 항이 RDF 그래프 안의 단언된 트리플에 나타나면, 그 RDF 항은 그 RDF 그래프에 나타난다고 합니다. RDF 트리플은 그것이 그 그래프의 단언된 트리플이거나, 그 그래프에 나타나는 트리플 항인 경우 RDF 그래프에 나타난다고 합니다.

RDF 항은 다음 세 조건 중 하나가 성립하는 경우 ground라고 합니다:

확장하여, RDF 트리플은 그 주어, 술어, 그리고 목적어가 모두 ground이면 ground라고 합니다. RDF 그래프는 모든 단언된 트리플이 ground이면 ground라고 합니다.

3.3 IRI

RDF 그래프 안의 IRI (Internationalized Resource Identifier)는 RFC 3987 [RFC3987]에 정의된 구문을 따르는 문자열입니다.

RDF 추상 구문의 IRI는 [RFC3986]에 따라 해결되어야 MUST 하며, 상대 참조여서는 MUST NOT 안 됩니다. IRI는 프래그먼트 식별자를 포함할 수 MAY 있습니다. IRI는 IRI 스킴이 정의한 규칙을 따르는 것이 SHOULD 좋습니다.

IRI 동일성: 두 IRI는 [RFC3987]의 섹션 5.3.1의 단순 문자열 비교와 같이, 동일한 Unicode 코드 포인트 시퀀스로 구성되는 경우에, 그리고 오직 그 경우에만 동일합니다. (이는 추상 구문에서 수행되므로, IRI는 이스케이프나 인코딩이 없는 해결된 IRI입니다.) 이 비교 전에 추가 정규화를 수행해서는 MUST NOT 안 됩니다.

참고

편의를 위해, [ABNF] 문법 전체가 [RFC3987]로부터 F. IRI 문법에 제공되어 있습니다.

참고

URI와 IRI: IRI는 더 넓은 범위의 Unicode 문자 [UNICODE]를 허용하는 URI [RFC3986]의 일반화입니다. 모든 URI와 URL은 IRI이지만, 모든 IRI가 URI인 것은 아닙니다. RDF에서 IRI는 [RFC3987] 섹션 1.3에 정의된 IRI 참조로 사용됩니다. IRI 참조는 Internationalized Resource Identifier의 일반적인 사용 방식입니다. IRI 참조는 해결된 IRI 또는 상대 IRI 참조를 가리키며, 이는 F. IRI 문법의 IRI-reference 생성에서 설명됩니다. 추상 구문은 완전히 해결된 IRI만 사용합니다. IRI가 URI에 대해서만 정의된 연산에서 사용되는 경우, 먼저 [RFC3987]의 섹션 3.1에 정의된 매핑에 따라 변환되어야 합니다. 대표적인 예는 HTTP 프로토콜을 통한 검색입니다. 이 매핑은 비ASCII 문자의 UTF-8 인코딩, URI에서 허용되지 않는 옥텟의 %-인코딩, 그리고 도메인 이름의 Punycode 인코딩을 포함합니다.

URL: URL Standard는 [RFC3987] IRI와 대체로 호환되지만, 웹 브라우저 내 구현에 중요한 처리 모델을 기반으로 하며 [ABNF] 문법으로 설명되지 않습니다.

3.3.1 RDF 참조 IRI

이 섹션은 비규범적입니다.

이 섹션은 데이터 게시자에게 조언을 제공합니다.

IRI는 리소스를 지시하는 데 사용되며, 각 IRI는 그 IRI가 어디에서 사용되든 동일한 리소스를 식별해야 합니다. [RFC3987]에 정의된 IRI의 일반 구문은 전역 참조가 되어야 한다는 요구사항을 충족하지 않는 IRI도 표현할 수 있음에 유의하십시오. 일부 URI 스킴은 추가 요구사항을 부과합니다. 예를 들어, HTTP URI 스킴은 비어 있지 않은 호스트 이름의 존재를 요구하는 http-URI를 정의하며, 그 결과 path 구성요소는 /로 시작합니다. [RFC3987] 구문은 http:abcd와 http:///abcd 같은 IRI를 허용하지만, 이들은 HTTP URI 스킴 정의를 만족하지 않기 때문에 유효하지 않습니다.

RDF 참조 IRI는 때때로 단순히 RDF 참조라고도 하며, 전역 참조로 사용하기에 적합한 IRI입니다.

참조 해결: RDF 참조 IRI는 참조 해결에 의해 변경되지 않습니다. http 및 https 같은 URI 스킴에서 path 구성요소는 해결 알고리즘에 보이는 계층 구조의 일부입니다. 해결되면 path 구성요소는 / 문자로 시작하고 . 또는 .. 세그먼트를 포함하지 않습니다. 예를 들어, 임의의 기본 IRI에 대해 해결된 https://example/data는 https://example/data(변경 없음)인 반면, 임의의 기본 IRI에 대해 해결된 https://example/path/../data는 https://example.com/data입니다.

상대 IRI 참조: 일부 구체적 RDF 구문은 최종 게시 위치를 알지 못한 상태에서 RDF 문서를 작성할 수 있게 하는 편리한 축약형으로 상대 IRI 참조 (IRI 문법의 irelative-ref 생성을 참조)를 허용합니다. 상대 IRI 참조는 기본 IRI에 대해 해결되어야 합니다. 따라서 그러한 구문으로 직렬화된 RDF 그래프는 기본 IRI를 설정할 수 있는 경우 [RFC3986]에만 잘 정의됩니다.

URI 스킴: 구현은 HTTP/HTTPS의 스킴 규칙 및 DID 구문과 같은 일반적인 스킴의 스킴별 규칙을 따르는 것이 권장됩니다. 구현은 인식하지 못하는 스킴에 대한 URI 스킴 규칙을 무시합니다.

IRI 정규화: [RFC3987]의 섹션 5에 따라 정규화된 IRI만 생성하면 상호운용성 문제를 피할 수 있습니다.

  • 스킴 이름에는 소문자를 사용합니다.
  • IRI 구문에서 필요한 경우에만 문자의 percent-encoding을 사용합니다.
  • HTTP 또는 HTTPS 기본 포트는 생략합니다. http://example/이 http://example:80/보다 권장됩니다.
  • percent-encoding 트리플릿 안에는 대문자 16진수 문자를 사용합니다. "%3f"보다 "%3F"가 권장됩니다.
  • HTTP IRI의 빈 경로에서는 경로가 없는 http://example보다 http://example/이 권장됩니다.
  • IRI의 path 구성요소에서 "/./" 및 "/../"을 제거하도록 IRI를 정규화합니다.
  • 도메인 이름에는 소문자를 사용합니다. 도메인 이름의 ASCII 문자는 대소문자를 구분하지 않지만, 도메인 이름의 비ASCII 문자는 대소문자를 구분한다는 점에 유의하십시오 [RFC5890]. 도메인은 일반적으로 소문자로만 등록됩니다 [RFC5892].
  • Internationalized Domain Names [RFC5890]에 대해 A-label (ASCII, punycode로 인코딩된 이름])을 IRI에서 사용하는 것을 피합니다.
  • Unicode Normalization Form C [I18N-Glossary]의 IRI를 사용합니다.

3.4 리터럴

리터럴은 문자열, 숫자, 날짜와 같은 값에 사용됩니다.

리터럴은 아래와 같이 두 개, 세 개 또는 네 개의 구성요소로 이루어집니다:

  1. RDF 문자열인 어휘 형식.
  2. 어휘 형식이 리터럴 값으로 매핑되는 방식을 결정하는 데이터형을 식별하는 IRI인 데이터형 IRI.
  3. 데이터형 IRI가 http://www.w3.org/1999/02/22-rdf-syntax-ns#langString 또는 http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString인 경우에, 그리고 오직 그 경우에만, [BCP47]에 정의된 비어 있지 않은 언어 태그가 있습니다. 언어 태그는 [BCP47]의 섹션 2.2.9에 따라 올바른 형식이어야 MUST 하며, 그에 따라, 즉 대소문자를 구분하지 않는 방식으로 처리되어야 MUST 합니다. 대소문자만 다른 두 [BCP47] 준수 문자열은 동일한 언어 태그를 나타냅니다.
  4. 데이터형 IRI가 http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString인 경우에, 그리고 오직 그 경우에만, 다음 중 하나여야 MUST 하는 기본 방향이 있습니다:
    • ltr, 초기 텍스트 방향이 왼쪽에서 오른쪽으로 설정됨을 나타냅니다
    • rtl, 초기 텍스트 방향이 오른쪽에서 왼쪽으로 설정됨을 나타냅니다

리터럴은 언어 태그가 있고 기본 방향이 없는 경우 언어 태그 문자열입니다. 리터럴은 언어 태그와 기본 방향이 모두 있는 경우 방향성이 있는 언어 태그 문자열입니다.

리터럴 항 동일성: 두 리터럴은 다음이 모두 참인 경우에, 그리고 오직 그 경우에만 항으로서 동일합니다(같은 RDF 항입니다):

3.4.1 리터럴의 표현

일부 구체적 구문은 데이터형 IRI, 언어 태그, 또는 기본 방향 없이 어휘 형식만으로 구성된 단순 리터럴을 지원합니다. 단순 리터럴은 http://www.w3.org/2001/XMLSchema#string (일반적으로 xsd:string으로 축약됨) 데이터형 IRI를 가진 추상 구문 리터럴을 위한 구문 설탕입니다.

마찬가지로, 대부분의 구체적 구문은 언어 태그 문자열 및 방향성이 있는 언어 태그 문자열을 데이터형 IRI 없이 표현합니다. 이는 항상 각각 http://www.w3.org/1999/02/22-rdf-syntax-ns#langString (rdf:langString) 또는 http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString (rdf:dirLangString)이기 때문입니다.

[BCP47]를 준수하는 모든 문자열은 구체적 구문 또는 구현에서 언어 태그를 표현하는 데 사용될 수 MAY 있습니다. 그러한 문자열은 (예를 들어 BCP 47 섹션 4.5에 정의된 대로 표준화하여) 대소문자가 정규화될 수 MAY 있습니다. 또는 구현은 원래 표현의 대소문자를 보존할 수 MAY 있으며, 단 대소문자를 구분하지 않는 방식으로 처리해야 합니다.

참고

3.4.2 리터럴 값

리터럴과 관련된 리터럴 값은 다음과 같이 정의됩니다.

  • 리터럴이 언어 태그 문자열이면, 리터럴 값은 그 어휘 형식과 그 언어 태그로 이루어진 쌍이며, 그 순서도 동일합니다.
  • 리터럴이 방향성이 있는 언어 태그 문자열이면, 리터럴 값은 그 어휘 형식, 그 언어 태그, 그리고 그 기본 방향의 튜플이며, 역시 그 순서도 동일합니다.
  • 리터럴의 데이터형이 RDF 구현에 의해 처리되는 경우, 다음 중 하나가 적용됩니다:
    • 리터럴의 어휘 형식이 데이터형의 어휘 공간 안에 있으면, 리터럴 값은 데이터형의 어휘-값 매핑을 어휘 형식에 적용한 결과입니다.
    • 그렇지 않으면, 리터럴은 잘못된 타입이며, 어떤 리터럴 값도 그 리터럴과 연결될 수 없습니다. 그러한 경우는 의미론적 불일치를 생성하지만, 구문적으로 잘못 형성된 것은 아닙니다. 구현은 잘못된 타입의 리터럴을 받아들이고 RDF 그래프를 생성하는 것이 SHOULD 좋습니다. 구현은 잘못된 타입의 리터럴을 만나면 경고를 생성할 수 MAY 있습니다.
  • 리터럴의 데이터형 IRI가 RDF 구현에 의해 처리되지 않는 경우, 리터럴 값은 이 명세에 의해 정의되지 않습니다. 구현은 알 수 없는 데이터형 IRI를 가진 리터럴을 받아들이고 RDF 그래프를 생성하는 것이 SHOULD 좋습니다.

위 내용에서, 두 리터럴은 같은 RDF 항이 아니면서도 같은 값을 가질 수 있음이 따릅니다. 예: 

"1"^^xsd:integer
"01"^^xsd:integer

이 둘은 같은 값을 지시하지만, 어휘 형식이 다르기 때문에 같은 리터럴 RDF 항은 아닙니다.

3.4.3 초기 텍스트 방향

이 섹션은 비규범적입니다.

방향성이 있는 언어 태그 문자열의 기본 방향은 오른쪽에서 왼쪽 및 왼쪽에서 오른쪽 스크립트가 혼합된 텍스트를 포함하여, 텍스트의 초기 방향을 설정하는 수단을 제공합니다. Unicode 양방향 알고리즘 [I18N-Glossary]은 문자 시퀀스를 논리적 순서로 자동 렌더링하여, 예상대로 시각적으로 정렬되도록 지원하지만, 이것만으로는 양방향 텍스트를 올바르게 렌더링하기에 항상 충분하지는 않습니다.

책 제목 "HTML and CSS: Designing Websites"의 아랍어 번역을 생각해 보십시오. 왼쪽에서 오른쪽 문맥(예: 영어 웹 페이지)에서, 적절한 bidi 격리는 있지만 명시적인 기본 방향이 없는 경우, 다음과 같이 잘못 표시됩니다:

HTML و CSS: تصميم مواقع الويب

반면 올바른 렌더링은 다음과 같습니다:

HTML و CSS: تصميم مواقع الويب

이 예시는 양방향 텍스트가 나타날 수 있는 문맥에서 단순한 언어 태그 문자열 대신 방향성이 있는 언어 태그 문자열을 사용하는 것의 중요성을 보여 줍니다.

언어와 기본 방향은 문자열을 문맥 안에서 올바르게 표시하는 것과 관련된 문자열 외부의 양방향 문제를 다룬다는 점에 유의하십시오 (예: spillover 문제 방지). 이는 문자열 내부의 방향성 문제를 다루지 않으며, 이러한 문제는 다음과 같은 더 복잡한 예에서 발생할 수 있습니다:

"HTML و CSS: تصميم مواقع الويب" is the Arabic title of the book.

이 예를 나타내는 방향성이 있는 언어 태그 문자열은 언어 태그 en과 기본 방향 ltr을 가지지만, 따옴표 사이의 텍스트를 rtl로 격리하고 표시하기 위해 특정 Unicode 양방향 서식 문자가 추가로 필요합니다.

참고
다른 데이터형은 언어와 양방향 텍스트를 인코딩하는 자체 방식을 제공합니다. 예: rdf:HTML 또는 rdf:XMLLiteral.

3.5 빈 노드

빈 노드는 IRI 및 리터럴과 서로소입니다. 그 밖에는, 가능한 빈 노드의 집합은 임의적입니다. RDF는 빈 노드의 어떤 내부 구조도 참조하지 않습니다.

빈 노드 동일성: 두 빈 노드는 동일한 빈 노드인 경우에, 그리고 오직 그 경우에만 동일합니다.

참고

빈 노드 식별자는 일부 구체적 RDF 구문 또는 RDF 저장소 구현에서 사용되는 로컬 식별자입니다. 이들은 항상 파일 또는 RDF 저장소에 로컬 범위를 가지며, 빈 노드에 대한 영속적이거나 이식 가능한 식별자가 아닙니다. 빈 노드 식별자는 RDF 추상 데이터 모델의 일부가 아니며, 전적으로 구체적 구문 또는 구현에 의존합니다. 따라서 빈 노드 식별자에 대한 구문적 제한이 있다면 그것 역시 구체적 RDF 구문 또는 구현에 의존합니다. 구체적 구문에서 빈 노드 식별자를 처리하는 구현은, 구문에서 이것이 지원되는 상황을 제외하고는 동일한 빈 노드 식별자의 여러 출현으로부터 같은 빈 노드를 만들지 않도록 주의해야 합니다.

"blank node label"이라는 용어는 때때로 빈 노드 식별자라는 용어의 대안으로 비형식적으로 사용됩니다. 이 대안은 [SPARQL11-QUERY] 같은 일부 RDF 관련 명세의 이전 버전에서도 사용되었습니다. 일관성을 위해, 이제 이 대체 용어의 사용은 권장되지 않습니다.

3.6 트리플 항

다른 트리플의 목적어로 사용되는 RDF 트리플은 트리플 항이라고 합니다. 주어진 RDF 그래프에서, 트리플은 트리플 항, 단언된 트리플, 또는 둘 다로 나타날 수 있습니다.

트리플 항 동일성: 트리플 항은 트리플이므로, 트리플 항의 동일성은 트리플 동일성과 같습니다.

3.7 그래프 비교

이 섹션은 RDF 그래프에 대한 그래프 동형성의 개념을 도입합니다. 이는 RDF 항 사이의 매핑을 기반으로 하며, 빈 노드를 빈 노드로 매핑하고 IRI와 리터럴에 대해서는 항등 함수입니다.

모든 RDF 항의 집합에서 그 동일한 집합으로 가는 함수 M은 다음 속성을 모두 가지면 동형 RDF-항 매핑이라고 합니다:

두 RDF 그래프 G와 G'는 다음과 같은 동형 RDF-항 매핑 M이 존재하는 경우 동형 (즉, 같은 형태를 가짐)입니다. 트리플 (s, p, o)가 G에 있는 것은 트리플 ( M(s), M(p), M(o) )가 G'에 있는 경우에, 그리고 오직 그 경우에만 성립합니다.

이 정의에 따르면, M은 G의 각 빈 노드를 새 빈 노드로 대체하여 G'를 얻는 방법을 보여 줍니다. 그래프 동형성은 RDF Test Cases [RDF11-TESTCASES] 명세를 지원하는 데 필요합니다.

4. RDF 데이터셋

RDF 데이터셋은 RDF 그래프의 컬렉션이며, 다음으로 구성됩니다:

빈 노드는 RDF 데이터셋 안의 그래프들 사이에서 공유될 수 있습니다.

참고

“이름 있는 그래프”에서 “이름”이라는 단어가 사용되지만, 그래프 이름이 그 그래프를 지시해야 하는 것은 아닙니다. 이는 단지 구문적으로 그래프와 짝지어져 있을 뿐입니다. RDF는 그래프 이름이 어떤 리소스를 지시할 수 있는지, 또는 그 리소스와 그래프 사이의 관계에 대해 어떤 형식적 제한도 두지 않습니다. 서로 다른 RDF 데이터셋 의미론에 대한 논의는 [RDF11-DATASETS]에서 확인할 수 있습니다.

일부 RDF 데이터셋 구현은 비어 있는 이름 있는 그래프를 추적하지 않습니다. 애플리케이션은 비어 있는 이름 있는 그래프의 존재 여부에 중요성을 부여하지 않음으로써 상호운용성 문제를 피할 수 있습니다.

SPARQL 버전 1.2 [SPARQL12-CONCEPTS]는 RDF 버전 1.1 및 1.2와 동일한 RDF 데이터셋 개념을 사용하며, 여기서 이름 있는 그래프의 그래프 이름은 IRI 또는 빈 노드일 수 있습니다. 이와 달리, SPARQL Query Language 버전 1.1 [SPARQL11-QUERY]은 그래프 이름으로 IRI만 허용했습니다.

4.1 RDF 데이터셋 비교

두 RDF 데이터셋 D1 및 D2 (각각 기본 그래프 DG1 및 DG2와 이름 있는 그래프의 집합 NG1 및 NG2를 가짐)는 다음 모든 속성이 성립하는 동형 RDF-항 매핑 M이 존재하는 경우에, 그리고 오직 그 경우에만 데이터셋-동형입니다:

4.2 RDF 데이터셋의 콘텐츠 협상

이 섹션은 비규범적입니다.

웹 리소스는 콘텐츠 협상 [WEBARCH]을 통해 제공되는 여러 표현을 가질 수 있습니다. 표현은 RDF 데이터셋과 RDF 그래프 모두의 표현을 지원하는 RDF 직렬화 형식으로 반환될 수 있습니다. RDF 데이터셋이 반환되고 소비자가 RDF 그래프를 기대하는 경우, 소비자는 RDF 데이터셋의 기본 그래프를 사용할 것으로 예상됩니다.

4.3 쿼드 집합으로서의 데이터셋

이 섹션은 비규범적입니다.

쿼드는 선택적인 그래프 이름과 연결된 트리플이며, RDF 데이터셋 안의 트리플을 가리킬 때 사용됩니다.

쿼드는 주어, 술어, 목적어, 그리고 선택적인 그래프 이름으로 구성된 튜플로 표현될 수 있습니다.

RDF 데이터셋은 쿼드의 집합으로 간주될 수 있으며, 그래프 이름이 없는 쿼드는 기본 그래프의 트리플을 제공하고, 같은 그래프 이름을 가진 쿼드는 그 이름을 가진 이름 있는 그래프의 트리플을 제공합니다.

참고

그래프 이름이 없는 쿼드는 트리플과 동일한 세 구성요소로 이루어져 있지만, 이는 별개의 개념입니다. 이는 RDF 데이터셋의 기본 그래프 안의 트리플이라는 개념을 구체적으로 포착하기 때문입니다.

5. 데이터형

데이터형은 문자열, 숫자 및 날짜와 같은 값을 표현하기 위해 RDF 리터럴과 함께 사용됩니다. RDF에서 사용되는 데이터형 추상화는 XML Schema [XMLSCHEMA11-2]와 호환됩니다. 이 추상화에 부합하는 모든 데이터형 정의는 XML Schema의 관점에서 정의되지 않았더라도 RDF에서 사용될 수 MAY 있습니다. RDF는 많은 XML Schema 내장 데이터형을 재사용하며, 세 가지 추가 데이터형인 rdf:JSON, rdf:HTML, 그리고 rdf:XMLLiteral을 정의합니다.

데이터형은 어휘 공간, 값 공간 및 어휘-값 매핑으로 구성되며, 하나 이상의 IRI로 식별됩니다.

데이터형의 어휘 공간은 문자열의 집합입니다.

데이터형의 어휘-값 매핑은 첫 번째 원소가 어휘 공간에 속하고, 두 번째 원소가 데이터형의 값 공간에 속하는 쌍의 집합입니다. 어휘 공간의 각 구성원은 정확히 하나의 값과 짝지어지며, 그 값의 어휘 표현입니다. 이 매핑은 어휘 공간에서 값 공간으로 가는 함수로 볼 수 있습니다.

참고

언어 태그 문자열은 http://www.w3.org/1999/02/22-rdf-syntax-ns#langString (일반적으로 rdf:langString으로 축약됨) 데이터형 IRI를 가집니다. 이 IRI에 대해 형식적으로 정의된 데이터형은 없습니다. 왜냐하면 데이터형의 정의가 어휘 공간 안의 언어 태그를 수용하지 않기 때문입니다. 이 데이터형 IRI와 관련된 값 공간은 문자열과 언어 태그로 이루어진 모든 쌍의 집합입니다. 마찬가지로, 방향성이 있는 언어 태그 문자열 http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString (일반적으로 rdf:dirLangString으로 축약됨)은 값 공간 안에 기본 방향도 가집니다. 이 데이터형 IRI와 관련된 값 공간은 문자열, 언어 태그 및 기본 방향으로 이루어진 모든 3-튜플의 집합입니다.

예를 들어, 값 공간의 각 구성원이 두 가지 어휘 표현을 갖는 XML Schema 데이터형 xsd:boolean은 다음과 같이 정의됩니다:

어휘 공간:
{"true", "false", "1", "0"}
값 공간:
{true, false}
어휘-값 매핑
{ <"true", true>, <"false", false>, <"1", true>, <"0", false>, }

이 데이터형을 사용하여 정의할 수 있는 리터럴은 다음과 같습니다:

이 표는 xsd:boolean 타입의 리터럴을 나열합니다.
리터럴 값
<"true", xsd:boolean> true
<"false", xsd:boolean> false
<"1", xsd:boolean> true
<"0", xsd:boolean> false

5.1 XML Schema 내장 데이터형

xxx가 데이터형의 이름인 경우, http://www.w3.org/2001/XMLSchema#xxx 형식의 IRI는 W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes [XMLSCHEMA11-2]에서 정의된 내장 데이터형을 지시합니다. 다음 표에 나열된 XML Schema 내장 타입은 RDF 호환 XSD 타입입니다. 이들의 사용은 RECOMMENDED됩니다.

독자는 이진 정보를 전송하기에 안전한 유일한 데이터형이 xsd:hexBinary 및 xsd:base64Binary임을 유의할 수 있습니다.

RDF 호환 XSD 타입 목록과 간단한 설명
데이터형 값 공간(정보성)
핵심 타입 xsd:string 문자열
xsd:boolean true, false
xsd:decimal 임의 정밀도 십진수
xsd:integer 임의 크기의 정수
IEEE 부동소수점
수		 xsd:double ±Inf, ±0, NaN을 포함하는 64비트 부동소수점 수
xsd:float ±Inf, ±0, NaN을 포함하는 32비트 부동소수점 수
시간 및 날짜 xsd:date 시간대가 있거나 없는 날짜(yyyy-mm-dd)
xsd:time 시간대가 있거나 없는 시간(hh:mm:ss.sss…)
xsd:dateTime 시간대가 있거나 없는 날짜와 시간
xsd:dateTimeStamp 필수 시간대가 있는 날짜와 시간
반복 및
부분 날짜		 xsd:gYear 그레고리력 연도
xsd:gMonth 그레고리력 월
xsd:gDay 그레고리력 월의 일
xsd:gYearMonth 그레고리력 연도와 월
xsd:gMonthDay 그레고리력 월과 일
기간 xsd:duration 시간의 기간
xsd:yearMonthDuration 시간의 기간(월과 연도만)
xsd:dayTimeDuration 시간의 기간(일, 시간, 분, 초만)
제한 범위
정수		 xsd:byte -128…+127 (8비트)
xsd:short -32768…+32767 (16비트)
xsd:int -2147483648…+2147483647 (32비트)
xsd:long -9223372036854775808…+9223372036854775807 (64비트)
xsd:unsignedByte 0…255 (8비트)
xsd:unsignedShort 0…65535 (16비트)
xsd:unsignedInt 0…4294967295 (32비트)
xsd:unsignedLong 0…18446744073709551615 (64비트)
xsd:positiveInteger 0보다 큰 정수
xsd:nonNegativeInteger 0 이상의 정수
xsd:negativeInteger 0보다 작은 정수
xsd:nonPositiveInteger 0 이하의 정수
인코딩된 이진 데이터 xsd:hexBinary 16진수로 인코딩된 이진 데이터
xsd:base64Binary Base64로 인코딩된 이진 데이터
기타
XSD 타입		 xsd:anyURI 해결된 또는 상대 URI 및 IRI 참조
xsd:language [BCP47]에 따른 언어 태그
xsd:normalizedString 공백이 정규화된 문자열
xsd:token 토큰화된 문자열
xsd:NMTOKEN XML NMTOKEN
xsd:Name XML 이름
xsd:NCName XML NCName

xsd:float 및 xsd:double에 대한 어휘-값 매핑은 doubleLexicalMap과 일치하는 방법을 사용해야 MUST 하며, 이는 floatPtRound [XMLSCHEMA11-2]에 설명된 반올림 방법을 엄격히 준수해야 MUST 합니다.

그 밖의 XML Schema 내장 데이터형은 여러 이유로 적합하지 않으며 사용해서는 SHOULD NOT 안 됩니다:

참고

xsd:double 및 xsd:float의 값 공간은 모든 십진수를 포함하지 않습니다. 이 두 데이터형 중 하나를 가진 모든 리터럴에 대해, 리터럴의 값은 해당 정밀도의 IEEE 754-2008 이진 부동소수점 표현으로 나타낼 수 있는 값입니다. 예를 들어, 어휘 형식이 "0.1"이고 데이터형이 xsd:float인 리터럴은 숫자 0.100000001490116119384765625를 지시합니다. xsd:double 또는 xsd:float 대신, 데이터형 xsd:decimal을 사용하여 임의의 십진수를 정확히 포착할 수 있습니다.

5.2 데이터형 IRI

데이터형은 IRI로 식별됩니다.

http://www.w3.org/2001/XMLSchema#xxx 형식의 어떤 IRI가 RDF 구현에 의해 처리되는 경우, 이는 섹션 5.1에 나열된 모든 XSD 타입에 대해 xsd:xxx라는 이름의 RDF 호환 XSD 타입을 참조해야 MUST 합니다.

아래 세 IRI로 식별되는 데이터형은 부록 A. 추가 데이터형에 정의되어 있습니다:

RDF 구현은 모든 데이터형을 처리할 필요가 없습니다. RDF 구현이 처리하지 않는 데이터형으로 타입이 지정된 모든 리터럴은 알 수 없는 IRI와 마찬가지로, 즉 알 수 없는 것을 참조하는 것으로 처리됩니다. 애플리케이션은 타입 지정 리터럴에 사용된 IRI의 지시 대상을 결정할 수 없는 경우 경고 메시지를 낼 수 MAY 있습니다. RDF 구현은 알 수 없는 데이터형을 가진 리터럴을 구문적 또는 의미론적 오류로 거부해서는 SHOULD NOT 안 됩니다.

다른 명세는 데이터형 IRI에 대해 추가 제약을 부과할 수 MAY 있습니다. 예를 들어 특정 데이터형의 지원을 요구할 수 있습니다.

참고

RDF의 의미론적 확장은 다른 데이터형 IRI를 인식하고 각각이 고정된 데이터형을 참조하도록 요구할 수 있습니다. 의미론적 확장에 대한 자세한 내용은 RDF 1.2 Semantics [RDF12-SEMANTICS]를 참조하십시오.

참고

Web Ontology Language [OWL2-OVERVIEW]는 RDF와 함께 사용할 수 있는 사용자 지정 데이터형을 형식적으로 정의하기 위한 기능을 제공합니다. 또한 사용자 정의 단순 XML Schema 데이터형을 식별하기 위한 관행이 [SWBP-XSCH-DATATYPES]에서 제안되어 있습니다. RDF 구현은 이러한 기능 중 어느 것도 지원할 필요가 없습니다.

참고

RDF 1.1에서는 인식된 데이터형 IRI가 RDF Concepts에서 정의되어, RDF Semantics의 데이터형 IRI “인식”과 의미론적 확장에 대해 중복되었습니다.

6. 프래그먼트 식별자

이 섹션은 비규범적입니다.

RDF는 리소스 식별자로 프래그먼트 식별자를 포함할 수 있는 IRI를 사용합니다. 프래그먼트 식별자의 의미론은 RFC 3986에 정의되어 있습니다 [RFC3986]: 이들은 일반적으로 기본 리소스의 일부, 보기, 그 안에서 정의된 것, 또는 그 안에서 설명된 것인 보조 리소스를 식별하며, 정확한 의미론은 기본 리소스에 대한 검색 동작의 결과로 얻어질 수 있는 표현들의 집합에 따라 달라집니다.

이 섹션은 RDF 그래프를 인코딩하는 표현에서 프래그먼트 식별자를 처리하는 방식을 논의합니다.

예를 들어 <https://example.com/foo>와 같은 기본 리소스의 RDF 포함 표현에서, 예를 들어 bar와 같은 프래그먼트 식별자가 식별하는 보조 리소스는 RDF 그래프 안의 전체 IRI가 지시하는 리소스이며, 이 경우에는 <https://example.com/foo#bar>가 됩니다. RDF 그래프 안의 IRI는 무엇이든 지시할 수 있으므로, 이는 그 표현의 외부에 있는 것일 수도 있고, 심지어 웹 외부에 있는 것일 수도 있습니다.

이러한 방식으로, RDF 포함 표현은 웹에서 접근 가능한 기본 리소스와 RDF 그래프가 설명할 수 있는 어떤 웹이 아닌 또는 추상 엔터티의 집합 사이에서 중개자 역할을 합니다.

다른 명세가 RDF 포함 표현에서 프래그먼트 식별자의 의미론을 제한하는 경우, 인코딩된 RDF 그래프는 이러한 제약과 일관된 방식으로 프래그먼트 식별자를 사용해야 합니다. 예를 들어, HTML+RDFa 문서 [HTML-RDFA]에서 chapter1과 같은 프래그먼트 식별자는 HTML의 @name 또는 @id 속성의 의미론을 통해 문서 섹션을 식별할 수 있습니다. 그러한 IRI, 예를 들어 <#chapter1>는 같은 문서 안의 RDFa로 인코딩된 모든 트리플에서 그 동일한 섹션을 지시하는 것으로 간주되어야 합니다. 마찬가지로, 프래그먼트 식별자는 콘텐츠 협상 [WEBARCH]을 통해 제공되는 여러 표현을 가진 리소스에서 일관되게 사용되어야 합니다. 예를 들어, 프래그먼트 식별자 chapter1이 기본 리소스의 HTML 표현에서 문서 섹션을 식별한다면, IRI <#chapter1>는 동일한 기본 리소스의 모든 RDF 포함 표현에서 그 동일한 섹션을 지시하는 것으로 간주되어야 합니다.

7. RDF 트리플, 그래프 및 데이터셋의 일반화

이 섹션은 비규범적입니다.

RDF 트리플에 대한 요구사항을 완화하는 것이 때때로 편리합니다. 예를 들어, RDFS 함의 규칙의 완전성은 대칭 RDF 트리플이라는 개념을 사용하면 더 쉽게 보일 수 있습니다.

7.1 대칭 RDF

대칭 RDF 트리플은 주어가 목적어 위치에서 허용되는 임의의 RDF 항일 수 있도록 허용합니다. 이는 IRI, 빈 노드, 리터럴, 또는 트리플 항 (그 자체가 대칭 RDF 트리플일 수도 있음) 중 하나입니다. 대칭 RDF 그래프는 대칭 RDF 트리플의 집합입니다. 대칭 RDF 데이터셋은 구별되는 대칭 RDF 그래프와, 각각 IRI 또는 빈 노드를 대칭 RDF 그래프와 연결하는 0개 이상의 쌍으로 구성됩니다.

대칭 RDF 트리플, 그래프 및 데이터셋은 표준적인 규범 RDF 트리플, 그래프, 및 데이터셋과 주어와 목적어 위치에 IRI, 빈 노드, 리터럴, 및 트리플 항을 허용한다는 점에서만 다릅니다.

7.2 일반화된 RDF

일반화된 RDF 트리플은 주어, 술어 및 목적어를 가진 트리플이며, 각각은 IRI, 빈 노드, 리터럴, 또는 트리플 항 (그 자체가 일반화된 RDF 트리플일 수도 있음)일 수 있습니다. 일반화된 RDF 그래프는 일반화된 RDF 트리플의 집합입니다. 일반화된 RDF 데이터셋은 구별되는 일반화된 RDF 그래프와, 각각 IRI, 빈 노드, 리터럴, 또는 트리플 항 (그 자체가 일반화된 RDF 트리플일 수도 있음)을 일반화된 RDF 그래프와 연결하는 0개 이상의 쌍으로 구성됩니다.

일반화된 RDF 트리플, 그래프 및 데이터셋은 표준적인 규범 RDF 트리플, 그래프, 및 데이터셋과 IRI, 빈 노드, 리터럴, 및 트리플 항이 임의의 위치, 즉 주어, 술어, 목적어 또는 그래프 이름으로 나타나는 것을 허용한다는 점에서만 다릅니다.

참고

대칭 또는 일반화된 RDF 트리플, 그래프 또는 데이터셋을 사용하는 모든 사용자는 이러한 개념이 RDF의 비표준 확장이라는 점과, 그 사용이 상호운용성 문제를 일으킬 수 있다는 점을 알아야 합니다. 어떤 RDF 도구도 표준적인 규범 RDF 트리플, 그래프 및 데이터셋을 넘어서는 것을 수용, 처리 또는 생성해야 한다는 요구사항은 없습니다.

A. 추가 데이터형

이 섹션은 RDF 구현이 지원할 수 MAY 있는 추가 데이터형을 정의합니다.

A.1 rdf:HTML 데이터형

RDF는 HTML 콘텐츠를 가능한 리터럴 값으로 제공합니다. 이를 통해 리터럴 값 안에 마크업을 포함할 수 있습니다. 이러한 콘텐츠는 RDF 그래프에서 데이터형이 rdf:HTML로 설정된 리터럴을 사용하여 표시됩니다.

rdf:HTML 데이터형은 다음과 같이 정의됩니다:

이 데이터형을 지시하는 IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML입니다.
값 공간
DOM DocumentFragment 노드 [DOM]의 집합입니다. 두 DocumentFragment 노드 node와 otherNode는 DOM 메서드 node.isEqualNode(otherNode) [DOM]가 true를 반환하는 경우에, 그리고 오직 그 경우에만 동일하다고 간주됩니다.
어휘-값 매핑

어휘 공간의 각 구성원은 다음 알고리즘을 적용한 결과와 연결됩니다:

참고

HTML 콘텐츠에서 원하는 모든 언어 주석(lang="…"), 텍스트 방향성 주석(dir="…") 또는 XML 네임스페이스(xmlns)는 HTML 리터럴에 명시적으로 포함되어야 합니다. href와 같은 속성의 상대 URL은 잘 정의된 기본 URL을 갖지 않으므로 피하는 것이 가장 좋습니다. RDF 애플리케이션은 동일한 문자열의 단일 텍스트 노드에 해당하는 rdf:HTML 리터럴과 xsd:string을 연결하는 관계와 같은 추가 동등성 관계를 사용할 수 있습니다.

A.2 rdf:XMLLiteral 데이터형

RDF는 XML 콘텐츠를 가능한 리터럴 값으로 제공합니다. 이러한 콘텐츠는 RDF 그래프에서 데이터형이 rdf:XMLLiteral로 설정된 리터럴을 사용하여 표시됩니다.

rdf:XMLLiteral 데이터형은 다음과 같이 정의됩니다:

이 데이터형을 지시하는 IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral입니다.
어휘 공간
균형이 맞고 자체 완결적인 XML 콘텐츠 [XML11]이며, 임의의 XML 시작 태그와 종료 태그 사이에 삽입했을 때 Namespaces in XML 1.0 (Third Edition) [XML-NAMES]에 부합하는 문서를 생성하는 모든 문자열의 집합입니다.
값 공간
DOM DocumentFragment 노드 [DOM]의 집합입니다. 두 DocumentFragment 노드 node와 otherNode는 DOM 메서드 node.isEqualNode(otherNode)가 true를 반환하는 경우에, 그리고 오직 그 경우에만 동일하다고 간주됩니다.
어휘-값 매핑

어휘 공간의 각 구성원은 다음 알고리즘을 적용한 결과와 연결됩니다:

참고

XML 콘텐츠에서 원하는 모든 XML 네임스페이스 선언(xmlns), 언어 주석(xml:lang) 또는 기본 URI 선언 (xml:base)은 XML 리터럴에 명시적으로 포함되어야 합니다. 일부 구체적 RDF 구문은 이를 문맥에서 상속하는 메커니즘을 정의할 수 있음에 유의하십시오(예: RDF/XML [RDF12-XML]의 @parseType="literal").

A.3 rdf:JSON 데이터형

RDF는 JSON 콘텐츠를 가능한 리터럴 값으로 제공합니다. 여기에는 리터럴 값 안에 마크업을 허용하는 것도 포함됩니다. 이러한 콘텐츠는 RDF 그래프에서 데이터형이 rdf:JSON으로 설정된 리터럴로 표시됩니다.

rdf:JSON 데이터형은 다음과 같이 정의됩니다:

이 데이터형을 지시하는 IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#JSON입니다.
어휘 공간
[RFC8259]의 섹션 2 JSON 문법에 설명된 JSON 문법을 따르고, 또한 The I-JSON Message Format [RFC7493]의 요구사항도 따르는 모든 RDF 문자열의 집합입니다.
참고
The JavaScript Object Notation (JSON) Data Interchange Format [RFC8259]은 문자열에 RDF 문자열에서 허용되지 않는 서로게이트 코드 포인트를 포함하는 것을 허용하지만, 이는 [RFC7493]에서도 제외됩니다. 따라서 JSON 리터럴의 어휘 표현은 서로게이트 코드 포인트를 포함하는 것을 제외합니다.
값 공간
문자열, 숫자(xsd:double), 값 공간 안의 값에 문자열을 매핑하는 유한 순서 없는 맵, 값 공간 안의 값들의 목록, 그리고 Infra Standard [INFRA] 및 W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes [XMLSCHEMA11-2]의 리터럴 값(true, false, 및 null)을 포함하는 가장 작은 집합입니다.
참고

유한 순서 없는 맵의 값 공간과 목록은 자신을 구성원으로 갖는 값을 포함하지 않으며, 이는 JSON으로 표현될 수 없습니다.

두 값은 값 공간의 동일한 원소인 경우에, 그리고 오직 그 경우에만 동일하다고 간주됩니다.

어휘-값 매핑
어휘 공간의 모든 원소를 이를 파싱한 결과인 문자열, 숫자(xsd:double), 유한 순서 없는 맵, 목록, 또는 리터럴 값(true, false, 및 null)으로 매핑합니다.
  • JSON Object는 각 객체 구성원을 구성원 이름에서 가져온 key와 구성원 값에 이 매핑을 수행하여 가져온 value를 가진 map entry로 변환함으로써 유한 순서 없는 맵으로 매핑됩니다.
  • JSON Array는 이 목록이 JSON Array와 같은 수의 원소를 포함하고, array 안의 모든 위치 i에 대해 목록의 i번째 위치의 원소가 array의 i번째 원소에 이 매핑을 적용한 결과인 값이 되도록 하는 목록으로 매핑됩니다.
  • JSON Number는 doubleLexicalMap과 일치하는 방법을 사용하여 xsd:double로 매핑되며, 이는 floatPtRound [XMLSCHEMA11-2]에 설명된 반올림 방법을 엄격히 준수해야 MUST 합니다.
    참고
    일부 숫자는 유한한 xsd:double 값으로 표현될 수 없으며 +INF 또는 -INF로 매핑될 수 있습니다. 그러한 값은 JSON Number로 표현될 수 없으므로, 그러한 값을 다시 JSON으로 직렬화하는 능력을 제한합니다.
  • JSON String은 모든 이스케이프 시퀀스를 관련된 Unicode 코드 포인트로 변환한 뒤 문자열로 매핑됩니다.
  • JSON literal name은 JSON true, false, 및 null 값을 각각 [INFRA]의 true, false, 및 null 값으로 매핑합니다.
참고

유한 순서 없는 맵은 key-value 쌍을 key 기준으로 ( Unicode 코드 포인트 순서를 사용하여) 체계적으로 정렬함으로써 ordered map [INFRA]으로 구현될 수 있습니다. 이는 객체 구성원의 순서만 다른 어휘 형식(예: {"a": "b", "c": "d"} 및 {"c": "d", "a": "b"})이 같은 값으로 매핑되도록 보장합니다.

B. 빈 노드를 IRI로 대체하기

빈 노드는 RDF 추상 데이터 모델에서 식별자를 갖지 않습니다. 일부 구체적 구문에서 도입한 빈 노드 식별자는 로컬 범위만 가지며 순전히 직렬화의 산물입니다.

더 강한 식별이 필요한 상황에서, 시스템은 RDF 그래프의 일부 또는 모든 빈 노드를 IRI로 체계적으로 대체할 수 MAY 있습니다. 이를 수행하려는 시스템은 이렇게 대체되는 각 빈 노드에 대해 새롭고 전역적으로 고유한 IRI(Skolem IRI)를 만들어내는 것이 SHOULD 좋습니다.

이 변환은 원래 그래프를 함의하는 새 그래프를 생성합니다 (Skolemization도 참조). 이 문맥에서 Skolem IRI와 빈 노드는 성격이 다르다는 점에 유의하는 것이 중요합니다: IRI는 리소스를 직접 지시하는 반면, 빈 노드는 리소스의 존재만을 나타냅니다. Skolem IRI를 생성함으로써, 우리는 이러한 존재에 대한 구체적인 증인을 만듭니다. Skolem IRI는 로컬이 아니므로, 이후 다른 그래프가 이를 사용할 수 있으며, 이는 빈 노드로는 불가능합니다.

시스템은 Skolem IRI가 오직 빈 노드를 대체하기 위해 도입되었음을 인식할 수 있는 방식으로 이를 만들어내고자 할 수 있습니다. 일부 문맥에서는, 필요할 경우 시스템이 Skolem IRI를 다시 빈 노드로 매핑할 수 있습니다.

Skolem IRI가 시스템 경계 밖에서도 인식 가능하기를 원하는 시스템은 등록된 이름 genid를 가진 well-known IRI [RFC8615]를 사용하는 것이 SHOULD 좋습니다. 이는 HTTP 또는 HTTPS 스킴을 사용하는 IRI이거나, well-known IRI를 사용하도록 지정된 다른 스킴을 사용하고, path 구성요소가 /.well-known/genid/로 시작하는 IRI입니다.

예를 들어, example.com 도메인을 책임지는 기관은 다음과 같은 인식 가능한 Skolem IRI를 만들어낼 수 있습니다: 

http://example.com/.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6
참고

RFC 8615 [RFC8615]는 well-known URI만 지정하며, IRI는 지정하지 않습니다. 이 문서의 목적상, well-known IRI는 IRI-to-URI 매핑 [RFC3987] 후에 well-known URI가 되는 모든 IRI입니다.

C. 개인정보 보호 고려사항

이 섹션은 비규범적입니다.

RDF는 임의의 애플리케이션 데이터를 표현하는 데 사용되며, 여기에는 개인 식별 정보(PII) 또는 민감하다고 간주될 수 있는 기타 정보의 표현이 포함될 수 있습니다. 그러한 정보를 게시하는 작성자는 그러한 정보를 게시할 필요와 사용을 신중히 고려하고, 데이터가 소비되고 잠재적으로 공개될 것으로 예상되는 지역에 적용되는 규정 (예: GDPR, CCPA, 기타)도 신중히 고려하는 것이 권장됩니다. 특히 데이터에 접근하기 위해 승인 조치가 필요한지 여부를 고려해야 합니다.

D. 보안 고려사항

이 섹션은 비규범적입니다.

RDF 추상 데이터 모델은 정보를 전달하는 데 직접 사용되지 않습니다. 구체적 직렬화 형식은 이를 위해 특별히 의도된 것입니다.

애플리케이션은 주어진 데이터를 평가하여 더 많은 단언을 추론하거나 IRI를 역참조할 수 있으며, 해당 IRI의 스킴에 대한 보안 고려사항이 적용됩니다. 특히 HTTP IRI에 대해서는 [RFC3023] 섹션 10의 개인정보 보호 문제에 유의하십시오. 부정확하거나 악의적인 데이터 소스에서 얻은 데이터는 부정확하거나 오해의 소지가 있는 결론뿐 아니라 의도하지 않은 IRI의 역참조로 이어질 수 있습니다. 참조한 리소스에 대한 신뢰를 데이터의 의도된 사용 민감도에 맞추도록 주의해야 합니다. 잠재적 의료 처치에 대한 추론은 여행 계획을 위한 추론과는 다른 신뢰를 요구할 가능성이 높습니다.

RDF는 임의의 애플리케이션 데이터를 표현하는 데 사용되므로, 보안 고려사항은 사용 도메인에 따라 달라집니다. 텍스트에 적용 가능한 보안 도구 및 프로토콜 (예: PGP 암호화, 체크섬 검증, 암호로 보호된 압축)도 RDF 문서에 사용할 수 있습니다. 내장된 정보의 민감도를 반영하는 보안/개인정보 보호 프로토콜을 적용하는 것이 바람직합니다.

RDF는 RDF Schema 레이블과 같이 사용자에게 표시되는 데이터를 표현할 수 있습니다. 신뢰할 수 없는 RDF 문서에서 가져온 문자열을 렌더링하거나, 이스케이프되지 않은 문자를 사용하는 애플리케이션은 악의적인 문자열이 독자를 오도하는 데 사용될 가능성을 제한하기 위해 경고와 기타 적절한 수단을 사용하는 것이 바람직합니다. XML의 미디어 타입 등록에 있는 보안 고려사항([RFC3023] 섹션 10)은 임의의 데이터와 마크업 표현에 관한 추가 지침을 제공합니다.

RDF는 항 식별자로 IRI를 사용합니다. RDF로 표현된 데이터를 해석하는 애플리케이션은 Internationalized Resource Identifiers (IRIs) [RFC3987] 섹션 8의 보안 문제뿐 아니라 Uniform Resource Identifier (URI): Generic Syntax [RFC3986] 섹션 7의 보안 문제도 다루는 것이 바람직합니다.

여러 IRI가 동일하게 보일 수 있습니다. 서로 다른 문자 체계의 문자가 비슷하게 보일 수 있습니다(예를 들어, 키릴 문자 "о"가 라틴 문자 "o"와 비슷하게 보일 수 있습니다). 문자 뒤에 결합 문자가 따라오면 다른 문자와 같은 시각적 표현을 가질 수 있습니다 (예: LATIN SMALL LETTER "E" 뒤에 COMBINING ACUTE ACCENT가 붙은 것은 LATIN SMALL LETTER "E" WITH ACUTE와 같은 시각적 표현을 가집니다). RDF에서 데이터를 작성하거나 해석하는 사람 또는 애플리케이션은 의도된 의미론과 일치하는 IRI를 사용하도록 주의해야 하며, 비슷해 보일 수 있는 IRI를 피해야 합니다. 시각적으로 유사한 문자의 매칭에 대한 추가 정보는 Unicode Security Considerations [UNICODE-SECURITY] 및 Internationalized Resource Identifiers (IRIs) [RFC3987] 섹션 8에서 찾을 수 있습니다.

그래프를 비교하거나, 그래프를 사용해 추론하는 것은 종종 (부분) 그래프 동형성 계산에 의존하며, 이는 최악의 경우 계산적으로 복잡한 것으로 알려져 있습니다. 그래프를 질의하는 것도 계산적으로 복잡한 연산을 포함할 수 있습니다. 이는 악의적인 그래프가 RDF 구현을 멈추게 하거나 메모리를 고갈시키도록 구성될 수 있음을 의미합니다. 신뢰할 수 없는 소스의 그래프를 처리하는 구현은 완화 조치를 제공할 것으로 기대됩니다. 예시는 [RDF-CANON]의 Dataset Poisoning 섹션에 제공되어 있습니다.

참고

이러한 고려사항은 [RDF12-TURTLE], [RDF12-TRIG], [RDF12-N-TRIPLES], 및 [RDF12-N-QUADS]의 보안 고려사항을 더 일반적인 형태로 제시한 것입니다.

E. 국제화 고려사항

이 섹션은 비규범적입니다.

Unicode [UNICODE]는 문자열 내부의 방향을 신호하기 위한 메커니즘을 제공합니다 (Unicode Bidirectional Algorithm [I18N-Glossary] 참조). RDF는 문자열의 초기 텍스트 방향을 신호하기 위해 방향성이 있는 언어 태그 문자열의 기본 방향을 지정하는 메커니즘을 제공합니다. 대부분의 인간 언어 문자열에서, 특히 문자열 내용만으로는 기본 방향을 정확히 결정할 수 없는 경우, 값의 적절한 표시와 격리를 얻기 위해 외부 표시자를 갖는 것은 유용합니다. 그러한 표시자의 한 예는 [HTML] dir 속성입니다; [STRING-META]를 참조하십시오.

JSON-LD 1.1 [JSON-LD11]은 RDF 리터럴의 기본 방향과 언어 태그를 모두 지정하기 위해 데이터형을 사용하는 i18n 네임스페이스를 도입했습니다.

F. IRI 문법

이 섹션은 비규범적입니다.

다음 [ABNF] 문법은 [RFC3987] 및 [RFC6874]의 변경사항을 [RFC3986]의 URI에 대한 수집된 ABNF 섹션에 적용하여 IRI를 위한 통합 문법을 제공합니다.

이는 편의를 위해서만 제공됩니다. 이것이 [RFC3986], [RFC3987] 또는 이후의 업데이트에 있는 정의와 다르다면, 해당 정의를 사용해야 합니다. 

IRI            = scheme ":" ihier-part [ "?" iquery ] [ "#" ifragment ]

ihier-part     = "//" iauthority ipath-abempty
               / ipath-absolute
               / ipath-rootless
               / ipath-empty

IRI-reference  = IRI / irelative-ref

absolute-IRI   = scheme ":" ihier-part [ "?" iquery ]

irelative-ref  = irelative-part [ "?" iquery ] [ "#" ifragment ]

irelative-part = "//" iauthority ipath-abempty
               / ipath-absolute
               / ipath-noscheme
               / ipath-empty

scheme         = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

iauthority     = [ iuserinfo "@" ] ihost [ ":" port ]
iuserinfo      = *( iunreserved / pct-encoded / sub-delims / ":" )
ihost          = IP-literal / IPv4address / ireg-name
port           = *DIGIT

IP-literal     = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"

ZoneID         = 1*( unreserved / pct-encoded )

IPv6addrz      = IPv6address "%25" ZoneID

IPvFuture      = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

IPv6address    =                            6( h16 ":" ) ls32
               /                       "::" 5( h16 ":" ) ls32
               / [               h16 ] "::" 4( h16 ":" ) ls32
               / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
               / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
               / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
               / [ *4( h16 ":" ) h16 ] "::"              ls32
               / [ *5( h16 ":" ) h16 ] "::"              h16
               / [ *6( h16 ":" ) h16 ] "::"

h16            = 1*4HEXDIG
ls32           = ( h16 ":" h16 ) / IPv4address
IPv4address    = dec-octet "." dec-octet "." dec-octet "." dec-octet

dec-octet      = DIGIT                 ; 0-9
               / %x31-39 DIGIT         ; 10-99
               / "1" 2DIGIT            ; 100-199
               / "2" %x30-34 DIGIT     ; 200-249
               / "25" %x30-35          ; 250-255

ireg-name      = *( iunreserved / pct-encoded / sub-delims )

ipath          = ipath-abempty   ; begins with "/" or is empty
               / ipath-absolute  ; begins with "/" but not "//"
               / ipath-noscheme  ; begins with a non-colon segment
               / ipath-rootless  ; begins with a segment
               / ipath-empty     ; zero characters

ipath-abempty  = *( "/" isegment )
ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]
ipath-noscheme = isegment-nz-nc *( "/" isegment )
ipath-rootless = isegment-nz *( "/" isegment )
ipath-empty    = 0

isegment       = *ipchar
isegment-nz    = 1*ipchar
isegment-nz-nc = 1*( iunreserved / pct-encoded / sub-delims / "@" )
               ; non-zero-length segment without any colon ":"

ipchar         = iunreserved / pct-encoded / sub-delims / ":" / "@"

iquery         = *( ipchar / iprivate / "/" / "?" )

ifragment      = *( ipchar / "/" / "?" )

iunreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar

ucschar        = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
               / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
               / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
               / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
               / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
               / %xD0000-DFFFD / %xE1000-EFFFD

iprivate       = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD

pct-encoded    = "%" HEXDIG HEXDIG

unreserved     = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved       = gen-delims / sub-delims
gen-delims     = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims     = "!" / "$" / "&" / "'" / "(" / ")"
               / "*" / "+" / "," / ";" / "="

ABNF는 iri-grammar.abnf에서도 직접 접근할 수 있습니다.

G. 감사의 말

이 섹션은 비규범적입니다.

G.1 RDF 1.0에 대한 감사의 말

이 섹션은 비규범적입니다.

명세 원본 버전의 편집자는 Graham Klyne (Nine by Nine) 및 Jeremy J. Carroll (Hewlett Packard Labs)이었습니다.

이 문서는 Pat Hayes, Sergey Melnik 및 Patrick Stickler의 중요한 기여를 포함하고 있으며, 이들의 지도 아래 정수 및 날짜와 같은 데이터형 지정 값을 표현하기 위한 RDF 명세군에 설명된 프레임워크가 개발되었습니다.

편집자들은 다음 사람들의 귀중한 기여에 감사드립니다: Frank Manola, Pat Hayes, Dan Brickley, Jos de Roo, Dave Beckett, Patrick Stickler, Peter F. Patel-Schneider, Jerome Euzenat, Massimo Marchiori, Tim Berners-Lee, Dave Reynolds 및 Dan Connolly.

Jeremy Carroll은 이탈리아 W3C Office의 호스트인 Oreste Signore와, Jeremy가 방문 연구원으로 있는 Consiglio Nazionale delle Ricerche의 일부인 Istituto di Scienza e Tecnologie dell'Informazione "Alessandro Faedo"에 감사드립니다.

이 문서는 장기간의 심의를 거친 RDFcore Working Group의 산물이며, 이 그룹의 구성원에는 다음이 포함되었습니다: Art Barstow (W3C), Dave Beckett (ILRT), Dan Brickley (ILRT), Dan Connolly (W3C), Jeremy Carroll (Hewlett Packard), Ron Daniel (Interwoven Inc), Bill dehOra (InterX), Jos De Roo (AGFA), Jan Grant (ILRT), Graham Klyne (Nine by Nine), Frank Manola (MITRE Corporation), Brian McBride (Hewlett Packard), Eric Miller (W3C), Stephen Petschulat (IBM), Patrick Stickler (Nokia), Aaron Swartz (HWG), Mike Dean (BBN Technologies / Verizon), R. V. Guha (Alpiri Inc), Pat Hayes (IHMC), Sergey Melnik (Stanford University) 및 Martyn Horner (Profium Ltd).

이 명세는 Ora Lassilla와 Ralph Swick이 편집한 이전 RDF Model and Syntax 문서와, Dan Brickley 및 R. V. Guha가 편집한 RDF Schema에도 기반을 두고 있습니다. 이 이전 작업에 기여한 RDF 및 RDF Schema Working Group 구성원은 다음과 같습니다: Nick Arnett (Verity), Tim Berners-Lee (W3C), Tim Bray (Textuality), Dan Brickley (ILRT / University of Bristol), Walter Chang (Adobe), Sailesh Chutani (Oracle), Dan Connolly (W3C), Ron Daniel (DATAFUSION), Charles Frankston (Microsoft), Patrick Gannon (CommerceNet), R. V. Guha (Epinions, previously of Netscape Communications), Tom Hill (Apple Computer), Arthur van Hoff (Marimba), Renato Iannella (DSTC), Sandeep Jain (Oracle), Kevin Jones, (InterMind), Emiko Kezuka (Digital Vision Laboratories), Joe Lapp (webMethods Inc.), Ora Lassila (Nokia Research Center), Andrew Layman (Microsoft), Ralph LeVan (OCLC), John McCarthy (Lawrence Berkeley National Laboratory), Chris McConnell (Microsoft), Murray Maloney (Grif), Michael Mealling (Network Solutions), Norbert Mikula (DataChannel), Eric Miller (OCLC), Jim Miller (W3C, emeritus), Frank Olken (Lawrence Berkeley National Laboratory), Jean Paoli (Microsoft), Sri Raghavan (Digital/Compaq), Lisa Rein (webMethods Inc.), Paul Resnick (University of Michigan), Bill Roberts (KnowledgeCite), i Tsuyoshi Sakata (Digital Vision Laboratories), Bob Schloss (IBM), Leon Shklar (Pencom Web Works), David Singer (IBM), Wei (William) Song (SISU), Neel Sundaresan (IBM), Ralph Swick (W3C), Naohiko Uramoto (IBM), Charles Wicksteed (Reuters Ltd.), Misha Wolf (Reuters Ltd.) 및 Lauren Wood (SoftQuad).

G.2 RDF 1.1에 대한 감사의 말

이 섹션은 비규범적입니다.

RDF 1.1 버전 명세의 편집자는 Richard Cyganiak (DERI), David Wood (3 Round Stones), 및 Markus Lanthaler (Graz University of Technology)였습니다.

편집자들은 Thomas Baker, Tim Berners-Lee, David Booth, Dan Brickley, Gavin Carothers, Jeremy Carroll, Pierre-Antoine Champin, Dan Connolly, John Cowan, Martin J. Dürst, Alex Hall, Steve Harris, Sandro Hawke, Pat Hayes, Ivan Herman, Peter F. Patel-Schneider, Addison Phillips, Eric Prud'hommeaux, Nathan Rixham, Andy Seaborne, Leif Halvard Silli, Guus Schreiber, Dominik Tomaszuk, 및 Antoine Zimmermann의 귀중한 기여에 감사드립니다.

RDF Working Group 구성원에는 Thomas Baker, Scott Bauer, Dan Brickley, Gavin Carothers, Pierre-Antoine Champin, Olivier Corby, Richard Cyganiak, Souripriya Das, Ian Davis, Lee Feigenbaum, Fabien Gandon, Charles Greer, Alex Hall, Steve Harris, Sandro Hawke, Pat Hayes, Ivan Herman, Nicholas Humfrey, Kingsley Idehen, Gregg Kellogg, Markus Lanthaler, Arnaud Le Hors, Peter F. Patel-Schneider, Eric Prud'hommeaux, Yves Raimond, Nathan Rixham, Guus Schreiber, Andy Seaborne, Manu Sporny, Thomas Steiner, Ted Thibodeau, Mischa Tuffield, William Waites, Jan Wielemaker, David Wood, Zhe Wu, 및 Antoine Zimmermann이 포함되었습니다.

G.3 RDF 1.2에 대한 감사의 말

이 섹션은 비규범적입니다.

편집자 외에도, 다음 사람들이 이 명세에 기여했습니다: Denis Ah-Kang, doerthe, Dominik Tomaszuk, Enrico Franconi, james anderson, Niklas Lindström, Peter F. Patel-Schneider, Ruben Taelman, Sarven Capadisli, Ted Thibodeau Jr, Thomas Tanon, and William Van Woensel

RDF & SPARQL Working Group Group 구성원에는 다음이 포함되었습니다: Vladimir Alexiev, James Anderson, Amin Anjomshoaa, Julián Arenas-Guerrero, Dörthe Arndt, Bilal Ben Mahria, Erich Bremer, Dan Brickley, Kurt Cagle, Sarven Capadisli, Rémi Ceres, Pierre-Antoine Champin, David Chaves-Fraga, Souripriya Das, Daniil Dobriy, Enrico Franconi, Jeffrey Phillips Freeman, Fabien Gandon, Benjamin Goering, Damien Graux, Adrian Gschwend, Olaf Hartig, Timothée Haudebourg, Ian Horrocks, Gregg Kellogg, Mark Kim, Jose Emilio Labra Gayo, Ora Lassila, Richard Lea, Niklas Lindström, Pasquale Lisena, Thomas Lörtsch, Matthew Nguyen, Peter Patel-Schneider, Thomas Pellissier Tanon, Dave Raggett, Jean-Yves ROSSI, Felix Sasaki, Andy Seaborne, Alan Snyder, Stuart Sutton, Ruben Taelman, Ted Thibodeau Jr, Dominik Tomaszuk, Raphaël Troncy, William Van Woensel, Gregory Williams, Jesse Wright, Achille Zappa, 및 Antoine Zimmermann.

편집자 참고

Task Force 구성원을 인정하시겠습니까? 기여자 목록을 찾기가 쉽지 않습니다.

H. RDF 1.1과 RDF 1.2 사이의 변경사항

이 섹션은 비규범적입니다.

참고

RDF 버전 1.1과 1.2 사이의 차이에 대한 자세한 개요는 What’s New in RDF 1.2 [RDF12-NEW]에서 확인할 수 있습니다.

I. 색인

I.1 이 명세에서 정의한 용어

I.2 참조로 정의된 용어

J. 참조

J.1 규범적 참조

[BCP47]
언어 식별을 위한 태그. A. Phillips, Ed.; M. Davis, Ed. IETF. 2009년 9월. 현행 모범 사례. URL: https://www.rfc-editor.org/rfc/rfc5646
[DOM]
DOM 표준. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[HTML5]
HTML5. Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 2018년 3월 27일. W3C 권고안. URL: https://www.w3.org/TR/html5/
[I18N-GLOSSARY]
국제화 용어집. Richard Ishida; Addison Phillips. W3C. 2024년 10월 17일. W3C 작업 그룹 노트. URL: https://www.w3.org/TR/i18n-glossary/
[INFRA]
Infra 표준. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[RDF11-TESTCASES]
RDF 1.1 테스트 케이스. Gregg Kellogg; Markus Lanthaler. W3C. 2014년 2월 25일. W3C 작업 그룹 노트. URL: https://www.w3.org/TR/rdf11-testcases/
[RFC2119]
RFC에서 요구사항 수준을 나타내는 데 사용하는 핵심 단어. S. Bradner. IETF. 1997년 3월. 현행 모범 사례. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3629]
UTF-8, ISO 10646의 변환 형식. F. Yergeau. IETF. 2003년 11월. 인터넷 표준. URL: https://www.rfc-editor.org/rfc/rfc3629
[RFC3986]
Uniform Resource Identifier (URI): 일반 구문. T. Berners-Lee; R. Fielding; L. Masinter. IETF. 2005년 1월. 인터넷 표준. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC3987]
Internationalized Resource Identifiers (IRI). M. Duerst; M. Suignard. IETF. 2005년 1월. 제안 표준. URL: https://www.rfc-editor.org/rfc/rfc3987
[RFC7493]
I-JSON 메시지 형식. T. Bray, Ed. IETF. 2015년 3월. 제안 표준. URL: https://www.rfc-editor.org/rfc/rfc7493
[RFC8174]
RFC 2119 핵심 단어에서 대문자와 소문자의 모호성. B. Leiba. IETF. 2017년 5월. 현행 모범 사례. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8259]
JavaScript Object Notation (JSON) 데이터 교환 형식. T. Bray, Ed. IETF. 2017년 12월. 인터넷 표준. URL: https://www.rfc-editor.org/rfc/rfc8259
[RFC8615]
Well-Known Uniform Resource Identifiers (URI). M. Nottingham. IETF. 2019년 5월. 제안 표준. URL: https://www.rfc-editor.org/rfc/rfc8615
[Unicode]
Unicode 표준. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
[XML-NAMES]
XML 1.0의 네임스페이스(제3판). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 2009년 12월 8일. W3C 권고안. URL: https://www.w3.org/TR/xml-names/
[XML11]
Extensible Markup Language (XML) 1.1 (제2판). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau; John Cowan et al. W3C. 2006년 8월 16일. W3C 권고안. URL: https://www.w3.org/TR/xml11/
[XMLSCHEMA11-2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: 데이터형. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 2012년 4월 5일. W3C 권고안. URL: https://www.w3.org/TR/xmlschema11-2/

J.2 정보성 참조

[ABNF]
구문 명세를 위한 확장 BNF: ABNF. D. Crocker, Ed.; P. Overell. IETF. 2008년 1월. 인터넷 표준. URL: https://www.rfc-editor.org/rfc/rfc5234
[COOLURIS]
Semantic Web을 위한 Cool URI. Leo Sauermann; Richard Cyganiak. W3C. 2008년 12월 3일. W3C 작업 그룹 노트. URL: https://www.w3.org/TR/cooluris/
[did-core]
Decentralized Identifiers (DID) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 2022년 7월 19일. W3C 권고안. URL: https://www.w3.org/TR/did-core/
[HTML]
HTML 표준. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[HTML-RDFA]
HTML+RDFa 1.1 - 제2판. Manu Sporny. W3C. 2015년 3월 17일. W3C 권고안. URL: https://www.w3.org/TR/html-rdfa/
[JSON-LD11]
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 2020년 7월 16일. W3C 권고안. URL: https://www.w3.org/TR/json-ld11/
[LINKED-DATA]
Linked Data 설계 이슈. Tim Berners-Lee. W3C. 2006년 7월 27일. W3C 내부 문서. URL: https://www.w3.org/DesignIssues/LinkedData.html
[OWL2-OVERVIEW]
OWL 2 Web Ontology Language 문서 개요 (제2판). W3C OWL Working Group. W3C. 2012년 12월 11일. W3C 권고안. URL: https://www.w3.org/TR/owl2-overview/
[OWL2-SYNTAX]
OWL 2 Web Ontology Language 구조 명세 및 함수형 구문(제2판). Boris Motik; Peter Patel-Schneider; Bijan Parsia. W3C. 2012년 12월 11일. W3C 권고안. URL: https://www.w3.org/TR/owl2-syntax/
[RDF-CANON]
RDF 데이터셋 정규화. Gregg Kellogg; Dave Longley; Dan Yamamoto. W3C. 2024년 5월 21일. W3C 권고안. URL: https://www.w3.org/TR/rdf-canon/
[RDF-CONCEPTS-20040210]
Resource Description Framework (RDF): 개념 및 추상 구문. Graham Klyne; Jeremy Carroll. W3C. 2004년 2월 10일. W3C 권고안. URL: https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
[RDF11-CONCEPTS]
RDF 1.1 개념 및 추상 구문. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 2014년 2월 25일. W3C 권고안. URL: https://www.w3.org/TR/rdf11-concepts/
[RDF11-DATASETS]
RDF 1.1: RDF 데이터셋의 의미론에 대하여. Antoine Zimmermann. W3C. 2014년 2월 25일. W3C 작업 그룹 노트. URL: https://www.w3.org/TR/rdf11-datasets/
[RDF11-MT]
RDF 1.1 의미론. Patrick Hayes; Peter Patel-Schneider. W3C. 2014년 2월 25일. W3C 권고안. URL: https://www.w3.org/TR/rdf11-mt/
[RDF12-INTEROP]
RDF 1.2 상호운용성. Pierre-Antoine Champin. W3C. W3C 편집자 초안. URL: https://w3c.github.io/rdf-interop/spec/
[RDF12-N-QUADS]
RDF 1.2 N-Quads. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026년 3월 20일. W3C 작업 초안. URL: https://www.w3.org/TR/rdf12-n-quads/
[RDF12-N-TRIPLES]
RDF 1.2 N-Triples. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026년 3월 26일. W3C 작업 초안. URL: https://www.w3.org/TR/rdf12-n-triples/
[RDF12-NEW]
RDF 1.2의 새로운 기능. The W3C RDF & SPARQL Working Group. W3C. W3C 편집자 초안. URL: https://w3c.github.io/rdf-new/spec/
[RDF12-PRIMER]
RDF 1.2 입문서. Niklas Lindström; Pierre-Antoine Champin. W3C. 2025년 4월 3일. DNOTE. URL: https://www.w3.org/TR/rdf12-primer/
[RDF12-SCHEMA]
RDF 1.2 Schema. Dominik Tomaszuk. W3C. 2026년 3월 20일. W3C 작업 초안. URL: https://www.w3.org/TR/rdf12-schema/
[RDF12-SEMANTICS]
RDF 1.2 의미론. Peter Patel-Schneider; Dörthe Arndt; Enrico Franconi. W3C. 2026년 3월 26일. W3C 작업 초안. URL: https://www.w3.org/TR/rdf12-semantics/
[RDF12-TRIG]
RDF 1.2 TriG. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026년 3월 20일. W3C 작업 초안. URL: https://www.w3.org/TR/rdf12-trig/
[RDF12-TURTLE]
RDF 1.2 Turtle. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026년 3월 20일. W3C 작업 초안. URL: https://www.w3.org/TR/rdf12-turtle/
[RDF12-XML]
RDF 1.2 XML 구문. Gregg Kellogg; Jerven Bolleman. W3C. 2026년 3월 26일. W3C 작업 초안. URL: https://www.w3.org/TR/rdf12-xml/
[RDFA-CORE]
RDFa Core 1.1 - 제3판. Ben Adida; Mark Birbeck; Shane McCarron; Ivan Herman et al. W3C. 2015년 3월 17일. W3C 권고안. URL: https://www.w3.org/TR/rdfa-core/
[RFC3023]
XML 미디어 타입. M. Murata; S. St. Laurent; D. Kohn. IETF. 2001년 1월. 제안 표준. URL: https://www.rfc-editor.org/rfc/rfc3023
[RFC5890]
애플리케이션을 위한 국제화 도메인 이름 (IDNA): 정의 및 문서 프레임워크. J. Klensin. IETF. 2010년 8월. 제안 표준. URL: https://www.rfc-editor.org/rfc/rfc5890
[RFC5892]
애플리케이션을 위한 Unicode 코드 포인트 및 국제화 도메인 이름(IDNA). P. Faltstrom, Ed. IETF. 2010년 8월. 제안 표준. URL: https://www.rfc-editor.org/rfc/rfc5892
[RFC6874]
주소 리터럴 및 Uniform Resource Identifier에서 IPv6 구역 식별자 표현하기. B. Carpenter; S. Cheshire; R. Hinden. IETF. 2013년 2월. 제안 표준. URL: https://www.rfc-editor.org/rfc/rfc6874
[rfc7230]
Hypertext Transfer Protocol (HTTP/1.1): 메시지 구문 및 라우팅. R. Fielding, Ed.; J. Reschke, Ed. IETF. 2014년 6월. 제안 표준. URL: https://httpwg.org/specs/rfc7230.html
[SPARQL11-QUERY]
SPARQL 1.1 질의 언어. Steven Harris; Andy Seaborne. W3C. 2013년 3월 21일. W3C 권고안. URL: https://www.w3.org/TR/sparql11-query/
[SPARQL12-CONCEPTS]
SPARQL 1.2 개념. The W3C RDF & SPARQL Working Group. W3C. W3C 편집자 초안. URL: https://w3c.github.io/sparql-concepts/spec/
[SPARQL12-ENTAILMENT]
SPARQL 1.2 함의 체제. Peter Patel-Schneider. W3C. 2025년 8월 14일. W3C 작업 초안. URL: https://www.w3.org/TR/sparql12-entailment/
[SPARQL12-FEDERATED-QUERY]
SPARQL 1.2 연합 질의. Ruben Taelman; Gregory Williams. W3C. 2026년 1월 26일. W3C 작업 초안. URL: https://www.w3.org/TR/sparql12-federated-query/
[SPARQL12-GRAPH-STORE-PROTOCOL]
SPARQL 1.2 Graph Store Protocol. Andy Seaborne; Thomas Pellissier Tanon. W3C. 2024년 12월 19일. W3C 작업 초안. URL: https://www.w3.org/TR/sparql12-graph-store-protocol/
[SPARQL12-NEW]
SPARQL 1.2의 새로운 기능. The W3C RDF & SPARQL Working Group. W3C. W3C 편집자 초안. URL: https://w3c.github.io/sparql-new/spec/
[SPARQL12-PROTOCOL]
SPARQL 1.2 Protocol. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2025년 8월 14일. W3C 작업 초안. URL: https://www.w3.org/TR/sparql12-protocol/
[SPARQL12-QUERY]
SPARQL 1.2 질의 언어. Olaf Hartig; Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026년 3월 23일. W3C 작업 초안. URL: https://www.w3.org/TR/sparql12-query/
[SPARQL12-RESULTS-CSV-TSV]
SPARQL 1.2 질의 결과 CSV 및 TSV 형식. Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2025년 8월 14일. W3C 작업 초안. URL: https://www.w3.org/TR/sparql12-results-csv-tsv/
[SPARQL12-RESULTS-JSON]
SPARQL 1.2 질의 결과 JSON 형식. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2025년 8월 14일. W3C 작업 초안. URL: https://www.w3.org/TR/sparql12-results-json/
[SPARQL12-RESULTS-XML]
SPARQL 1.2 질의 결과 XML 형식. Ruben Taelman; Dominik Tomaszuk; Thomas Pellissier Tanon. W3C. 2024년 12월 27일. W3C 작업 초안. URL: https://www.w3.org/TR/sparql12-results-xml/
[SPARQL12-SERVICE-DESCRIPTION]
SPARQL 1.2 서비스 설명. Ruben Taelman; Gregory Williams. W3C. 2026년 3월 19일. W3C 작업 초안. URL: https://www.w3.org/TR/sparql12-service-description/
[SPARQL12-UPDATE]
SPARQL 1.2 Update. Ruben Taelman; Andy Seaborne; Thomas Pellissier Tanon. W3C. 2025년 8월 14일. W3C 작업 초안. URL: https://www.w3.org/TR/sparql12-update/
[STRING-META]
웹의 문자열: 언어 및 방향 메타데이터. Richard Ishida; Addison Phillips. W3C. 2024년 10월 17일. W3C 작업 그룹 노트. URL: https://www.w3.org/TR/string-meta/
[SWBP-N-ARYRELATIONS]
Semantic Web에서 N-항 관계 정의하기. Natasha Noy; Alan Rector. W3C. 2006년 4월 12일. W3C 작업 그룹 노트. URL: https://www.w3.org/TR/swbp-n-aryRelations/
[SWBP-XSCH-DATATYPES]
RDF 및 OWL에서의 XML Schema 데이터형. Jeremy Carroll; Jeff Pan. W3C. 2006년 3월 14일. W3C 작업 그룹 노트. URL: https://www.w3.org/TR/swbp-xsch-datatypes/
[UNICODE-SECURITY]
Unicode 보안 고려사항. Mark Davis; Michel Suignard. Unicode Consortium. 2014년 9월 19일. Unicode 기술 보고서 #36. URL: https://www.unicode.org/reports/tr36/tr36-15.html
[URL]
URL 표준. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[VOCAB-ORG]
조직 온톨로지. Dave Reynolds. W3C. 2014년 1월 16일. W3C 권고안. URL: https://www.w3.org/TR/vocab-org/
[WEBARCH]
월드 와이드 웹의 아키텍처, 제1권. Ian Jacobs; Norman Walsh. W3C. 2004년 12월 15일. W3C 권고안. URL: https://www.w3.org/TR/webarch/