Copyright © 2008-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
리소스 기술 프레임워크 (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은 또한
방향성이 있는 언어 태그 문자열을 지원한다.
이 절은 이 문서가 공개된 시점의 상태를 설명한다. 현재 W3C 간행물 목록과 이 기술 보고서의 최신 개정판은 W3C 표준 및 초안 색인에서 확인할 수 있다.
이 문서는 RDF 1.2 문서 모음의 일부이다. 이 문서는 RDF [RDF12-CONCEPTS]를 위한 구체적 구문인 간결한 RDF 트리플 언어, Turtle을 정의한다.
이 문서는 RDF & SPARQL 작업 그룹이 권고안 트랙을 사용하여 작업 초안으로 공개하였다.
작업 초안으로 공개되었다고 해서 W3C와 그 회원들의 승인을 의미하지는 않는다.
이 문서는 초안 문서이며 언제든지 다른 문서로 업데이트, 대체 또는 폐기될 수 있다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 적절하지 않다. 앞으로 이 권고안의 업데이트에는 새 기능이 포함될 수 있다.
이 문서는 W3C 특허 정책에 따라 운영되는 그룹에 의해 작성되었다. W3C는 해당 그룹의 산출물과 관련하여 이루어진 모든 특허 공개의 공개 목록을 유지 관리한다. 그 페이지에는 특허를 공개하기 위한 지침도 포함되어 있다. 어떤 특허가 필수 청구항을 포함한다고 실제로 알고 있는 개인은 W3C 특허 정책 6절에 따라 해당 정보를 공개해야 한다.
이 문서는 2025년 8월 18일 W3C 프로세스 문서의 적용을 받는다.
이 절은 비규범적입니다.
이 문서는 RDF [RDF12-CONCEPTS]를 위한 구체적 구문인 간결한 RDF 트리플 언어 Turtle을 정의한다.
Turtle 문서는 RDF 그래프의 텍스트 표현이다. 다음 Turtle 문서는 Green Goblin과 Spiderman 사이의 관계를 설명한다.
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 그래프를 간결한 텍스트 형식으로 작성할 수 있게 한다. RDF 그래프는 주어, 술어, 객체로 구성되는 트리플로 이루어진다.
주석은 다른 어휘 토큰의 일부가 아닌 # 뒤에
올 수 있으며, 줄 끝까지 계속된다.
가장 단순한 트리플 문은
(주어,
술어,
그리고
객체)
용어의 시퀀스이며,
RDF 트리플을
형성하고, 마침표(.)로 끝난다.
공백
(공백 문자,
탭,
LF, 및/또는
CR)은
용어 주위에 올 수 있다.
단, 문법에서 명시한 것처럼 의미가 있는 경우는 예외이다.
<http://example.org/#spiderman>
<http://www.perceive.net/schemas/relationship/enemyOf>
<http://example.org/#green-goblin> .
동일한 주어가 여러 술어에 의해 참조되는 경우가 많다.
predicateObjectList 생성 규칙은
주어 뒤에 오는, ;로 구분된 일련의 술어와 객체에
일치한다.
이는 해당 주어를 가진 일련의 RDF 트리플을 표현하며,
각 술어와
객체가 하나의 트리플에 할당된다.
따라서 ;는
술어와 객체 RDF
용어만 달라지는 트리플들의 주어를 반복하는 데 사용된다.
이 두 예제는 Spiderman에 관한 트리플을 작성하는 동등한 방식이다.
<http://example.org/#spiderman> <http://www.perceive.net/schemas/relationship/enemyOf> <http://example.org/#green-goblin> ;
<http://xmlns.com/foaf/0.1/name> "Spiderman" .
<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" .
술어와 마찬가지로, 동일한 주어와 술어가 서로 다른 객체와 함께 반복되는 경우가 많다.
objectList 생성 규칙은
술어 뒤에 오는, ,로 구분된 일련의 객체에
일치한다.
이는 동일한 주어와
술어를 가진 일련의 RDF 트리플을 표현하며,
각 객체가 하나의 트리플에 할당된다.
따라서 ,는 객체
RDF 용어만
다른 트리플들의 주어와 술어를 반복하는 데 사용된다.
이 두 예제는 두 언어로 된 Spiderman의 이름을 작성하는 동등한 방식이다.
<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Spiderman", "Человек-паук"@ru .
<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은 각각을 작성하는 여러 방법을 제공한다.
Turtle 언어는 처음 등장한 이후 발전해 왔으며, RDF
1.2는
새로운 구문을 추가한다.
RDF 1.2 Turtle은
선택적 version 미디어 유형 매개변수와 함께
VERSION 및
@version 지시자를 도입한다.
초기 텍스트 방향
또는 트리플
용어와 같은 새 기능으로 Turtle을 직렬화할 때,
저자는 이러한 지시자를 사용하여 새 구문 형식의 사용을 선언할 수 있다.
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 |} .
또는 이전 스타일의 지시자를 사용할 수 있다
(뒤에 "."가 붙는다는 점에 유의):
@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
미디어 유형 매개변수를 사용하여 버전을 선언할 수 있다:
HTTP/1.1 200 OK
Content-Type: text/turtle; version=1.2
초기 텍스트 방향과 같은
RDF 1.2 전용 기능을 사용할 때에는,
문서 초반에 VERSION
또는 @version
지시자를 사용하여 특정 RDF 버전을 선언해야 한다.
이를 통해 이러한 기능을 지원하지 않는 파서가
그런 기능의 존재를 일찍 감지하고, 잠재적으로
사용자에게 알려 작업을 중지하거나
입력 데이터의 일부가 원하는 대로 처리되지 않을 것이라는 사실에
대응할 기회를 줄 수 있다.
Turtle 문서에는 여러 버전 지시자가 나타날 수 있다. 지시자는 해당 지시자 뒤의 문서 부분에 적용되며, 다른 지시자가 나타나거나 문서 끝에 도달할 때까지 유효하다.
현재 버전 지시자가 없는 경우, 미디어 유형의 일부로 지정된 모든 버전이 고려된다.
버전 정보가 전혀 없는 경우, 이전 Turtle 버전 [TURTLE]과의
호환성을 극대화하기 위해 적절한 기본값은 "1.1"이다.
어떤 경우에도 버전 선언은 단지 힌트일 뿐이다;
파서는 선언된 버전 밖의 기능을 반드시 거부해야 하는 것은 아니다
(다만 경고로 표시할 수는 있다).
"1.1"은 허용되는 버전 레이블이지만,
VERSION 또는 @version 지시자에서 이를 사용하는 것은 권장되지 않는다.
이는 Turtle 1.1 파서를 불필요하게 실패하게 만들 수 있기 때문이다.
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를
작성하려면:
http://www.perceive.net/schemas/relationship/에 대한 접두사 레이블을
somePrefix로 정의한다
somePrefix:enemyOf를 작성한다. 이는
<http://www.perceive.net/schemas/relationship/enemyOf>를 작성하는 것과 동등하다
이는 접두사 선언에 대한 SPARQL 스타일 구문을 사용하여 작성할 수 있다:
PREFIX somePrefix: <http://www.perceive.net/schemas/relationship/>
<http://example.org/#green-goblin> somePrefix:enemyOf <http://example.org/#spiderman> .
또는 접두사 선언을 위한 원래 Turtle 구문으로 작성할 수 있다:
@prefix somePrefix: <http://www.perceive.net/schemas/relationship/> .
<http://example.org/#green-goblin> somePrefix:enemyOf <http://example.org/#spiderman> .
접두 이름은 XML QName의 상위집합이다. 차이점은 접두 이름의 로컬 부분에 다음을 포함할 수 있다는 점이다:
leg:3032571 또는 isbn13:9780136019701og:video:heightwgs:lat\-long다음 Turtle 문서는 Turtle에서 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 foaf: <http://xmlns.com/foaf/0.1/>
<http://example.org/#green-goblin> foaf:name "Green Goblin" .
<http://example.org/#spiderman> foaf:name "Spiderman" .
따옴표로 묶인 리터럴(문법 생성 규칙
RDFLiteral)은 어휘 형식 뒤에
언어 태그
(선택적으로 초기 텍스트 방향 포함),
데이터형 IRI, 또는 둘 다 없는 형태를 가진다.
어휘 형식의 표현은 시작 구분자
(예:
",
',
""", 또는
''');
허용된 문자, 숫자 이스케이프 시퀀스,
및/또는 문자열 이스케이프 시퀀스의 시퀀스;
그리고 시작 구분자와 일치하는 끝 구분자로
구성된다.
이에 대응하는 RDF 어휘
형식은
이스케이프 시퀀스를 처리한 뒤 구분자 사이에 있는 문자들이다.
존재하는 경우, 언어 태그 앞에는
@가 오며,
언어 태그와 --로 구분된
초기 텍스트 방향이
뒤따를 수 있다.
언어 태그가 없으면
데이터형 IRI가 있을 수 있으며,
그 앞에는 ^^가 온다.
Turtle의 데이터형 IRI는
해결된 IRI,
상대 IRI 참조,
또는 접두 이름을 사용하여 작성할 수 있다.
데이터형 IRI와 언어 태그가 모두 없으면,
데이터형은 xsd:string이다.
\는
이스케이프 시퀀스의 일부가 아닌 한 어떤 따옴표 리터럴에도 나타날 수 없다.
그 밖의 제한은 구분자에 따라 다르다:
'로 구분된 리터럴은
이스케이프되지 않은
',
LF, 또는
CR
문자를 포함할 수 없다.
"로 구분된 리터럴은
이스케이프되지 않은
",
LF, 또는
CR
문자를 포함할 수 없다.
'''로 구분된 리터럴은 그러한
시퀀스를 포함할 수 없다."""로 구분된 리터럴은 그러한
시퀀스를 포함할 수 없다.
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
숫자는 어휘 형식과 데이터형을 가진 다른 리터럴처럼 작성할 수 있다
(예: "-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]". |
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
불리언 값은 true 또는
false로 작성할 수 있으며(대소문자 구분),
데이터형 xsd:boolean을 가진
RDF 리터럴을 나타낸다
[XMLSCHEMA11-2].
PREFIX : <http://example.org/stats/>
<http://somecountry.example/census2007>
:isLandlocked false . # xsd:boolean
Turtle의
RDF 빈
노드는
_: 뒤에 일련의 문자로 이루어진
빈 노드 식별자가 오는 방식으로 표현된다.
식별자의 문자는
PN_CHARS_BASE를 기반으로 하며,
다음과 같이 완화된다:
_와
숫자 문자 0–9는
빈 노드 식별자의
어느 위치에나 나타날 수 있다.
.는
첫 번째 또는 마지막 문자를 제외한 어느 위치에나 나타날 수 있다.-,
·,
‿,
⁀,
그리고
결합 발음 구별 부호(U+0300
부터 U+036F까지)는
첫 번째 문자를 제외한 어느 위치에나 허용된다.
문서에서 고유한 각 빈 노드 식별자마다 새로운 RDF 빈 노드가 할당된다. 같은 빈 노드 식별자를 반복해서 사용하면 동일한 빈 노드를 식별한다.
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
_:alice foaf:knows _:bob .
_:bob foaf:knows _:alice .
Turtle에서는
blankNodePropertyList
생성 규칙과 터미널 ANON에 일치할 때도
새로운 RDF 빈
노드가 할당된다.
이 둘은 모두 트리플의 subject
또는 object 위치에 나타날 수 있다
(Turtle 문법 참조).
해당 주어 또는 객체는 새로운 RDF 빈
노드이다.
이 빈 노드는 또한 blankNodePropertyList 안에 포함된
predicateObjectList 생성 규칙에
일치하여 생성되는 트리플들의 주어 역할도 한다.
이러한 트리플의 생성은
술어 목록에서 설명한다.
빈 노드는 아래에서 설명하는 컬렉션에 대해서도 할당된다.
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를 사용하는 것은
어떤 노드의 일련의 속성을 표현하는 일반적인 관용구이다.
| 축약형: | 대응하는 단순 트리플: |
|---|---|
|
|
RDF는 RDF 노드 목록을 위한
컬렉션 [RDF12-SEMANTICS]
구조를 제공한다.
컬렉션에 대한 Turtle 구문은 RDF 용어의
비어 있을 수 있는 목록을
()로 둘러싼 것이다.
이 컬렉션은 rdf:first/rdf:rest
목록 구조를 나타내며, () 안에 둘러싸인 용어의 순서가
rdf:first
문의 객체 시퀀스가 된다.
(…) 구문은 트리플의
subject
또는 object 위치에
나타나야 한다
(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 () .
트리플
용어는
ttSubject,
predicate, 및
ttObject를 가진
tripleTerm으로 표현되며,
이들 모두 앞에는 <<(가 오고,
모두 뒤에는 )>>가 온다.
트리플 용어는
중첩될 수 있다는 점에 유의한다.
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 .
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 >> >>.
reifiedTriple이
IRI
또는 빈
노드로 식별되지 않으면,
새로운 RDF 빈
노드가 할당되어
이 관계를 식별하는 데 사용된다.
VERSION "1.2"
PREFIX : <http://www.example.org/>
:employee38 :familyName "Smith" .
<< :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .
PREFIX : <http://www.example.org/>
:employee38 :familyName "Smith" .
<< :employee38 :jobTitle "Assistant Designer" ~ _:id >> :accordingTo :employee22 .
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을 가지고 있다고 단언하지 않는다는 점에 유의한다;
이 그래프는 employee22가
reifiedTriple을 사용해 그 주장을 했다고 말한다.
다시 말해, "employee38 has a jobTitle of 'Assistant Designer'"라는 트리플은,
위의 "employee38 has a familyName of 'Smith'"처럼 그래프 자체의 구성원이 아니다;
오히려 그것은 구체화 트리플로 알려져 있다.
reifiedTriple은
rdf:reifies 술어를 사용하여
구체화자를
tripleTerm에 연결하는
구문적 설탕이다.
Turtle은 또한 주석 구문을 정의하여 트리플을 구체화하고 단언할 수 있게 하며, 편리한 단축 표현을 제공한다. 주석은 명시적 또는 암시적 식별자를 통해 트리플을 동시에 단언하고, 해당 트리플이 추가 트리플의 주어 또는 객체가 되게 하는 데 사용할 수 있다. 명시적으로 식별된 경우, 동일한 구체화자는 추가 트리플 및/또는 트리플 용어의 주어 또는 객체로 사용될 수 있다.
reifiedTriple처럼,
주석 구문은
IRI 또는
빈
노드로 작성되는
구체화자를 사용하며,
그 앞에는 틸드(~)가 와서
구체화되는
트리플
용어를 식별한다.
그러나
reifiedTriple에는
최대 하나의 구체화자만 포함될 수 있는 반면,
주석 구문에는 임의의 수의
구체화자가 포함될 수 있다.
각 구체화자는
대응하는 구체화 트리플을 생성하게 한다.
구체화자 뒤에는 주석 블록이 올 수 있다.
구체화자 뒤에 주석 블록이 오지 않으면,
이는 추가 주석이 없는
reifiedTriple과
유사하게 처리된다.
주석 블록 바로 앞에 구체화자가 오지 않으면,
새로운 RDF 빈 노드가 할당되어
트리플
용어의
구체화자 역할을 한다.
주석 구문은 Turtle의 구문적 단축 표현이다. RDF 추상 구문 [RDF11-CONCEPTS]은 트리플이 어떻게 작성되었는지를 구별하지 않는다.
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 |} .
는 다음과 동일한 트리플 집합이다:
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 .
트리플 용어를 구체화자 대신 사용하도록 완전히 확장하면 다음과 같은 결과가 된다:
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 빈 노드가 할당되어 트리플 용어의 구체화자 역할을 한다.
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 빈
노드를 나타낸다:
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 빈 노드와
연결된다.
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 빈
노드를 나타낸다:
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 .
주석 구문은 주석 블록 없이 여러 명시적 구체화자를 포함할 수도 있다. 이러한 각 구체화자는 대응하는 구체화 트리플을 생성하게 한다.
VERSION "1.2"
PREFIX : <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
:alice :name "Alice" ~ :stmt1 ~ :stmt2 .
이 예제를 완전히 확장하면 다음 트리플이 된다:
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" )>> .
이 절은 비규범적입니다.
이 예제는 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 컬렉션의 예.
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""" .
문법이 나타내는 것처럼,
collection은
subject 또는
object일 수 있다.
이 주어 또는 객체는 컬렉션에 하나 이상의 객체가 있는 경우 첫 번째 객체를 위한 새로운
빈
노드가 되며,
컬렉션이 비어 있으면 rdf:nil이 된다.
예를 들어,
PREFIX : <http://example.org/stuff/1.0/>
(1 2.0 3E1) :p "w" .
는 다음에 대한 구문적 설탕이다(여기서
빈
노드
b0, b1, 및 b2는
RDF 그래프의 다른 어느 곳에도 나타나지 않는다는 점에 유의):
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 컬렉션은 중첩될 수 있으며 다른 구문 형식도 포함할 수 있다:
PREFIX : <http://example.org/stuff/1.0/>
(1 [:p :q] ( 2 ) ) :p2 :q2 .
는 다음에 대한 구문적 설탕이다:
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 .
이 절은 비규범적입니다.
SPARQL 1.2 Query Language (SPARQL) [SPARQL12-QUERY]는 TriplesBlock 생성 규칙에 Turtle 스타일 구문을 사용한다. 이 생성 규칙은 다음 점에서 Turtle 언어와 다르다:
?name 또는
$name)를 허용한다.
a를 제외하고
대소문자를 구분하지 않는 키워드를 사용한다.
Turtle의 @prefix 및 @base 선언은 대소문자를 구분하며,
SPARQL에서 파생된
PREFIX 및 BASE는 대소문자를 구분하지 않는다.
true와 false는
SPARQL에서는 대소문자를 구분하지 않지만
Turtle에서는 대소문자를 구분한다.
TrUe는 Turtle에서 유효한 불리언 값이 아니다.
자세한 정보는 SPARQL 질의 문서 [SPARQL12-QUERY]의 IRI 구문 및 SPARQL 문법 절을 참조한다.
비규범적이라고 표시된 절뿐 아니라, 이 명세의 모든 작성 지침, 도표, 예제 및 참고는 비규범적이다. 이 명세의 그 밖의 모든 것은 규범적이다.
이 문서에서 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 파서가 부적합한 입력 문서를 처리하는 방식을 정의하지 않는다.
Turtle의 미디어 유형은 text/turtle이다.
Turtle 콘텐츠의 콘텐츠 인코딩은 항상 UTF-8 [RFC3629]이다.
Turtle 문서는 UTF-8 [RFC3629]로
인코딩된 RDF 문자열이다.
U+0000부터 U+D7FF까지 및
U+E000부터 U+10FFFF까지의
범위에 있는 Unicode 스칼라 값만
허용된다. 이는
범위 U+D800부터 U+DFFF까지의
서러게이트 코드 포인트를 제외한다.
공백(생성 규칙 WS)은 그렇지 않으면 하나의 터미널로
(잘못) 인식될 수 있는 두 터미널을 구분하는 데 사용된다. 아래에서 대문자로 된 규칙 이름은
공백이 의미를 가지는 위치를 나타내며, 이는 Turtle 파서를 구성하기 위한 터미널 선택지 중 하나를 이룬다.
공백은 String 생성 규칙에서 의미가 있다.
Turtle의 주석은
IRIREF,
STRING_LITERAL_SINGLE_QUOTE,
STRING_LITERAL_QUOTE,
STRING_LITERAL_LONG_SINGLE_QUOTE,
또는
STRING_LITERAL_LONG_QUOTE의
외부에 있는 #로 시작하며,
줄 끝(LF 또는
CR로 표시)까지
계속되거나, 주석 표시 뒤에 줄 끝이 없으면 파일 끝까지 계속된다.
주석은 공백으로 처리된다.
상대 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를 설정한다.
Turtle 문서에는 세 가지 형태의 이스케이프가 사용된다:
숫자 이스케이프 시퀀스는 Unicode 코드 포인트의 값을 나타낸다.
숫자 이스케이프 시퀀스는
Unicode 서러게이트의 범위인
U+D800부터 U+DFFF까지의
범위에 있는 코드 포인트 값을 생성해서는 안 된다.
| 이스케이프 시퀀스 | Unicode 코드 포인트 |
|---|---|
\u hex
hex
hex
hex
|
네 개의 16진수 숫자를 최상위 숫자에서 최하위 숫자로
해석하여 인코딩된 값에 대응하는,
U+0000부터 U+D7FF까지 및
U+E000부터 U+FFFF까지의
범위에 있는 Unicode 코드 포인트.
|
\U hex
hex
hex
hex
hex
hex
hex
hex
|
여덟 개의 16진수 숫자를 최상위 숫자에서 최하위 숫자로
해석하여 인코딩된 값에 대응하는,
U+0000부터
U+D7FF까지 및
U+E000부터 U+10FFFF까지의
범위에 있는 Unicode 코드 포인트.
|
여기서 hex는 16진수 문자이다
HEX ::= [0-9] |
[A-F] |
[a-f]
문자열 이스케이프 시퀀스는 문자열 리터럴에서 전통적으로 이스케이프되는 문자를 나타낸다:
| 이스케이프 시퀀스 | Unicode 코드 포인트 |
|---|---|
\t |
U+0009 |
\b |
U+0008 |
\n |
U+000A |
\r |
U+000D |
\f |
U+000C |
\" |
U+0022 |
\' |
U+0027 |
\\ |
U+005C |
예약 문자 이스케이프 시퀀스는
\ 뒤에
다음 문자 중 하나 ~.-!$&'()*+,;=/?#@%_가 오는 것으로 구성되며,
\ 오른쪽의 문자를 나타낸다.
| 숫자 이스케이프 |
문자열 이스케이프 |
예약 문자 이스케이프 |
|
|---|---|---|---|
IRI,
RDF 용어로 사용되거나
@prefix,
PREFIX,
@base,
또는 BASE 선언에서 사용됨
|
예 | 아니요 | 아니요 |
| 로컬 이름 | 아니요 | 아니요 | 예 |
| 문자열 | 예 | 예 | 아니요 |
이스케이프 시퀀스는 관련 문법 생성 규칙과 일치하는 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를 지정한다.
여기서 사용되는 EBNF는 XML 1.0 [EBNF-NOTATION]에서 정의된다.
참고:
@base',
'@prefix',
'@version',
'a',
'true', 및
'false')는
대소문자를 구분한다.
큰따옴표 안의 키워드
("BASE",
"PREFIX", 및
"VERSION")는
대소문자를 구분하지 않는다.
UCHAR와
ECHAR는
대소문자를 구분한다.
turtleDoc이다.
@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 |
::= | '\' ('_' | '~' | '.' | '-' | "!" | '$' | '&' | "'" | '(' | ')' | '*' | '+' | ',' | ';' | '=' | '/' | '?' | '#' | '@' | '%') |
이 문법의 텍스트 버전은 여기에서 사용할 수 있다.
이 문서는 몇 가지 특정 터미널 리터럴 문자열 [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 문자의 특정 시퀀스로 구성된다:
spaceU+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)가
온다
_:_ 뒤에 :가 온다--- 문자가 이어진 것RDF 1.2 Concepts and Abstract Syntax 명세
[RDF12-CONCEPTS]는 네 가지 유형의 RDF 용어를 정의한다:
IRI,
리터럴,
빈
노드, 그리고
트리플
용어.
리터럴은 어휘 형식과
선택적 언어 태그 [BCP47]
– 가능하면 초기 텍스트 방향을 포함 –
또는 데이터형 IRI로 구성된다.
추가 유형인 prefix는 파싱 중 문자열 식별자를
이름공간 IRI에 매핑하는 데 사용된다.
이 절은 6.5 문법의 문법에 부합하는
문자열을
생성 규칙과 어휘 토큰에 일치하는 문자열을
RDF 용어 또는 그 구성 요소(예: 언어
태그, 리터럴의 어휘
형식)에 매핑하여 트리플 집합으로 매핑한다.
문법 생성 규칙은 파서 상태를 변경하고 트리플을 내보낸다.
Turtle 파싱에는 아홉 가지 항목으로 이루어진 상태가 필요하다:
base 생성 규칙에 도달하면, 두 번째 규칙
인자인
IRIREF가 상대
IRI 해석에 사용되는 기준 URI이다.
prefixID 생성 규칙의
두 번째와 세 번째 규칙 인자
(PNAME_NS 및 IRIREF)는
접두사
(PNAME_NS)에 대한
이름공간 이름(IRIREF)을 할당한다.
prefixID 또는
sparqlPrefix 생성 규칙의
외부에서는,
모든 PNAME_NS가
namespaces 맵의 현재 상태에 있는
이름공간으로 대체된다.
접두사는 PNAME_NS 생성 규칙
PN_PREFIX? ':'에 따라 빈 문자열일 수도 있다는 점에 유의한다.
subject,
rtSubject,
ttSubject,
blankNodePropertyList,
collection, 및
annotationBlock
생성 규칙에 바인딩된다.
verb 생성 규칙에 바인딩된다.
일치한 토큰이 a이면,
curPredicate는 IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#type에 바인딩된다.
object,
rtObject, 및
ttObject 생성 규칙에 바인딩된다.
reifier 및
annotationBlock 생성 규칙에 바인딩된다.
xsd:string curVersion –
문서를 트리플로 파싱하는 데 사용되는
RDF 버전.
미디어 유형의 일부로 지정된 경우,
curVersion의 기본값은
version 매개변수에서 가져온다.
curVersion에 허용되는 값은 [RDF12-CONCEPTS]의 2.1 Version Labels에서 정의된다.
버전 선언은 단지 힌트일 뿐이다;
이 명세는 curVersion에 기반한 어떤 파서 동작도 의무화하지 않지만,
파서는 curVersion의 값과 일치하지 않는 기능을 만나거나,
curVersion에 허용되지 않는 값을 만났을 때
오류 또는 경고를 보낼 MAY.
용어 생성자는 "records the curSubject and curPredicate."와 같은 언어를 사용하여 표시되는 이러한 값들의 스택을 만들 수 있다.
이 표는 생성 규칙과 어휘 토큰을 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 규칙이 일치하면,
데이터형 IRI가
iri에서 파생되며,
리터럴에는 언어 태그가 없다. 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 빈 노드에서 가져온다. |
입력에서 오류를 감지하는 처리기는 입력에 설명된 것보다 적은 수의 트리플을 포함하는 그래프 (트리플이 전혀 없는 경우 포함)를 만들 수 있으므로, 소비자는 출력 트리플을 사용할 때 신호된 모든 오류 정보를 고려해야 한다. 출력 트리플은 불완전하거나 잘못된 형식의 또는 올바르지 않게 구성된 용어를 포함할 수 있다.
Turtle 문서는 RDF 그래프를 정의하며, 이는
RDF 트리플들의 집합으로 구성된다.
subject 생성 규칙은
curSubject를 설정한다.
verb 생성 규칙은
curPredicate를 설정한다.
object 및
ttObject 생성 규칙은
curObject를 설정한다.
문서 안의 각 object
N은 RDF 트리플을 생성한다:
curSubject
curPredicate N .
reifier 생성 규칙을 시작하면,
curReifier는 reifier 용어
생성자에서 가져온다.
그런 다음 RDF 트리플 curReifier
rdf:reifies curTripleTerm을 산출한다.
reifiedTriple 생성 규칙을 시작하면
curTripleTerm을 기록한다.
새 tripleTerm 인스턴스
curTripleTerm가
rtSubject,
verb, 및
rtObject 생성 규칙을 사용하여 생성된다.
reifiedTriple 생성 규칙을 끝낼 때,
curReifier가 설정되어 있지 않으면, 새로운 RDF 빈
노드가 할당된다;
다음으로 RDF 트리플
curReifier
rdf:reifies curTripleTerm을 산출하고,
그런 다음 curTripleTerm의 기록된 값을 복원한다.
reifiedTriple에 일치하여
생성되는 노드는 curReifier이다.
annotation 생성 규칙을 시작하면
curSubject와 curPredicate를 기록한다.
새 tripleTerm 인스턴스
curTripleTerm가
curSubject curPredicate curObject를 사용하여 생성되고,
curReifier의 값은 지워진다.
annotation 생성 규칙을 끝낼 때
curSubject와 curPredicate의 기록된 값을 복원한다.
annotationBlock 생성 규칙을
시작하면
curTripleTerm을 기록한다.
curReifier가 설정되어 있지 않으면, 새로운 RDF 빈
노드가 할당되고,
생성 규칙은 RDF 트리플
curReifier rdf:reifies curTripleTerm을 산출한다.
curSubject는 curReifier에서 가져온다.
annotationBlock 생성 규칙을
끝낼 때
curReifier의 값을 지우고
curTripleTerm을 복원한다.
curReifier가 이미 설정되어 있었다면,
구체화 트리플 curReifier rdf:reifies curTripleTerm은
7.3.1
구체화자에서 내보내졌다.
blankNodePropertyList
생성 규칙을 시작하면 curSubject와 curPredicate를 기록하고,
curSubject를 새로운 빈 노드 B로 설정한다.
blankNodePropertyList
생성 규칙을 끝낼 때 curSubject와 curPredicate를 복원한다.
blankNodePropertyList에
일치하여 생성되는 노드는 빈 노드 B이다.
collection 생성 규칙을 시작하면
curSubject와 curPredicate를 기록한다.
collection 생성 규칙 안의
각 object는
curSubject가 새로운 빈 노드 B로 설정되고,
curPredicate가
rdf:first로 설정된다.
첫 번째 이후의 각 객체 objectn는 트리플을 생성한다:objectn-1 rdf:rest
objectn .
collection 생성 규칙을 끝낼 때
추가 트리플 curSubject rdf:rest rdf:nil .을 생성하고
curSubject와 curPredicate를 복원한다.
collection에 일치하여 생성되는 노드는
비어 있지 않은 목록의 경우 첫 번째 빈 노드 B이고, 빈 목록의 경우
rdf:nil이다.
이 절은 비규범적입니다.
다음 정보성 예제는 LALR(1) 파서로 이 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> .
ericFoaf를 IRI
http://www.w3.org/People/Eric/ericP-foaf.rdf#에 매핑한다.
http://xmlns.com/foaf/0.1/에 매핑한다.http://www.w3.org/People/Eric/ericP-foaf.rdf#ericP를 할당한다.
http://xmlns.com/foaf/0.1/givenName를 할당한다.<...rdf#ericP> <.../givenName>
"Eric"
.http://xmlns.com/foaf/0.1/knows를 할당한다.<...rdf#ericP> <.../knows>
<...who/dan-brickley> .<...rdf#ericP> <.../knows>
_:1 .
_:1로 재할당한다.http://xmlns.com/foaf/0.1/mbox를 할당한다._:1 <.../mbox>
<mailto:timbl@w3.org>
.<...rdf#ericP>, <.../knows>)으로 복원한다.<...rdf#ericP> <.../knows>
<http://getopenid.com/amyvdh> .이 절은 비규범적입니다.
HTML [HTML5]
script 태그는
문서에 데이터 블록을 삽입하는 데 사용할 수 있다. Turtle은 이 방식으로 HTML에 쉽게 삽입할 수 있다.
<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 문서의 인코딩과 일치한다.
이 절은 비규범적입니다.
JavaScript와 마찬가지로, HTML(text/html)용으로 작성된 Turtle은 XHTML
(application/xhtml+xml)에서 사용될 때 깨질 수 있다. 해결책은 JavaScript에 사용되는 것과 동일하다.
<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/html과 application/xhtml+xml 양쪽으로 제공되는
폴리글랏 문서에서도 Turtle을 안전하게 만들 수 있다. CDATA 절을 사용하지 않거나
]]>를 이스케이프하지 않으면 올바른 형식이 아닌 XML 문서가 될 수 있다.
이 절은 비규범적입니다.
삽입된 Turtle을 파싱하는 것과 일반 Turtle 문서를 파싱하는 것 사이에는
구문적 차이나 문법 차이가 없다.
HTML DOM에서 파싱된 Turtle 문서는 UTF-8 [RFC3629] 코드
포인트의 스트림이 아니라 문자 데이터의 스트림이 된다.
HTML 문서가 이미 DOM으로 파싱되었다면 디코딩은 필요하지 않다.
각 script 데이터 블록은 자체적인 Turtle 문서로 간주된다.
Turtle 데이터 블록 안의 PREFIX 및 BASE 선언은 해당 데이터 블록에 범위가 한정되며
다른 데이터 블록에 영향을 주지 않는다.
HTML lang 속성이나 XHTML xml:lang 속성은
데이터 블록의 파싱에 아무 영향도 주지 않는다.
둘러싼 HTML 문서의 기준 URI는 RFC3986 5.1.1절에 따른
"콘텐츠에 포함된 기준 URI"를 제공한다.
이 절은 비규범적입니다.
Turtle 형식은 임의의 애플리케이션 데이터를 표현하는 데 사용되며, 여기에는 개인 식별 정보(PII)의 표현이나 민감한 것으로 간주될 수 있는 다른 정보가 포함될 수 있다. 이러한 정보를 공개하는 저자는 그러한 정보를 공개할 필요와 사용 방식을 신중하게 고려하는 것이 좋으며, 데이터가 소비되고 잠재적으로 드러날 것으로 예상되는 지역에 적용되는 규정 (예: GDPR, CCPA, 기타)도 함께 고려해야 한다. 특히 데이터에 접근하기 위한 권한 부여 조치가 필요한지 여부를 고려해야 한다.
이 절은 비규범적입니다.
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절에서 찾을 수 있다.
Turtle의 인터넷 미디어 유형(이전의 MIME 유형)은 "text/turtle"이다.
다음 정보는 검토, 승인 및 IANA 등록을 위해 Internet Engineering Steering Group (IESG)에 제출되었다.
versionversion의 허용 가능한 값은
[RDF12-CONCEPTS]의
Version Labels에서 정의된다.
profileprofile 매개변수의 값은 공백으로 구분된 URI의 비어 있지 않은 목록이다.
자세한 정보와 배경은 [RFC6906]를 참조한다.
\uXXXX (U+0000부터 U+FFFF까지) 또는
\UXXXXXXXX 구문(U+10FFFF까지의 코드 포인트)으로도 표현할 수 있으며,
여기서 X는 16진수 숫자 [0-9A-Fa-f]이다
profile 매개변수는 클라이언트가 콘텐츠 협상 과정에서 자신의 선호를 표현하고,
서버가 응답에 대한 추가 정보를 나타내는 데 사용할 수 있다.
클라이언트가 profile 매개변수를 제공한 경우, 서버는
서버가 인식하는 목록의 모든 프로파일을 존중하는 문서를
반환하는 것이 좋다.
서버는 프로파일 값만을 근거로 오류로 응답하지 않는 것이 좋다.
서버가 profile 매개변수를 제공한 경우, 클라이언트는 이를 무시할 수 있다.
프로파일 URI는 역참조 가능하고 해당 URI에서 유용한 문서를 제공하는 것이 권장된다.
미디어 유형 매개변수
[RFC4288]로서
HTTP Content-Type 헤더
또는
HTTP Accept 헤더
[RFC7231]에서
사용될 때,
profile 매개변수의 값은 여러 프로파일 URI를 구분하는 데 사용되는 공백을 포함하여
공백 문자와 같은 특수 문자를 포함하면 따옴표(ASCII ")로 둘러싸야 한다.
profile 매개변수의 값은 하나 이상의 URI를 포함하며 IRI가 아니라는 점에
유의하는 것이 중요하다. 따라서 [RFC3987]의
3절 IRI와 URI의 관계에
지정된 대로 IRI와 URI 사이의 변환이 필요할 수 있다.
이 절은 비규범적입니다.
이 작업은 다른 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 Bristol의 Institute for Learning and Research Technology가 지원했다 (2002년-2005년 9월).
이 버전에 대한 귀중한 기여는 Gregg Kellogg, Andy Seaborne, Sandro Hawke 및 RDF Working Group 구성원들이 했다.
이 문서는 더 넓은 커뮤니티의 검토 과정을 통해 개선되었다.
이 절은 비규범적입니다.
편집자 외에도 다음 사람들이 이 명세에 기여했다: 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
Task Force 구성원을 인정할 것인가? 기여자 목록을 찾기가 쉽지 않다.
이 절은 비규범적입니다.
STRING_LITERAL_QUOTE
및 STRING_LITERAL_SINGLE_QUOTE에 포함되는 문자에 대한 정보성 제한을 업데이트했다.LANGTAG 터미널 생성 규칙을
LANG_DIR로 변경했다.
@version이
LANG_DIR와 일치하지 않는다는
조항도 포함되어 있음에 유의한다;
이전 버전의 문법은 그러한 일치를 허용했지만,
[BCP47]에 따라 잘못된 형식의 언어 태그를 가진 리터럴이 되고
유효하지 않은 리터럴을 형성하게 된다.
profile 미디어 유형 매개변수를 추가했다.Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: