JSON-LD 1.1 프레이밍

JSON-LD 구문을 위한 애플리케이션 프로그래밍 인터페이스의 확장

W3C 권고안

이 버전:
https://www.w3.org/TR/2020/REC-json-ld11-framing-20200716/
최신 발행 버전:
https://www.w3.org/TR/json-ld11-framing/
최신 편집자 초안:
https://w3c.github.io/json-ld-framing/
테스트 스위트:
https://w3c.github.io/json-ld-framing/tests/
구현 보고서:
https://w3c.github.io/json-ld-api/reports/
이전 버전:
https://www.w3.org/TR/2020/PR-json-ld11-framing-20200507/
편집자:
Dave Longley (Digital Bazaar) (v1.0 및 v1.1)
Gregg Kellogg (v1.0 및 v1.1)
Pierre-Antoine Champin (LIRIS - Université de Lyon) (v1.1)
이전 편집자:
Manu Sporny (Digital Bazaar) (v1.0)
Markus Lanthaler (Google) (v1.0)
저자:
Dave Longley (Digital Bazaar) (v1.0)
Manu Sporny (Digital Bazaar) (v1.0)
Gregg Kellogg (v1.0 및 v1.1)
Markus Lanthaler (Google) (v1.0)
Niklas Lindström (v1.0)
참여:
GitHub w3c/json-ld-framing
버그 보고
커밋 이력
풀 리퀘스트

발행 이후 보고된 오류나 문제는 정오표를 확인하십시오.

다음도 참조하십시오: 번역본.

이 문서는 다음 비규범 형식으로도 제공됩니다: EPUB

Copyright © 2010-2020 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.

초록

JSON-LD 프레이밍은 개발자가 예제로 쿼리하고 JSON-LD 문서에 특정 트리 레이아웃을 강제할 수 있게 합니다.

이 명세는 JSON-LD 프레이밍 1.0 [JSON-LD10-FRAMING]에 정의된 기능의 상위 집합을 설명하며, 별도로 명시된 경우를 제외하고, 이 명세에서 설명하는 알고리즘은 이전 커뮤니티 표준을 사용해 만든 문서와 완전히 호환됩니다.

이 문서의 상태

이 섹션은 발행 당시의 이 문서 상태를 설명합니다. 다른 문서가 이 문서를 대체할 수 있습니다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정판은 W3C 기술 보고서 색인에서 https://www.w3.org/TR/로 확인할 수 있습니다.

이 문서는 JSON-LD 워킹 그룹에서 개발했으며, JSON-LD 커뮤니티 그룹의 최종 보고서에서 파생되었습니다.

이 문서에 설명된 기능을 시연할 수 있는 라이브 JSON-LD 플레이그라운드가 있습니다.

이 문서는 JSON-LD 워킹 그룹에서 권고안으로 발행했습니다.

이 명세에 대한 논의에는 GitHub Issues 사용이 권장됩니다. 또는 메일링 리스트로 의견을 보낼 수도 있습니다. 다음 주소로 보내 주십시오. public-json-ld-wg@w3.org (아카이브).

워킹 그룹의 구현 보고서를 참조하십시오.

이 문서는 W3C 회원, 소프트웨어 개발자, 기타 W3C 그룹 및 관심 있는 당사자들의 검토를 받았으며, Director에 의해 W3C 권고안으로 승인되었습니다. 이 문서는 안정적인 문서이며 다른 문서에서 참고 자료로 사용하거나 인용할 수 있습니다. 권고안을 만드는 데 있어 W3C의 역할은 이 명세에 주의를 환기하고 폭넓은 배포를 촉진하는 것입니다. 이는 웹의 기능성과 상호운용성을 향상합니다.

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

이 문서는 2019년 3월 1일 W3C 프로세스 문서의 적용을 받습니다.

문서 세트

이 문서는 JSON-LD 워킹 그룹에서 작성한 세 개의 JSON-LD 1.1 권고안 중 하나입니다.

1. 소개

이 섹션은 비규범입니다.

JSON-LD는 JSON [RFC8259]에서 링크드 데이터 [LINKED-DATA]를 직렬화하기 위한 경량 구문입니다. 그 설계는 기존 JSON이 최소한의 변경만으로 링크드 데이터로 해석될 수 있게 합니다. 방향 그래프를 설명하는 링크드 데이터의 다른 표현과 마찬가지로, 하나의 방향 그래프는 여러 가지 서로 다른 직렬화를 가질 수 있으며, 각각은 정확히 같은 정보를 표현합니다. 개발자는 일반적으로 JSON 객체로 표현되는 트리를 다룹니다. 그래프를 트리에 매핑할 수는 있지만, 최종 결과의 레이아웃은 미리 지정해야 합니다. 개발자는 JSON-LD 문서에서 프레임을 사용해 그래프의 결정적 레이아웃을 지정할 수 있습니다.

데이터 덩어리 주위에 구분자를 사용하는 것은 "프레이밍"이라고 합니다. JSON-LD는 { 및 } 같은 JSON 구분자를 사용해 특정 주어에 대한 문장을 분리합니다. JSON-LD는 또한 주어가 문자열로 표현된 식별자를 사용해 다른 주어를 참조할 수 있게 합니다.

그러나 JSON-LD가 하나 이상의 정보 그래프를 표현한다는 점을 고려하면, 여러 관련 주어에 대한 문장을 하나의 전체 문서로 프레이밍하는 방법은 둘 이상입니다. 사실 정보 그래프는 어떤 방식으로도 함께 묶이지 않은 독립적인 문장(일명 트리플)의 긴 목록으로 생각할 수 있습니다.

JSON-LD 프레이밍 API는 개발자가 데이터를 정확히 어떤 방식으로 프레이밍할지 지정할 수 있게 하며, 이를 통해 특정 주어에 대한 문장들이 함께 묶이고, { 및 }로 구분되며, 관련된 주어들이 애플리케이션이 기대하는 특정 트리 구조로 "중첩"되도록 합니다.

1.1 이 문서를 읽는 방법

이 섹션은 비규범입니다.

이 문서는 JSON에서 링크드 데이터를 직렬화하는 방법에 대한 상세 명세입니다. 이 문서는 주로 다음 대상 독자를 위해 작성되었습니다:

동반 문서인 JSON-LD 1.1 명세 [JSON-LD11]는 JSON-LD 문서의 문법을 지정합니다.

이 명세의 기본 사항을 이해하려면 먼저 JSON에 익숙해야 하며, 이는 [RFC8259]에 자세히 설명되어 있습니다. 또한 이 문서의 모든 알고리즘에서 사용하는 기본 구문인 JSON-LD 1.1 구문 명세 [JSON-LD11]와 JSON-LD 1.1 API [JSON-LD11-API]도 이해해야 합니다. API와 그것이 프로그래밍 환경에서 어떻게 작동하도록 의도되었는지 이해하려면 JavaScript 프로그래밍 언어 [ECMASCRIPT]와 WebIDL [WEBIDL]에 대한 실무 지식이 있으면 유용합니다. JSON-LD가 RDF에 어떻게 매핑되는지 이해하려면 기본 RDF 개념 [RDF11-CONCEPTS]에 익숙한 것이 도움이 됩니다.

이 문서는 JSON-LD 1.0 버전 이후의 변경 사항을 강조 표시할 수 있습니다. 변경 사항을 선택하십시오.

1.2 기여하기

이 섹션은 비규범입니다.

이 명세의 개발에 참여할 수 있는 방법은 여러 가지가 있습니다:

1.3 표기 규칙

이 섹션은 비규범입니다.

이 명세에서는 다음 표기 규칙을 사용합니다:

markup
마크업(요소, 속성, 프로퍼티), 기계가 처리할 수 있는 값(문자열, 문자, 미디어 타입), 프로퍼티 이름, 또는 파일 이름은 붉은 주황색 고정폭 글꼴로 표시됩니다.
variable
의사 코드나 알고리즘 설명의 변수는 이탤릭체로 표시됩니다.
정의
이 명세나 다른 명세의 다른 곳에서 사용되는 용어의 정의는 굵은 이탤릭체로 표시됩니다.
정의 참조
이 문서 안의 정의에 대한 참조는 밑줄이 그어져 있으며 해당 정의 자체로 연결되는 활성 링크이기도 합니다.
마크업 정의 참조
이 문서 안의 정의에 대한 참조가 그 자체로 마크업이기도 한 경우, 밑줄이 그어지고 붉은 주황색 고정폭 글꼴로 표시되며 해당 정의 자체로 연결되는 활성 링크이기도 합니다.
외부 정의 참조
다른 문서의 정의에 대한 참조는 밑줄이 그어지고 이탤릭체로 표시되며, 해당 정의 자체로 연결되는 활성 링크이기도 합니다.
마크업 외부 정의 참조
다른 문서의 정의에 대한 참조가 그 자체로 마크업이기도 한 경우, 밑줄이 그어지고 이탤릭체 붉은 주황색 고정폭 글꼴로 표시되며, 해당 정의 자체로 연결되는 활성 링크이기도 합니다.
하이퍼링크
하이퍼링크는 밑줄이 그어지고 파란색으로 표시됩니다.
[참조]
문서 참조(규범 또는 정보)는 대괄호로 묶이며 참고 문헌 섹션으로 연결됩니다.
권고안에서의 변경 사항
이전 권고안에서 변경된 섹션이나 문구는 § 1.1 이 문서를 읽는 방법의 컨트롤을 사용해 강조 표시될 수 있습니다.
참고

참고는 연한 녹색 상자 안에 녹색 왼쪽 테두리와 함께 표시되며, 녹색의 "참고" 머리말을 가집니다. 참고는 항상 정보입니다.

예제 1 
예제는 연한 카키색 상자 안에 카키색 왼쪽 테두리와 함께 표시되며,
번호가 붙은 카키색 "예제" 머리말을 가집니다.
예제는 항상 정보입니다. 예제의 내용은 고정폭 글꼴로 표시되며 구문 색상이 적용될 수 있습니다.

예제에는 탭으로 된 탐색 버튼이 있을 수 있으며,
예제를 다른 표현으로 변환한 결과를 보여줄 수 있습니다.

1.4 용어

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

다른 명세에서 가져온 용어

ECMAScript 언어 명세 [ECMASCRIPT], JavaScript Object Notation (JSON) 데이터 교환 형식 [RFC8259], Infra 표준 [INFRA], 및 Web IDL [WEBIDL]에서 가져온 용어

배열
JSON 직렬화에서, 배열 구조는 0개 이상의 값을 둘러싸는 대괄호로 표현됩니다. 값은 쉼표로 구분됩니다. 내부 표현에서, 리스트(배열이라고도 함)는 0개 이상의 값으로 이루어진 순서가 있는 컬렉션입니다. JSON-LD는 JSON과 같은 배열 표현을 사용하지만, 컬렉션은 기본적으로 순서가 없습니다. 일반 JSON 배열에서는 순서가 보존되지만, 일반 JSON-LD 배열에서는 특별히 정의되지 않는 한 순서가 보존되지 않습니다 (JSON-LD 1.1의 집합과 리스트 섹션 참조.
불리언
두 가지 가능한 상태 중 하나를 표현하는 데 사용되는 true 및 false 값.
JSON 객체
JSON 직렬화에서, 객체 구조는 0개 이상의 이름/값 쌍(또는 멤버)을 둘러싸는 중괄호 쌍으로 표현됩니다. 이름은 문자열입니다. 각 이름 뒤에는 하나의 콜론이 오며, 이름과 값을 구분합니다. 하나의 쉼표는 값을 다음 이름과 구분합니다. JSON-LD에서 객체의 이름은 고유해야 합니다.

내부 표현에서 JSON 객체는 키/값 쌍을 가진 맵 ( [INFRA] 참조)으로 설명되며, 엔트리로 구성됩니다.

애플리케이션 프로그래밍 인터페이스에서, 맵은 [WEBIDL] record를 사용해 설명됩니다.

null
JSON-LD 내에서 null 값의 사용은 값을 무시하거나 재설정하는 데 사용됩니다. 값 또는 값의 @id가 null인 @context의 맵 엔트리는 용어와 IRI의 연결을 명시적으로 분리합니다. 값이 null인 맵 엔트리가 JSON-LD 문서 본문에 있으면, 그 맵 엔트리가 정의되지 않은 것과 같은 의미를 가집니다. 확장 형태에서 @value, @list, 또는 @set이 null로 설정되면, 전체 JSON 객체가 무시됩니다.
숫자
JSON 직렬화에서, 숫자는 대부분의 프로그래밍 언어에서 사용되는 것과 유사하지만, 8진수와 16진수 형식이 사용되지 않고 선행 0이 허용되지 않는다는 점이 다릅니다. 내부 표현에서, 숫자는 숫자에 0이 아닌 소수 부분이 있는지에 따라 long 또는 double과 동등합니다( [WEBIDL] 참조).
스칼라
스칼라는 문자열, 숫자, true, 또는 false 중 하나입니다.
문자열
문자열은 0개 이상의 Unicode(UTF-8) 문자로 이루어진 시퀀스이며, 큰따옴표로 둘러싸이고 (필요한 경우) 백슬래시 이스케이프를 사용합니다. 문자는 단일 문자 문자열로 표현됩니다.

국제화 리소스 식별자(IRI) [RFC3987]에서 가져온 용어

IRI
scheme과 path, 선택적 query 및 fragment 세그먼트를 포함하는 IRI의 절대 형식.
IRI 참조
국제화 리소스 식별자의 일반적인 사용을 나타냅니다. IRI 참조는 절대일 수도 있고 상대일 수도 있습니다. 그러나 그러한 참조에서 생성되는 "IRI"는 절대 IRI만 포함합니다; 모든 상대 IRI 참조는 절대 형식으로 해석됩니다.
상대 IRI 참조
상대 IRI 참조는 다른 어떤 IRI, 일반적으로 문서의 기준 IRI에 상대적인 IRI 참조입니다. 프로퍼티, @type의 값, 그리고 어휘 상대로 정의된 용어의 값은 어휘 매핑에 상대적으로 해석되며, 기준 IRI에 상대적으로 해석되지 않는다는 점에 유의하십시오.

RDF 1.1 개념과 추상 구문 [RDF11-CONCEPTS], RDF Schema 1.1 [RDF-SCHEMA], 및 링크드 데이터 설계 이슈 [LINKED-DATA]에서 가져온 용어

기준 IRI
기준 IRI는 컨텍스트에서 설정된 IRI이거나, JSON-LD 문서 위치를 기반으로 합니다. 기준 IRI는 상대 IRI 참조를 IRI로 바꾸는 데 사용됩니다.
빈 노드
그래프 안의 노드로, IRI도 아니고 리터럴도 아닙니다. 빈 노드는 역참조 가능한 식별자를 포함하지 않습니다. 이는 본질적으로 일시적이거나 링크드 데이터 그래프 바깥에서 링크할 필요가 있는 정보를 포함하지 않기 때문입니다. JSON-LD에서, 빈 노드에는 _: 접두사로 시작하는 식별자가 할당됩니다.
빈 노드 식별자
빈 노드 식별자는 JSON-LD 문서의 범위 안에서 빈 노드의 식별자로 사용할 수 있는 문자열입니다. 빈 노드 식별자는 _:로 시작합니다.
데이터셋
정확히 하나의 기본 그래프와 0개 이상의 명명된 그래프를 포함하는 RDF 그래프들의 컬렉션을 표현하는 데이터셋.
데이터타입 IRI
데이터타입 IRI는 어휘 형태가 리터럴 값에 어떻게 매핑되는지 결정하는 데이터타입을 식별하는 IRI입니다.
기본 그래프
데이터셋의 기본 그래프는 RDF 그래프이며, 이름이 없고 비어 있을 수 있습니다.
그래프 이름
명명된 그래프를 식별하는 IRI 또는 빈 노드.
언어 태그가 붙은 문자열
언어 태그가 붙은 문자열은 [BCP47]에서 정의한 문자열과 비어 있지 않은 언어 태그로 구성됩니다. 언어 태그는 [BCP47]의 섹션 2.2.9 적합성 클래스에 따라 올바른 형식이어야 합니다. 프로세서는 언어 태그를 소문자로 정규화할 수 있습니다.
링크드 데이터
각각 링크드 데이터 그래프 또는 데이터셋의 표현을 포함하는 문서 집합.
리스트
리스트는 IRI, 빈 노드, 및 리터럴의 순서가 있는 시퀀스입니다.
리터럴
문자열 또는 숫자 같은 값으로 표현되는 객체. 암시적으로 또는 명시적으로 데이터타입 IRI를 포함하며, 데이터타입이 rdf:langString인 경우 선택적 언어 태그를 포함합니다.
명명된 그래프
명명된 그래프는 IRI 또는 빈 노드로 식별되는 링크드 데이터 그래프입니다.
노드
RDF 그래프 안의 노드로, 적어도 하나의 트리플의 주어와 객체 중 하나입니다. 노드는 그래프 안에서 두 역할(주어와 객체)을 모두 할 수 있으며, 심지어 같은 트리플 안에서도 가능하다는 점에 유의하십시오.
객체
객체는 하나 이상의 들어오는 간선을 가진 노드이며, 링크드 데이터 그래프 안에 있습니다.
프로퍼티
링크드 데이터 그래프 안의 방향성 호의 이름입니다. 모든 프로퍼티는 방향성을 가지며, IRI 또는 빈 노드 식별자로 레이블이 붙습니다. 가능한 경우, 프로퍼티에는 IRI로 레이블을 붙여야 합니다.
참고
프로퍼티에 레이블을 붙이기 위해 빈 노드 식별자를 사용하는 것은 폐기되었으며, JSON-LD의 향후 버전에서 제거될 수 있습니다.
또한 [RDF11-CONCEPTS]의 predicate도 참조하십시오.
RDF 그래프
레이블이 붙은 방향성 그래프, 즉 방향성 호로 연결된 노드들의 집합입니다. 링크드 데이터 그래프라고도 합니다.
리소스
세계의 어떤 것("담화 세계")을 표현하는 IRI, 빈 노드 또는 리터럴로 표시되는 리소스.
주어
주어는 하나 이상의 나가는 간선을 가진 노드이며, 링크드 데이터 그래프 안에서 프로퍼티를 통해 객체 노드와 관련됩니다.
트리플
주어, predicate, 및 객체를 포함하는 RDF 그래프의 구성 요소이며, RDF 그래프의 노드-호-노드 세그먼트를 표현합니다.

JSON-LD 특화 용어 정의

활성 컨텍스트
처리 알고리즘이 실행되는 동안 용어를 해석하는 데 사용되는 컨텍스트.
기준 방향
기준 방향은 문자열에 직접 연결된 방향이 없을 때 사용되는 방향입니다. 이는 컨텍스트에서 @direction 키를 사용해 설정할 수 있으며, 그 값은 "ltr", "rtl", 또는 null 문자열 중 하나여야 합니다. 규범적 설명은 JSON-LD 1.1의 컨텍스트 정의 섹션을 참조하십시오.
컨텍스트
JSON-LD 1.1의 컨텍스트 섹션에 설명되어 있고, JSON-LD 1.1의 컨텍스트 정의 섹션에서 규범적으로 지정된 대로, JSON-LD 문서를 해석하기 위한 규칙 집합.
기본 객체
기본 객체는 @default 키를 가진 맵입니다.
프레임
매칭 및 임베딩 규칙을 사용해 다른 JSON-LD 문서를 변환하기 위한 형식을 설명하는 JSON-LD 문서. 프레임 문서는 매칭 및 변환 과정을 설명하기 위해 추가 키워드와 특정 맵 엔트리를 허용합니다.
프레임 객체
프레임 객체는 프레임 안의 맵 요소이며, 입력의 노드 객체 또는 값 객체와 매칭되는 프레임의 특정 부분을 표현합니다. 규범적 설명은 JSON-LD 1.1의 프레임 객체 섹션을 참조하십시오.
JSON-LD 문서
JSON-LD 문서는 RDF 데이터셋의 직렬화입니다. 형식적 설명은 JSON-LD 1.1의 JSON-LD 문법 섹션을 참조하십시오.
JSON-LD 내부 표현
JSON-LD 내부 표현은 JSON 구문 구조를 직접 처리에 적합한 핵심 데이터 구조로 변환한 결과입니다: 배열, 맵, 문자열, 숫자, 불리언, 및 null.
JSON-LD 프로세서
JSON-LD 프로세서는 JSON-LD 1.1 처리 알고리즘 및 API에 정의된 알고리즘을 수행할 수 있는 시스템입니다. 형식적 설명은 JSON-LD 1.1 API의 적합성 섹션을 참조하십시오.
JSON-LD 값
JSON-LD 값은 문자열, 숫자, true 또는 false, 타입이 지정된 값, 또는 언어 태그가 붙은 문자열입니다. 이는 RDF 리터럴을 표현합니다.
키워드
JSON-LD에 특화된 문자열로, JSON-LD 1.1의 구문 토큰 및 키워드 섹션에 설명되어 있고, JSON-LD 1.1의 키워드 섹션에서 규범적으로 지정됩니다,
노드 객체
노드 객체는 JSON-LD 문서에 의해 직렬화된 그래프 안의 노드의 0개 이상의 프로퍼티를 표현합니다. 맵은 JSON-LD 컨텍스트 바깥에 존재하고 다음 조건을 만족하면 노드 객체입니다:
  • @value, @list, 또는 @set 키워드를 포함하지 않거나,
  • JSON-LD 문서의 최상위 맵이 아니며, 이 최상위 맵이 @graph와 @context 외의 다른 엔트리로 구성되어 있지 않은 경우입니다.
키가 키워드가 아닌 노드 객체의 엔트리는 그 노드 객체의 프로퍼티라고도 합니다. 규범적 설명은 JSON-LD 1.1의 노드 객체 섹션을 참조하십시오.
노드 참조
@id 키만 가진 노드를 참조하는 데 사용되는 노드 객체.
처리 모드
처리 모드는 JSON-LD 문서가 처리되는 방식을 정의합니다. 기본적으로 모든 문서는 이 명세에 적합하다고 가정됩니다. 컨텍스트의 @version 엔트리를 사용해 다른 버전을 정의함으로써, 게시자는 JSON-LD 1.0 [JSON-LD10]에 적합한 프로세서가 JSON-LD 1.1 문서를 실수로 처리해 다른 출력을 만들지 않도록 할 수 있습니다. API는 처리 모드를 json-ld-1.0으로 설정하는 옵션을 제공하며, 이는 JSON-LD 1.1 기능이 활성화되는 것을 방지하거나, 컨텍스트의 @version 엔트리가 명시적으로 1.1로 설정된 경우 오류를 발생시킵니다. 이 명세는 json-ld-1.1 처리 모드를 통해 JSON-LD 1.0을 확장합니다.
범위 지정 컨텍스트
범위 지정 컨텍스트는 @context 엔트리를 사용하는 확장 용어 정의의 일부입니다. 이는 임베디드 컨텍스트와 같은 형식을 가집니다. 용어가 타입으로 사용될 때는 타입 범위 컨텍스트를 정의하고, 프로퍼티로 사용될 때는 프로퍼티 범위 컨텍스트를 정의합니다.
타입이 지정된 값
타입이 지정된 값은 값과 타입으로 구성되며, 값은 문자열이고, 타입은 IRI입니다.
값 객체
값 객체는 @value 엔트리를 가진 맵입니다. 규범적 설명은 JSON-LD 1.1의 값 객체 섹션을 참조하십시오.
어휘 매핑
어휘 매핑은 컨텍스트에서 @vocab 키를 사용해 설정되며, 그 값은 IRI, 축약 IRI, 용어, 또는 null이어야 합니다. 규범적 설명은 JSON-LD 1.1의 컨텍스트 정의 섹션을 참조하십시오.

1.4.1 알고리즘 용어

다음 용어는 특정 알고리즘 안에서 사용됩니다.

활성 프로퍼티
프로세서가 처리할 때 사용해야 하는 현재 활성 프로퍼티 또는 키워드. 활성 프로퍼티는 원래의 어휘 형식으로 표현되며, 이는 활성 컨텍스트에서 강제 변환 매핑을 찾는 데 사용됩니다.
명시적 포함 플래그
출력에 포함될 프로퍼티가 매칭되는 프레임 안에 명시적으로 선언되어야 함을 지정하는 플래그.
프레이밍 상태
객체 임베드 플래그, 모두 요구 플래그, 객체 임베딩이 적절한지 판단하는 데 내부적으로 사용되는 임베디드 플래그, 명시적 포함 플래그, 및 기본값 생략 플래그의 값을 포함하는 맵.
입력 프레임
프레이밍 알고리즘에 제공되는 초기 프레임.
IRI 축약
다양한 알고리즘 안에서 매크로로 사용되어, IRI 또는 키워드를 나타내는 문자열 var를 active context를 사용해 축약하는 과정을 설명하는 데 쓰이는 언어를 줄입니다. 이 active context는 직접 지정되었거나 이 용어를 사용하는 알고리즘 단계의 범위에서 온 것입니다. 선택적 value는 명시적으로 제공된 경우 사용됩니다. 별도로 지정되지 않으면, vocab 플래그의 기본값은 true이고, reverse 플래그의 기본값은 false입니다.
  1. IRI 축약 알고리즘을 사용한 결과를 반환합니다. 이때 active context, var, value (제공된 경우), vocab, 및 result를 전달합니다.
JSON-LD 입력
알고리즘에 입력으로 제공되는 JSON-LD 데이터 구조.
평탄화된 주어들의 맵
노드 맵 생성 알고리즘의 결과인 주어들의 맵.
객체 임베드 플래그
노드 객체가 해당 IRI로 참조되는 대신, 출력에 직접 임베드되어야 함을 지정하는 플래그.
기본값 생략 플래그
JSON-LD 입력에는 없지만 입력 프레임에는 있는 프로퍼티가 출력에서 생략되어야 함을 지정하는 플래그.
그래프 생략 플래그
프레이밍 출력이 항상 @graph 엔트리 안에 포함되는지, 또는 여러 노드 객체를 표현하는 데 필요한 경우에만 포함되는지를 결정하는 플래그.
모두 요구 플래그
프레임이 매칭되려면 입력 프레임에 있는 모든 프로퍼티가 기본값을 가지거나 JSON-LD 입력에 존재해야 함을 지정하는 플래그.

1.5 구문 토큰 및 키워드

이 명세는 JSON-LD 1.1 구문 명세 [JSON-LD11]에 정의된 키워드에 여러 키워드(프레이밍 키워드)를 추가합니다:

@default
프레이밍에서 프레이밍된 노드 객체가 해당 프로퍼티를 포함하지 않을 때, 출력 프로퍼티의 기본값을 설정하는 데 사용됩니다.
@embed
프레이밍에서 특정 프레임 안의 객체 임베드 플래그 값을 재정의하는 데 사용됩니다. @embed의 유효한 값은 다음과 같습니다:
@always
순환 참조가 발생하지 않는 한, 노드 객체를 항상 프로퍼티 값으로 임베드합니다.
@once
주어진 노드 객체 안의 단 하나의 값만 임베드되어야 하며, 다른 프로퍼티의 다른 값은 노드 참조를 사용합니다. 이는 @embed와 객체 임베드 플래그가 모두 지정되지 않은 경우의 기본값입니다.
참고
임베드하도록 선택되는 특정 노드 객체는 순서에 따라 달라집니다. ordered 플래그가 true이면, 처음 마주치는 노드 객체가 되며, 그렇지 않으면 임의의 노드 객체일 수 있습니다.
@never
매칭되는 값을 직렬화할 때 항상 노드 참조를 사용합니다.

@embed의 다른 모든 값은 유효하지 않으며, invalid @embed value 오류가 감지되었고 처리가 중단됨을 나타냅니다.

@explicit
프레이밍에서 특정 프레임 안의 명시적 포함 플래그 값을 재정의하는 데 사용됩니다.
@null
프레이밍에서 null 값이 반환되어야 할 때 사용되며, 그렇지 않으면 축약 시 제거됩니다.
@omitDefault
프레이밍에서 특정 프레임 안의 기본값 생략 플래그 값을 재정의하는 데 사용됩니다.
@requireAll
프레이밍에서 특정 프레임 안의 모두 요구 플래그 값을 재정의하는 데 사용됩니다.

모든 JSON-LD 토큰과 키워드는 대소문자를 구분합니다.

2. 기능

이 섹션은 비규범입니다.

JSON-LD 1.1은 JSON-LD 1.0 [JSON-LD10]과 호환되는 새 기능을 도입하지만, JSON-LD 1.0 프로세서로 처리할 경우 다른 결과를 생성할 수 있습니다. 프로세서는 processingMode API 옵션이 명시적으로 json-ld-1.0으로 설정되지 않는 한, 기본적으로 json-ld-1.1을 사용합니다. 게시자는 JSON-LD 1.0 프로세서가 JSON-LD 1.1 기능을 잘못 해석하지 않도록 하기 위해 맵 엔트리 @version을 컨텍스트 안에서 1.1로 설정해 사용하는 것이 권장됩니다.

2.1 프레이밍

이 섹션은 비규범입니다.

프레이밍은 JSON-LD 문서의 데이터를 형성하는 데 사용되며, 예시 프레임 문서를 사용합니다. 이 문서는 평탄화된 데이터와 매칭하는 데 사용되고, 결과 데이터가 어떤 형태여야 하는지에 대한 예시를 보여주는 데도 사용됩니다. 매칭은 프레임에 있는 프로퍼티를 사용해 공통 값을 공유하는 데이터 안의 객체를 찾는 방식으로 수행됩니다. 매칭은 프레임에 있는 모든 프로퍼티를 사용하거나, 프레임의 임의 프로퍼티를 사용해 수행할 수 있습니다. 매칭된 프로퍼티 값을 사용해 객체를 연결함으로써 객체를 서로의 내부에 임베드할 수 있습니다.

프레임은 또한 컨텍스트를 포함하며, 이는 결과로 나온 프레이밍된 출력을 축약하는 데 사용됩니다.

예를 들어, 다음 JSON-LD 프레임을 가정합니다:

예제 2: 샘플 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "@type": "Library",
  "contains": {
    "@type": "Book",
    "contains": {
      "@type": "Chapter"
    }
  }
}

이 프레임 문서는 Library 타입의 객체를 최상위에 배치하고, contains 프로퍼티를 사용해 라이브러리 객체에 연결된 Book 타입의 객체를 프로퍼티 값으로 임베드하는 임베딩 구조를 설명합니다. 또한 Chapter 타입의 객체를 참조하는 Book 객체 안에 Book 객체의 임베드된 값으로 배치합니다.

프레임 구성 요소와 매칭되는 평탄화된 객체 집합을 사용할 때:

예제 3: 평탄화된 라이브러리 객체 
{
  "@context": {
    "@vocab": "http://example.org/",
    "contains": {"@type": "@id"}
  },
  "@graph": [{
    "@id": "http://example.org/library",
    "@type": "Library",
    "location": "Athens",
    "contains": "http://example.org/library/the-republic"
  }, {
    "@id": "http://example.org/library/the-republic",
    "@type": "Book",
    "creator": "Plato",
    "title": "The Republic",
    "contains": "http://example.org/library/the-republic#introduction"
  }, {
    "@id": "http://example.org/library/the-republic#introduction",
    "@type": "Chapter",
    "description": "An introductory chapter on The Republic.",
    "title": "The Introduction"
  }]
}

프레임 알고리즘은 프레임의 구조를 따르는 새 문서를 만들 수 있습니다:

처리 모드가 json-ld-1.0이 아니거나, 그래프 생략 플래그가 true이면, 최상위 @graph 엔트리를 생략할 수 있습니다.

예제 5: 프레이밍된 라이브러리 객체 
{
  "@context": {"@vocab": "http://example.org/"},
  "@id": "http://example.org/library",
  "@type": "Library",
  "location": "Athens",
  "contains": {
    "@id": "http://example.org/library/the-republic",
    "@type": "Book",
    "creator": "Plato",
    "title": "The Republic",
    "contains": {
      "@id": "http://example.org/library/the-republic#introduction",
      "@type": "Chapter",
      "description": "An introductory chapter on The Republic.",
      "title": "The Introduction"
    }
  }
}

프레이밍 알고리즘은 먼저 입력 프레임과 문서를 모두 확장함으로써 이를 수행합니다. 그런 다음 평탄화된 주어들의 맵을 만듭니다. 프레임 안의 가장 바깥쪽 노드 객체는 맵 안의 객체와 매칭하는 데 사용되며, 이 경우 @type이 Library이고, 해당 프로퍼티의 값을 매칭하는 데 사용되는 또 다른 프레임을 가진 contains 프로퍼티가 있는 노드 객체를 찾습니다. 입력 문서는 그러한 노드 객체를 정확히 하나 포함합니다. contains의 값도 노드 객체를 가지며, 이는 다시 Library 객체의 contains 값인 주어들의 집합과 매칭하는 프레임으로 취급되는 식입니다.

2.1.1 프로퍼티 기준 매칭

이 섹션은 비규범입니다.

타입 기준 매칭에 더해, 프레임은 하나 이상의 프로퍼티를 기준으로 매칭할 수 있습니다.

예를 들어, 다음 프레임은 @type이 아니라 프로퍼티 값을 기준으로 객체를 선택합니다.

예제 6: 프로퍼티 매칭을 사용하는 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "location": "Athens",
  "contains": {
    "title": "The Republic",
    "contains": {
      "title": "The Introduction"
    }
  }
}

프로퍼티 값이 각 노드 객체에 고유하므로, 이는 @type을 기준으로 선택할 때와 같은 프레이밍 결과를 생성합니다.

매칭을 그러한 나열된 프로퍼티 중 전부가 아니라 모두 포함하는 노드 객체와 매칭하도록 어떻게 제한할 수 있는지는 § 2.3.5 모두 요구 플래그를 참조하십시오.

2.1.2 와일드카드 매칭

이 섹션은 비규범입니다.

빈 맵 ({})은 와일드카드로 사용되며, 대상 노드 객체에 프로퍼티가 존재하면 특정 값과 관계없이 매칭합니다.

예를 들어, 다음 프레임은 @type이 아니라 프로퍼티 와일드카딩을 기준으로 객체를 선택합니다.

예제 8: 와일드카드 매칭을 사용하는 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "location": {},
  "contains": {
    "creator": {},
    "contains": {
      "description": {}
    }
  }
}

매칭된 프로퍼티가 각 노드 객체에 구별되므로, 이는 @type을 기준으로 선택할 때와 같은 프레이밍 결과를 생성합니다.

2.1.3 프로퍼티 부재 기준 매칭

이 섹션은 비규범입니다.

빈 배열 ([])은 match none에 사용되며, 대상 노드 객체에 프로퍼티가 존재하지 않는 경우에만 노드 객체와 매칭합니다.

예를 들어, 다음 프레임은 @type이 아니라 프로퍼티의 부재를 기준으로 객체를 선택합니다.

예제 10: 부재 매칭을 사용하는 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "creator": [],
  "title": [],
  "contains": {
    "location": [],
    "description": [],
    "contains": {
      "location": []
    }
  }
}

제외된 프로퍼티가 각 노드 객체를 고유하게 식별하므로, 이는 @type을 기준으로 선택할 때와 같은 프레이밍 결과를 생성합니다. 명시적으로 제외된 프로퍼티에는 null 값을 가진 추가 프로퍼티가 추가된다는 점에 유의하십시오.

2.1.4 값 기준 매칭

이 섹션은 비규범입니다.

프레임은 특정 프로퍼티 값의 존재를 기준으로 매칭될 수 있습니다. 이 값 자체는 와일드카드를 사용할 수 있으며, 이를 통해 특정 값이나 값 집합, 언어 태그, 타입, 또는 기준 방향을 기준으로 매칭할 수 있습니다.

예시로, 더 복잡한 값 표현을 가진 다국어 버전의 라이브러리 예제를 사용하겠습니다.

예제 12: 다국어 라이브러리 객체 
{
  "@context": {
    "@vocab": "http://example.org/",
    "contains": {"@type": "@id"}
  },
  "@graph": [{
    "@id": "http://example.org/library",
    "@type": "Library",
    "location": [
      {"@value": "Athens", "@language": "en"},
      {"@value": "Αθήνα", "@language": "grc"},
      {"@value": "Athína", "@language": "el-Latn"}
    ],
    "contains": "http://example.org/library/the-republic"
  }, {
    "@id": "http://example.org/library/the-republic",
    "@type": "Book",
    "creator": [
      {"@value": "Plato", "@language": "en"},
      {"@value": "Πλάτων", "@language": "grc"},
      {"@value": "Plátōn", "@language": "el-Latn"}
    ],
    "title": [
      {"@value": "The Republic", "@language": "en"},
      {"@value": "Πολιτεία", "@language": "grc"},
      {"@value": "Res Publica", "@language": "el-Latn"}
    ],
    "contains": "http://example.org/library/the-republic#introduction"
  }, {
    "@id": "http://example.org/library/the-republic#introduction",
    "@type": "Chapter",
    "description": "An introductory chapter on The Republic.",
    "title": "The Introduction"
  }]
}

값의 속성을 기준으로 매칭함으로써, 그 속성을 가진 프레임과 매칭하고 결과를 매칭되는 프로퍼티 값으로 제한할 수 있습니다. 이 경우, 라틴 문자로 표기된 그리스어(el-Latn) 값만 기준으로 Library와 Book 객체를 프레이밍합니다:

예제 13: 언어 매칭을 사용하는 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "location": {"@value": {}, "@language": "el-Latn"},
  "contains": {
    "creator": {"@value": {}, "@language": "el-Latn"},
    "title": {"@value": {}, "@language": "el-Latn"},
    "contains": {
      "title": "The Introduction"
    }
  }
}

이는 다음과 같은 프레이밍 결과를 생성합니다:

2.1.5 @id 기준 매칭

이 섹션은 비규범입니다.

프레임은 특정 식별자(@id)와 매칭될 때 매칭될 수 있습니다. 이는 특정 @id 값에 대해 매칭하는 프레임을 사용해 원래의 평탄화된 라이브러리 객체 입력으로 설명할 수 있습니다:

예제 15: @id 매칭을 사용하는 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "@id": "http://example.org/library",
  "contains": {
    "@id": "http://example.org/library/the-republic",
    "contains": {
      "@id": "http://example.org/library/the-republic#introduction"
    }
  }
}

이는 다음과 같은 프레이밍 결과를 생성합니다:

프레임은 식별자 배열로부터도 매칭될 수 있습니다. 프레임 안에서 @id가 배열 값을 갖는 것은 허용되며, 이때 개별 값은 IRI로 취급됩니다.

예제 17: 배열 @id 매칭을 사용하는 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "@id": ["http://example.org/home", "http://example.org/library"],
  "contains": {
    "@id": ["http://example.org/library/the-republic"],
    "contains": {
      "@id": ["http://example.org/library/the-republic#introduction"]
    }
  }
}

이는 다음과 같은 프레이밍 결과를 생성합니다:

2.1.6 빈 프레임

이 섹션은 비규범입니다.

빈 프레임은 모든 노드 객체와 매칭하며, 해당 객체가 다른 곳에 임베드되어 있더라도 최상위 수준에서 직렬화되도록 합니다.

예제 19: 빈 프레임 
{
  "@context": {"@vocab": "http://example.org/"}
}

이는 다음과 같은 프레이밍 결과를 생성합니다:

2.2 기본 콘텐츠

이 섹션은 비규범입니다.

프레임은 입력 파일에 존재하지 않는 프로퍼티를 지정할 수 있습니다. 명시적 포함 플래그가 false이면, 프레이밍 알고리즘은 결과에 프로퍼티와 값을 추가합니다. 노드 객체 또는 값 객체 안의 @default 프로퍼티, 또는 @type의 값으로서의 @default는 결과 출력 문서에서 사용할 기본값을 제공합니다. @default 값이 없으면, 해당 프로퍼티는 null 값으로 출력됩니다. (이를 피하는 방법은 § 2.3.3 기본값 생략 플래그를 참조하십시오).

참고

프레임 안의 프로퍼티 값은 그 외에는 출력 문서에서 사용되지 않습니다. 그 목적은 프레임 매칭과 기본값 찾기입니다. 다음 예제에서 Library의 description 값에 유의하십시오.

예제 21: @default 값을 가진 샘플 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "@type": "Library",
  "description": "A great Library.",
  "contains": {
    "@type": "Book",
    "description": {"@default": "A great book."},
    "contains": {
      "@type": "Chapter"
    }
  }
}

기본값은 다른 프로퍼티와 유사하게 @type에도 사용할 수 있습니다. 이 경우, @type이 없는 매칭된 노드 객체는 프레임의 기본 객체 값을 취합니다. 기본 객체는 단일 IRI인 값을 가집니다. 여러 IRI가 지정된 경우, 첫 번째 것만 기본 타입으로 사용됩니다.

프레임은 특정 프로퍼티 값을 가진 객체와 매칭하며, 매칭된 객체에 대한 @type 기본값을 제공합니다.

예제 23: @default 타입을 가진 샘플 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "@type": "Library",
  "contains": {
    "@type": {"@default": "Book"},
    "creator": "Plato",
    "contains": {
      "@type": {"@default": "Chapter"},
      "description": "An introductory chapter on The Republic."
    }
  }
}

@type에 대한 특정 값은 없지만 다른 프로퍼티 값을 기준으로 매칭되는 데이터입니다.

예제 24: 타입 없는 라이브러리 객체 
{
  "@context": {
    "@vocab": "http://example.org/",
    "contains": {"@type": "@id"}
  },
  "@graph": [{
    "@id": "http://example.org/library",
    "@type": "Library",
    "contains": "http://example.org/library/the-republic"
  }, {
    "@id": "http://example.org/library/the-republic",
    "creator": "Plato",
    "title": "The Republic",
    "contains": "http://example.org/library/the-republic#introduction"
  }, {
    "@id": "http://example.org/library/the-republic#introduction",
    "description": "An introductory chapter on The Republic.",
    "title": "The Introduction"
  }]
}

2.3 프레이밍 플래그

이 섹션은 비규범입니다.

프레이밍은 API 옵션을 사용하거나, § 1.5 구문 토큰 및 키워드에 설명된 대로 프레임 안에 프레이밍 키워드를 추가하여 제어할 수 있습니다.

참고

키워드를 사용해 설정된 프레이밍 플래그는 그것이 나타나는 프레임과, 프레임 객체가 없는 객체에 대해 생성되는 암시적 프레임에만 영향을 줍니다.

2.3.1 객체 임베드 플래그

이 섹션은 비규범입니다.

객체 임베드 플래그는 참조된 노드 객체가 참조하는 객체의 프로퍼티 값으로 임베드될지, 아니면 노드 참조로 유지될지를 결정합니다. 객체 임베드 플래그의 초기값은 embed 옵션을 사용해 설정됩니다. 객체 임베드 플래그의 기본 @once 값을 기준으로 한 다음 프레임을 고려하십시오:

예제 26: 암시적 @embed가 @once로 설정된 샘플 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "@type": "Library"
}

객체 임베드 플래그의 기본값이 @once이고 (명시적 포함 플래그가 false인 것에 더해), 나열되지 않은 프로퍼티가 출력에 추가되고 기본 빈 프레임을 사용해 암시적으로 임베드됩니다. 그 결과, ordered 플래그가 true라고 가정하면, 위의 프레이밍된 라이브러리 객체에서 사용한 것과 같은 출력이 생성됩니다.

그러나 @embed 프로퍼티가 @never 값으로 명시적으로 추가되면, Book과 Chapter의 값은 제외됩니다.

예제 28: 명시적 @embed가 @never로 설정된 샘플 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "@type": "Library",
  "contains": {
    "@type": "Book",
    "@embed": "@never"
  }
}

@once가 값을 확장하지 않는 경우를 설명하기 위해, 책이 이중으로 인덱싱된 대체 라이브러리 예제를 고려하십시오.

예제 30: 이중 인덱스를 가진 평탄화된 라이브러리 객체 
{
  "@context": {
    "@vocab": "http://example.org/",
    "books": {"@type": "@id"},
    "contains": {"@type": "@id"}
  },
  "@graph": [{
    "@id": "http://example.org/library",
    "@type": "Library",
    "books": "http://example.org/library/the-republic",
    "contains": "http://example.org/library/the-republic"
  }, {
    "@id": "http://example.org/library/the-republic",
    "@type": "Book",
    "creator": "Plato",
    "title": "The Republic",
    "contains": "http://example.org/library/the-republic#introduction"
  }, {
    "@id": "http://example.org/library/the-republic#introduction",
    "@type": "Chapter",
    "description": "An introductory chapter on The Republic.",
    "title": "The Introduction"
  }]
}

@embed의 기본값이 @once인 같은 프레임으로 프레이밍하면, ordered 플래그가 true인 경우 "books" 프로퍼티만 콘텐츠를 가지며, "contains" 프로퍼티는 참조를 사용합니다.

"@embed": "@always"를 사용하는 프레임을 사용하면, 두 프로퍼티 모두 확장된 값을 포함합니다.

예제 32: 명시적 @embed가 @always로 설정된 샘플 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "@type": "Library",
  "@embed": "@always"
}

2.3.2 명시적 포함 플래그

이 섹션은 비규범입니다.

명시적 포함 플래그는 출력 문서에 포함될 프로퍼티를 결정하는 데 사용됩니다. 기본값은 false이며, 이는 입력 노드 객체에 존재하지만 연결된 프레임에는 없는 프로퍼티가 출력 객체에 포함된다는 뜻입니다. true이면, 입력 프레임에 있는 프로퍼티만 출력에 배치됩니다. 명시적 포함 플래그의 초기값은 explicit 옵션을 사용해 설정됩니다.

예를 들어, 입력의 일부 프로퍼티는 포함하지만 다른 프로퍼티는 생략하는 라이브러리 프레임의 확장 버전을 살펴보겠습니다.

예제 34: @explicit이 true로 설정된 샘플 라이브러리 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "@type": "Library",
  "description": {},
  "contains": {
    "@type": "Book",
    "@explicit": true,
    "title": {},
    "contains": {
      "@type": "Chapter"
    }
  }
}

결과 출력은 프레임 객체에 명시적으로 나열되지 않은 Book의 프로퍼티를 제외합니다:

Library 객체는 "description": {}를 사용해 프레임에서 명시적으로 요구되었으므로, null인 description 프로퍼티를 포함합니다. creator 프로퍼티는 명시적이지 않기 때문에 출력에 존재하지 않습니다.

2.3.3 기본값 생략 플래그

이 섹션은 비규범입니다.

기본값 생략 플래그는 프레임에 설명된 프로퍼티가 입력 문서에 없을 때 프레이밍이 출력을 생성하는 방식을 변경합니다. 기본값 생략 플래그의 초기값은 omitDefault 옵션을 사용해 설정됩니다. 자세한 논의는 § 2.2 기본 콘텐츠를 참조하십시오.

다음 입력 문서를 고려하십시오:

예제 36: 샘플 부모/자식 관계 데이터 
{
  "@context": {
    "@vocab": "http://example.org/",
    "child": {"@type": "@id"}
  },
  "@graph": [{
    "@id": "http://example.org#John",
    "@type": "Person",
    "name": "John",
    "child": "http://example.org#Jane"
  }, {
    "@id": "http://example.org#Jane",
    "@type": "Person",
    "name": "Jane"
  }]
}

기본값 생략 플래그가 유용한 곳을 설명하기 위해, @omitDefault를 사용하지 않는 다음 프레임을 고려하십시오:

예제 37: @omitDefault 없는 샘플 부모/자식 관계 프레임 
{
  "@context": {
    "@vocab": "http://example.org/",
    "child": {"@type": "@id"}
  },
  "@type": "Person",
  "child": {
    "@embed": "@always"
  }
}

결과 출력은 null 값을 가진 "child" 프로퍼티를 포함하며, 이는 항상 원하는 것은 아닐 수 있습니다:

프레임에서 child 프로퍼티 아래에 "@embed": "@always" 옵션이 지정되어 있기 때문에, 해당 프로퍼티가 없는 매칭에 대해 "child": null이 출력에 나타난다는 점에 유의하십시오. 이는 바람직하지 않을 수 있습니다. 이 기본 null 출력이 발생하지 않도록 하려면, 다음과 같이 @omitDefault를 true로 설정할 수 있습니다:

예제 39: @omitDefault를 사용하는 샘플 부모/자식 관계 프레임 
{
  "@context": {
    "@vocab": "http://example.org/",
    "child": {"@type": "@id"}
  },
  "@type": "Person",
  "child": {
    "@embed": "@always",
    "@omitDefault": true
  }
}

이는 다음과 같은 (바람직한) 출력을 생성합니다:

2.3.4 그래프 생략 플래그

이 섹션은 비규범입니다.

그래프 생략 플래그는 단일 노드 객체를 포함하는 프레이밍된 출력이 @graph 안에 포함될지 여부를 결정합니다. 그래프 생략 플래그의 초기값은 omitGraph 옵션을 사용하거나 처리 모드를 기반으로 설정됩니다. 처리 모드가 json-ld-1.0이면 출력은 항상 @graph 엔트리를 포함하며, 그렇지 않으면 @graph 엔트리는 축약과 일관되게 여러 노드 객체를 설명하는 데만 사용됩니다. 자세한 논의는 § 4.1 프레이밍 알고리즘을 참조하십시오.

결과는 원래의 평탄화된 라이브러리 객체 예제와 같지만, 최상위에 @graph가 있습니다. 예제 5는 그래프 생략 플래그가 true로 설정된 결과를 보여주며, 이는 처리 모드가 기본 json-ld-1.1로 설정되어 있을 때의 기본값입니다. 처리 모드를 json-ld-1.0으로 설정하거나, 그래프 생략 플래그를 false로 설정하여 최상위 객체를 @graph 안에 둘 수 있습니다.

2.3.5 모두 요구 플래그

이 섹션은 비규범입니다.

모두 요구 플래그는 프레임 매칭에서 입력 문서의 노드 객체가 프레임과 언제 매칭되는지 결정하는 데 사용됩니다. 매칭할 때 객체는 @type 및 다른 프로퍼티를 포함할 수 있으며, 모두 요구 플래그의 값이 false(기본값)인 경우, 객체 안의 어떤 프로퍼티 값이라도 프레임 객체 안의 노드 패턴과 매칭되면 매칭이 이루어집니다. 플래그 값이 true이면, 노드가 매칭되기 위해 프레임 객체 안의 모든 프로퍼티가 노드 객체에 존재해야 합니다.

다음 프레임은 프로퍼티의 부재를 포함하여 여러 프로퍼티를 기준으로 매칭합니다. 평탄화된 라이브러리 객체 예제를 사용하면, title과 description 또는 title과 creator 프로퍼티를 모두 포함하는 객체를 기준으로 매칭할 수 있습니다. @requireAll을 false로 설정하면, 모든 프로퍼티가 아니라 임의의 프로퍼티 존재를 기준으로 매칭할 수 있습니다.

예제 42: @requireAll을 사용하는 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "@type": "Library",
  "contains": {
    "@requireAll": true,
    "creator": {},
    "title": {},
    "contains": {
      "@requireAll": true,
      "description": {},
      "title": {}
    }
  }
}

이는 다시 원하는 프레이밍 출력을 재현합니다:

2.4 역방향 프레이밍

이 섹션은 비규범입니다.

프레임은 출력 객체 안의 관계를 반전하기 위해 @reverse 또는 @reverse를 사용해 정의된 용어의 값을 포함할 수 있습니다. 예를 들어, Library 예제는 다음 프레임을 사용해 반전할 수 있습니다:

예제 44: 반전된 라이브러리 프레임 
{
  "@context": {
    "@vocab": "http://example.org/",
    "within": {"@reverse": "contains"}
  },
  "@type": "Chapter",
  "within": {
    "@type": "Book",
    "within": {
      "@type": "Library"
    }
  }
}

위의 평탄화된 라이브러리 예제를 사용하면 다음과 같은 결과가 나옵니다:

참고

일반 프로퍼티와 역방향 프로퍼티 사이에는 비대칭성이 있습니다. 일반적으로 노드 객체를 프레이밍할 때, 명시적 포함 플래그가 설정되어 있지 않으면 노드의 모든 프로퍼티가 출력에 포함되지만, 역방향 프로퍼티는 실제로 노드의 프로퍼티가 아니므로 포함되지 않습니다.

출력에 역방향 프로퍼티를 포함하려면, 프레임에 명시적으로 추가하십시오. 역방향 관계가 존재하지 않으면, 단순히 출력에서 빠진다는 점에 유의하십시오.

2.5 명명된 그래프 프레이밍

이 섹션은 비규범입니다.

프레임은 @graph를 포함할 수 있으며, 이를 통해 명명된 그래프의 정보가 JSON-LD 문서 안에 포함되어 있을 때 적절한 그래프 컨텍스트 안에서 드러날 수 있습니다. 기본적으로 프레이밍은 입력 안의 모든 그래프에 걸친 모든 노드 객체로 구성된 merged graph를 사용합니다. 프레임 안에서 @graph를 사용하면, 출력 문서는 입력 문서 안에 포함된 명명된 그래프의 정보를 구체적으로 포함할 수 있습니다.

다음 예제는 정보가 기본 그래프와 http://example.org/graphs/books라는 이름의 그래프 사이에 나뉘어 있는 라이브러리 테마의 변형을 사용합니다:

예제 46: 명명된 그래프를 사용하는 프레임 
{
  "@context": {"@vocab": "http://example.org/"},
  "@type": "Library",
  "contains": {
    "@id": "http://example.org/graphs/books",
    "@graph": {
      "@type": "Book"
    }
  }
}
예제 47: 명명된 그래프가 있는 평탄화된 입력 
[{
  "@context": {"@vocab": "http://example.org/"},
  "@id": "http://example.org/graphs/books",
  "@graph": [{
    "@id": "http://example.org/library/the-republic",
    "@type": "http://example.org/Book",
    "http://example.org/contains": {
      "@id": "http://example.org/library/the-republic#introduction"
    },
    "http://example.org/creator": "Plato",
    "http://example.org/title": "The Republic"
  }, {
    "@id": "http://example.org/library/the-republic#introduction",
    "@type": "http://example.org/Chapter",
    "http://example.org/description": "An introductory chapter on The Republic.",
    "http://example.org/title": "The Introduction"
  }]
}, {
  "@context": {"@vocab": "http://example.org/"},
  "@id": "http://example.org/library",
  "@type": "http://example.org/Library",
  "http://example.org/contains": {"@id": "http://example.org/graphs/books"},
  "http://example.org/name": "Library"
}]

3. 적합성

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

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

이 명세에 대한 적합성을 주장할 수 있는 제품 클래스는 하나입니다: JSON-LD 프로세서.

적합한 JSON-LD 프로세서는 이 명세에 정의된 알고리즘과 일관되는 방식으로 프레이밍 연산을 수행할 수 있는 시스템입니다.

JSON-LD 프로세서는 잘못된 형식의 IRI 또는 언어 태그를 수정하려고 시도해서는 MUST NOT 됩니다; 그러나 검증 경고를 발행할 수는 MAY 있습니다. IRI는 상대 및 절대 IRI 사이의 변환 외에는 수정되지 않습니다.

processingMode API 옵션을 사용해 지정하지 않는 한, 처리 모드는 로컬 컨텍스트 안의 @version 엔트리를 사용해 설정되며, 확장 및 축약을 포함한 알고리즘의 동작에 영향을 줍니다. 일단 설정되면 다른 처리 모드로 변경하려는 시도는 오류이며, 프로세서는 processing mode conflict 오류를 생성하고 이후 처리를 중단해야 MUST 합니다.

이 명세의 알고리즘은 일반적으로 효율성보다 명확성을 더 중시하여 작성되었습니다. 따라서 JSON-LD 프로세서는 최종 결과가 명세의 알고리즘으로 얻을 수 있는 결과와 구별할 수 없는 한, 이 명세에 제시된 알고리즘을 원하는 어떤 방식으로든 구현할 수 MAY 있습니다.

키워드에 대한 연산을 설명하는 알고리즘 단계에서, 그러한 단계는 키워드 별칭에도 적용됩니다.

참고

구현자는 JSON-LD 프레이밍 테스트 스위트의 테스트 케이스를 성공적으로 통과함으로써 이 명세에 대한 적합성 수준을 부분적으로 확인할 수 있습니다. 그러나 테스트 스위트의 모든 테스트를 통과한다는 것이 이 명세에 대한 완전한 적합성을 의미하지는 않는다는 점에 유의하십시오. 이는 구현이 테스트 스위트에서 테스트한 측면에 적합하다는 것만 의미합니다.

4. 프레이밍

다음 섹션들은 JSON-LD 문서를 프레이밍하기 위한 알고리즘을 설명합니다. 프레이밍은 정보 그래프를 표현하는 JSON-LD 문서를 가져와 특정 그래프 레이아웃(프레임이라고 함)을 적용하는 과정입니다.

프레이밍은 노드 맵 생성 알고리즘을 사용하여 JSON-LD 문서에 정의된 각 객체를 평탄화된 주어들의 맵에 배치함으로써, 프레이밍 알고리즘이 그것들을 대상으로 동작할 수 있게 합니다.

이 섹션에 설명된 모든 알고리즘은 언어 네이티브 데이터 구조에서 동작하도록 의도되었습니다. 즉, 텍스트 기반 JSON 문서로의 직렬화는 이러한 알고리즘의 입력이나 출력으로 필요하지 않습니다.

JSON 데이터 구조에 대한 참조는 알고리즘 설명을 위해 그 내부 표현을 사용해 해석됩니다.

4.1 프레이밍 알고리즘

4.1.1 개요

유효한 JSON-LD 프레임은 유효한 JSON-LD 문서의 상위 집합이며, 확장을 통해 보존되는 추가 콘텐츠를 허용합니다. JSON-LD 1.1 구문 명세 [JSON-LD11]에 정의된 문법은 다음과 같이 확장됩니다:

4.1.2 알고리즘

프레이밍 알고리즘은 다섯 개의 필수 입력 변수와 하나의 선택적 입력 변수를 받습니다. 필수 입력은 프레이밍 상태 (state), 프레이밍할 subjects의 리스트, 입력 프레임 (expanded frame), 부분 프레임 결과를 수집하는 데 사용되는 parent, 그리고 active property입니다. 선택적 입력 변수는 ordered 플래그입니다.

알고리즘은 parent가 배열이면 요소를 parent에 추가하거나, parent가 맵이면 parent 안에서 active property와 연결된 배열에 추가함으로써 parent에 요소를 추가합니다. parent가 배열인 경우 active property는 null이어야 MUST 하며, 그것이 맵인 경우 null이어서는 MUST NOT 안 됩니다.

  1. frame이 배열이면, frame을 배열의 값으로 설정합니다. 이 값은 유효한 프레임이어야 MUST 합니다. frame이 유효하지 않은 것으로 판단되면, invalid frame 오류가 감지되었으며 처리가 중단됩니다.
    1. Frame은 맵이어야 MUST 합니다.
    2. frame에 @id 엔트리가 있는 경우, 그 값은 값으로 단일 빈 맵을 포함하는 배열, 유효한 IRI, 또는 모든 값이 유효한 IRI인 배열 중 하나여야 MUST 합니다.
    3. frame에 @type 엔트리가 있는 경우, 그 값은 값으로 단일 빈 맵을 포함하는 배열, 키가 @default인 엔트리를 가진 맵을 포함하는 배열, 유효한 IRI, 또는 모든 값이 유효한 IRI인 배열 중 하나여야 MUST 합니다.
  2. state 안의 객체 임베드 플래그, 명시적 포함 플래그, 및 모두 요구 플래그에서 embed, explicit, 및 requireAll 플래그를 초기화하되, frame 안의 @embed, @explicit, 및 @requireAll에 대한 프로퍼티 값으로 재정의합니다.
  3. 프레임 매칭 알고리즘을 state, subjects, frame, 및 requireAll과 함께 사용하여 subjects를 frame에 대해 필터링함으로써 매칭된 주어들의 리스트를 만듭니다.
  4. 매칭된 주어들의 집합에서 각 id 및 연결된 노드 객체 node에 대해, 선택적 ordered 플래그가 true인 경우 id를 기준으로 사전식 순서로:
    1. @id와 id를 가진 새 맵으로 output을 초기화합니다.
    2. state 안의 임베디드 플래그가 false이고, state 안의 graph name 및 id와 연결된 기존 임베드된 노드가 parent에 있으면, 이 node에 대해 추가 처리를 수행하지 않습니다.
    3. 그렇지 않고, state 안의 임베디드 플래그가 true이고 embed가 @never이거나 임베드로 인해 순환 참조가 만들어질 경우, output을 parent에 추가하고 이 node에 대해 추가 처리를 수행하지 않습니다.
    4. 그렇지 않고, state 안의 임베디드 플래그가 true이고, embed가 @once이며, state 안의 graph name 및 id와 연결된 기존 임베드된 노드가 parent에 있으면, output을 parent에 추가하고 이 node에 대해 추가 처리를 수행하지 않습니다.
    5. state 안의 graph map에 id에 대한 엔트리가 있으면:
      1. frame에 @graph 엔트리가 없으면, state 안의 graph name이 @merged인 경우를 제외하고 recurse를 true로 설정하고 subframe을 새 빈 맵으로 설정합니다.
      2. 그렇지 않으면, frame 안의 @graph에 대한 첫 번째 엔트리로 subframe을 설정하거나, 그것이 없으면 새 빈 맵으로 설정하고, id가 @merged 또는 @default인 경우를 제외하고 recurse를 true로 설정합니다.
      3. recurse가 true이면:
        1. state 안의 graph name 값을 id로 설정합니다.
        2. state 안의 임베디드 플래그 값을 false로 설정합니다.
        3. graph name의 값을 id로 설정하고 임베디드 플래그의 값을 false로 설정한 state의 복사본을 사용하여 알고리즘을 호출합니다. 이때 state 안의 graph map에서 id와 연결된 키를 subjects로, subframe을 frame으로, output을 parent로, 그리고 @graph를 active property로 전달합니다.
    6. frame에 @included 엔트리가 있으면, 임베디드 플래그의 값을 false로 설정한 state의 복사본을 사용하여 알고리즘을 호출합니다. 이때 subjects, frame, output을 parent로, 그리고 @included를 active property로 전달합니다.
    7. node 안의 각 property 및 objects에 대해, 선택적 ordered 플래그가 true인 경우 property를 기준으로 사전식 순서로:
      1. property가 키워드이면, property와 objects를 output에 추가합니다.
      2. 그렇지 않고, property가 frame 안에 없고 explicit이 true이면, 프로세서는 property에 대한 어떤 값도 output에 추가해서는 MUST NOT 안 되며, 다음 단계들은 건너뜁니다.
      3. objects 안의 각 item에 대해:
        1. item이 프로퍼티 @list를 가진 맵이면, 리스트 안의 각 listitem을 순서대로 처리하여 출력 안의 새 리스트 맵에 추가합니다:
          1. listitem이 노드 참조이면, 임베디드 플래그의 값을 true로 설정한 state의 복사본을 사용하여 알고리즘을 호출합니다. 이때 listitem의 @id 값을 새 subjects 배열의 유일한 항목으로, frame 안의 @list에서 첫 번째 값을 frame으로, list를 parent로, 그리고 @list를 active property로 전달합니다. frame이 존재하지 않으면, embed, explicit 및 requireAll에서 가져온 @embed, @explicit, @requireAll 프로퍼티를 가진 새 맵을 사용하여 새 frame을 만듭니다.
          2. 그렇지 않으면, listitem의 복사본을 list 안의 @list에 추가합니다.
        2. item이 노드 참조이면, 임베디드 플래그의 값을 true로 설정한 state의 복사본을 사용하여 알고리즘을 호출합니다. 이때 item의 @id 값을 새 subjects 배열의 유일한 항목으로, frame 안의 property에서 첫 번째 값을 frame으로, output을 parent로, 그리고 property를 active property로 전달합니다. frame이 존재하지 않으면, embed, explicit 및 requireAll에서 가져온 @embed, @explicit 및 @requireAll 프로퍼티를 가진 새 맵을 사용하여 새 frame을 만듭니다.
        3. 그렇지 않으면, item의 복사본을 output 안의 활성 프로퍼티에 추가합니다.
      4. frame 안의 각 비-키워드 property 및 objects에 대해, (`@type 제외) output 안에 없는 경우:
        1. item을 objects 안의 첫 번째 값으로 둡니다. 이 값은 프레임 객체이어야 MUST 합니다.
        2. property frame을 objects 안의 첫 번째 값으로 설정하거나, 값이 objects이면 새로 만든 프레임 객체로 설정합니다. property frame은 맵이어야 MUST 합니다.
        3. property frame이 값 true의 @omitDefault를 포함하거나, @omitDefault를 포함하지 않고 state 안의 기본값 생략 플래그 값이 true이면, property와 property frame을 건너뜁니다.
        4. @preserve 프로퍼티와 값을 가진 새 맵과 함께 property를 output에 추가합니다. 그 값은 존재하는 경우 frame 안의 @default 값의 복사본이고, 그렇지 않으면 문자열 @null입니다.
      5. frame에 프로퍼티 @reverse가 있으면, frame 안의 @reverse 값인 각 reverse property 및 sub frame에 대해:
        1. reverse dict라는 새 맵을 값으로 가진 @reverse 프로퍼티를 output 안에 만듭니다.
        2. 평탄화된 주어들의 맵 안의 각 reverse id 및 node에 대해, 프로퍼티 reverse property가 id의 @id를 가진 노드 참조를 포함하는 경우:
          1. reverse property를 reverse dict에 새 빈 배열을 값으로 하여 추가합니다.
          2. 임베디드 플래그의 값을 true로 설정한 state의 복사본을 사용하여 알고리즘을 호출합니다. 이때 reverse id를 새 subjects 배열의 유일한 항목으로, sub frame을 frame으로, null을 active property로, 그리고 reverse dict 안의 reverse property의 배열 값을 parent로 전달합니다.
      6. 이전 단계에서 요구된 대로 output이 설정되면, output을 parent에 추가합니다.

4.2 프레임 매칭 알고리즘

프레임 매칭 알고리즘은 프레이밍 알고리즘의 일부로 사용되어 특정 노드 객체가 프레임에 설정된 기준과 매칭되는지 결정합니다. 일반적으로 노드 객체는 @type, @id 기준 매칭을 충족하거나, 여러 서로 다른 프로퍼티 중 하나와 매칭되는 경우 프레임과 매칭됩니다. 모두 요구 플래그가 true이면, 프레임이 매칭되려면 모든 프로퍼티가 기본값을 가지거나 매칭되어야 합니다.

참고

매칭은 확장된 노드 객체에서 수행되므로, 모든 값은 배열의 형태가 됩니다.

노드 매칭은 JSON 구성 요소의 조합을 사용하여 임의, 없음, 또는 일부 특정 값과 매칭합니다:

[] (match none)
빈 배열은 어떤 값과도 매칭하지 않거나, 그 자체가 빈 배열인 값과 매칭합니다.
[프레임 객체] (node pattern)
재귀적 노드 매칭을 사용해 특정 값과 매칭하는 데 사용되는 비어 있지 않은 프레임 객체.
[IRI+]
IRI 형식의 하나 이상의 문자열로, @type과 @id 기준 매칭에 사용되며, 나열된 IRI 중 임의의 것과 매칭할 수 있게 합니다.
[값 객체] (value pattern)
특정 값과 매칭하는 데 사용되는 값 객체. 값 객체 안에서 @value, @type, 및 @language의 값은 하나 이상의 문자열 값의 배열일 수도 있으며, @language의 값은 대소문자를 구분하지 않고 비교됩니다.
{} (wildcard)
빈 객체를 포함하는 배열은 (프레이밍 키워드인 프로퍼티를 제외한 뒤) 존재하는 모든 값과 매칭하며, 값이 없으면 매칭하지 않습니다.

프레임 매칭 알고리즘은 프레이밍 상태 (state), 평탄화된 주어들의 맵에서 매칭할 주어들의 리스트 (subjects), 매칭 대상인 프레임 (frame), 및 requireAll 플래그를 받고, subjects 안의 각 node를 다음과 같이 필터링하여 매칭된 주어들의 리스트를 반환합니다:

@id와 @type을 포함한 모든 프로퍼티가 매칭 시 고려되지만, 다른 키워드는 고려되지 않습니다.

  1. frame에 프로퍼티가 없으면 node가 매칭됩니다.
  2. requireAll이 true이면, frame 안의 모든 프로퍼티(property)가 다음 조건 중 하나와 매칭될 때 node가 매칭됩니다. 또는 requireAll이 false이면, frame 안의 프로퍼티(property) 중 하나라도 다음 조건 중 하나와 매칭될 때 매칭됩니다. node 안의 frame에서 온 각 property의 values에 대해:
    1. property가 @id이면:
      1. 프레임 안의 @id 프로퍼티가 values 안의 임의의 IRI를 포함하면 property가 매칭됩니다.
      2. 그렇지 않으면, frame 안의 @type 프로퍼티가 wildcard 또는 match none이면 property가 매칭됩니다.
      참고
      프레이밍은 평탄화된 주어들의 맵에서 동작하며, 평탄화 행위는 모든 주어가 @id 프로퍼티를 갖도록 보장합니다. 따라서 "@id": [] 패턴은 어떤 노드 객체와도 매칭되지 않습니다. "@id": [{}] 패턴은 모든 노드 객체와 매칭되며, frame 안에서 @id 프로퍼티를 전혀 지정하지 않는 것과 동등합니다.
    2. 그렇지 않고, property가 @type이면:
      1. 프레임 안의 @type 프로퍼티가 values 안의 임의의 IRI를 포함하면 property가 매칭됩니다.
      2. 그렇지 않으면, values가 비어 있지 않고 frame 안의 @type 프로퍼티가 wildcard이면 property가 매칭됩니다.
      3. 그렇지 않으면, values가 비어 있고 frame 안의 @type 프로퍼티가 match none이면 property가 매칭됩니다.
      4. 그렇지 않으면, 프레임 안의 @type 프로퍼티가 기본 객체이면 property가 매칭됩니다.
      5. 그렇지 않으면, property는 매칭되지 않습니다.
    3. property가 @id 또는 @type이고 매칭되지 않으면, node는 매칭되지 않으며, 처리가 종료됩니다.
    4. 그렇지 않으면, frame 안의 property 값은 비어 있거나 유효한 프레임을 포함하는 배열이어야 MUST 합니다.
    5. values가 비어 있거나 존재하지 않고, frame 안의 property 값이 임의의 값을 가진 @default 엔트리만 포함하는 맵이며, node 안의 다른 어떤 프로퍼티가 기본값이 아닌 매칭을 가지면 property가 매칭됩니다.
    6. values가 비어 있지 않고 frame 안의 property 값이 match none이면, node는 매칭되지 않으며 추가 매칭은 중단됩니다.
    7. 그렇지 않으면, values가 비어 있지 않고 frame 안의 property 값이 wildcard이면 property가 매칭됩니다.
    8. 그렇지 않고, frame 안의 property 값이 value pattern (value pattern)이면: 프로퍼티 매칭은 값 매칭 알고리즘을 사용해 결정됩니다.
    9. 그렇지 않으면, frame 안의 property 값 중 하나인 임의의 node pattern (node pattern)에 대해:
      1. values의 노드 객체 값과 매칭되는 평탄화된 주어들의 맵의 주어 리스트를 value subjects로 둡니다.
      2. state, subjects로서의 value subjects, frame으로서의 node pattern, 그리고 requireAll 플래그를 사용해 이 알고리즘을 재귀적으로 호출한 결과를 matched subjects로 둡니다.
      3. matched subjects가 비어 있지 않으면 property가 매칭됩니다.
    10. 그렇지 않으면, property는 매칭되지 않습니다.

4.3 값 패턴 매칭 알고리즘

값 패턴 매칭 알고리즘은 프레이밍 및 프레임 매칭 알고리즘의 일부로 사용됩니다. 값 객체는 @value, @type, 및 @language에 대한 match none 및 wildcard 패턴을 사용하고, 각 값 객체 프로퍼티에 대해 배열 형식을 사용해 정의된 값 집합과 특정 값이 매칭될 수 있도록 허용함으로써 값 패턴과 매칭됩니다.

알고리즘은 value pattern (pattern)과 값 객체 (value)를 매개변수로 받습니다. Value는 다음 알고리즘을 사용해 pattern과 매칭됩니다:

  1. v1, t1, 및 l1을 value 안의 @value, @type, 및 @language 값으로 두거나, 존재하지 않으면 null로 둡니다. 이때 @language의 값은 소문자로 정규화됩니다.
  2. v2, t2, 및 l2를 value pattern 안의 @value, @type, 및 @language 값으로 두거나, 존재하지 않으면 null로 둡니다. 이때 @language의 문자열 값은 소문자로 정규화됩니다.
  3. pattern이 wildcard이거나, 다음 조건을 만족할 때 Value는 pattern과 매칭됩니다:
    1. v1이 v2 안에 있거나, v1이 null이 아니고 v2가 wildcard이며, 그리고
    2. t1이 t2 안에 있거나, t1이 null이 아니고 t2가 wildcard, 또는 null이거나, 또는 t1이 null이고 t2가 null 또는 match none이며, 그리고
    3. l1이 l2 안에 있거나, l1이 null이 아니고 l2가 wildcard, 또는 null이거나, 또는 l1이 null이고 l2가 null 또는 match none입니다.

5. 애플리케이션 프로그래밍 인터페이스

이 API는 개발자가 JSON-LD 데이터를 다양한 프로그래밍 언어에서 더 쉽게 다룰 수 있는 여러 출력 형식으로 변환할 수 있게 하는 깔끔한 메커니즘을 제공합니다. 프로그래밍 환경에서 JSON-LD API가 제공되는 경우, 다음 API 전체가 구현되어야 MUST 합니다.

JSON-LD API는 다양한 지연 연산의 결과를 표현하기 위해 Promises를 사용합니다. Promises는 [ECMASCRIPT]에 정의되어 있습니다. 명세 안에서의 일반적인 사용은 [promises-guide]에서 확인할 수 있습니다. 구현은 일반적으로 같은 메서드, 인수 및 옵션을 사용하고 같은 결과를 반환하는 한, 해당 네이티브 환경에 적합한 방식으로 구현하기로 선택할 수 MAY 있습니다.

참고

인터페이스는 [Exposed=JsonLd]로 표시되며, 이는 전역 인터페이스를 만듭니다. JSON-LD에서 WebIDL을 사용하는 것은 브라우저 내 사용에 적합하지만, 그러한 사용으로 제한되지는 않습니다.

5.1 JsonLdProcessor

JSON-LD 프로세서 인터페이스는 개발자가 JSON-LD 변환 메서드에 접근하는 데 사용하는 고수준 프로그래밍 구조입니다. 아래 정의는 JSON-LD 1.1 API [JSON-LD11-API]에 정의된 인터페이스의 실험적 확장입니다.

구현이 입력 매개변수를 수정하지 않는다는 점을 강조하는 것이 중요합니다. 오류가 감지되면, Promise는 적절한 code를 가진 JsonLdFramingError로 거부되고 처리는 중단됩니다. 

WebIDL/*
 * The JsonLd interface is created to expose the JsonLdProcessor interface.
 */
[Global=JsonLd, Exposed=JsonLd]
interface JsonLd {};

[Exposed=JsonLd]
interface JsonLdProcessor {
  constructor();
  static Promise<JsonLdRecord> frame(
    JsonLdInput input,
    JsonLdInput frame,
    optional JsonLdOptions options = {});
};

JsonLdProcessor 인터페이스의 frame() 메서드는 frame을 사용해 주어진 input을 프레이밍 알고리즘의 단계에 따라 프레이밍합니다:

  1. 새 Promise promise를 만들고 반환합니다. 그런 다음 다음 단계들이 비동기적으로 실행됩니다.
  2. 제공된 input이 RemoteDocument이면, remote document를 input으로 초기화합니다.
  3. 그렇지 않고, 제공된 input이 원격 문서의 IRI를 나타내는 문자열이면, LoadDocumentCallback을 사용해 이를 remote document로 기다리고 역참조합니다. 이때 input을 url로 전달하고, options에서 온 extractAllScripts 옵션을 extractAllScripts로 전달합니다.
  4. expanded input을 expand 메서드를 사용한 결과로 설정합니다. 이때 remote document를 사용하거나, remote document가 없으면 input을 input으로, options를 사용하며 ordered를 false로 설정합니다.
  5. 제공된 frame이 RemoteDocument이면, remote frame을 frame으로 초기화합니다.
  6. 그렇지 않고, 제공된 frame이 원격 문서의 IRI를 나타내는 문자열이면, LoadDocumentCallback을 사용해 이를 remote frame으로 기다리고 역참조합니다. 이때 frame을 url로 전달하고, options에서 온 extractAllScripts 옵션을 extractAllScripts로 전달합니다.
  7. expanded frame을 expand 메서드를 사용한 결과로 설정합니다. 이때 remote frame을 사용하거나, remote frame이 없으면 frame을 input으로, options와 frameExpansion 옵션을 true로 설정해 사용하고, 그리고ordered를 false로 설정합니다.
  8. context를 remote frame 또는 frame에서 가져온 @context 값으로 설정합니다. 존재하지 않으면 새 빈 컨텍스트로 설정합니다.
  9. context base를 사용 가능한 경우 remote frame에서 온 documentUrl로 설정하고, 그렇지 않으면 options에서 온 base 옵션으로 설정합니다.
  10. 새 빈 컨텍스트를 active context로, context를 local context로, 그리고 context base를 base URL로 전달해 컨텍스트 처리 알고리즘을 수행한 결과로 active context를 초기화합니다.
  11. context를 사용해 활성 컨텍스트를 초기화합니다; 기준 IRI는 설정된 경우 options에서 온 base 옵션으로 설정됩니다; 그렇지 않고 compactToRelative 옵션이 true이면, 사용 가능한 경우 현재 처리 중인 문서의 IRI로 설정되고, 그렇지 않으면 null로 설정됩니다.
  12. 역 컨텍스트 생성 알고리즘을 수행한 결과로 inverse context를 초기화합니다.
  13. frame에 @graph로 확장되는 최상위 프로퍼티가 있으면, options에 대해 frameDefault 옵션을 값 true로 설정합니다.
  14. 새 프레이밍 상태 (state)를 빈 맵으로 초기화합니다.
    1. state 안의 객체 임베드 플래그를 기본값 @once를 가진 embed로 설정합니다.
    2. state 안의 임베디드 플래그를 false로 설정합니다.
    3. state 안의 명시적 포함 플래그를 기본값 false를 가진 explicit로 설정합니다.
    4. state 안의 모두 요구 플래그를 기본값 false를 가진 requireAll로 설정합니다.
    5. state 안의 기본값 생략 플래그를 기본값 false를 가진 omitDefault로 설정합니다.
    6. state 안의 graph name을 frameDefault가 true이면 @default로, 그렇지 않으면 false로 설정합니다.
    7. state 안의 graph map을 expanded input에 대해 노드 맵 생성 알고리즘을 수행한 결과로 설정합니다.
      1. state 안의 graph name이 @merged이면, graph map에 @merged에 대한 엔트리를 추가하고, 그 값을 graph map을 전달해 노드 맵 병합 알고리즘을 수행한 결과로 설정합니다.
    8. state 안의 subject map을 graph map 안의 graph name 값인 평탄화된 주어들의 맵으로 설정합니다.
  15. results를 빈 배열로 초기화합니다.
  16. 프레이밍 알고리즘을 호출하며, state, subjects로 state 안의 subject map에서 온 키, expanded frame, parent로 results, 그리고 active property로 null을 전달합니다.
  17. 처리 모드가 json-ld-1.0이 아니면, results 안의 각 노드 객체에서, 엔트리 값이 results 안의 어떤 프로퍼티 값에서도 한 번만 나타나는 빈 노드 식별자인 @id 엔트리를 제거합니다.
  18. results 안에서 키가 @preserve인 모든 엔트리를 재귀적으로 해당 엔트리의 첫 번째 값으로 교체합니다.
    참고
    엔트리의 값은 단일 값을 가진 배열입니다; 이는 @preserve를 포함하는 맵을 사실상 그 값으로 교체합니다.
  19. active context, inverse context, active property로 null, element로 results,, 그리고 options에서 온 compactArrays 및 ordered 플래그를 사용해 compact 메서드를 사용한 결과로 compacted results를 설정합니다.
    1. compacted results가 빈 배열이면, 이를 새 맵으로 교체합니다.
    2. 그렇지 않고, compacted results가 배열이면, 이를 단일 엔트리를 가진 새 맵으로 교체합니다. 그 키는 @graph의 IRI 축약 결과이고, 값은 compacted results입니다.
    3. compacted results에 @context 엔트리를 추가하고 그 값을 제공된 context로 설정합니다.
  20. compacted results 안의 모든 @null 값을 재귀적으로 null로 교체합니다. 교체 후 배열이 null 값만 포함하면 그 값을 제거하여 빈 배열로 남깁니다.
  21. omitGraph가 false이고 compacted results가 최상위 @graph 엔트리를 가지지 않거나, 그 값이 배열이 아니면, compacted results를 수정하여 compacted results의 @context가 아닌 엔트리를 @graph의 배열 값 안에 포함된 맵 안에 배치합니다. omitGraph가 true이면, 최상위 @graph 엔트리는 여러 노드 객체를 포함하는 데만 사용됩니다.
  22. promise를 compacted results로 해결하고, compacted results를 내부 표현에서 JSON 직렬화로 변환합니다.
input
프레이밍을 수행할 JSON-LD 객체 또는 JSON-LD 객체 배열, 또는 프레이밍할 JSON-LD 문서를 참조하는 IRI.
frame
input의 데이터를 재배열할 때 사용할 프레임; 맵 형식이거나 IRI일 수 있습니다.
options
예를 들어 입력 문서의 기준 IRI처럼, 프레이밍 알고리즘에 영향을 줄 수 있는 옵션 집합입니다. JsonLdOptions 타입은 기본 옵션 값을 정의합니다. 
WebIDLtypedef record<USVString, any> JsonLdRecord;

JsonLdRecord는 JSON 객체를 파싱한 결과인 임의의 맵 엔트리를 포함하는 데 사용되는 맵의 정의입니다. 

WebIDLtypedef (JsonLdRecord or sequence<JsonLdRecord> or USVString or RemoteDocument) JsonLdInput;

JsonLdInput 인터페이스는 JsonLdRecord, JsonLdRecords의 sequence, 유효한 JSON 문서를 가져오기 위해 역참조될 수 있는 IRI를 나타내는 문자열, 또는 이미 역참조된 RemoteDocument일 수 있는 입력 값을 가리키는 데 사용됩니다.

값이 JsonLdRecord 또는 JsonLdRecords의 시퀀스인 경우, 값들은 그에 대응하는 내부 표현 값으로 취급됩니다. 여기서 JsonLdRecord는 맵과 동등하며, JsonLdRecords의 시퀀스는 맵들의 배열과 동등합니다. 맵 엔트리는 [INFRA]의 대응 항목으로 변환됩니다.

5.2 오류 처리

JsonLdFramingError 타입은 처리 오류를 보고하는 데 사용됩니다.

WebIDLdictionary JsonLdFramingError {
  JsonLdFramingErrorCode code;
  USVString? message = null;
};
enum JsonLdFramingErrorCode {
  "invalid frame",
  "invalid @embed value"
};

JSON-LD 프레이밍은 JSON-LD 1.1 처리 알고리즘 및 API JSON-LD 1.1 API [JSON-LD11-API]에 정의된 오류 인터페이스와 코드를 확장합니다.

code
이 문서의 여러 알고리즘에 설명된 특정 오류 타입을 나타내는 문자열.
message
추가 디버깅 정보를 포함하는 선택적 오류 메시지. 오류 메시지의 구체적인 내용은 이 명세의 범위를 벗어납니다.

JsonLdFramingErrorCode는 유효한 JSON-LD 프레이밍 오류 코드들의 컬렉션을 나타냅니다.

invalid @embed value
@embed의 값이 객체 임베드 플래그에 대해 인식되는 값이 아닙니다.
invalid frame
프레임이 유효하지 않습니다.

5.3 데이터 구조

이 섹션은 JSON-LD API 안에서 사용되는 데이터타입 정의를 설명합니다.

5.3.1 JsonLdContext

JsonLdContext 타입은 맵, IRI를 나타내는 문자열, 또는 맵과 문자열의 배열일 수 있는 값을 가리키는 데 사용됩니다.

JSON-LD 1.1 API [JSON-LD11-API]의 JsonLdContext 정의를 참조하십시오.

5.3.2 JsonLdOptions

JsonLdOptions 타입은 JsonLdProcessor 메서드에 다양한 옵션을 전달하는 데 사용됩니다. 

WebIDLdictionary JsonLdOptions {
  (JsonLdEmbed or boolean)  embed         = "@once";
  boolean                   explicit      = false;
  boolean                   omitDefault   = false;
  boolean                   omitGraph;
  boolean                   requireAll    = false;
  boolean                   frameDefault  = false;
  boolean                   ordered       = false;
};

enum JsonLdEmbed {
  "@always",
  "@once",
  "@never"
};

JSON-LD 1.1 API [JSON-LD11-API]에 정의된 옵션에 더해, 프레이밍은 다음 추가 옵션을 정의합니다:

embed
프레이밍 알고리즘에서 사용되는 객체 임베드 플래그 값을 설정합니다. 불리언 값 true는 플래그를 @once로 설정하고, 값 false는 플래그를 @never로 설정합니다.
explicit
프레이밍 알고리즘에서 사용되는 명시적 포함 플래그 값을 설정합니다.
frameDefault
merged graph를 프레이밍하는 대신, 기본 그래프만 프레이밍합니다.
omitDefault
프레이밍 알고리즘에서 사용되는 기본값 생략 플래그 값을 설정합니다
omitGraph
프레이밍 알고리즘에서 사용되는 그래프 생략 플래그 값을 설정합니다. 명시적으로 설정되지 않으면, 처리 모드가 json-ld-1.0인 경우 false로 설정되고, 그렇지 않으면 true로 설정됩니다.
ordered
true로 설정되면, 표시된 특정 알고리즘 처리 단계가 사전식 순서로 정렬됩니다. false이면 처리에서 순서가 고려되지 않습니다.
requireAll
프레이밍 알고리즘에서 사용되는 모두 요구 플래그 값을 설정합니다.

JsonLdEmbed는 embed 옵션의 값을 열거합니다:

@always
순환 참조를 일으키지 않는 한, 노드 객체를 항상 프로퍼티 값으로 임베드합니다.
@never
매칭되는 값을 직렬화할 때 항상 노드 참조를 사용합니다.
@once
주어진 노드 객체 안의 단일 값만 임베드되어야 하며, 다른 프로퍼티의 다른 값은 노드 참조를 사용합니다. 이는 @embed와 객체 임베드 플래그 둘 다 지정되지 않은 경우의 기본값입니다.

JSON-LD 1.1 API [JSON-LD11-API]의 JsonLdOptions 정의를 참조하십시오.

6. 보안 고려 사항

§ A. IANA 고려 사항의 보안 고려 사항을 참조하십시오.

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

[JSON-LD11]의 개인정보 보호 고려 사항을 참조하십시오.

8. 국제화 고려 사항

[JSON-LD11]의 국제화 고려 사항을 참조하십시오.

A. IANA 고려 사항

이 섹션은 단지 표준 커뮤니티 검토를 위해 포함되었으며, 이 명세가 W3C 권고안이 되면 Internet Engineering Steering Group에 제출될 예정입니다.

JSON-LD 프레임은 필수 profile 매개변수와 함께 [JSON-LD11]에 설명된 같은 MIME 미디어 타입을 사용합니다.

application/ld+json

타입 이름:
application
하위 타입 이름:
ld+json
필수 매개변수:
없음
선택적 매개변수:
profile

리소스를 JSON-LD 프레임으로 식별하는 단일 URI. 프로파일은 프로파일 지식 없이 처리될 때 리소스 표현의 의미를 변경하지 않으므로, 프로파일된 리소스를 알고 있는 클라이언트와 알지 못하는 클라이언트 모두가 같은 표현을 안전하게 사용할 수 있습니다.

http://www.w3.org/ns/json-ld#framed
JSON-LD 프레임을 지정하기 위한 것.

JSON-LD 프레임 문서를 제공하고 요청할 때는 http://www.w3.org/ns/json-ld#framed를 사용해야 SHOULD 합니다.

인코딩 고려 사항:
RFC 8259, 섹션 11을 참조하십시오.
보안 고려 사항:
RFC 8259, 섹션 12 [RFC8259]를 참조하십시오

JSON-LD는 방향 그래프를 위한 순수 데이터 교환 형식이 되도록 의도되었으므로, 직렬화는 파싱을 위해 JavaScript의 eval() 함수 같은 코드 실행 메커니즘을 통과해서는 SHOULD NOT 안 됩니다. (유효하지 않은) 문서는 실행될 경우 예기치 않은 부작용을 일으켜 시스템 보안을 손상시킬 수 있는 코드를 포함할 수 있습니다.

JSON-LD 문서를 처리할 때, 원격 컨텍스트에 대한 링크는 일반적으로 자동으로 따라가게 되며, 그 결과 각 파일에 대한 사용자의 명시적 요청 없이 파일이 전송됩니다. 원격 컨텍스트가 제3자에 의해 제공되는 경우, 이로 인해 사용 패턴이나 유사한 정보를 수집할 수 있어 개인정보 보호 우려로 이어질 수 있습니다. JSON-LD 1.1 처리 알고리즘 및 API 명세 [JSON-LD11-API]에 정의된 API 같은 특정 구현은 이 동작을 제어하기 위한 세분화된 메커니즘을 제공할 수 있습니다.

HTTP 같은 비보안 연결을 통해 웹에서 로드되는 JSON-LD 컨텍스트는 공격자에 의해 변경될 위험이 있으며, 그 결과 JSON-LD 활성 컨텍스트가 보안을 손상시킬 수 있는 방식으로 수정될 수 있습니다. 중요한 목적을 위해 원격 컨텍스트에 의존하는 모든 애플리케이션은 시스템이 이를 사용하도록 허용하기 전에 원격 컨텍스트를 검토하고 캐시하는 것이 권장됩니다.

JSON-LD는 긴 IRI를 짧은 용어로 대체할 수 있게 하므로, JSON-LD 문서는 처리될 때 상당히 확장될 수 있으며, 최악의 경우 결과 데이터가 수신자의 모든 리소스를 소비할 수도 있습니다. 애플리케이션은 모든 데이터를 적절히 의심스럽게 다뤄야 합니다.

JSON-LD는 사용할 수 있는 IRI 스킴에 제한을 두지 않고, 어휘 상대 IRI는 IRI 해석이 아니라 문자열 연결을 사용하므로, 역참조될 경우 악의적으로 사용될 수 있는 IRI를 구성하는 것이 가능합니다.

상호운용성 고려 사항:
해당 없음
발행된 명세:
https://www.w3.org/TR/json-ld11-framing
이 미디어 타입을 사용하는 애플리케이션:
방향 그래프의 교환을 필요로 하는 모든 프로그래밍 환경. JSON-LD 구현은 JavaScript, Python, Ruby, PHP 및 C++용으로 만들어졌습니다.
추가 정보:
매직 넘버:
해당 없음
파일 확장자:
.jsonld
Macintosh 파일 타입 코드:
TEXT
추가 정보를 위한 연락 담당자 및 이메일 주소:
Ivan Herman <ivan@w3.org>
의도된 사용:
일반
사용 제한:
없음
저자:
Manu Sporny, Gregg Kellogg, Markus Lanthaler, Dave Longley
변경 관리 주체:
W3C

application/ld+json과 함께 사용되는 프래그먼트 식별자는 RDF 1.1 개념과 추상 구문 [RDF11-CONCEPTS]에 따라 RDF 구문에서와 같이 처리됩니다.

B. IDL 색인

이 섹션은 비규범입니다.

WebIDL/*
 * The JsonLd interface is created to expose the JsonLdProcessor interface.
 */
[Global=JsonLd, Exposed=JsonLd]
interface JsonLd {};

[Exposed=JsonLd]
interface JsonLdProcessor {
  constructor();
  static Promise<JsonLdRecord> frame(
    JsonLdInput input,
    JsonLdInput frame,
    optional JsonLdOptions options = {});
};

typedef record<USVString, any> JsonLdRecord;

typedef (JsonLdRecord or sequence<JsonLdRecord> or USVString or RemoteDocument) JsonLdInput;

dictionary JsonLdFramingError {
  JsonLdFramingErrorCode code;
  USVString? message = null;
};
enum JsonLdFramingErrorCode {
  "invalid frame",
  "invalid @embed value"
};

dictionary JsonLdOptions {
  (JsonLdEmbed or boolean)  embed         = "@once";
  boolean                   explicit      = false;
  boolean                   omitDefault   = false;
  boolean                   omitGraph;
  boolean                   requireAll    = false;
  boolean                   frameDefault  = false;
  boolean                   ordered       = false;
};

enum JsonLdEmbed {
  "@always",
  "@once",
  "@never"
};

C. 열린 이슈

이 섹션은 비규범입니다.

다음은 발행 당시 열려 있던 이슈 목록입니다.

Issue 29: 클래스 범위 프레이밍 허용 defer-future-versionspec:enhancement

클래스 범위 프레이밍을 허용합니다.

Issue 38: 같은 프레임 문서 안의 여러 프레임? defer-future-versionspec:enhancementspec:substantive

같은 프레임 문서 안의 여러 프레임?

Issue 73: 관계 재프레이밍 defer-future-version

관계 재프레이밍.

D. 2012년 8월 30일 1.0 초안 이후의 변경 사항

이 섹션은 비규범입니다.

E. JSON-LD 커뮤니티 그룹 최종 보고서 이후의 변경 사항

이 섹션은 비규범입니다.

F. 2019년 12월 12일 후보 릴리스 이후의 변경 사항

이 섹션은 비규범입니다.

G. 2020년 5월 7일 제안 권고안 릴리스 이후의 변경 사항

이 섹션은 비규범입니다.

H. 감사의 말

이 섹션은 비규범입니다.

편집자들은 이 명세의 작성과 편집에 중요한 기여를 한 다음 개인들에게 특별히 감사를 표합니다:

또한, 발행 당시 다음 사람들이 워킹 그룹의 구성원이었습니다:

메일링 리스트와 주간 원격 회의를 통해 많은 기술적 이슈를 처리한 JSON-LD 커뮤니티 그룹 참가자들에게도 큰 감사를 표합니다: Chris Webber, David Wood, Drummond Reed, Eleanor Joslin, Fabien Gandon, Herm Fisher, Jamie Pitts, Kim Hamilton Duffy, Niklas Lindström, Paolo Ciccarese, Paul Frazze, Paul Warren, Reto Gmür, Rob Trainer, Ted Thibodeau Jr., and Victor Charpenay.

I. 참고 문헌

I.1 규범 참고 문헌

[BCP47]
Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
[ECMASCRIPT]
ECMAScript Language Specification. Ecma International. URL: https://tc39.es/ecma262/
[INFRA]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[JSON-LD10]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Marcus Langhaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/2014/REC-json-ld-20140116/
[JSON-LD11]
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 7 May 2020. W3C Proposed Recommendation. URL: https://www.w3.org/TR/json-ld11/
[JSON-LD11-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg; Dave Longley; Pierre-Antoine Champin. W3C. 7 May 2020. W3C Proposed Recommendation. URL: https://www.w3.org/TR/json-ld11-api/
[LINKED-DATA]
Linked Data Design Issues. Tim Berners-Lee. W3C. 27 July 2006. W3C-Internal Document. URL: https://www.w3.org/DesignIssues/LinkedData.html
[promises-guide]
Writing Promise-Using Specifications. Domenic Denicola. W3C. 9 November 2018. TAG Finding. URL: https://www.w3.org/2001/tag/doc/promises-guide
[RDF-SCHEMA]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[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/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174
[RFC8259]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. December 2017. Internet Standard. URL: https://tools.ietf.org/html/rfc8259
[WEBIDL]
Web IDL. Boris Zbarsky. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/

I.2 정보 참고 문헌

[JSON-LD10-FRAMING]
JSON-LD Framing 1.0. Manu Sporny; Gregg Kellogg; David Longley; Marcus Langhaler. W3C. 30 August 2012. Unofficial Draft. URL: https://json-ld.org/spec/ED/json-ld-framing/20120830/