RDF 1.2 Turtle

간결한 RDF 트리플 언어

W3C 작업 초안

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2026/WD-rdf12-turtle-20260612/
최신 공개 버전:
https://www.w3.org/TR/rdf12-turtle/
최신 편집자 초안:
https://w3c.github.io/rdf-turtle/spec/
이력:
https://www.w3.org/standards/history/rdf12-turtle/
커밋 이력
테스트 스위트:
https://w3c.github.io/rdf-tests/rdf/rdf12/rdf-turtle/
최신 권고안:
https://www.w3.org/TR/turtle
편집자:
Gregg Kellogg (2025-09-06까지), 추모
Andy Seaborne
Dominik Tomaszuk
이전 편집자:
Eric Prud'hommeaux (RDF 1.1)
Gavin Carothers (RDF 1.1)
저자:
David Beckett
Tim Berners-Lee (W3C)
Eric Prud'hommeaux (W3C)
Gavin Carothers (Lex Machina, Inc)
피드백:
GitHub w3c/rdf-turtle (pull requests, 새 이슈, 열린 이슈)
public-rdf-star-wg@w3.org 제목 줄에 [rdf12-turtle] … 메시지 주제 … 포함 (아카이브)

초록

리소스 기술 프레임워크 (RDF)는 웹에서 정보를 표현하기 위한 범용 언어입니다.

이 문서는 Turtle이라고 하는 RDF의 텍스트 구문을 정의하며, 이는 RDF 그래프를 일반적인 사용 패턴과 데이터형에 대한 축약을 사용하여, 간결하고 자연스러운 텍스트 형식으로 완전히 작성할 수 있게 한다. Turtle은 N-Triples [RDF12-N-TRIPLES] 형식뿐 아니라 SPARQL 1.2 Query Language W3C 권고안의 트리플 패턴 구문과도 일정 수준의 호환성을 제공한다.

RDF 1.2 Turtle은 트리플 용어RDF 용어의 네 번째 종류로 도입하며, 이는 다른 트리플객체로 사용될 수 있어, 다른 진술에 대한 진술을 할 수 있게 한다. 트리플 용어는 일반적으로 명시적으로 사용되지 않으며, 보통 reifiedTriple 구성이 선호된다. RDF 1.2 Turtle은 또한 방향성이 있는 언어 태그 문자열을 지원한다.

또한 RDF 1.2 Turtle은 주석 구문을 도입하며, 이를 통해 트리플 용어도 단언할 수 있다.

이 문서의 상태

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

이 문서는 RDF 1.2 문서 모음의 일부이다. 이 문서는 RDF [RDF12-CONCEPTS]를 위한 구체적 구문인 간결한 RDF 트리플 언어, Turtle을 정의한다.

이 문서는 RDF & SPARQL 작업 그룹권고안 트랙을 사용하여 작업 초안으로 공개하였다.

작업 초안으로 공개되었다고 해서 W3C와 그 회원들의 승인을 의미하지는 않는다.

이 문서는 초안 문서이며 언제든지 다른 문서로 업데이트, 대체 또는 폐기될 수 있다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 적절하지 않다. 앞으로 이 권고안의 업데이트에는 새 기능이 포함될 수 있다.

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

이 문서는 2025년 8월 18일 W3C 프로세스 문서의 적용을 받는다.

1. 소개

이 절은 비규범적입니다.

이 문서는 RDF [RDF12-CONCEPTS]를 위한 구체적 구문인 간결한 RDF 트리플 언어 Turtle을 정의한다.

Turtle 문서RDF 그래프의 텍스트 표현이다. 다음 Turtle 문서는 Green Goblin과 Spiderman 사이의 관계를 설명한다.

예제 1: Turtle 예제

BASE <http://example.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX rel: <http://www.perceive.net/schemas/relationship/>

<#green-goblin>
  rel:enemyOf <#spiderman> ;
  a foaf:Person ;    # in the context of the Marvel universe
  foaf:name "Green Goblin" .

<#spiderman>
  rel:enemyOf <#green-goblin> ;
  a foaf:Person ;
  foaf:name "Spiderman", "Человек-паук"@ru .

이 예제는 Turtle 언어의 여러 기능을 소개한다: BASE와 상대 IRI 참조, PREFIX와 접두 이름, 술어 목록;로 구분되고, 객체 목록,로 구분되며, 토큰 a, 그리고 리터럴.

triples에 대한 Turtle 문법은 TriplesBlock에 대한 SPARQL 1.2 Query Language [SPARQL12-QUERY] 문법의 부분집합이다. 두 문법은 가능한 경우 생성 규칙과 터미널 이름을 공유한다.

Turtle 문서로부터 RDF 그래프를 구성하는 방식은 Turtle 문법파싱에서 정의한다.

2. Turtle 언어

이 절은 비규범적입니다.

Turtle 문서RDF 그래프를 간결한 텍스트 형식으로 작성할 수 있게 한다. RDF 그래프는 주어, 술어, 객체로 구성되는 트리플로 이루어진다.

주석은 다른 어휘 토큰의 일부가 아닌 # 뒤에 올 수 있으며, 줄 끝까지 계속된다.

2.1 단순 트리플

가장 단순한 트리플 문은 (주어, 술어, 그리고 객체) 용어의 시퀀스이며, RDF 트리플을 형성하고, 마침표(.)로 끝난다. 공백 (공백 문자, , LF, 및/또는 CR)은 용어 주위에 올 수 있다. 단, 문법에서 명시한 것처럼 의미가 있는 경우는 예외이다.

예제 2: 단순 트리플

<http://example.org/#spiderman>
  <http://www.perceive.net/schemas/relationship/enemyOf>
    <http://example.org/#green-goblin> .

2.2 술어 목록

동일한 주어가 여러 술어에 의해 참조되는 경우가 많다. predicateObjectList 생성 규칙은 주어 뒤에 오는, ;로 구분된 일련의 술어와 객체에 일치한다. 이는 해당 주어를 가진 일련의 RDF 트리플을 표현하며, 각 술어와 객체가 하나의 트리플에 할당된다. 따라서 ;는 술어와 객체 RDF 용어만 달라지는 트리플들의 주어를 반복하는 데 사용된다.

이 두 예제는 Spiderman에 관한 트리플을 작성하는 동등한 방식이다.

예제 3: 술어 목록

<http://example.org/#spiderman> <http://www.perceive.net/schemas/relationship/enemyOf> <http://example.org/#green-goblin> ;
  <http://xmlns.com/foaf/0.1/name> "Spiderman" .
예제 4: 술어 목록을 단순 트리플로 확장한 것

<http://example.org/#spiderman> <http://www.perceive.net/schemas/relationship/enemyOf> <http://example.org/#green-goblin> .
<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Spiderman" .

2.3 객체 목록

술어와 마찬가지로, 동일한 주어와 술어가 서로 다른 객체와 함께 반복되는 경우가 많다. objectList 생성 규칙은 술어 뒤에 오는, ,로 구분된 일련의 객체에 일치한다. 이는 동일한 주어와 술어를 가진 일련의 RDF 트리플을 표현하며, 각 객체가 하나의 트리플에 할당된다. 따라서 ,는 객체 RDF 용어만 다른 트리플들의 주어와 술어를 반복하는 데 사용된다.

이 두 예제는 두 언어로 된 Spiderman의 이름을 작성하는 동등한 방식이다.

예제 5: 객체 목록

<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Spiderman", "Человек-паук"@ru .
예제 6: 객체 목록을 단순 트리플로 확장한 것

<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Spiderman" .
<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Человек-паук"@ru .

RDF 개념에서 정의된 RDF 용어는 네 가지이다: IRI (국제화 리소스 식별자), 리터럴, 빈 노드, 그리고 트리플 용어; Turtle은 각각을 작성하는 여러 방법을 제공한다.

2.4 버전 선언

Turtle 언어는 처음 등장한 이후 발전해 왔으며, RDF 1.2는 새로운 구문을 추가한다. RDF 1.2 Turtle은 선택적 version 미디어 유형 매개변수와 함께 VERSION@version 지시자를 도입한다. 초기 텍스트 방향 또는 트리플 용어와 같은 새 기능으로 Turtle을 직렬화할 때, 저자는 이러한 지시자를 사용하여 새 구문 형식의 사용을 선언할 수 있다.

예제 7: 버전 선언

VERSION "1.2"
PREFIX : <http://example.com/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
:a :name "Alice" ~ :t {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .

또는 이전 스타일의 지시자를 사용할 수 있다 (뒤에 "."가 붙는다는 점에 유의):

예제 8: 이전 스타일 버전 선언

@version "1.2" .
@prefix : <http://example.com/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
:a :name "Alice" ~ :t {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .

HTTP를 통해 콘텐츠를 제공할 때 서버는 선택적 version 미디어 유형 매개변수를 사용하여 버전을 선언할 수 있다:

예제 9: Turtle 버전 1.2 응답을 선언하는 HTTP 응답

HTTP/1.1 200 OK
Content-Type: text/turtle; version=1.2

초기 텍스트 방향과 같은 RDF 1.2 전용 기능을 사용할 때에는, 문서 초반에 VERSION 또는 @version 지시자를 사용하여 특정 RDF 버전을 선언해야 한다. 이를 통해 이러한 기능을 지원하지 않는 파서가 그런 기능의 존재를 일찍 감지하고, 잠재적으로 사용자에게 알려 작업을 중지하거나 입력 데이터의 일부가 원하는 대로 처리되지 않을 것이라는 사실에 대응할 기회를 줄 수 있다.

Turtle 문서에는 여러 버전 지시자가 나타날 수 있다. 지시자는 해당 지시자 뒤의 문서 부분에 적용되며, 다른 지시자가 나타나거나 문서 끝에 도달할 때까지 유효하다.

현재 버전 지시자가 없는 경우, 미디어 유형의 일부로 지정된 모든 버전이 고려된다. 버전 정보가 전혀 없는 경우, 이전 Turtle 버전 [TURTLE]과의 호환성을 극대화하기 위해 적절한 기본값은 "1.1"이다. 어떤 경우에도 버전 선언은 단지 힌트일 뿐이다; 파서는 선언된 버전 밖의 기능을 반드시 거부해야 하는 것은 아니다 (다만 경고로 표시할 수는 있다).

참고
버전 레이블은 RDF 1.2 Concepts and Abstract Data Model2.1 버전 레이블 절에서 정의한다. 처리기는 인식되지 않는 레이블을 오류 또는 경고로 처리할 수 있다.

"1.1"은 허용되는 버전 레이블이지만, VERSION 또는 @version 지시자에서 이를 사용하는 것은 권장되지 않는다. 이는 Turtle 1.1 파서를 불필요하게 실패하게 만들 수 있기 때문이다.

2.5 IRI

IRI해결된 IRI, 상대 IRI 참조, 또는 접두 이름으로 작성할 수 있다. 상대 및 해결된 IRI는 <로 시작하고, >가 뒤따르며, 숫자 이스케이프 시퀀스(아래 설명)를 포함할 수 있다. 예: <http://example.org/#green-goblin>.

<#green-goblin> 같은 상대 IRI 참조는 현재 기준 IRI에 상대적으로 해결된다. 새 기준 IRI는 @base 또는 BASE 지시자를 사용하여 정의할 수 있다. 이 작업의 세부 사항은 6.3 IRI 참조에서 정의한다.

Turtle 트리플의 술어 위치에 있는 토큰 a는 IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#type을 나타낸다.

접두 이름은 접두사 레이블과 로컬 부분으로 이루어지며, :로 구분된다. 접두 이름은 접두사와 연결된 IRI와 로컬 부분을 이어 붙여 IRI로 변환된다. @prefix 또는 PREFIX 지시자는 접두사 레이블을 IRI와 연결한다. 뒤따르는 @prefix 또는 PREFIX 지시자는 동일한 접두사 레이블을 다시 매핑할 수 있다.

참고

Turtle 언어는 원래 접두사와 기준 지시자를 작성할 때 @ 문자를 포함하는 구문만 허용했다. 대소문자를 구분하지 않는 PREFIX, BASE, 및 VERSION 형식은 Turtle 구문을 SPARQL의 구문과 맞추기 위해 추가되었다. 원래 지시자인 @prefix, @base, 또는 @version도 사용할 수 있다. PREFIX, BASE, 및 VERSION를 사용하면 선언을 SPARQL 질의로 복사하기 더 쉬울 수 있다.

접두 이름을 사용하여 http://www.perceive.net/schemas/relationship/enemyOf를 작성하려면:

  1. 어휘 IRI http://www.perceive.net/schemas/relationship/에 대한 접두사 레이블을 somePrefix로 정의한다
  2. 그런 다음 somePrefix:enemyOf를 작성한다. 이는 <http://www.perceive.net/schemas/relationship/enemyOf>를 작성하는 것과 동등하다

이는 접두사 선언에 대한 SPARQL 스타일 구문을 사용하여 작성할 수 있다:

예제 10: 접두사 선언을 위한 SPARQL 구문

PREFIX somePrefix: <http://www.perceive.net/schemas/relationship/>

<http://example.org/#green-goblin> somePrefix:enemyOf <http://example.org/#spiderman> .

또는 접두사 선언을 위한 원래 Turtle 구문으로 작성할 수 있다:

예제 11: 접두사 선언을 위한 원래 구문

@prefix somePrefix: <http://www.perceive.net/schemas/relationship/> .

<http://example.org/#green-goblin> somePrefix:enemyOf <http://example.org/#spiderman> .
참고

접두 이름은 XML QName의 상위집합이다. 차이점은 접두 이름의 로컬 부분에 다음을 포함할 수 있다는 점이다:

다음 Turtle 문서는 Turtle에서 IRI를 작성하는 서로 다른 모든 방식의 예를 포함한다.

예제 12: IRI를 작성하는 여러 방식

# A triple with all resolved IRIs
<http://one.example/subject1> <http://one.example/predicate1> <http://one.example/object1> .

@base <http://one.example/> .
<subject2> <predicate2> <object2> .     # relative IRI references, e.g., http://one.example/subject2

BASE <http://one.example/>
<subject2> <predicate2> <object2> .     # relative IRI references, e.g., http://one.example/subject2

@prefix p: <http://two.example/> .
p:subject3 p:predicate3 p:object3 .     # prefixed name, e.g., http://two.example/subject3

PREFIX p: <http://two.example/>
p:subject3 p:predicate3 p:object3 .     # prefixed name, e.g., http://two.example/subject3

@prefix p: <path/> .                    # prefix p: now stands for http://one.example/path/
p:subject4 p:predicate4 p:object4 .     # prefixed name, e.g., http://one.example/path/subject4

PrEfIx : <http://another.example/>       # empty prefix
:subject5 :predicate5 :object5 .        # prefixed name, e.g., http://another.example/subject5

:subject6 a :subject7 .                 # same as :subject6 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> :subject7 .

<http://伝言.example/?user=أ&channel=R%26D> a :subject8 . # a multi-script subject IRI .
참고

@prefix@base 지시자는 IRI 뒤에 후행 .가 필요하지만, 이에 대응하는 PREFIXBASE에는 지시자의 IRI 부분 뒤에 후행 .가 없다. PREFIXBASE는 대소문자를 구분하지 않으며, prefixbase로 또는 대소문자를 섞은 어떤 조합으로도 작성할 수 있다.

2.6 RDF 리터럴

리터럴은 문자열, 숫자, 날짜와 같은 값을 식별하는 데 사용된다.

예제 13: Turtle의 리터럴

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

<http://example.org/#green-goblin> foaf:name "Green Goblin" .

<http://example.org/#spiderman> foaf:name "Spiderman" .

2.6.1 따옴표로 묶인 리터럴

따옴표로 묶인 리터럴(문법 생성 규칙 RDFLiteral)은 어휘 형식 뒤에 언어 태그 (선택적으로 초기 텍스트 방향 포함), 데이터형 IRI, 또는 둘 다 없는 형태를 가진다.

어휘 형식의 표현은 시작 구분자 (예: ", ', """, 또는 '''); 허용된 문자, 숫자 이스케이프 시퀀스, 및/또는 문자열 이스케이프 시퀀스의 시퀀스; 그리고 시작 구분자와 일치하는 끝 구분자로 구성된다. 이에 대응하는 RDF 어휘 형식은 이스케이프 시퀀스를 처리한 뒤 구분자 사이에 있는 문자들이다.

존재하는 경우, 언어 태그 앞에는 @가 오며, 언어 태그와 --로 구분된 초기 텍스트 방향이 뒤따를 수 있다.

언어 태그가 없으면 데이터형 IRI가 있을 수 있으며, 그 앞에는 ^^가 온다. Turtle의 데이터형 IRI는 해결된 IRI, 상대 IRI 참조, 또는 접두 이름을 사용하여 작성할 수 있다.

데이터형 IRI와 언어 태그가 모두 없으면, 데이터형은 xsd:string이다.

\는 이스케이프 시퀀스의 일부가 아닌 한 어떤 따옴표 리터럴에도 나타날 수 없다. 그 밖의 제한은 구분자에 따라 다르다:

  • '로 구분된 리터럴은 이스케이프되지 않은 ', LF, 또는 CR 문자를 포함할 수 없다.
  • "로 구분된 리터럴은 이스케이프되지 않은 ", LF, 또는 CR 문자를 포함할 수 없다.
  • '''로 구분된 리터럴은 그러한 시퀀스를 포함할 수 없다.
  • """로 구분된 리터럴은 그러한 시퀀스를 포함할 수 없다.
예제 14: 따옴표로 묶인 리터럴

VERSION "1.2"
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX show: <http://example.org/vocab/show/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

show:218 rdfs:label "That Seventies Show"^^xsd:string .                # literal with XML Schema string datatype
show:218 rdfs:label "That Seventies Show"^^<http://www.w3.org/2001/XMLSchema#string> . # same as above
show:218 rdfs:label "That Seventies Show" .                                            # same again
show:218 show:localName "That Seventies Show"@en .                     # literal with a language tag
show:218 show:localName "HTML היא שפת סימון."@he--rtl .                # literal with a language tag and initial text direction
show:218 show:localName "That Seventies Show"@en-us--ltr .             # literal with a language tag, region subtag, and initial text direction
show:218 show:localName 'Cette Série des Années Soixante-dix'@fr .     # literal delimited by single quote
show:218 show:localName "Cette Série des Années Septante"@fr-be .      # literal with a region subtag
show:218 show:blurb '''This is a multi-line
                       literal with many quotes (""""")
                       and up to two sequential apostrophes ('').''' . # literal with embedded new lines and quotes

2.6.2 숫자

숫자는 어휘 형식과 데이터형을 가진 다른 리터럴처럼 작성할 수 있다 (예: "-5.0"^^xsd:decimal). Turtle은 정수 값, 임의 정밀도 십진수 값, 그리고 배정밀도 부동소수점 값을 작성하기 위한 축약 구문을 가진다.

데이터형 축약형 어휘형 설명
xsd:integer -5 "-5"^^xsd:integer 정수 값은 선택적 부호와 일련의 숫자로 작성할 수 있다. 정수는 정규식 "[+-]?[0-9]+"에 일치한다.
xsd:decimal -5.0 "-5.0"^^xsd:decimal 임의 정밀도 십진수는 선택적 부호, 0개 이상의 숫자, 소수점, 그리고 하나 이상의 숫자로 작성할 수 있다. 십진수는 정규식 "[+-]?[0-9]*\.[0-9]+"에 일치한다.
xsd:double 4.2E9 "4.2E9"^^xsd:double 배정밀도 부동소수점 값은 선택적 부호가 있는 가수와 선택적 소수점, 문자 e 또는 문자 E, 그리고 선택적 부호가 있는 정수 지수로 작성할 수 있다. 지수는 정규식 "[+-]?[0-9]+"에 일치하고 가수는 다음 정규식 중 하나에 일치한다: "[+-]?[0-9]+\.[0-9]+", "[+-]?\.[0-9]+", 또는 "[+-]?[0-9]".
예제 15: 숫자 리터럴

PREFIX : <http://example.org/elements/>
<http://en.wikipedia.org/wiki/Helium>
    :atomicNumber 2 ;               # xsd:integer
    :atomicMass 4.002602 ;          # xsd:decimal
    :specificGravity 1.663E-4 .     # xsd:double

2.6.3 불리언

불리언 값은 true 또는 false로 작성할 수 있으며(대소문자 구분), 데이터형 xsd:boolean을 가진 RDF 리터럴을 나타낸다 [XMLSCHEMA11-2].

예제 16: 불리언 리터럴

PREFIX : <http://example.org/stats/>
<http://somecountry.example/census2007>
    :isLandlocked false .           # xsd:boolean

2.7 RDF 빈 노드

Turtle의 RDF 빈 노드_: 뒤에 일련의 문자로 이루어진 빈 노드 식별자가 오는 방식으로 표현된다. 식별자의 문자는 PN_CHARS_BASE를 기반으로 하며, 다음과 같이 완화된다:

문서에서 고유한 각 빈 노드 식별자마다 새로운 RDF 빈 노드가 할당된다. 같은 빈 노드 식별자를 반복해서 사용하면 동일한 빈 노드를 식별한다.

예제 17: Turtle의 빈 노드

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

_:alice foaf:knows _:bob .
_:bob foaf:knows _:alice .

2.8 빈 노드 식별자가 없는 빈 노드의 중첩

Turtle에서는 blankNodePropertyList 생성 규칙과 터미널 ANON에 일치할 때도 새로운 RDF 빈 노드가 할당된다. 이 둘은 모두 트리플의 subject 또는 object 위치에 나타날 수 있다 (Turtle 문법 참조). 해당 주어 또는 객체는 새로운 RDF 빈 노드이다. 이 빈 노드는 또한 blankNodePropertyList 안에 포함된 predicateObjectList 생성 규칙에 일치하여 생성되는 트리플들의 주어 역할도 한다. 이러한 트리플의 생성은 술어 목록에서 설명한다. 빈 노드는 아래에서 설명하는 컬렉션에 대해서도 할당된다.

예제 18: 빈 노드 속성 목록
  
  PREFIX foaf: <http://xmlns.com/foaf/0.1/>

  # Someone knows someone else, who has the name "Bob".
  [] foaf:knows [ foaf:name "Bob" ] .

Turtle 문법은 blankNodePropertyList가 중첩될 수 있게 한다. 이 경우 각 내부 [는 새 주어 빈 노드를 설정하며, 이는 ]에서 바깥 노드로 되돌아가고, 술어 객체 목록의 현재 주어로 작용한다.

blankNodePropertyList 안에서 predicateObjectList를 사용하는 것은 어떤 노드의 일련의 속성을 표현하는 일반적인 관용구이다.

축약형: 대응하는 단순 트리플:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

[ foaf:name "Alice" ] foaf:knows [
    foaf:name "Bob" ;
    foaf:knows [
        foaf:name "Eve" ] ;
    foaf:mbox <mailto:bob@example.com> ] .

_:a <http://xmlns.com/foaf/0.1/name> "Alice" .
_:a <http://xmlns.com/foaf/0.1/knows> _:b .
_:b <http://xmlns.com/foaf/0.1/name> "Bob" .
_:b <http://xmlns.com/foaf/0.1/knows> _:c .
_:c <http://xmlns.com/foaf/0.1/name> "Eve" .
_:b <http://xmlns.com/foaf/0.1/mbox> <mailto:bob@example.com> .

2.9 컬렉션

RDFRDF 노드 목록을 위한 컬렉션 [RDF12-SEMANTICS] 구조를 제공한다. 컬렉션에 대한 Turtle 구문은 RDF 용어의 비어 있을 수 있는 목록을 ()로 둘러싼 것이다. 이 컬렉션은 rdf:first/rdf:rest 목록 구조를 나타내며, () 안에 둘러싸인 용어의 순서가 rdf:first 문의 객체 시퀀스가 된다.

(…) 구문은 트리플의 subject 또는 object 위치에 나타나야 한다 (Turtle 문법 참조). 목록의 머리에 있는 빈 노드는 포함하는 트리플의 주어 또는 객체이다.

예제 21: Turtle의 컬렉션

PREFIX : <http://example.org/foo/>
# the object of this triple is the RDF collection blank node
:subject :predicate ( :a :b :c ) .

# an empty collection value - rdf:nil
:subject :predicate2 () .

2.10 트리플 용어

트리플 용어RDF 트리플객체가 될 수 있다.

트리플 용어ttSubject, predicate, 및 ttObject를 가진 tripleTerm으로 표현되며, 이들 모두 앞에는 <<(가 오고, 모두 뒤에는 )>>가 온다. 트리플 용어는 중첩될 수 있다는 점에 유의한다.

예제 22: 트리플 용어

VERSION     "1.2"
PREFIX :    <http://www.example.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

_:e38  :familyName                     "Smith" .
_:anno rdf:reifies <<( _:e38 :jobTitle "Designer" )>> .
_:anno :accordingTo                     _:e22 .

2.11 트리플 구체화

RDF에서 트리플 용어는 직접 사용되는 경우가 드물며, 일반적으로 rdf:reifies 술어를 사용하여 트리플객체로만 사용되도록 제한된다. 그러한 트리플은 구체화 트리플이라고 한다. Turtle은 reifiedTriple 생성 규칙을 사용하여 구체화 트리플을 작성하는 축약 표기법을 제공한다.

reifiedTriple구체화 트리플을 나타내는 구문적 설탕이며, 식별자(구체화자)와 트리플 용어 사이의 특정 관계를 정의한다. 이 식별자는 이 입력 문서에 대응하는 그래프 안에서 단언될 수도 있고 단언되지 않을 수도 있는 트리플 용어를 간접적으로 참조하는 방법이 된다.

참고

RDF 1.2의 구체화는 원래 RDF Semantics에서 정의된 구체화 어휘와는 구별되는 개념이다. 두 용어 모두 구성 요소를 사용하여 RDF 트리플을 표현하는 것을 설명하지만, RDF 1.2는 이 용어를 rdf:reifies 술어를 사용하여 트리플 용어를 식별하는 데 사용한다.

구체화 트리플reifiedTriple 생성 규칙을 사용하여 표현되며, <<로 시작하고, rtSubject, predicate, 및 rtObject가 뒤따르며, 선택적 reifier가 뒤따른다. 이는 ~와 그 뒤에 오는 선택적 iri 생성 규칙 또는 BlankNode 생성 규칙으로 구성되며, >>로 끝난다. 예: << :subject :predicate :object ~ :IRIREF >>. 구체화자가 없거나, reifier 바로 뒤에 iri 또는 BlankNode가 오지 않으면, << :subject :predicate :object >> 또는 << :subject :predicate :object ~ >>에서처럼 새로운 RDF 빈 노드가 할당된다.

참고

reifiedTriples는 다음처럼 중첩될 수 있다.
<< :subject1 :predicate1 << :subject2 :predicate2 :object2 >> ~:IRIREF1 >> 또는
<< :subject4 :predicate4 << :subject3 :predicate3 :object3 ~:IRIREF3 >> >>.

reifiedTripleIRI 또는 빈 노드로 식별되지 않으면, 새로운 RDF 빈 노드가 할당되어 이 관계를 식별하는 데 사용된다.

예제 23: 구체화된 트리플

VERSION     "1.2"
PREFIX :    <http://www.example.org/>

:employee38 :familyName "Smith" .
<< :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .
예제 24: 명시적 구체화자가 있는 구체화된 트리플

PREFIX :    <http://www.example.org/>

:employee38 :familyName "Smith" .
<< :employee38 :jobTitle "Assistant Designer" ~ _:id >> :accordingTo :employee22 .
예를 들어, 위 예제의 구문적 설탕은 다음과 동등하다:
예제 25: 구체화된 트리플을 트리플 용어로 확장한 것

PREFIX :    <http://www.example.org/>

:employee38 :familyName "Smith" .
_:id rdf:reifies <<( :employee38 :jobTitle "Assistant Designer" )>> .
_:id :accordingTo :employee22 .
참고

reifiedTriple의 구문적 설탕 (즉, << [...] >>)과 일반적인 tripleTerm(즉, <<( [...] )>>) 사이의 구문 차이에 유의한다.

IRI를 축약할 수 있도록 접두사를 선언한 뒤, 이 예제의 첫 번째 트리플은 employee38이 "Smith"라는 familyName을 가지고 있다고 단언한다. 이 그래프는 employee38이 "Assistant Designer"라는 jobTitle을 가지고 있다고 단언하지 않는다는 점에 유의한다; 이 그래프는 employee22reifiedTriple을 사용해 그 주장을 했다고 말한다. 다시 말해, "employee38 has a jobTitle of 'Assistant Designer'"라는 트리플은, 위의 "employee38 has a familyName of 'Smith'"처럼 그래프 자체의 구성원이 아니다; 오히려 그것은 구체화 트리플로 알려져 있다.

reifiedTriplerdf:reifies 술어를 사용하여 구체화자tripleTerm에 연결하는 구문적 설탕이다.

2.11.1 주석 구문

Turtle은 또한 주석 구문을 정의하여 트리플을 구체화하고 단언할 수 있게 하며, 편리한 단축 표현을 제공한다. 주석은 명시적 또는 암시적 식별자를 통해 트리플을 동시에 단언하고, 해당 트리플이 추가 트리플의 주어 또는 객체가 되게 하는 데 사용할 수 있다. 명시적으로 식별된 경우, 동일한 구체화자는 추가 트리플 및/또는 트리플 용어주어 또는 객체로 사용될 수 있다.

reifiedTriple처럼, 주석 구문은 IRI 또는 빈 노드로 작성되는 구체화자를 사용하며, 그 앞에는 틸드(~)가 와서 구체화되는 트리플 용어를 식별한다. 그러나 reifiedTriple에는 최대 하나의 구체화자만 포함될 수 있는 반면, 주석 구문에는 임의의 수의 구체화자가 포함될 수 있다. 각 구체화자는 대응하는 구체화 트리플을 생성하게 한다.

구체화자 뒤에는 주석 블록이 올 수 있다. 구체화자 뒤에 주석 블록이 오지 않으면, 이는 추가 주석이 없는 reifiedTriple과 유사하게 처리된다. 주석 블록 바로 앞에 구체화자가 오지 않으면, 새로운 RDF 빈 노드가 할당되어 트리플 용어구체화자 역할을 한다.

참고

주석 구문은 Turtle의 구문적 단축 표현이다. RDF 추상 구문 [RDF11-CONCEPTS]은 트리플이 어떻게 작성되었는지를 구별하지 않는다.

예제 26: 주석이 달린 트리플

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" ~ :t {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .

는 다음과 동일한 트리플 집합이다:

예제 27: 주석이 달린 트리플을 구체화자로 확장한 것

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" .
<< :alice :name "Alice" ~ :t >> :statedBy :bob ;
                                :recorded "2021-07-07"^^xsd:date .

트리플 용어를 구체화자 대신 사용하도록 완전히 확장하면 다음과 같은 결과가 된다:

예제 28: 주석이 달린 트리플을 트리플 용어로 확장한 것

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" .
:t rdf:reifies <<( :alice :name "Alice" )>> .
:t :statedBy :bob .
:t :recorded "2021-07-07"^^xsd:date .

이전 예제에서 그래프는 네 개의 트리플을 포함한다. 구체화자:t로 식별된다.

주석 블록은 명시적 구체화자 없이도 사용할 수 있다. 이 경우, 새로운 RDF 빈 노드가 할당되어 트리플 용어구체화자 역할을 한다.

예제 29: 암시적 구체화자가 있는 주석이 달린 트리플

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .

이 예제를 완전히 확장하면 다음 트리플이 되며, 여기서 _:b0는 새로운 RDF 빈 노드를 나타낸다:

예제 30: 암시적 구체화자가 있는 주석이 달린 트리플 확장

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" .
_:b0 rdf:reifies <<( :alice :name "Alice" )>> .
_:b0 :statedBy :bob .
_:b0 :recorded "2021-07-07"^^xsd:date .

annotation은 임의의 수의 주석 블록을 포함할 수 있다. 이러한 블록 바로 앞에 명시적 구체화자가 없으면, 각 블록은 해당 구체화자로 할당된 새로운 RDF 빈 노드와 연결된다.

예제 31: 여러 암시적 구체화자가 있는 주석이 달린 트리플

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice"
  {| :statedBy :alice ; :recorded "2017-02-01"^^xsd:date |}
  {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .

이 예제를 완전히 확장하면 다음 트리플이 되며, 여기서 _:b0_:b1은 새로운 RDF 빈 노드를 나타낸다:

예제 32: 여러 암시적 구체화자가 있는 주석이 달린 트리플 확장

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" .
_:b0 rdf:reifies <<( :alice :name "Alice" )>> .
_:b0 :statedBy :alice .
_:b0 :recorded "2017-02-01"^^xsd:date .
_:b1 rdf:reifies <<( :alice :name "Alice" )>> .
_:b1 :statedBy :bob .
_:b1 :recorded "2021-07-07"^^xsd:date .

주석 구문은 주석 블록 없이 여러 명시적 구체화자를 포함할 수도 있다. 이러한 각 구체화자는 대응하는 구체화 트리플을 생성하게 한다.

예제 33: 여러 명시적 구체화자가 있는 주석이 달린 트리플

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

:alice :name "Alice" ~ :stmt1 ~ :stmt2 .

이 예제를 완전히 확장하면 다음 트리플이 된다:

예제 34: 여러 명시적 구체화자가 있는 주석이 달린 트리플 확장

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

:alice :name "Alice" .
:stmt1 rdf:reifies <<( :alice :name "Alice" )>> .
:stmt2 rdf:reifies <<( :alice :name "Alice" )>> .

3. 예제

이 절은 비규범적입니다.

이 예제는 RDF 1.2 XML 구문예제 7을 Turtle로 번역한 것이다 (example1.ttl):

PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX ex: <http://example.org/stuff/1.0/>

<https://www.w3.org/TR/rdf12-xml/>
  dc:title "RDF 1.2 XML Syntax" ;
  ex:editor [
    ex:fullName "Gregg Kellogg" ;
    ex:homePage <https://greggkellogg.net/>
  ] .

두 리터럴로 이루어진 RDF 컬렉션의 예.

예제 36: 두 리터럴로 이루어진 RDF 컬렉션

PREFIX : <http://example.org/stuff/1.0/>
:a :b ( "apple" "banana" ) .

이는 다음의 축약형이다(example2.ttl):

PREFIX : <http://example.org/stuff/1.0/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
:a :b
  [ rdf:first "apple";
    rdf:rest [ rdf:first "banana";
               rdf:rest rdf:nil ]
  ] .

줄바꿈을 포함하는 리터럴 객체를 가진 두 개의 동일한 트리플을 일반 리터럴 형식과 긴 리터럴 형식으로 작성한 예이다. 이 예제의 줄바꿈은 LF이다. (example3.ttl):

PREFIX : <http://example.org/stuff/1.0/>

:a :b "The first line\nThe second line\n  more" .

:a :b """The first line
The second line
  more""" .

문법이 나타내는 것처럼, collectionsubject 또는 object일 수 있다. 이 주어 또는 객체는 컬렉션에 하나 이상의 객체가 있는 경우 첫 번째 객체를 위한 새로운 빈 노드가 되며, 컬렉션이 비어 있으면 rdf:nil이 된다.

예를 들어,

예제 39: 주어로 사용된 컬렉션

PREFIX : <http://example.org/stuff/1.0/>
(1 2.0 3E1) :p "w" .

는 다음에 대한 구문적 설탕이다(여기서 빈 노드 b0, b1, 및 b2RDF 그래프의 다른 어느 곳에도 나타나지 않는다는 점에 유의):

예제 40: 빈 노드로 표현된 컬렉션

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX : <http://example.org/stuff/1.0/>
_:b0  rdf:first  1 ;
      rdf:rest   _:b1 .
_:b1  rdf:first  2.0 ;
      rdf:rest   _:b2 .
_:b2  rdf:first  3E1 ;
      rdf:rest   rdf:nil .
_:b0  :p         "w" .

RDF 컬렉션은 중첩될 수 있으며 다른 구문 형식도 포함할 수 있다:

예제 41: 중첩된 컬렉션

PREFIX : <http://example.org/stuff/1.0/>
(1 [:p :q] ( 2 ) ) :p2 :q2 .

는 다음에 대한 구문적 설탕이다:

예제 42: 빈 노드로 표현된 중첩 컬렉션

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX : <http://example.org/stuff/1.0/>
_:b0  :p2  :q2 .
_:b0  rdf:first  1 ;
      rdf:rest   _:b1 .
_:b1  rdf:first  _:b2 .
_:b2  :p         :q .
_:b1  rdf:rest   _:b3 .
_:b3  rdf:first  _:b4 .
_:b4  rdf:first  2 ;
      rdf:rest   rdf:nil .
_:b3  rdf:rest   rdf:nil .

4. SPARQL과 비교한 Turtle

이 절은 비규범적입니다.

SPARQL 1.2 Query Language (SPARQL) [SPARQL12-QUERY]는 TriplesBlock 생성 규칙에 Turtle 스타일 구문을 사용한다. 이 생성 규칙은 다음 점에서 Turtle 언어와 다르다:

  1. SPARQLRDF 리터럴트리플 패턴의 주어로 허용한다.
  2. SPARQL은 트리플 형식의 어느 부분에서도 변수(?name 또는 $name)를 허용한다.
  3. Turtle은 접두사, 기준 및 버전 선언을 트리플 외부 어디에서나 허용한다. SPARQL에서는 이러한 선언이 Prologue (SPARQL 질의의 시작 부분)에서만 허용된다.
  4. SPARQLa를 제외하고 대소문자를 구분하지 않는 키워드를 사용한다. Turtle의 @prefix@base 선언은 대소문자를 구분하며, SPARQL에서 파생된 PREFIXBASE는 대소문자를 구분하지 않는다.
  5. truefalseSPARQL에서는 대소문자를 구분하지 않지만 Turtle에서는 대소문자를 구분한다. TrUe는 Turtle에서 유효한 불리언 값이 아니다.

자세한 정보는 SPARQL 질의 문서 [SPARQL12-QUERY]의 IRI 구문SPARQL 문법 절을 참조한다.

5. 적합성

비규범적이라고 표시된 절뿐 아니라, 이 명세의 모든 작성 지침, 도표, 예제 및 참고는 비규범적이다. 이 명세의 그 밖의 모든 것은 규범적이다.

이 문서에서 MAY, MUST, MUST NOT, 및 SHOULD라는 핵심 단어는, 여기에 표시된 것처럼 모두 대문자로 나타나는 경우에만, BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 한다.

이 명세는 다음에 대한 적합성 기준을 정의한다:

적합한 Turtle 문서RDF 문자열이며, 6. Turtle 문법에 정의된 문법 및 추가 제약 조건을 따르고, turtleDoc 생성 규칙으로 시작한다. Turtle 문서RDF 그래프를 직렬화한다.

적합한 Turtle 파서는 애플리케이션을 대신하여 Turtle 문서를 읽을 수 있는 시스템이다. 이는 7. 파싱에 정의된 대로, 직렬화된 RDF 그래프를 일반적으로 어떤 형태의 API를 통해 애플리케이션에 제공한다.

Turtle 언어를 식별하는 IRI는 다음과 같다: http://www.w3.org/ns/formats/Turtle

참고

이 명세는 Turtle 파서가 부적합한 입력 문서를 처리하는 방식을 정의하지 않는다.

5.1 미디어 유형 및 콘텐츠 인코딩

Turtle의 미디어 유형은 text/turtle이다. Turtle 콘텐츠의 콘텐츠 인코딩은 항상 UTF-8 [RFC3629]이다.

6. Turtle 문법

Turtle 문서는 UTF-8 [RFC3629]로 인코딩된 RDF 문자열이다. U+0000부터 U+D7FF까지 및 U+E000부터 U+10FFFF까지의 범위에 있는 Unicode 스칼라 값만 허용된다. 이는 범위 U+D800부터 U+DFFF까지의 서러게이트 코드 포인트를 제외한다.

6.1 공백

공백(생성 규칙 WS)은 그렇지 않으면 하나의 터미널로 (잘못) 인식될 수 있는 두 터미널을 구분하는 데 사용된다. 아래에서 대문자로 된 규칙 이름은 공백이 의미를 가지는 위치를 나타내며, 이는 Turtle 파서를 구성하기 위한 터미널 선택지 중 하나를 이룬다.

공백은 String 생성 규칙에서 의미가 있다.

6.2 주석

Turtle의 주석은 IRIREF, STRING_LITERAL_SINGLE_QUOTE, STRING_LITERAL_QUOTE, STRING_LITERAL_LONG_SINGLE_QUOTE, 또는 STRING_LITERAL_LONG_QUOTE의 외부에 있는 #로 시작하며, 줄 끝(LF 또는 CR로 표시)까지 계속되거나, 주석 표시 뒤에 줄 끝이 없으면 파일 끝까지 계속된다. 주석은 공백으로 처리된다.

6.3 IRI 참조

상대 IRI 참조Uniform Resource Identifier (URI): Generic Syntax [RFC3986]에 따라, 5.2절의 기본 알고리즘만 사용하여 기준 IRI로 해결된다. 구문 기반 정규화나 스킴 기반 정규화 (RFC3986의 6.2.2절 및 6.2.3절에 설명됨)는 수행되지 않는다. IRI 참조에서 추가로 허용되는 문자는 Internationalized Resource Identifiers (IRIs) [RFC3987] 6.5절에 따라, URI 참조에서 비예약 문자가 처리되는 방식과 동일하게 처리된다.

@base 또는 BASE 지시자는 [RFC3986] 5.1.1절, "콘텐츠에 포함된 기준 URI"에 따라 상대 IRI 참조를 해결하는 데 사용되는 기준 IRI를 정의한다. 5.1.2절, "캡슐화 엔터티에서 온 기준 URI"는 범위 내 기준 IRI가, 예를 들어 xml:base 지시자를 가진 SOAP 봉투나 Content-Location 헤더를 가진 MIME multipart 문서와 같은 캡슐화 문서에서 올 수 있는 방식을 정의한다. 5.1.3절, "검색 URI에서 온 기준 URI"에서 식별되는 "검색 URI"는 특정 Turtle 문서를 가져온 URL이다. 위의 어느 것도 기준 URI를 지정하지 않으면, 기본 기준 URI(5.1.4절, "기본 기준 URI")가 사용된다. 각 @base 또는 BASE 지시자는 이전 기준 URI에 상대적으로 새로운 범위 내 기준 URI를 설정한다.

6.4 이스케이프 시퀀스

Turtle 문서에는 세 가지 형태의 이스케이프가 사용된다:

각 종류의 이스케이프 시퀀스를 사용할 수 있는 컨텍스트
숫자
이스케이프
문자열
이스케이프
예약 문자
이스케이프
IRI, RDF 용어로 사용되거나 @prefix, PREFIX, @base, 또는 BASE 선언에서 사용됨 아니요 아니요
로컬 이름 아니요 아니요
문자열 아니요

이스케이프 시퀀스는 관련 문법 생성 규칙과 일치하는 Unicode 코드 포인트의 시퀀스를 취한 뒤, 다음 단계를 적용하여 처리된다.

  1. Unicode 코드 포인트의 시퀀스를 왼쪽에서 오른쪽으로 스캔하여 처음 일치하는 이스케이프 시퀀스를 찾는다.
  2. 이스케이프 시퀀스가 발견되면, 해당 이스케이프 시퀀스에 대응하는 코드 포인트로 이스케이프 시퀀스를 대체한다.
  3. Unicode 코드 포인트 시퀀스의 스캔은 대체된 이스케이프 시퀀스 바로 뒤의 코드 포인트부터 계속된다.
처리된 이스케이프 시퀀스의 예
입력 코드 포인트 출력 코드 포인트 코드 포인트 수
abc\u005Cdef abc\def 7
abc\u005Ctuv abc\tuv 7
\u005CA \A 2
\\u005C \u005C 6
\u005C\u005C \\ 2
\\\u005C \\ 2
\\\\ \\ 2
\u005Cn \n 2
참고

%-인코딩된 시퀀스는 IRI의 문자 범위 안에 있으며 로컬 이름에서 명시적으로 허용된다. 이들은 % 뒤에 두 개의 16진수 문자가 오는 형태로 나타나며, 동일한 세 문자 시퀀스를 나타낸다. 이러한 시퀀스는 처리 중에 디코딩되지 않는다. Turtle에서 <http://a.example/%66oo-bar>로 작성된 용어는 IRI http://a.example/%66oo-bar를 지정하며, IRI http://a.example/foo-bar를 지정하지 않는다. 접두사 PREFIX ex: <http://a.example/>와 함께 ex:%66oo-bar로 작성된 용어도 IRI http://a.example/%66oo-bar를 지정한다.

6.5 문법

여기서 사용되는 EBNF는 XML 1.0 [EBNF-NOTATION]에서 정의된다.

참고:

  1. 작은따옴표 안의 키워드 ('@base', '@prefix', '@version', 'a', 'true', 및 'false')는 대소문자를 구분한다. 큰따옴표 안의 키워드 ("BASE", "PREFIX", 및 "VERSION")는 대소문자를 구분하지 않는다.
  2. 이스케이프 시퀀스 UCHARECHAR는 대소문자를 구분한다.
  3. 입력을 토큰화하고 문법 규칙을 선택할 때 가장 긴 일치가 선택된다.
  4. Turtle 문법은 대문자 이름의 규칙을 터미널로 사용할 때 LL(1) 및 LALR(1)이다.
  5. 문법의 진입점은 turtleDoc이다.
  6. 부호가 있는 숫자에서는 부호와 숫자 사이에 공백이 허용되지 않는다.
  7. 문자열 '@prefix', '@base', 및 '@version'는 LANG_DIR의 패턴과 일치하지만, prefix, base, 또는 version등록된 언어 하위 태그가 아니다. 이 명세는 따옴표로 묶인 리터럴 뒤에 이러한 토큰 중 하나가 오는 경우 (예: "A"@base)가 Turtle 언어에 속하는지 여부를 정의하지 않는다.
[1] turtleDoc ::= statement*
[2] statement ::= directive | (triples '.')
[3] directive ::= prefixID | base | version | sparqlPrefix | sparqlBase | sparqlVersion
[4] prefixID ::= '@prefix' PNAME_NS IRIREF '.'
[5] base ::= '@base' IRIREF '.'
[6] version ::= '@version' VersionSpecifier '.'
[7] sparqlPrefix ::= "PREFIX" PNAME_NS IRIREF
[8] sparqlBase ::= "BASE" IRIREF
[9] sparqlVersion ::= "VERSION" VersionSpecifier
[10] VersionSpecifier ::= STRING_LITERAL_QUOTE | STRING_LITERAL_SINGLE_QUOTE
[11] triples ::= (subject predicateObjectList) | (blankNodePropertyList predicateObjectList?) | (reifiedTriple predicateObjectList?)
[12] predicateObjectList ::= verb objectList (';' (verb objectList)?)*
[13] objectList ::= object annotation (',' object annotation)*
[14] verb ::= predicate | 'a'
[15] subject ::= iri | BlankNode | collection
[16] predicate ::= iri
[17] object ::= iri | BlankNode | collection | blankNodePropertyList | literal | tripleTerm | reifiedTriple
[18] literal ::= RDFLiteral | NumericLiteral | BooleanLiteral
[19] blankNodePropertyList ::= '[' predicateObjectList ']'
[20] collection ::= '(' object* ')'
[21] NumericLiteral ::= INTEGER | DECIMAL | DOUBLE
[22] RDFLiteral ::= String (LANG_DIR | ('^^' iri))?
[23] BooleanLiteral ::= 'true' | 'false'
[24] String ::= STRING_LITERAL_QUOTE | STRING_LITERAL_SINGLE_QUOTE | STRING_LITERAL_LONG_SINGLE_QUOTE | STRING_LITERAL_LONG_QUOTE
[25] iri ::= IRIREF | PrefixedName
[26] PrefixedName ::= PNAME_LN | PNAME_NS
[27] BlankNode ::= BLANK_NODE_LABEL | ANON
[28] reifier ::= '~' (iri | BlankNode)?
[29] reifiedTriple ::= '<<' rtSubject verb rtObject reifier? '>>'
[30] rtSubject ::= iri | BlankNode | reifiedTriple
[31] rtObject ::= iri | BlankNode | literal | tripleTerm | reifiedTriple
[32] tripleTerm ::= '<<(' ttSubject verb ttObject ')>>'
[33] ttSubject ::= iri | BlankNode
[34] ttObject ::= iri | BlankNode | literal | tripleTerm
[35] annotation ::= (reifier | annotationBlock)*
[36] annotationBlock ::= '{|' predicateObjectList '|}'

터미널을 위한 생성 규칙

[38] IRIREF ::= '<' ([^#x00-#x20<>"{}|^`\] | UCHAR)* '>'
/* #x00=NULL #x01-#x1F=control codes #x20=space */
[39] PNAME_NS ::= PN_PREFIX? ':'
[40] PNAME_LN ::= PNAME_NS PN_LOCAL
[41] BLANK_NODE_LABEL ::= '_:' (PN_CHARS_U | [0-9]) ((PN_CHARS | '.')* PN_CHARS)?
[42] LANG_DIR ::= '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)* ('--' [a-zA-Z]+)?
[43] INTEGER ::= [+-]? [0-9]+
[44] DECIMAL ::= [+-]? ([0-9]* '.' [0-9]+)
[45] DOUBLE ::= [+-]? (([0-9]+ ('.' [0-9]*)?) | ('.' [0-9]+)) EXPONENT
[46] EXPONENT ::= [eE] [+-]? [0-9]+
[47] STRING_LITERAL_QUOTE ::= '"' ([^#x22#x5C#x0A#x0D] | ECHAR | UCHAR)* '"'
[48] STRING_LITERAL_SINGLE_QUOTE ::= "'" ([^#x27#x5C#x0A#x0D] | ECHAR | UCHAR)* "'"
[49] STRING_LITERAL_LONG_SINGLE_QUOTE ::= "'''" (("'" | "''")? ([^'\] | ECHAR | UCHAR))* "'''"
[50] STRING_LITERAL_LONG_QUOTE ::= '"""' (('"' | '""')? ([^"\] | ECHAR | UCHAR))* '"""'
[51] UCHAR ::= ('\u' HEX HEX HEX HEX) | ('\U' HEX HEX HEX HEX HEX HEX HEX HEX)
[52] ECHAR ::= '\' [tbnrf\"']
[53] WS ::= #x20 | #x09 | #x0D | #x0A
[54] ANON ::= '[' WS* ']'
[55] PN_CHARS_BASE ::= [A-Z]
| [a-z]
| [#xC0-#xD6]
| [#xD8-#xF6]
| [#xF8-#x02FF]
| [#x0370-#x037D]
| [#x037F-#x1FFF]
| [#x200C-#x200D]
| [#x2070-#x218F]
| [#x2C00-#x2FEF]
| [#x3001-#xD7FF]
| [#xF900-#xFDCF]
| [#xFDF0-#xFFFD]
| [#x00010000-#x000EFFFF]
[56] PN_CHARS_U ::= PN_CHARS_BASE | '_'
[57] PN_CHARS ::= PN_CHARS_U | '-' | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
[58] PN_PREFIX ::= PN_CHARS_BASE ((PN_CHARS | '.')* PN_CHARS)?
[59] PN_LOCAL ::= (PN_CHARS_U | ':' | [0-9] | PLX) ((PN_CHARS | '.' | ':' | PLX)* (PN_CHARS | ':' | PLX))?
[60] PLX ::= PERCENT | PN_LOCAL_ESC
[61] PERCENT ::= '%' HEX HEX
[62] HEX ::= [0-9] | [A-F] | [a-f]
[63] PN_LOCAL_ESC ::= '\' ('_' | '~' | '.' | '-' | "!" | '$' | '&' | "'" | '(' | ')' | '*' | '+' | ',' | ';' | '=' | '/' | '?' | '#' | '@' | '%')

이 문법의 텍스트 버전은 여기에서 사용할 수 있다.

6.6 선택된 터미널 리터럴 문자열

이 문서는 몇 가지 특정 터미널 리터럴 문자열 [EBNF-NOTATION]을 사용한다. 이러한 터미널 리터럴 문자열에 사용되는 Unicode 코드 포인트를 명확히 하기 위해, 다음 표는 이 문서 전체에서 사용되는 특정 문자와 시퀀스를 설명한다.

코드 글리프 설명
U+0009 HT 수평 탭
U+000A LF 줄 바꿈
U+000D CR 캐리지 리턴
U+0022 " 따옴표
U+0023 # 숫자 기호
U+0025 % 퍼센트 기호
U+0027 ' 아포스트로피
U+0028 ( 왼쪽 괄호
U+0029 ) 오른쪽 괄호
U+002C , 쉼표
U+002D - 하이픈
U+002E . 마침표
U+0030 0 숫자 0
U+0039 9 숫자 9
U+003B : 콜론
U+003B ; 세미콜론
U+003C < 보다 작음 기호
U+003E > 보다 큼 기호
U+0040 @ 앳 기호
U+0045 E 라틴 대문자 E
U+005B [ 왼쪽 대괄호
U+005C \ 백슬래시
U+005D [ 오른쪽 대괄호
U+005F _ 밑줄
U+0061 a 라틴 소문자 a
U+0065 e 라틴 소문자 e
U+007C | 수직선
U+007E ~ 틸드
U+00B7 · 가운뎃점
U+203F 언더타이
U+2040 문자 타이

그 밖의 짧은 터미널 리터럴 문자열은 Unicode 문자의 특정 시퀀스로 구성된다:

space
U+0020
"""
세 개의 따옴표 문자가 이어진 것으로, 각 문자의 코드 포인트는 U+0022이다
'''
세 개의 아포스트로피 문자가 이어진 것으로, 각 문자의 코드 포인트는 U+0027이다
<<
두 개의 보다 작음 기호 문자가 이어진 것으로, 각 문자의 코드 포인트는 U+003C이다
>>
두 개의 보다 큼 기호 문자가 이어진 것으로, 각 문자의 코드 포인트는 U+003E이다
<<(
두 개의 보다 작음 기호 문자가 이어진 것으로, 각 문자의 코드 포인트는 U+003C이며, 그 뒤에 코드 포인트 U+0028인 왼쪽 괄호 문자가 온다
)>>
코드 포인트 U+0029인 왼쪽 괄호 문자 뒤에 두 개의 보다 큼 기호 문자가 이어지며, 각 기호의 코드 포인트는 U+003E이다
^^
두 개의 곡절 악센트 문자가 이어진 것으로, 각 문자의 코드 포인트는 U+005E이다
{|
{ (왼쪽 중괄호, 코드 포인트 U+007B) 뒤에 | (수직선, 코드 포인트 U+007C)가 온다
|}
| (수직선, 코드 포인트 U+007C) 뒤에 } (오른쪽 중괄호, 코드 포인트 U+007D)가 온다
_:
_ 뒤에 :가 온다
--
두 개의 - 문자가 이어진 것

7. 파싱

RDF 1.2 Concepts and Abstract Syntax 명세 [RDF12-CONCEPTS]는 네 가지 유형의 RDF 용어를 정의한다: IRI, 리터럴, 빈 노드, 그리고 트리플 용어. 리터럴은 어휘 형식과 선택적 언어 태그 [BCP47] – 가능하면 초기 텍스트 방향을 포함 – 또는 데이터형 IRI로 구성된다. 추가 유형인 prefix는 파싱 중 문자열 식별자를 이름공간 IRI에 매핑하는 데 사용된다. 이 절은 6.5 문법의 문법에 부합하는 문자열을 생성 규칙과 어휘 토큰에 일치하는 문자열을 RDF 용어 또는 그 구성 요소(예: 언어 태그, 리터럴의 어휘 형식)에 매핑하여 트리플 집합으로 매핑한다. 문법 생성 규칙은 파서 상태를 변경하고 트리플을 내보낸다.

7.1 파서 상태

Turtle 파싱에는 아홉 가지 항목으로 이루어진 상태가 필요하다:

용어 생성자는 "records the curSubject and curPredicate."와 같은 언어를 사용하여 표시되는 이러한 값들의 스택을 만들 수 있다.

7.2 RDF 용어 생성자

이 표는 생성 규칙과 어휘 토큰을 RDF 용어 또는 RDF 용어의 구성 요소에 매핑하며, 이들은 7. 파싱에 나열되어 있다:

생성 규칙 유형 절차
IRIREF IRI <> 사이의 문자를 가져와, 숫자 이스케이프 시퀀스를 이스케이프 해제하여 IRI를 형성한다. 상대 IRI 참조 해석은 6.3절에 따라 수행된다. 결과 IRI는 일반 IRI 구문의 구문적 제한을 준수해야 하며, [RFC3986]의 3.3절을 따르고 해당 IRI 스킴 명세가 부과하는 더 좁은 제한도 준수하는 것이 좋다.
PNAME_NS prefix prefixID 또는 sparqlPrefix 생성 규칙에서 사용될 때, prefix는 규칙의 첫 번째 인자와 일치하는, 잠재적으로 빈 RDF 문자열이며, 확장된 두 번째 인자가 향후 조회를 위해 저장되는 namespaces 맵의 키이다.
IRI PrefixedName 생성 규칙에서 사용될 때; namespaces 맵은 대응하는 namespace를 가져야 하며, 이것이 IRI의 RDF 문자열을 형성한다. 결과 IRI는 일반 IRI 구문의 구문적 제한을 준수해야 하며, 해당 IRI 스킴 명세가 부과하는 더 좁은 제한도 준수하는 것이 좋다.
PNAME_LN IRI 잠재적으로 빈 prefix는 첫 번째 시퀀스인 PNAME_NS로 식별된다. namespaces 맵은 대응하는 namespace를 가져야 한다. IRI의 RDF 문자열은 두 번째 인자인 PN_LOCAL에서 예약 문자를 이스케이프 해제하고, 이를 namespace에 이어 붙여 형성된다. 결과 IRI는 일반 IRI 구문의 구문적 제한을 준수해야 하며, 해당 IRI 스킴 명세가 부과하는 더 좁은 제한도 준수하는 것이 좋다.
VersionSpecifier 리터럴. curVersion은 일치한 RDF 문자열 어휘 형식과 xsd:string 데이터형을 사용하는 리터럴에서 가져온다.
STRING_LITERAL_SINGLE_QUOTE 어휘 형식 가장 바깥쪽 '들 사이의 문자를 가져와, 숫자문자열 이스케이프 시퀀스를 그것들이 나타내는 문자로 대체한 뒤, 어휘 형식의 RDF 문자열을 형성한다.
STRING_LITERAL_QUOTE 어휘 형식 가장 바깥쪽 "들 사이의 문자를 가져와, 숫자문자열 이스케이프 시퀀스를 이스케이프 해제하여, 어휘 형식의 RDF 문자열을 형성한다.
STRING_LITERAL_LONG_SINGLE_QUOTE 어휘 형식 가장 바깥쪽 '''들 사이의 문자를 가져와, 숫자문자열 이스케이프 시퀀스를 이스케이프 해제하여, 어휘 형식의 RDF 문자열을 형성한다.
STRING_LITERAL_LONG_QUOTE 어휘 형식 가장 바깥쪽 """들 사이의 문자를 가져와, 숫자문자열 이스케이프 시퀀스를 그것들이 나타내는 문자로 대체한 뒤, 어휘 형식의 RDF 문자열을 형성한다.
LANG_DIR 언어 태그 @ 뒤의 문자는 언어 태그와, 일치한 문자에 --가 포함되어 있으면 선택적으로 초기 텍스트 방향을 형성한다. 언어 태그는 [BCP47]의 2.2.9절에 따라 올바른 형식이어야 한다. 존재하는 경우, 초기 텍스트 방향ltr 또는 rtl이어야 한다.
RDFLiteral 리터럴 리터럴은 첫 번째 규칙 인자인 String의 어휘 형식을 가진다. '^^' iri 규칙이 일치하면, 데이터형 IRIiri에서 파생되며, 리터럴에는 언어 태그가 없다. LANG_DIR 규칙이 일치하면, 언어 태그초기 텍스트 방향LANG_DIR에서 가져온다. 초기 텍스트 방향이 없으면, 데이터형은 rdf:langString이다. 초기 텍스트 방향이 있으면, 데이터형은 rdf:dirLangString이다. 어느 것도 일치하지 않으면, 데이터형은 xsd:string이고, 리터럴에는 언어 태그가 없다.
INTEGER 리터럴 리터럴은 입력 문자열의 어휘 형식과 xsd:integer 데이터형을 가진다.
DECIMAL 리터럴 리터럴은 입력 문자열의 어휘 형식과 xsd:decimal 데이터형을 가진다.
DOUBLE 리터럴 리터럴은 입력 문자열의 어휘 형식과 xsd:double 데이터형을 가진다.
BooleanLiteral 리터럴 리터럴은 입력에서 어느 것이 일치했는지에 따라 true 또는 false의 어휘 형식과 xsd:boolean 데이터형을 가진다.
BLANK_NODE_LABEL 빈 노드 두 번째 인자인 PN_LOCAL에 일치하는 문자열은 bnodeLabels의 키이다. 맵에 대응하는 빈 노드가 없으면, 하나가 할당된다.
ANON 빈 노드 빈 노드가 생성된다.
blankNodePropertyList 빈 노드 빈 노드가 생성된다. 다음 절의 blankNodePropertyList 규칙에 유의한다.
collection 빈 노드 비어 있지 않은 목록의 경우, 빈 노드가 생성된다. 다음 절의 collection 규칙에 유의한다.
IRI 빈 목록의 경우, 결과 IRI는 rdf:nil이다. 다음 절의 collection 규칙에 유의한다.
reifier IRI | 빈 노드 curReifier는 일치한 iri 생성 규칙 또는 BlankNode 생성 규칙에서 가져온 term에서 가져온다(있는 경우). 그러한 생성 규칙이 일치하지 않으면, term은 새로운 RDF 빈 노드에서 가져온다.
tripleTerm 트리플 용어 트리플 용어ttSubject, predicate, 및 ttObject 생성 규칙에서 구성된 용어들로 구성된다.
reifiedTriple IRI | 빈 노드 term은 일치한 reifier에서 가져오며(있는 경우), 없으면 새로운 RDF 빈 노드에서 가져온다.
annotationBlock IRI | 빈 노드 term은 이전에 일치한 구체화자에서 가져오며(있는 경우), 없으면 새로운 RDF 빈 노드에서 가져온다.
참고

입력에서 오류를 감지하는 처리기는 입력에 설명된 것보다 적은 수의 트리플을 포함하는 그래프 (트리플이 전혀 없는 경우 포함)를 만들 수 있으므로, 소비자는 출력 트리플을 사용할 때 신호된 모든 오류 정보를 고려해야 한다. 출력 트리플은 불완전하거나 잘못된 형식의 또는 올바르지 않게 구성된 용어를 포함할 수 있다.

7.3 RDF 트리플 생성자

Turtle 문서RDF 그래프를 정의하며, 이는 RDF 트리플들의 집합으로 구성된다. subject 생성 규칙은 curSubject를 설정한다. verb 생성 규칙은 curPredicate를 설정한다. objectttObject 생성 규칙은 curObject를 설정한다. 문서 안의 각 object NRDF 트리플을 생성한다: curSubject curPredicate N .

7.3.1 구체화자

reifier 생성 규칙을 시작하면, curReifierreifier 용어 생성자에서 가져온다. 그런 다음 RDF 트리플 curReifier rdf:reifies curTripleTerm을 산출한다.

7.3.2 구체화된 트리플

reifiedTriple 생성 규칙을 시작하면 curTripleTerm을 기록한다. 새 tripleTerm 인스턴스 curTripleTermrtSubject, verb, 및 rtObject 생성 규칙을 사용하여 생성된다. reifiedTriple 생성 규칙을 끝낼 때, curReifier가 설정되어 있지 않으면, 새로운 RDF 빈 노드가 할당된다; 다음으로 RDF 트리플 curReifier rdf:reifies curTripleTerm을 산출하고, 그런 다음 curTripleTerm의 기록된 값을 복원한다. reifiedTriple에 일치하여 생성되는 노드는 curReifier이다.

7.3.3 주석

annotation 생성 규칙을 시작하면 curSubjectcurPredicate를 기록한다. 새 tripleTerm 인스턴스 curTripleTermcurSubject curPredicate curObject를 사용하여 생성되고, curReifier의 값은 지워진다. annotation 생성 규칙을 끝낼 때 curSubjectcurPredicate의 기록된 값을 복원한다.

7.3.4 주석 블록

annotationBlock 생성 규칙을 시작하면 curTripleTerm을 기록한다. curReifier가 설정되어 있지 않으면, 새로운 RDF 빈 노드가 할당되고, 생성 규칙은 RDF 트리플 curReifier rdf:reifies curTripleTerm을 산출한다. curSubjectcurReifier에서 가져온다. annotationBlock 생성 규칙을 끝낼 때 curReifier의 값을 지우고 curTripleTerm을 복원한다.

참고

curReifier가 이미 설정되어 있었다면, 구체화 트리플 curReifier rdf:reifies curTripleTerm7.3.1 구체화자에서 내보내졌다.

7.3.5 속성 목록

blankNodePropertyList 생성 규칙을 시작하면 curSubjectcurPredicate를 기록하고, curSubject를 새로운 빈 노드 B로 설정한다. blankNodePropertyList 생성 규칙을 끝낼 때 curSubjectcurPredicate를 복원한다. blankNodePropertyList에 일치하여 생성되는 노드는 빈 노드 B이다.

7.3.6 컬렉션

collection 생성 규칙을 시작하면 curSubjectcurPredicate를 기록한다. collection 생성 규칙 안의 각 objectcurSubject가 새로운 빈 노드 B로 설정되고, curPredicaterdf:first로 설정된다. 첫 번째 이후의 각 객체 objectn는 트리플을 생성한다:objectn-1 rdf:rest objectn . collection 생성 규칙을 끝낼 때 추가 트리플 curSubject rdf:rest rdf:nil .을 생성하고 curSubjectcurPredicate를 복원한다. collection에 일치하여 생성되는 노드는 비어 있지 않은 목록의 경우 첫 번째 빈 노드 B이고, 빈 목록의 경우 rdf:nil이다.

7.4 파싱 예제

이 절은 비규범적입니다.

다음 정보성 예제는 LALR(1) 파서로 이 Turtle 문서를 파싱할 때 수행되는 의미 동작을 보여 준다:

예제 43: Turtle 파싱 예제

  PREFIX ericFoaf: <http://www.w3.org/People/Eric/ericP-foaf.rdf#>
  PREFIX : <http://xmlns.com/foaf/0.1/>
  ericFoaf:ericP :givenName "Eric" ;
    :knows <http://norman.walsh.name/knows/who/dan-brickley> ,
            [ :mbox <mailto:timbl@w3.org> ] ,
            <http://getopenid.com/amyvdh> .

A. HTML 문서에 Turtle 삽입하기

이 절은 비규범적입니다.

HTML [HTML5] script 태그는 문서에 데이터 블록을 삽입하는 데 사용할 수 있다. Turtle은 이 방식으로 HTML에 쉽게 삽입할 수 있다.

예제 44: HTML에 Turtle 삽입하기

<script type="text/turtle">
  PREFIX dc: <http://purl.org/dc/terms/>
  PREFIX frbr: <http://purl.org/vocab/frbr/core#>

  <http://books.example.com/works/45U8QJGZSQKDH8N> a frbr:Work ;
    dc:creator "Wil Wheaton"@en ;
    dc:title "Just a Geek"@en ;
    frbr:realization <http://books.example.com/products/9780596007683.BOOK>,
      <http://books.example.com/products/9780596802189.EBOOK> .

  <http://books.example.com/products/9780596007683.BOOK> a frbr:Expression ;
    dc:type <http://books.example.com/product-types/BOOK> .

  <http://books.example.com/products/9780596802189.EBOOK> a frbr:Expression ;
    dc:type <http://books.example.com/product-types/EBOOK> .
</script>

Turtle 콘텐츠는 type 속성이 text/turtle로 설정된 script 태그 안에 배치하는 것이 좋다. <> 기호는 script 태그 안에서 이스케이프할 필요가 없다. 삽입된 Turtle의 문자 인코딩은 HTML 문서의 인코딩과 일치한다.

A.1 XHTML

이 절은 비규범적입니다.

JavaScript와 마찬가지로, HTML(text/html)용으로 작성된 Turtle은 XHTML (application/xhtml+xml)에서 사용될 때 깨질 수 있다. 해결책은 JavaScript에 사용되는 것과 동일하다.

예제 45: XHTML에 Turtle 삽입하기

<script type="text/turtle">
  <span class="hl-bold"># <![CDATA[</span>
  PREFIX frbr: <http://purl.org/vocab/frbr/core#>

  <http://books.example.com/works/45U8QJGZSQKDH8N> a frbr:Work .
  <span class="hl-bold"># ]]></span>
</script>

XHTML에 삽입될 때 Turtle 데이터 블록은 CDATA 절로 둘러싸여야 한다. 이러한 CDATA 표식은 Turtle 주석 안에 있어야 한다. 문자 시퀀스 ]]>가 문서에 나타나면 문자열 이스케이프(\u005D\u005D\u003E)를 사용하여 이스케이프해야 한다. 이렇게 하면 text/htmlapplication/xhtml+xml 양쪽으로 제공되는 폴리글랏 문서에서도 Turtle을 안전하게 만들 수 있다. CDATA 절을 사용하지 않거나 ]]>를 이스케이프하지 않으면 올바른 형식이 아닌 XML 문서가 될 수 있다.

A.2 HTML에서 Turtle 파싱하기

이 절은 비규범적입니다.

삽입된 Turtle을 파싱하는 것과 일반 Turtle 문서를 파싱하는 것 사이에는 구문적 차이나 문법 차이가 없다. HTML DOM에서 파싱된 Turtle 문서는 UTF-8 [RFC3629] 코드 포인트의 스트림이 아니라 문자 데이터의 스트림이 된다. HTML 문서가 이미 DOM으로 파싱되었다면 디코딩은 필요하지 않다. 각 script 데이터 블록은 자체적인 Turtle 문서로 간주된다. Turtle 데이터 블록 안의 PREFIXBASE 선언은 해당 데이터 블록에 범위가 한정되며 다른 데이터 블록에 영향을 주지 않는다. HTML lang 속성이나 XHTML xml:lang 속성은 데이터 블록의 파싱에 아무 영향도 주지 않는다. 둘러싼 HTML 문서의 기준 URI는 RFC3986 5.1.1절에 따른 "콘텐츠에 포함된 기준 URI"를 제공한다.

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

이 절은 비규범적입니다.

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

C. 보안 고려 사항

이 절은 비규범적입니다.

STRING_LITERAL_SINGLE_QUOTE, STRING_LITERAL_QUOTE, STRING_LITERAL_LONG_SINGLE_QUOTE, 및 STRING_LITERAL_LONG_QUOTE 생성 규칙은 이스케이프되지 않은 제어 문자의 사용을 허용한다. 이 명세가 이러한 콘텐츠를 최종 사용자에게 직접 노출하지는 않지만, 사용자 에이전트를 통해 제시될 수 있으며, 그러한 문자의 표시로 인해 표시된 텍스트가 난독화될 수 있다.

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

Turtle 언어는 임의의 애플리케이션 데이터를 표현하는 데 사용된다; 보안 고려 사항은 사용 도메인에 따라 달라진다. 텍스트에 적용 가능한 보안 도구와 프로토콜 (예: PGP 암호화, 체크섬 검증, 비밀번호로 보호된 압축)도 Turtle 문서에 사용할 수 있다. 포함된 정보의 민감도를 반영하는 보안/개인정보 보호 프로토콜이 부과되어야 한다.

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

Turtle은 용어 식별자로 IRI를 사용한다. Turtle로 표현된 데이터를 해석하는 애플리케이션은 Internationalized Resource Identifiers (IRIs) [RFC3987] 8절과 Uniform Resource Identifier (URI): Generic Syntax [RFC3986] 7절의 보안 문제를 다루는 것이 좋다.

여러 IRI가 동일하게 보일 수 있다. 서로 다른 문자 체계의 문자는 비슷하게 보일 수 있다(예를 들어, 키릴 문자 "о"(코드 포인트 U+043E)는 라틴 문자 "o"(코드 포인트 U+006F)와 비슷하게 보일 수 있다). 결합 문자가 뒤따르는 문자는 다른 문자와 동일한 시각적 표현을 가질 수 있다 (예를 들어, LATIN SMALL LETTER "E"(코드 포인트 U+0065) 뒤에 COMBINING ACUTE ACCENT(코드 포인트 U+0301)가 오면 LATIN SMALL LETTER "E" WITH ACUTE (U+00E9)와 동일한 시각적 표현을 가진다). Turtle로 데이터를 작성하거나 해석하는 사람 또는 애플리케이션은 의도한 의미와 일치하는 IRI를 사용하고, 비슷하게 보일 수 있는 IRI를 피하도록 주의해야 한다. 시각적으로 유사한 문자를 일치시키는 것에 대한 추가 정보는 Unicode Security Considerations [UNICODE-SECURITY] 및 Internationalized Resource Identifiers (IRIs) [RFC3987] 8절에서 찾을 수 있다.

D. 인터넷 미디어 유형 및 파일 확장자

Turtle의 인터넷 미디어 유형(이전의 MIME 유형)은 "text/turtle"이다.

다음 정보는 검토, 승인 및 IANA 등록을 위해 Internet Engineering Steering Group (IESG)에 제출되었다.

유형 이름:
text
하위 유형 이름:
turtle
필수 매개변수:
없음
선택적 매개변수:
version
이 매개변수는 선택적이다. 존재하는 경우, version의 허용 가능한 값은 [RDF12-CONCEPTS]의 Version Labels에서 정의된다.
profile
이 매개변수는 선택적이며 추가 정보를 포함하는 데 사용된다. 프로파일에 대한 지식 없이 처리될 때 리소스 표현의 의미를 변경하지 않는다. profile 매개변수의 값은 공백으로 구분된 URI의 비어 있지 않은 목록이다. 자세한 정보와 배경은 [RFC6906]를 참조한다.
인코딩 고려 사항:
Turtle의 구문은 Unicode [UNICODE]의 코드 포인트 위에서 표현된다. 인코딩은 항상 UTF-8 [UTF-8]이다.
Unicode 코드 포인트\uXXXX (U+0000부터 U+FFFF까지) 또는 \UXXXXXXXX 구문(U+10FFFF까지의 코드 포인트)으로도 표현할 수 있으며, 여기서 X는 16진수 숫자 [0-9A-Fa-f]이다
보안 고려 사항:
C. 보안 고려 사항을 참조한다.
상호운용성 고려 사항:
알려진 상호운용성 문제는 없다.
공개된 명세:
이 명세.
이 미디어 유형을 사용하는 애플리케이션:
Turtle은 RDF 데이터를 표현하는 데 널리 사용된다. 대부분의 일반적인 프로그래밍 언어에서 구현을 사용할 수 있다.
추가 정보:
매직 넘버:
Turtle 문서는 문서의 시작 부분 근처에 문자열 '@prefix' 또는 '@base'(대소문자 구분) 또는 문자열 'PREFIX' 또는 'BASE'(대소문자 구분 없음)를 가질 수 있다.
파일 확장자:
.ttl
기준 URI:
Turtle '@base <IRIref>' 또는 'BASE <IRIref>' 용어는 문서에서 이후 순차적으로 사용되는 질의 언어의 상대 IRI 참조에 대한 현재 기준 URI를 변경할 수 있다.
추가 정보를 위한 연락 담당자 및 이메일 주소:
RDF & SPARQL Working Group <public-rdf-star-wg@w3.org>
의도된 사용:
일반
사용 제한:
없음
저자:
Turtle 명세는 RDF & SPARQL WG의 산출물이다. W3C는 이 명세에 대한 변경 관리를 보유한다.
참고

profile 매개변수는 클라이언트가 콘텐츠 협상 과정에서 자신의 선호를 표현하고, 서버가 응답에 대한 추가 정보를 나타내는 데 사용할 수 있다.

클라이언트가 profile 매개변수를 제공한 경우, 서버는 서버가 인식하는 목록의 모든 프로파일을 존중하는 문서를 반환하는 것이 좋다. 서버는 프로파일 값만을 근거로 오류로 응답하지 않는 것이 좋다.

서버가 profile 매개변수를 제공한 경우, 클라이언트는 이를 무시할 수 있다.

참고

프로파일 URI는 역참조 가능하고 해당 URI에서 유용한 문서를 제공하는 것이 권장된다.

참고

미디어 유형 매개변수 [RFC4288]로서 HTTP Content-Type 헤더 또는 HTTP Accept 헤더 [RFC7231]에서 사용될 때, profile 매개변수의 값은 여러 프로파일 URI를 구분하는 데 사용되는 공백을 포함하여 공백 문자와 같은 특수 문자를 포함하면 따옴표(ASCII ")로 둘러싸야 한다.

profile 매개변수의 값은 하나 이상의 URI를 포함하며 IRI가 아니라는 점에 유의하는 것이 중요하다. 따라서 [RFC3987]의 3절 IRI와 URI의 관계에 지정된 대로 IRI와 URI 사이의 변환이 필요할 수 있다.

E. 감사의 말

E.1 RDF 1.1에 대한 감사의 말

이 절은 비규범적입니다.

이 작업은 다른 RDF 구문과 Turtle의 배경을 논의하는 논문 New Syntaxes for RDF에 설명되었다 (WWW2004에 제출되었으며, 그곳에서는 N-Triples Plus라고 불렸다).

이 작업은 EU IST-7 프로그램 IST-2001-34732(2002-2004)의 지원을 받은 Semantic Web Advanced Development Europe (SWAD-Europe) 프로젝트 중에 시작되었으며, 이후 개발은 영국 University of BristolInstitute for Learning and Research Technology가 지원했다 (2002년-2005년 9월).

이 버전에 대한 귀중한 기여는 Gregg Kellogg, Andy Seaborne, Sandro Hawke 및 RDF Working Group 구성원들이 했다.

이 문서는 더 넓은 커뮤니티의 검토 과정을 통해 개선되었다.

E.2 RDF 1.2에 대한 감사의 말

이 절은 비규범적입니다.

편집자 외에도 다음 사람들이 이 명세에 기여했다: Andrew Louis, Denis Ah-Kang, John Walker, Mirek Kratochvil, Niklas Lindström, Peter F. Patel-Schneider, Pierre-Antoine Champin, Ted Thibodeau Jr, Thomas Tanon, and William Van Woensel

RDF & SPARQL Working Group Group의 구성원에는 다음이 포함되었다
James Anderson, Dörthe Arndt, Jerven Bolleman, Erich Bremer, Pierre-Antoine Champin, Souripriya Das, Enrico Franconi, Adrian Gschwend, Olaf Hartig, Gregg Kellogg†, Ora Lassila, Niklas Lindström, Thomas Lörtsch, Peter Patel-Schneider, Dave Raggett, Felix Sasaki, Andy Seaborne, Ruben Taelman, Thomas Pellissier Tanon, Ted Thibodeau Jr, Dominik Tomaszuk, Gregory Williams, William Van Woensel, and Antoine Zimmermann
† Gregg Kellogg는 2025년 9월에 세상을 떠났다. RDF 및 관련 표준의 더 넓은 생태계에 대한 그의 방대한 기여에 깊이 감사한다.
편집자 참고

Task Force 구성원을 인정할 것인가? 기여자 목록을 찾기가 쉽지 않다.

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

이 절은 비규범적입니다.

G. 색인

G.1 이 명세가 정의한 용어

G.2 참조로 정의된 용어

H. 참고문헌

H.1 규범적 참고문헌

[BCP47]
Tags for Identifying Languages. A. Phillips, Ed.; M. Davis, Ed. IETF. September 2009. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646
[EBNF-NOTATION]
EBNF Notation. Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. W3C Recommendation. URL: https://www.w3.org/TR/xml/#sec-notation
[I18N-GLOSSARY]
Internationalization Glossary. Richard Ishida; Addison Phillips. W3C. 17 October 2024. W3C Working Group Note. URL: https://www.w3.org/TR/i18n-glossary/
[RDF12-CONCEPTS]
RDF 1.2 Concepts and Abstract Data Model. Andy Seaborne; Gregg Kellogg; Olaf Hartig; Pierre-Antoine Champin. W3C. 7 April 2026. W3C Candidate Recommendation. URL: https://www.w3.org/TR/rdf12-concepts/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3629]
UTF-8, a transformation format of ISO 10646. F. Yergeau. IETF. November 2003. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3629
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3987
[RFC6906]
The 'profile' Link Relation Type. E. Wilde. IETF. March 2013. Informational. URL: https://www.rfc-editor.org/rfc/rfc6906
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[UNICODE]
The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/

H.2 정보성 참고문헌

[HTML5]
HTML5. Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 27 March 2018. W3C Recommendation. URL: https://www.w3.org/TR/html5/
[LANG-SUBTAG-REGISTRY]
Language Subtag Registry. IANA. URL: http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
[RDF-MT]
RDF Semantics. Patrick Hayes. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-mt/
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[RDF12-INTEROP]
RDF 1.2 Interoperability. Pierre-Antoine Champin. W3C. W3C Editor's Draft. URL: https://w3c.github.io/rdf-interop/spec/
[RDF12-N-QUADS]
RDF 1.2 N-Quads. Gregg Kellogg; Dominik Tomaszuk. W3C. 28 May 2026. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-n-quads/
[RDF12-N-TRIPLES]
RDF 1.2 N-Triples. Gregg Kellogg; Dominik Tomaszuk. W3C. 15 May 2026. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-n-triples/
[RDF12-NEW]
What’s New in RDF 1.2. The W3C RDF & SPARQL Working Group. W3C. W3C Editor's Draft. URL: https://w3c.github.io/rdf-new/spec/
[RDF12-PRIMER]
RDF 1.2 Primer. Pierre-Antoine Champin; Niklas Lindström. W3C. 16 April 2026. DNOTE. URL: https://www.w3.org/TR/rdf12-primer/
[RDF12-SCHEMA]
RDF 1.2 Schema. Dominik Tomaszuk. W3C. 28 March 2026. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-schema/
[RDF12-SEMANTICS]
RDF 1.2 Semantics. Peter Patel-Schneider; Enrico Franconi; Dörthe Arndt. W3C. 7 April 2026. W3C Candidate Recommendation. URL: https://www.w3.org/TR/rdf12-semantics/
[RDF12-TRIG]
RDF 1.2 TriG. Gregg Kellogg; Dominik Tomaszuk. W3C. 28 May 2026. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-trig/
[RDF12-XML]
RDF 1.2 XML Syntax. Gregg Kellogg; Jerven Bolleman. W3C. 9 April 2026. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-xml/
[RFC3023]
XML Media Types. M. Murata; S. St. Laurent; D. Kohn. IETF. January 2001. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3023
[RFC4288]
Media Type Specifications and Registration Procedures. N. Freed; J. Klensin. IETF. December 2005. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc4288
[RFC7231]
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[SPARQL12-CONCEPTS]
SPARQL 1.2 Concepts. The W3C RDF & SPARQL Working Group. W3C. W3C Editor's Draft. URL: https://w3c.github.io/sparql-concepts/spec/
[SPARQL12-ENTAILMENT]
SPARQL 1.2 Entailment Regimes. Peter Patel-Schneider. W3C. 9 April 2026. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-entailment/
[SPARQL12-FEDERATED-QUERY]
SPARQL 1.2 Federated Query. Ruben Taelman; Gregory Williams. W3C. 23 April 2026. W3C Working Draft. 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. 19 December 2024. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-graph-store-protocol/
[SPARQL12-NEW]
What’s New in SPARQL 1.2. The W3C RDF & SPARQL Working Group. W3C. W3C Editor's Draft. URL: https://w3c.github.io/sparql-new/spec/
[SPARQL12-PROTOCOL]
SPARQL 1.2 Protocol. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 26 April 2026. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-protocol/
[SPARQL12-QUERY]
SPARQL 1.2 Query Language. Olaf Hartig; Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 28 May 2026. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-query/
[SPARQL12-RESULTS-CSV-TSV]
SPARQL 1.2 Query Results CSV and TSV Formats. Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 28 March 2026. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-results-csv-tsv/
[SPARQL12-RESULTS-JSON]
SPARQL 1.2 Query Results JSON Format. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 28 March 2026. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-results-json/
[SPARQL12-RESULTS-XML]
SPARQL 1.2 Query Results XML Format. Ruben Taelman; Dominik Tomaszuk; Thomas Pellissier Tanon. W3C. 27 December 2024. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-results-xml/
[SPARQL12-SERVICE-DESCRIPTION]
SPARQL 1.2 Service Description. Ruben Taelman; Gregory Williams. W3C. 23 April 2026. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-service-description/
[SPARQL12-UPDATE]
SPARQL 1.2 Update. Ruben Taelman; Andy Seaborne; Thomas Pellissier Tanon. W3C. 23 April 2026. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-update/
[TURTLE]
RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
[UNICODE-SECURITY]
Unicode Security Considerations. Mark Davis; Michel Suignard. Unicode Consortium. 19 September 2014. Unicode Technical Report #36. URL: https://www.unicode.org/reports/tr36/tr36-15.html
[XML-NAMES]
Namespaces in XML 1.0 (Third Edition). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 8 December 2009. W3C Recommendation. URL: https://www.w3.org/TR/xml-names/
[XMLSCHEMA11-2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/