YAML-LD 1.0

초록

[JSON-LD11]은 링크드 데이터 [LINKED-DATA]를 직렬화하기 위한 JSON 기반 형식이다. 최근 몇 년 동안 [YAML]은 더 간결한 형식으로 부상했으며 이전에 [JSON]으로 직렬화되던 정보를 표현하는 데 쓰인다. 여기에는 API 명세, 데이터 스키마, 링크드 데이터가 포함된다.

이 문서는 YAML-LD를 YAML 위의 일련의 규약으로 정의하며, JSON-LD 구문, 의미론, API를 기반으로 링크드 데이터를 YAML로 직렬화하는 방법을 지정한다.

YAML은 사용 가능한 데이터 타입과 문서 구조 모두에서 JSON보다 더 표현력이 높기 때문에 ([RFC9512] 참조), 이 문서는 모든 YAML-LD 문서가 JSON-LD로 표현될 수 있도록 YAML에 대한 제약을 식별한다.

목적
이 문서는 YAML 위에 구축된 일련의 규약인 YAML-LD를 정의하며, JSON-LD 구문, 의미론, API를 기반으로 링크드 데이터를 YAML로 직렬화하는 방법을 개괄한다. 링크드 데이터를 포함하여 이전에 JSON으로 직렬화되던 정보를 표현하기 위한 더 간결한 형식으로 YAML이 부상하면서 YAML-LD가 개발되었다.

방법
이 문서는 모든 YAML-LD 문서가 JSON-LD로 표현될 수 있도록 YAML에 대한 제약을 정의한다. 이는 YAML이 사용 가능한 데이터 타입과 문서 구조 양쪽 측면에서 JSON보다 더 표현력이 높기 때문에 필요하다. 이 문서는 또한 application/ld+yaml 미디어 타입을 등록한다.

결과
이 문서는 링크드 데이터를 YAML로 직렬화하는 방법에 대한 명확한 설명을 제공한다. 또한 JSON과 YAML의 비교, 지원되는 YAML 기능, 인코딩 고려사항을 포함하여 YAML-LD를 구현하기 위한 기본 개념과 핵심 요구사항도 설명한다.

한계
YAML 기능 집합은 JSON의 기능 집합보다 더 풍부하며, 이 명세에서는 여러 YAML 기능이 지원되지 않는다. 그러나 Extended YAML-LD Profile을 통해 이러한 기능을 지원할 YAML-LD 버전의 향후 개발을 위한 기반이 마련되어 있다.

결론
YAML-LD는 YAML을 사용할 수 있는 다양한 프로그래밍 언어에서 링크드 데이터를 인코딩하는 효율적인 방법을 제공한다.

YAML-LD 입문 예제가 아래에 제시되어 있다.

예제 1: 입문용 YAML-LD 문서

"@context":
  - https://json-ld.org/contexts/dollar-convenience.jsonld
  - schema: https://schema.org/
    dbo: http://dbpedia.org/ontology/
    dbp: http://dbpedia.org/property/
    dbr: http://dbpedia.org/resource/
    xsd: http://www.w3.org/2001/XMLSchema#
    dbp:discovered:
      "@type": xsd:date
    dbp:star:
      "@type": "@id"

$id: dbr:Proxima_Centauri_b
$type: dbo:Planet
schema:description: >-
  지구에서 가장 가까운 것으로 알려진 외계 행성으로,
  프록시마 센타우리의 생명체 거주 가능 영역을 공전한다.
dbp:discovered: 2016-08-24
dbp:star: dbr:Proxima_Centauri

편집자 주

이 명세에 대한 YAML-LD 설명은 spec.yamlld 를 참조한다.

이 절은 비규범적이다.

이 명세의 기본 사항을 이해하려면 다음에 익숙해야 한다.

[YAML] 데이터 마크업 언어. 이는 YAML-LD의 기반 구문이다
기본 링크드 데이터 [LINKED-DATA] 원칙

이 문서는 주로 아래에 설명된 두 주요 독자를 대상으로 한다.

소프트웨어 개발자 중 다음을 원하는 사람 —
- YAML을 사용할 수 있는 다양한 프로그래밍 언어에서 링크드 데이터를 인코딩하기
- 기존 YAML을 YAML-LD로 변환하기
- YAML-LD의 설계 결정과 언어 구문 이해하기
- YAML-LD용 처리기와 API 구현하기
- YAML 구문으로 링크드 데이터, RDF 그래프, 또는 RDF 데이터셋을 생성하거나 소비하기
관련 기술 중에서 JSON-LD에 대한 친숙함은 대부분의 YAML-LD 지원 애플리케이션을 구축하는 데 필요하지만, RDF에 대한 친숙함은 YAML-LD를 RDF 그래프로 변환하거나 그 반대로 변환하려는 경우에만 필요하다.
IT 분야 및 그 외 분야의 기타 전문가 중 YAML-LD 형식의 링크드 데이터 문서를 읽거나 작성하려는 사람. 이러한 문서는 —
- YAML-LD를 이해할 수 있는 프로그래밍 시스템에 의해 소비될 수 있다
- JSON-LD 프레이밍 알고리즘으로 변환될 수 있다
- 사람과 기계의 소비를 위해 웹에 게시될 수 있다
이러한 사용자에게 JSON-LD에 대한 친숙함은 필수는 아니지만, 링크드 데이터 원칙에 대한 이해는 도움이 될 수 있다.

이 절은 비규범적이다.

이 문서는 외부 명세에서 정의된 다음 용어를 사용하며 JSON-LD에 특화된 용어를 정의한다.

YAML-LD 스트림은 YAML 스트림 중 YAML-LD 문서들로 이루어진 것이다.

YAML-LD 문서는 [JSON]으로 변환했을 때 [LINKED-DATA]로 해석될 수 있는 유효한 JSON-LD 문서가 생성되는 모든 YAML 문서이다.

미디어 타입이라는 용어는 [RFC6838]에서 가져온 것이다.

JSON이라는 용어는 [JSON]에서 가져온 것이다.

JSON 문서라는 용어는 [JSON] 문법을 준수하는 리소스의 직렬화를 나타낸다.

JSON-LD 문서와 값 객체 용어는 [JSON-LD11]에서 가져온 것이다.

내부 표현과 documentLoader 용어는 [JSON-LD11-API]에서 가져온 것이다.

배열, 불리언, 맵, 맵 항목, null, 그리고 문자열 용어는 [INFRA]에서 가져온 것이다.

숫자 용어는 [ECMASCRIPT]에서 가져온 것이다.

YAML, YAML 표현 그래프, YAML 스트림, YAML 지시문, TAG 지시문, YAML 문서, YAML 시퀀스 ( 블록 시퀀스 또는 플로우 시퀀스), YAML 매핑 ( 블록 매핑 또는 플로우 매핑), 노드, 스칼라, 노드 앵커, 노드 태그, 그리고 별칭 노드 용어는 [YAML]에서 가져온 것이다.

콘텐츠 협상 용어는 [RFC9110]에서 가져온 것이다.

RDF 리터럴, 언어 태그가 붙은 문자열, 데이터타입 IRI, 그리고 언어 태그 용어는 [RDF11-CONCEPTS]에서 가져온 것이다.

이 문서에서 프래그먼트와 프래그먼트 식별자 용어는 [URI]에서의 의미로 해석해야 한다.

링크드 데이터 용어는 [LINKED-DATA]에서 가져온 것이다.

이 절은 비규범적이다.

이 명세는 다음 네임스페이스 접두사를 사용한다.

접두사	IRI
ex	https://example.org/
i18n	https://www.w3.org/ns/i18n#
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs	http://www.w3.org/2000/01/rdf-schema#
xsd	http://www.w3.org/2001/XMLSchema#
schema	https://schema.org/
prov	http://www.w3.org/ns/prov#

편집자 주

이 표의 YAML-LD 버전은 namespace-prefixes.yamlld 를 참조한다.

이들은 이 문서 안에서 축약 IRI의 일부로 사용되며, 결과 IRI에 대한 약어로 쓰인다. 예를 들어 schema:url은 https://schema.org/url을 나타내는 데 사용된다.

이 절은 비규범적이다.

YAML은 JSON의 상위 집합이다. 즉, 모든 유효한 JSON 문서는 유효한 YAML 문서이기도 하다. YAML은 또한 여러 추가 기능을 제공하며, 그중 대표적인 것은 최소한의 구두점을 사용할 수 있기 때문에 사람의 가독성이 향상된다는 점이다.

아래 비교 표에서 볼 수 있듯이 YAML은 JSON보다 더 유연하다.

기능	[JSON]	[YAML]	YAML-LD
허용되는 인코딩
UTF-8	✅	✅	✅
UTF-16	❌	✅	❌
UTF-32	❌	✅	❌
네이티브 데이터 타입
`{}` 객체	✅	✅	✅
`[]` 배열	✅	✅	✅
문자열	✅	✅	✅
숫자	✅	✅ 정수 부동 소수점	✅
bool	✅	✅	✅
null	✅	✅	✅
기능
구분 기호가 있는 문자열, 배열, 객체	✅	✅	✅
구두점 없는 문자열, 배열, 객체	❌	✅	✅
사용자 정의 타입	❌	태그를 통해 ✅	Core Schema만
파일당 문서 수	1	YAML 스트림을 통해 ⩾ 1	⩾ 1 (`extractAllScripts` 플래그에 따라 다름, 스트림 처리 참조)
주석	❌	✅	✅ 공백으로 취급됨
앵커와 별칭	❌	✅	✅ 앵커 이름은 의미 정보를 담지 않음
사이클	❌	✅	❌ 허용되지 않음
매핑 키 타입	`string`	문자열부터 매핑까지, YAML에서 표현 가능한 모든 타입	`string`

편집자 주

이 표의 YAML-LD 버전은 json-vs-yaml.yamlld 를 참조한다.

이 명세의 첫 번째 목표는 JSON-LD 문서가 처리되어 YAML로 직렬화되고, 이후 의미 정보의 손실 없이 다시 JSON-LD로 되돌아갈 수 있도록 하는 것이다.

이는 항상 가능하다. 그 이유는 다음과 같다.

YAML 표현 그래프는 항상 트리를 표현할 수 있다
JSON 데이터 타입 집합은 YAML 데이터 타입 집합의 부분집합이다
JSON 인코딩은 UTF-8이다.

예제 1의 JSON-LD 직렬화:

예제 2: 입문 예제와 동등한 JSON-LD

{
  "@context": [
    "https://json-ld.org/contexts/dollar-convenience.jsonld",
    {
      "schema": "https://schema.org/",
      "dbo": "http://dbpedia.org/ontology/",
      "dbp": "http://dbpedia.org/property/",
      "dbr": "http://dbpedia.org/resource/",
      "xsd": "http://www.w3.org/2001/XMLSchema#",
      "dbp:discovered": {
        "@type": "xsd:date"
      },
      "dbp:star": {
        "@type": "@id"
      }
    }
  ],
  "$id": "dbr:Proxima_Centauri_b",
  "$type": "dbo:Planet",
  "schema:description": "지구에서 가장 가까운 것으로 알려진 외계 행성으로, 프록시마 센타우리의 생명체 거주 가능 영역을 공전한다.",
  "dbp:discovered": "2016-08-24",
  "dbp:star": "dbr:Proxima_Centauri"
}

YAML-LD 문서는 [JSON]과의 상호운용성을 보장하기 위해 UTF-8로 인코딩되어야 MUST 한다. 그렇지 않으면 invalid-encoding이 감지되어야 MUST 하며, 처리는 중단되어야 한다.

YAML-LD 문서의 주석은 공백으로 취급된다.

자세한 내용은 "+yaml" 구조화 구문 접미사의 상호운용성 고려사항을 참조한다.

참고

이 명세에서 앵커는 직렬화된 그래프에서 동일한 논리 노드를 참조로 재사용하기 위한 YAML의 노드 앵커 메커니즘 (별칭 노드와 함께, 직렬화에서 &와 *를 사용)을 의미한다. 이는 HTML 하이퍼링크나 URL 프래그먼트 식별자와 관련이 없다. [YAML] §3.2.2.2 Anchors and Aliases 및 §6.9.2 Node Anchors를 참조한다.

앵커 이름은 직렬화 세부사항이므로, 이러한 앵커는 관련 정보를 전달하는 데 사용되어서는 MUST NOT 안 되며, 문서를 처리할 때 변경될 MAY 있고, YAML-LD 처리 중에 삭제될 MAY 있다.

YAML-LD 문서는 앵커가 지정된 노드와 별칭 노드를 포함할 MAY 있지만, 그 표현 그래프는 사이클을 포함해서는 MUST NOT 안 된다. 그렇지 않으면 loading-document-failed 오류가 감지되어야 MUST 하며, 처리는 중단되어야 한다.

문서를 JSON-LD로 해석할 때, 별칭 노드는 대상 노드에 대한 값으로 해석되어야 MUST 한다.

앵커는 특히 @context 블록 안에서 유용하다. 여러 용어가 동일한 용어 정의를 공유할 때 — 예를 들어 모든 IRI 값 속성 — 공유 정의를 한 번 앵커로 지정하고 각 용어에 별칭으로 재사용하여 반복을 피할 수 있다. 다음 예제는 IRI 강제 변환 정의를 &iri로 앵커 지정하고 세 속성에서 재사용한다.

예제 3: 앵커를 사용하는 YAML-LD 컨텍스트

"@context":
  dbo: http://dbpedia.org/ontology/
  dbp: http://dbpedia.org/property/
  dbr: http://dbpedia.org/resource/

  dbp:star:            &iri
    "@type": "@id"
  dbp:discoveryMethod: *iri
  dbp:discoverySite:   *iri

"@id": dbr:Proxima_Centauri_b
dbp:star:            dbr:Proxima_Centauri
dbp:discoveryMethod: dbr:Doppler_spectroscopy
dbp:discoverySite:   dbr:European_Southern_Observatory

모든 앵커와 별칭이 해석되면, 동등한 JSON-LD는 다음과 같다.

예제 4: 앵커가 있는 YAML-LD 컨텍스트에서 나온 JSON-LD

{
  "@context": {
    "dbo": "http://dbpedia.org/ontology/",
    "dbp": "http://dbpedia.org/property/",
    "dbr": "http://dbpedia.org/resource/",
    "dbp:star": {
      "@type": "@id"
    },
    "dbp:discoveryMethod": {
      "@type": "@id"
    },
    "dbp:discoverySite": {
      "@type": "@id"
    }
  },
  "@id": "dbr:Proxima_Centauri_b",
  "dbp:star": "dbr:Proxima_Centauri",
  "dbp:discoveryMethod": "dbr:Doppler_spectroscopy",
  "dbp:discoverySite": "dbr:European_Southern_Observatory"
}

참고: 앵커와 별칭은 YAML 직렬화의 기능이다

매핑 키 타입은 string이어야 MUST 한다. 그렇지 않으면 처리 오류가 발생한다.

YAML-LD는 스칼라 타입 해석에 YAML Core Schema를 사용한다. [JSON]으로 표현할 수 없는 부동소수점 값 — 구체적으로 무한대(.inf, -.inf, +.inf)와 숫자 아님(.nan) — 은 loading-document-failed 오류를 발생시켜야 MUST 한다.

YAML Core Schema는 타임스탬프 타입을 정의하지 않는다. 2018-04-01 같은 스칼라는 일반 문자열로 해석된다. 그러나 많은 YAML 라이브러리는 기본적으로 YAML 1.1 타임스탬프 해석을 구현하고 이러한 스칼라를 네이티브 date 또는 datetime 객체로 조용히 변환한다. YAML-LD 처리기는 이러한 변환을 수행해서는 MUST NOT 안 되며, 이러한 값을 문자열로 취급해야 MUST 한다.

YAML-LD는 노드 태그에 YAML Core Schema가 정의한 스칼라 타입 해석을 넘어서는 추가 JSON-LD 의미를 부여하지 않는다.

참고: Core Schema 타입 해석

다음 표는 YAML Core Schema와 YAML-LD 동작에 따른 스칼라 타입 해석을 요약한다.

패턴	해석된 태그	YAML-LD
`null \| Null \| NULL \| ~`	`tag:yaml.org,2002:null`	JSON `null`
(비어 있음)	`tag:yaml.org,2002:null`	JSON `null`
`true \| True \| TRUE \| false \| False \| FALSE`	`tag:yaml.org,2002:bool`	JSON `true` / `false`
`[-+]?[0-9]+`	`tag:yaml.org,2002:int` (10진수)	JSON number
`0o[0-7]+`	`tag:yaml.org,2002:int` (8진수)	JSON number
`0x[0-9a-fA-F]+`	`tag:yaml.org,2002:int` (16진수)	JSON number
`[-+]?(\.[0-9]+\|[0-9]+(\.[0-9]*)?)([eE][-+]?[0-9]+)?`	`tag:yaml.org,2002:float` (숫자)	JSON number
`[-+]?(\.inf\|\.Inf\|\.INF)`	`tag:yaml.org,2002:float` (무한대)	`loading-document-failed`를 발생시킴
`\.nan\|\.NaN\|\.NAN`	`tag:yaml.org,2002:float` (NaN)	`loading-document-failed`를 발생시킴
(그 밖의 모든 것)	`tag:yaml.org,2002:str`	JSON string

모든 YAML-LD 파일은 YAML-LD 스트림이며, 아래 예제에 표시된 것처럼 여러 YAML-LD 문서를 포함할 수 있다.

예제 5: 한 파일 안의 여러 문서가 있는 YAML-LD

"@context":
  dbo: http://dbpedia.org/ontology/
  dbr: http://dbpedia.org/resource/
"@id": dbr:Proxima_Centauri
"@type": dbo:Star
---
"@context":
  dbo: http://dbpedia.org/ontology/
  dbr: http://dbpedia.org/resource/
"@id": dbr:Proxima_Centauri_b
"@type": dbo:Planet

[JSON-LD11-API]는 extractAllScripts 플래그를 정의하며, 이 플래그는 HTML 문서에서 JSON-LD 콘텐츠가 있는 여러 <script> 태그를 파싱할 수 있게 한다.

적합한 YAML-LD 명세는 일반 YAML-LD 스트림을 파싱할 때도 이 플래그를 고려해야 MUST 한다.

플래그가 true이면, YAML 스트림은 배열로 간주되며, 스트림에 문서가 하나만 있더라도 그 안의 각 문서는 해당 배열의 항목이 된다;
플래그가 false이면, 스트림의 첫 번째 문서만 처리된다.

참고: YAML 스트림에 대한 상호운용성 고려사항

YAML 스트림에 대한 상호운용성 고려사항은 YAML Media Type의 관련 절을 참조하라.

이 절은 비규범적이다.

JSON-LD 1.1의 @json 키워드는 JSON 리터럴을 @type @json과 JSON 데이터를 포함하는 @value를 가진 값 객체로 정의한다. 처리기는 이러한 값을 JSON-LD로 더 해석하지 않고 JSON 리터럴로 취급한다. 다음 예제를 살펴보자.

예제 6: 프록시마 센타우리 b의 궤도 매개변수를 담은 JSON 리터럴

"@context":
  schema: https://schema.org/
  dbr: http://dbpedia.org/resource/

"@id": dbr:Proxima_Centauri_b
schema:additionalProperty:
  "@type": "@json"
  "@value":
    semiMajorAxis: 0.0485
    orbitalPeriod: 11.186
    equilibriumTemperature: 234
    eccentricity: 0.11

확장된 형식을 살펴보자.

예제 7: 프록시마 센타우리 b의 궤도 매개변수를 담은 확장된 JSON 리터럴

[
  {
    "@id": "http://dbpedia.org/resource/Proxima_Centauri_b",
    "https://schema.org/additionalProperty": [
      {
        "@type": "@json",
        "@value": {
          "semiMajorAxis": 0.0485,
          "orbitalPeriod": 11.186,
          "equilibriumTemperature": 234,
          "eccentricity": 0.11
        }
      }
    ]
  }
]

키워드 이름은 @json이지만, YAML-LD에서 @value의 값을 JSON 구문으로 작성해야 하는 것은 아니다. 이 예제가 보여주듯이, 메타데이터 값 객체는 확장 과정에서 JSON-LD 형식으로 보존된다. — 이 키워드가 요구하는 바와 같다.

RDF로 변환될 때, JSON 리터럴의 어휘 형식은 JSON 텍스트이며, 이는 내부 표현에서 재구성된다.

이 절은 IANA의 검토, 승인 및 등록을 위해 Internet Engineering Steering Group(IESG)에 제출되었다.

이 절은 [RFC6838]에 따라 위 미디어 타입을 등록하는 데 필요한 정보를 설명한다.

타입 이름:

application

서브타입 이름:

ld+yaml

필수 매개변수:

해당 없음

선택적 매개변수:

profile

[RFC6906]에 따라 YAML-LD 문서에 적용되는 특정 제약이나 규약을 식별하는, 공백으로 구분된 URI의 비어 있지 않은 목록. 프로파일은 프로파일 지식 없이 처리될 때 리소스 표현의 의미를 변경하지 않으므로, 프로파일된 리소스에 대한 지식이 있는 클라이언트와 없는 클라이언트 모두 동일한 표현을 안전하게 사용할 수 있다. profile 매개변수는 콘텐츠 협상 과정에서 클라이언트가 자신의 선호를 표현하는 데 사용될 MAY 있다. profile 매개변수가 제공된 경우, 서버는 자신이 인식하는 목록의 프로파일을 준수하는 문서를 반환해야 SHOULD 하며, 인식하지 못하는 목록의 프로파일은 무시해야 MUST 한다. profile URI는 역참조 가능하고 해당 URI에서 유용한 문서를 제공하는 것이 RECOMMENDED된다. 자세한 정보와 배경은 [RFC6906]을 참조한다.

이 명세는 에 나열된 profile 매개변수의 사용을 허용하며, 추가로 다음을 정의한다:

http://www.w3.org/ns/json-ld#extended: 확장 YAML-LD 문서 형식을 요청하거나 지정하기 위한 것.

편집자 주

이는 YAML 고유 기능을 사용하는 확장 YAML-LD 문서 형식 같은 것을 지정하기 위한 자리표시자이다.

[RFC4288]의 미디어 타입 매개변수로서, [RFC9110]의 HTTP Accept 헤더 필드에서 사용될 때, profile 매개변수의 값은 여러 profile URI가 결합될 때 필요한 공백과 같은 특수 문자를 포함하는 경우 따옴표(")로 둘러싸야 MUST 한다.

"profile" 미디어 타입 매개변수를 처리할 때는 그 값이 하나 이상의 IRI가 아니라 URI를 포함한다는 점에 유의하는 것이 중요하다. 따라서 경우에 따라 [RFC3987]의 3절 IRI와 URI의 관계에 명시된 대로 IRI와 URI 사이를 변환해야 할 수도 있다.

인코딩 고려사항:

+yaml과 동일.

보안 고려사항:

6. 보안 고려사항을 참조한다.

상호운용성 고려사항:

8. 상호운용성 고려사항을 참조한다.

공개된 명세:

http://www.w3.org/TR/yaml-ld

이 미디어 타입을 사용하는 애플리케이션:

방향 그래프의 교환이 필요한 모든 프로그래밍 환경.

추가 정보:

이 타입의 폐기된 별칭 이름:

해당 없음

매직 넘버:

application/yaml과 동일

파일 확장자:

.yaml
.yamlld

Macintosh 파일 타입 코드:

application/yaml과 동일

Windows 클립보드 이름:

application/yaml과 동일

추가 정보를 위한 담당자 및 이메일 주소:

W3C JSON-LD Working Group <public-json-ld-wg@w3.org>

의도된 사용:

일반

사용 제한:

해당 없음

저자:

Roberto Polli, Gregg Kellogg

변경 관리자:

W3C

[HTML]: HTML 표준. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. 생활 표준. URL: https://html.spec.whatwg.org/multipage/
[INFRA]: Infra 표준. Anne van Kesteren; Domenic Denicola. WHATWG. 현행 표준. URL: https://infra.spec.whatwg.org/
[JSON]: JavaScript Object Notation (JSON) 데이터 교환 형식. T. Bray, Ed. IETF. 2017년 12월. 인터넷 표준. URL: https://www.rfc-editor.org/info/rfc8259/
[JSON-LD11]: JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 2020년 7월 16일. W3C 권고안. URL: https://www.w3.org/TR/json-ld11/
[JSON-LD11-API]: JSON-LD 1.1 처리 알고리즘 및 API. Gregg Kellogg; Dave Longley; Pierre-Antoine Champin. W3C. 2020년 7월 16일. W3C 권고안. URL: https://www.w3.org/TR/json-ld11-api/
[JSON-LD11-FRAMING]: JSON-LD 1.1 Framing. Dave Longley; Gregg Kellogg; Pierre-Antoine Champin. W3C. 2020년 7월 16일. W3C 권고안. URL: https://www.w3.org/TR/json-ld11-framing/
[RFC2119]: RFC에서 요구 수준을 나타내기 위해 사용하는 핵심어. S. Bradner. IETF. 1997년 3월. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC3986]: Uniform Resource Identifier (URI): 일반 구문. T. Berners-Lee; R. Fielding; L. Masinter. IETF. 2005년 1월. 인터넷 표준. URL: https://www.rfc-editor.org/info/rfc3986/
[RFC3987]: 국제화된 리소스 식별자 (IRI). M. Duerst; M. Suignard. IETF. 2005년 1월. 제안 표준. URL: https://www.rfc-editor.org/info/rfc3987/
[RFC4288]: 미디어 타입 명세 및 등록 절차. N. Freed; J. Klensin. IETF. 2005년 12월. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc4288/
[RFC6838]: 미디어 타입 명세 및 등록 절차. N. Freed; J. Klensin; T. Hansen. IETF. 2013년 1월. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc6838/
[RFC6906]: 'profile' 링크 관계 타입. E. Wilde. IETF. 2013년 3월. 정보 제공. URL: https://www.rfc-editor.org/info/rfc6906/
[RFC8174]: RFC 2119 핵심어에서 대문자와 소문자의 모호성. B. Leiba. IETF. 2017년 5월. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc8174/
[RFC9110]: HTTP 의미론. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. IETF. 2022년 6월. 인터넷 표준. URL: https://httpwg.org/specs/rfc9110.html
[YAML]: YAML Ain't Markup Language (YAML™) version 1.2.2. Oren Ben-Kiki; Clark Evans; Ingy döt Net. YAML Language Development Team. 2021-10-01. URL: https://yaml.org/spec/1.2.2/
[yaml-ld-extended-profile]: YAML-LD Extended Profile. Gregg Kellogg; Pierre-Antoine Champin; Anatoly Scherbakov. W3C. W3C 초안 그룹 노트. URL: https://www.w3.org/TR/yaml-ld-extended-profile/

[ECMASCRIPT]: ECMAScript 언어 명세. Ecma International. URL: https://tc39.es/ecma262/multipage/
[LINKED-DATA]: 링크드 데이터 설계 이슈. Tim Berners-Lee. W3C. 2006년 7월 27일. W3C 내부 문서. URL: https://www.w3.org/DesignIssues/LinkedData.html
[RDF11-CONCEPTS]: RDF 1.1 개념 및 추상 구문. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 2014년 2월 25일. W3C 권고안. URL: https://www.w3.org/TR/rdf11-concepts/
[RFC8259]: JavaScript Object Notation (JSON) 데이터 교환 형식. T. Bray, Ed. IETF. 2017년 12월. 인터넷 표준. URL: https://www.rfc-editor.org/info/rfc8259/
[RFC9512]: YAML 미디어 타입. R. Polli; E. Wilde; E. Aro. IETF. 2024년 2월. 정보 제공. URL: https://www.rfc-editor.org/info/rfc9512/
[TURTLE]: RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 2014년 2월 25일. W3C 권고안. URL: https://www.w3.org/TR/turtle/
[URI]: Uniform Resource Identifier (URI): 일반 구문. T. Berners-Lee; R. Fielding; L. Masinter. IETF. 2005년 1월. 인터넷 표준. URL: https://www.rfc-editor.org/info/rfc3986/

[TURTLE] 및 주석을 지원하는 다른 링크드 데이터 직렬화

문서를 처리하고 다른 형식으로 직렬화할 때 이를 보존할 수단을 제공하지 않는다

YAML

문서에서 다음과 같이 표현 그래프에 반영되지 않는 부분은

주석
지시문
매핑 키 순서
앵커 이름

애플리케이션 수준 정보를 전달하는 데 사용해서는 안 된다고 요구한다.

이론적으로는 YAML 주석을 JSON-LD 문서로 수집해 볼 수도 있다. 예를 들어 https://json-ld.org/yaml-ld/comment 같은 특정 술어를 정의하고, 모든 # My comment 조각을 JSON-LD 문서의 {"yaml-ld:comment": "My comment"} 조각으로 변환할 수 있다.

그러나 이는 구현에 다음과 같은 영향을 미친다.

대부분의 산업적으로 사용 가능한 YAML 파서는 YAML 데이터를 읽을 때 주석을 버리기 때문에 구현이 더 복잡해진다
JSON에서는 키의 순서가 보존되지 않기 때문에 예측 가능성이 낮아진다. 따라서 JSON-LD 문서를 다시 YAML-LD로 변환할 때 주석이 다른 위치로 이동할 수 있다.

YAML-LD 1.0

초록

이 문서의 상태

1. 소개

1.1 이 문서를 읽는 방법

1.2 용어

1.3 네임스페이스 접두사

2. 적합성

2.1 기반 명세 버전

2.2 테스트 모음

3. 기본 개념

3.1 JSON과 YAML 비교

4. 핵심 요구사항

4.1 인코딩

4.2 주석

4.3 앵커와 별칭

4.4 매핑 키 타입

4.5 스칼라 값 타입

4.6 스트림

4.7 JSON 리터럴

5. YamlLdErrorCode

6. 보안 고려사항

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

8. 상호운용성 고려사항

9. HTML 문서에 YAML-LD 삽입하기

A. IANA 고려사항

A.1 application/ld+yaml

B. 왜 주석은 공백으로 취급되는가?

B.1 일관성

B.2 예측 가능성

C. 감사의 말

C.1 추모

C.2 기여

D. 참고문헌

D.1 규범 참고문헌

D.2 정보 참고문헌