JSON-LD 1.1

1.1 문서 읽는 방법

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

이 문서는 JSON에서 Linked Data를 직렬화하는 방법에 대한 상세 명세입니다. 이 문서는 주로 다음과 같은 독자를 대상으로 합니다:

• JSON을 사용할 수 있는 다양한 프로그래밍 언어에서 Linked Data를 인코딩하려는 소프트웨어 개발자
• 기존 JSON을 JSON-LD로 변환하려는 소프트웨어 개발자
• JSON-LD의 설계 결정과 언어 문법을 이해하려는 소프트웨어 개발자
• JSON-LD 프로세서와 API를 구현하려는 소프트웨어 개발자
• JSON 구문으로 Linked Data, RDF graph, 또는 RDF Dataset을 생성하거나 소비하려는 소프트웨어 개발자

동반 문서인 JSON-LD 1.1 Processing Algorithms and API 명세서 [JSON-LD11-API]는 일반적인 JSON-LD 작업을 위한 표준 라이브러리 인터페이스를 제공하여 상위 수준에서 JSON-LD를 다루는 방법을 규정합니다.

이 명세의 기본을 이해하려면 먼저 JSON을 숙지해야 합니다. JSON은 [RFC8259]에 자세히 설명되어 있습니다.

이 문서는 하이퍼링크을 논의할 때 주로 IRI (Internationalized Resource Indicator) 용어를 사용합니다. 많은 웹 개발자는 URL 용어에 더 익숙합니다. 이 문서는 드물게 URI 용어도 사용합니다. 이러한 용어들은 기술 커뮤니티에서 종종 혼용되지만 서로 중요한 차이가 있으므로 명세서는 가능한 한 올바른 용어를 사용하려 노력합니다.

이 문서는 JSON-LD 1.0 이후의 변경사항을 강조할 수 있습니다. 변경사항을 보려면 을 선택하세요.

1.2 기여하기

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

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

• 기술적 논의는 일반적으로 작업 그룹 메일링 리스트에서 이루어집니다: public-json-ld-wg@w3.org
• 작업 그룹은 실시간 논의를 위해 #json-ld IRC 채널을 사용합니다. irc.w3.org에서 접속할 수 있습니다.
• #json-ld IRC 채널은 irc.freenode.net에서도 실시간 논의를 위해 사용할 수 있습니다.

1.3 타이포그래피 규약

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

Examples are in light khaki boxes, with khaki left border,
and with a numbered "Example" header in khaki.
Examples are always informative. The content of the example is in monospace font and may be syntax colored.

Examples may have tabbed navigation buttons
to show the results of transforming an example into other representations.

1.4 용어 정의

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

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

1.5 설계 목표 및 근거

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

JSON-LD는 다음과 같은 설계 목표를 만족합니다:

단순성

기본 형태로 JSON-LD를 사용하기 위해 추가적인 프로세서나 소프트웨어 라이브러리가 필요하지 않습니다. 언어는 개발자에게 매우 쉬운 학습 곡선을 제공합니다. Linked Data에 관심이 없는 개발자는 JSON을 이해하고 @context 속성을 포함하되 무시하면 JSON-LD의 기본 기능을 사용할 수 있습니다.

호환성

JSON-LD 문서는 항상 유효한 JSON 문서입니다. 이는 표준 JSON 라이브러리들이 JSON-LD 문서와 원활하게 작동함을 보장합니다.

표현력

이 문법은 라벨이 붙은 방향성 그래프를 직렬화합니다. 이는 거의 모든 현실 세계의 데이터 모델을 표현할 수 있음을 보장합니다.

간결성

JSON-LD 문법은 매우 간결하고 사람이 읽기 쉬우며 개발자의 노력을 최소화합니다.

대부분의 경우 편집 불필요

JSON-LD는 기존 JSON 기반 시스템에서 부드럽고 단순한 전환을 보장합니다. 많은 경우 JSON 문서에 대한 편집 없이 HTTP 응답에 한 줄을 추가하는 것만으로 충분합니다 (참조: § 6.1 Interpreting JSON as JSON-LD). 이는 이미 널리 배포된 JSON 기반 인프라를 보유한 조직이 현재 서비스에 큰 지장을 주지 않고 JSON-LD의 기능을 사용할 수 있게 합니다. 그러나 JSON을 그래프 표현으로 매핑하는 작업이 복잡할 수 있는 경우도 있습니다. 이러한 경우에는 언어의 복잡성을 크게 늘리지 않기 위해 일부 사용 사례를 지원하지 않기로 했습니다. Zero Edits는 설계 목표이지만 항상 가능하지는 않으며 언어의 단순성을 우선시합니다.

RDF로서의 사용 가능성

JSON-LD는 개발자가 RDF를 이해하지 않고도 관습적인 JSON으로 사용할 수 있습니다. 또한 RDF로서도 사용 가능하므로 RDF 도구와 함께 JSON-LD를 사용하려는 사람들은 다른 RDF 구문처럼 사용할 수 있음을 알게 될 것입니다. JSON-LD가 RDF와 어떻게 관련되는지에 대한 전체 세부 사항은 § 10. RDF와의 관계에 있습니다.

1.6 데이터 모델 개요

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

일반적으로 JSON-LD 문서가 설명하는 데이터 모델은 라벨이 붙은 방향성 있는 그래프입니다. 그래프는 방향성 있는 호로 연결된 노드를 포함합니다. 노드는 resource로서 속성을 가지거나, 해당 속성들의 데이터 값들(문자열, 숫자, typed values(예: 날짜 및 시간), IRIs 등)일 수 있습니다.

방향성 그래프 내에서 노드는 resource이며 이름이 없을 수 있습니다(즉 IRI로 식별되지 않음). 이를 blank nodes라 하며 blank node identifier로 식별될 수 있습니다. 이러한 식별자는 JSON과 같은 트리 구조를 사용하여 완전히 연결된 그래프를 표현하는 데 필요할 수 있지만 본질적 의미는 없습니다. 문자열과 숫자 같은 리터럴 값도 resource로 간주되며, JSON-LD는 서로 다른 종류의 resource를 구분하기 위해 node objects와 value objects를 구별합니다.

이 단순한 데이터 모델은 매우 유연하고 강력하여 거의 모든 종류의 데이터를 모델링할 수 있습니다. 데이터 모델에 대한 자세한 설명은 § 8. Data Model을 참조하십시오.

Linked Data 기술에 익숙한 개발자라면 이 데이터 모델이 RDF 데이터 모델임을 알 것입니다. JSON-LD와 RDF의 관계를 더 깊이 이해하려면 § 10. RDF와의 관계를 참조하십시오.

표면적으로 JSON-LD 문서는 단순히 JSON입니다(자세한 내용은 RFC8259 참조). 핵심 데이터 구조를 설명하기 위해 이는 배열, 맵(파싱된 JSON 객체의 버전), 문자열, 숫자, 불리언, null로 제한됩니다. 이들은 JSON-LD 내부 표현이라 불리며, 표면 구문이 JSON 이외의 형식일 경우에도 동일한 알고리즘으로 조작할 수 있게 합니다..

1.7 구문 토큰 및 키워드

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

JSON-LD는 언어의 핵심 부분인 여러 구문 토큰과 키워드를 규정합니다. 키워드에 대한 규범적 설명은 § 9.16 Keywords에 있습니다.

:

compact IRIs를 사용하는 JSON 키와 값의 구분자입니다.

@base

상대 IRI 참조를 문서에 대해 해석할 때 기준이 되는 base IRI를 설정하는 데 사용됩니다. 이 키워드는 Base IRI 섹션에서 설명됩니다.

@container

@container는 term의 기본 컨테이너 유형을 설정하는 데 사용됩니다. 이 키워드는 다음 섹션들에서 설명됩니다:

• § 4.3 Value Ordering,
• § 4.6.1 Data Indexing,
• § 4.6.2 Language Indexing,
• § 4.6.3 Node Identifier Indexing,
• § 4.6.4 Node Type Indexing
• § 4.9 Named Graphs,
• § 4.9.3 Named Graph Indexing, and
• § 4.9.2 Named Graph Data Indexing

@context

문서 전체에서 사용되는 약식 이름(term)을 정의하는 데 사용됩니다. @context 키워드는 The Context 섹션에서 자세히 설명됩니다.

@direction

@direction은 문자열에 직접 방향이 지정되지 않았을 때의 기본 방향을 설정하는 데 사용됩니다. 이 키워드는 String Internationalization 섹션에서 설명됩니다.

@graph

그래프를 표현하는 데 사용됩니다. 이 키워드는 Named Graphs 섹션에서 설명됩니다.

@id

문서에서 기술되는 node objects를 IRI 또는 blank node identifiers로 고유하게 식별하는 데 사용됩니다. 이 키워드는 Node Identifiers 섹션에서 설명됩니다. node reference는 @id 속성만 포함하는 node object입니다.

@import

context 정의에서 외부 context를 로드하여 해당 context 정의가 병합되도록 하는 데 사용됩니다. 이는 JSON-LD 1.0 context에 JSON-LD 1.1 기능을 추가할 때 유용할 수 있습니다.

@included

최상위 node object에서 포함 블록(included block)을 정의하는 데 사용되며, 다른 node objects를 포함하는 데 사용됩니다.

@index

컨테이너가 정보를 색인화하는 데 사용되며 처리가 JSON 데이터 구조 내부로 더 깊게 계속되어야 함을 지정합니다. 이 키워드는 Data Indexing 섹션에서 설명됩니다.

@json

JSON literal의 @type 값으로 사용됩니다. JSON Literals 섹션을 참조하십시오.

@language

특정 문자열 값의 언어 또는 JSON-LD 문서의 기본 언어를 지정하는 데 사용됩니다. String Internationalization 섹션을 참조하십시오.

@list

순서 있는 데이터 집합을 표현하는 데 사용됩니다. Lists 섹션을 참조하십시오.

@nest

node object의 프로퍼티를 그룹화하지만 그래프의 엣드는 아닌 프로퍼티를 정의하는 데 사용됩니다.

@none

index map, id map, language map, type map 등에서 색인 값으로 사용되며, 색인된 노드가 색인 대상 특성을 가지고 있지 않을 때 사용됩니다.

@prefix

값이 true인 경우, 이 term은 compact IRI를 구성하는 데 사용할 수 있습니다. 값이 false이면 term이 compact IRI 구성에 사용되는 것을 방지합니다. 또한 compact IRI를 확장할 때 term이 고려될지 여부를 결정합니다.

@propagate

context 정의에서 해당 context의 범위를 변경하는 데 사용됩니다. 기본값은 true로, context는 node objects를 가로질러 전파됩니다(타입-스코프 컨텍스트는 기본적으로 false). 이를 false로 설정하면 새로운 node object로 들어갈 때 해당 context 내에서 생성된 term 정의가 제거됩니다.

@protected

context의 term definitions가 다른 context에 의해 재정의되는 것을 방지하는 데 사용됩니다. Protected Term Definitions 섹션을 참조하십시오.

@reverse

역방향 프로퍼티를 표현하는 데 사용됩니다. Reverse Properties 섹션을 참조하십시오.

@set

값을 항상 배열로 표현하고 순서가 없는 집합을 표현하는 데 사용됩니다. Sets 섹션을 참조하십시오.

@type

노드의 타입이나 typed value의 데이터타입을 설정하는 데 사용됩니다. Specifying the Type 및 Typed Values 섹션을 참조하십시오.

참고

@type를 node objects와 value objects 모두의 타입을 정의하는 데 사용하는 것은 데이터의 타입 지정을 위한 기본 필요를 충족합니다. 전문가들은 @type의 중첩 사용에 대해 우려할 수 있지만, 웹 개발자들이 이 기능을 수년간 사용해 온 결과 typed literal 값을 표현하는 데 @type가 남용된 사례는 드뭅니다.

@value

그래프에서 특정 프로퍼티와 연관된 데이터를 지정하는 데 사용됩니다. String Internationalization 및 Typed Values 섹션을 참조하십시오.

@version

context 정의에서 processing mode를 설정하는 데 사용됩니다. 이 명세서에 설명된 JSON-LD 1.1의 새로운 기능들은 @version이 json-ld-1.0으로 설정되었을 때 사용 불가능합니다.

참고

context 정의 내에서 @version은 숫자 값 1.1을 사용합니다(문자열 값이 아닌 숫자 값을 사용). JSON-LD 1.0 프로세서는 문자열 값을 허용할 수 있지만 숫자 값을 거부할 수 있습니다.

참고

@version 값으로 1.1을 사용하는 것은 JSON-LD 1.0 프로세서가 처리를 중단하게 만들기 위한 의도입니다. 비록 JSON-LD 1.1과 관련이 있음이 분명하지만, 이것은 Semantic Versioning 요구사항을 따르지는 않습니다.

@vocab

공통 접두사를 사용하여 @type의 속성과 값을 확장하는 데 사용됩니다. Default Vocabulary 섹션을 참조하십시오.

JSON-LD의 모든 키, 키워드 및 값은 대소문자를 구분합니다.

3.1 컨텍스트

이 절은 비규범적입니다.

두 사람이 서로 소통할 때 대화는 일반적으로 공유된 환경, 즉 "대화의 컨텍스트"에서 이루어집니다. 이 공유된 컨텍스트는 상호 친구의 이름과 같은 약식 용어를 사용하여 더 빠르게 소통하되 정확성을 잃지 않도록 합니다. JSON-LD의 컨텍스트도 같은 방식으로 작동합니다. 컨텍스트는 두 애플리케이션이 약식 용어를 사용하여 서로 효율적으로 소통하되 정확성을 잃지 않도록 해 줍니다.

간단히 말해, 컨텍스트는 용어를 IRI로 매핑하는 데 사용됩니다. 용어는 대소문자를 구분하며, 예약된 JSON-LD 키워드가 아닌 대부분의 유효한 문자열은 용어로 사용할 수 있습니다. 예외는 빈 문자열 ""와 키워드 형태(즉 "@"로 시작하고 하나 이상의 문자로만 이루어진 문자열)를 가지는 문자열이며, 이러한 문자열은 용어로 사용할 수 없습니다. 또한 ":"를 포함하는 등 IRI 형태의 문자열은 용어로 사용해서는 안 됩니다.

앞 절의 샘플 문서에 대한 컨텍스트는 대략 다음과 같습니다:

{
  "@context": {
    "name": "http://schema.org/name",
    ↑ 이는 'name'이 'http://schema.org/name'의 약식 표기임을 의미합니다
    "image": {
      "@id": "http://schema.org/image",
      ↑ 이는 'image'가 'http://schema.org/image'의 약식 표기임을 의미합니다
      "@type": "@id"
      ↑ 이는 'image'와 연관된 문자열 값이 IRI 식별자로 해석되어야 함을 의미합니다
    },
    "homepage": {
      "@id": "http://schema.org/url",
      ↑ 이는 'homepage'가 'http://schema.org/url'의 약식 표기임을 의미합니다
      "@type": "@id"
      ↑ 이는 'homepage'와 연관된 문자열 값이 IRI 식별자로 해석되어야 함을 의미합니다 
    }
  }
}

위의 컨텍스트가 보여주듯, 용어 정의의 값은 단순한 문자열로서 용어를 IRI로 매핑할 수도 있고, map일 수도 있습니다.

컨텍스트는 @context 키를 가진 entry로 도입되며, node object나 value object 내에 나타날 수 있습니다.

만약 용어 키를 가진 entry의 값이 map이라면, 그 map은 expanded term definition이라 불립니다. 위 예제는 image와 homepage의 값이 문자열일 경우 이를 IRI로 해석해야 함을 지정합니다. Expanded term definitions는 용어를 index maps에 사용하거나 배열 값을 sets 또는 lists로 해석할지 지정할 수 있게 합니다. 확장된 용어 정의는 키로 IRI 또는 compact IRI를 사용할 수 있으며, 이는 타입 또는 언어 정보를 IRI나 compact IRI에 연관짓는 데 주로 사용됩니다.

컨텍스트는 문서 내에 직접 포함된 형태(임베디드 컨텍스트)로 나타나거나 URL을 통해 참조될 수 있습니다. 이전 예제의 컨텍스트 문서가 https://json-ld.org/contexts/person.jsonld에서 가져올 수 있다고 가정하면, 단 한 줄을 추가하여 JSON-LD 문서를 훨씬 간결하게 표현할 수 있습니다:

참조된 컨텍스트는 용어들이 Schema.org 어휘 내에서 어떻게 IRI로 매핑되는지뿐만 아니라 homepage와 image에 연관된 문자열 값들이 "@type": "@id"로 IRI로 해석될 수 있음을 지정합니다(자세한 내용은 § 3.2 IRIs 참조). 이 정보는 개발자들이 사이트별로 데이터 상호운용 방식을 합의하지 않아도 서로의 데이터를 재사용할 수 있게 해 줍니다. 외부 JSON-LD 컨텍스트 문서는 @context 키 밖에 문서화나 용어에 관한 추가 정보를 포함할 수 있습니다. @context 값 밖에 포함된 정보는 외부 JSON-LD 컨텍스트 문서로 사용될 때 무시됩니다.

원격 컨텍스트는 상대 URL로도 참조될 수 있으며, 이는 참조를 포함한 문서의 위치를 기준으로 해석됩니다. 예를 들어 문서가 http://example.org/document.jsonld에 있고 context.jsonld로 상대 참조가 있다면 참조된 컨텍스트 문서는 http://example.org/context.jsonld에 위치합니다.

{
  "@context": "context.jsonld",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "image": "http://manu.sporny.org/images/manu.png"
}

JSON 문서는 컨텍스트를 HTTP Link Header로 참조함으로써 수정 없이 JSON-LD로 해석될 수 있습니다(자세한 내용은 § 6.1 Interpreting JSON as JSON-LD 참조). 또한 JSON-LD 1.1 API를 사용하여 사용자 정의 컨텍스트를 적용할 수도 있습니다 [JSON-LD11-API].

JSON-LD 문서에서는 컨텍스트를 인라인으로 지정할 수도 있습니다. 이렇게 하면 웹 연결이 없어도 문서를 처리할 수 있다는 장점이 있습니다. 궁극적으로 이는 모델링 결정이며 사용 사례에 따라 다른 처리가 필요할 수 있습니다. 원격 컨텍스트 사용에 관한 논의는 보안 고려사항을 § C. IANA Considerations에서 확인하십시오.

이 절은 JSON-LD 컨텍스트의 가장 기본적인 기능만 다룹니다. 컨텍스트는 indexed values, 정렬된 값, 및 중첩된 속성과 같은 더 복잡한 JSON 데이터 구조를 해석하는 데에도 사용할 수 있습니다. 컨텍스트와 관련된 고급 기능은 § 4. Advanced Concepts에서 다룹니다.

3.2 IRI

이 절은 비규범적입니다.

IRIs는 Linked Data에서 근본적입니다. 대부분의 노드와 속성을 식별하는 방식이기 때문입니다. JSON-LD에서는 IRI가 IRI 참조로 표현될 수 있습니다. IRI는 [RFC3987]에 따라 스킴과 경로, 선택적 쿼리 및 프래그먼트 세그먼트를 포함하는 것으로 정의됩니다. 상대 IRI 참조는 다른 IRI에 상대적인 참조입니다. JSON-LD에서는 아래에 명시된 예외를 제외하고 모든 상대 IRI 참조는 base IRI를 기준으로 해석됩니다.

문자열은 IRI로 해석될 수 있으며, 특히 키가 @id인 map entry의 값일 때 그렇습니다:

{
  ...
  "homepage": { "@id": "http://example.com/" }
  ...
}

IRI로 해석되는 값들은 상대 IRI 참조로도 표현될 수 있습니다. 예를 들어 다음 문서가 http://example.com/about/에 위치한다고 가정하면 상대 참조 ../는 http://example.com/로 확장됩니다(상대 IRI 참조를 어디에 사용할 수 있는지에 대한 자세한 내용은 § 9. JSON-LD Grammar를 참조하십시오).

{
  ...
  "homepage": { "@id": "../" }
  ...
}

IRI는 키 위치에 직접 표현될 수도 있습니다:

{
  ...
  "http://schema.org/name": "Manu Sporny",
  ...
}

위 예제에서 키 http://schema.org/name는 IRI로 해석됩니다.

용어가 active context 내에 정의된 용어와 일치하면 용어→IRI 확장이 발생합니다:

위 예제에서처럼 JSON 키가 IRI로 확장되지 않으면(예: 위의 status) Linked Data가 아니므로 처리 시 무시됩니다.

만약 특정 용어 또는 속성 IRI에 대해 형 변환(coercion) 규칙이 @context에 지정되어 있다면, 문자열 값으로부터 IRI가 생성됩니다:

위 예제에서 값 http://manu.sporny.org/는 JSON 문자열로 표현되어 있으므로, 형 변환 규칙에 따라 처리 시 IRI로 변환됩니다. 이 기능에 대한 자세한 내용은 § 4.2.3 Type Coercion를 참조하십시오.

요약하면, JSON-LD에서 IRI는 여러 가지 방식으로 표현될 수 있습니다:

1. Map entries의 키가 용어와 매치되어 active context에 정의된 경우 해당 키는 IRI로 확장됩니다(이는 context definition 밖에서만 적용됩니다).
2. @id 또는 @type을 사용하여 지정된 문자열 값에 대해 IRI가 생성됩니다.
3. @type이 @id 또는 @vocab 값으로 설정된 형 변환 규칙을 포함하는 경우, 해당 키의 문자열 값에 대해 IRI가 생성됩니다.

이 절은 JSON-LD에서 IRI와 관련된 가장 기본적인 기능만 다룹니다. IRI와 관련된 고급 기능은 § 4. Advanced Concepts에서 다룹니다.

3.3 노드 식별자

이 절은 비규범적입니다.

RDF 그래프에서 노드를 외부에서 참조하려면 노드에 식별자가 있어야 합니다. IRI는 Linked Data의 근본 개념이며, 노드를 진정으로 연결하려면 식별자를 dereference했을 때 그 노드의 표현을 반환해야 합니다. 이를 통해 애플리케이션은 해당 노드에 대한 추가 정보를 검색할 수 있습니다.

JSON-LD에서 노드는 @id 키워드를 사용하여 식별됩니다:

위 예제는 node object가 http://me.markus-lanthaler.com/라는 IRI로 식별되는 것을 보여줍니다.

이 절은 JSON-LD에서 노드 식별자와 관련된 가장 기본적인 기능만 다룹니다. 노드 식별자와 관련된 고급 기능은 § 4. Advanced Concepts에서 다룹니다.

3.5 타입 지정

이 절은 비규범적입니다.

Linked Data에서는 그래프 노드의 타입을 지정하는 것이 일반적이며, 많은 경우 특정 node object 내에서 사용되는 속성들 또는 노드가 값인 속성에 근거해 타입을 추론할 수 있습니다. 예를 들어 schema.org 어휘에서 givenName 속성은 Person과 연관되어 있으므로 node object에 givenName 속성이 있다면 그 노드의 타입은 Person일 것이라고 추론할 수 있습니다. @type으로 이를 명시하면 연관성을 분명히 할 수 있습니다.

특정 노드의 타입은 @type 키워드를 사용하여 지정할 수 있습니다. Linked Data에서 타입은 IRI로 고유하게 식별됩니다.

배열을 사용하여 노드에 여러 타입을 할당할 수 있습니다:

@type 키의 값은 active context에 정의된 용어일 수도 있습니다:

노드의 타입을 설정하는 것 외에도, @type은 값의 타입을 설정하여 타입된 값(typed value)을 만들기 위해 사용할 수 있습니다. 이 용도의 @type은 node object의 타입을 정의할 때와 유사하지만, value objects는 단일 타입만 가질 수 있도록 제한됩니다. typed values에 대한 자세한 논의는 § 4.2.1 Typed Values를 참조하십시오.

타입된 값은 확장된 용어 정의에서 @type을 지정하여 암묵적으로 정의될 수도 있습니다. 이 내용은 § 4.2.3 Type Coercion에서 더 자세히 다룹니다.

4.1 고급 컨텍스트 사용

이 절은 비규범적입니다.

섹션 § 3.1 The Context에서는 JSON-LD가 작동하는 기본 사항을 소개했습니다. 이 절에서는 컨텍스트의 기본 원칙을 확장하고 JSON-LD를 사용하여 보다 고급 사용 사례를 달성하는 방법을 보여줍니다.

일반적으로 컨텍스트는 map이 정의되는 모든 곳에서 사용할 수 있습니다. 직접 다른 컨텍스트 정의의 자식으로(확장된 용어 정의의 일부로 나타나는 경우를 제외하고) 컨텍스트를 표현할 수 없는 경우만 예외입니다. 예를 들어, JSON-LD 문서는 하나 이상의 배열 형태일 수 있으며, 각 최상위 노드 객체에서 컨텍스트 정의를 사용할 수 있습니다:

외부 배열은 확장된 문서 형태 및 플래튼된 문서 형태에서 문서의 표준이며, 노드들이 서로 참조하지 않는 연결 끊긴 그래프를 기술할 때 필요할 수 있습니다. 이러한 경우, 최상위 map에 @graph 속성을 사용하는 것이 @context의 반복을 줄이는 데 유용할 수 있습니다. 자세한 내용은 § 4.5 임베딩을 참조하십시오.

중복된 컨텍스트 용어는 가장 최근에 정의된 항목이 우선하는 방식으로 재정의됩니다.

위 예제에서 details 구조 안에 있는 더 깊게 중첩된 임베디드 컨텍스트는 name 용어를 재정의합니다. 이는 대부분의 경우 좋은 작성 관행은 아니며, 대개 이전 컨텍스트의 특정 map 구조에 의존하는 레거시 애플리케이션을 다룰 때 사용됩니다. 용어가 컨텍스트 내에서 재정의되면 이전 정의와 관련된 모든 규칙이 제거됩니다. 용어가 null로 재정의되면, 해당 용어는 활성 컨텍스트에 정의된 용어 목록에서 효과적으로 제거됩니다.

여러 컨텍스트는 배열을 사용해 결합할 수 있으며, 이는 순서대로 처리됩니다. 특정 map 내에 정의된 컨텍스트 집합을 로컬 컨텍스트(local contexts)라고 합니다. 활성 컨텍스트는 문서 내 특정 지점에서 유효한 로컬 컨텍스트들의 누적을 나타냅니다. 로컬 컨텍스트를 null로 설정하면, 이전 컨텍스트에 정의된 용어 정의, 기본 언어 등 없이 활성 컨텍스트를 빈 컨텍스트로 효과적으로 재설정합니다. 다음 예제는 외부 컨텍스트를 지정한 다음 그 위에 임베디드 컨텍스트를 겹쳐서 사용하는 예입니다:

JSON-LD 1.1에는 스코프된 컨텍스트와 임포트된 컨텍스트를 포함하여 컨텍스트를 도입하는 다른 메커니즘과 용어 정의를 보호하는 새로운 방법들이 있습니다. 따라서 마지막으로 정의된 인라인 컨텍스트가 반드시 용어의 범위를 결정하는 것은 아닐 수 있습니다. 자세한 내용은 § 4.1.8 스코프된 컨텍스트, § 4.1.9 컨텍스트 전파, § 4.1.10 임포트된 컨텍스트, 및 § 4.1.11 보호된 용어 정의를 참조하십시오.

{
  "@context": {
    "@version": 1.1,
    ...
  },
  ...
}

{
  "@context": {
    "label": "http://www.w3.org/2000/01/rdf-schema#label"
  },
  "@id": "",
  "label": "Just a simple document"
}

{
  "@context": {
    "@version": 1.1,
    "@base": "http://example/document",
    "@vocab": "#"
  },
  "@id": "http://example.org/places#BrewEats",
  "@type": "Restaurant",
  "name": "Brew Eats"
  ...
}

[{
  "http://example.com/vocab/property": [{"@value": "property"}],
  "http://example.com/vocab/propertyOne": [{"@value": "propertyOne"}]
}]

{
  "@context": {
    "vocab": "http://example.com/vocab/",
    "property": "http://example.com/vocab/property"
  }
}

{
  "@context": {
    "@version": 1.1,
    "vocab": "http://example.com/vocab/",
    "property": {
      "@id": "http://example.com/vocab/property",
      "@prefix": true
    }
  }
}

{
  "@context": {
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "http://xmlns.com/foaf/0.1/name",
    "age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "age": {
      "@id": "foaf:age",
      "@type": "xsd:integer"
    },
    "homepage": {
      "@id": "foaf:homepage",
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "foaf:homepage": {
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "foaf:homepage": {
     "@id": "http://schema.org/url",
     "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "http://xmlns.com/foaf/0.1/homepage": {
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "term1": "term2:foo",
    "term2": "term1:bar"
  },
  ...
}

{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.com/vocab/",
    "property": {
      "@id": "http://example.com/vocab/property",
      "@context": {
        "term1": "http://example.com/vocab/term1"
         ↑ "property"에 대한 스코프된 컨텍스트가 term1을 정의합니다
      }
    },
    "Type1": {
      "@id": "http://example.com/vocab/Type1",
      "@context": {
        "term3": "http://example.com/vocab/term3"
         ↑ "Type1"에 대한 스코프된 컨텍스트가 term3을 정의합니다
      }
    },
    "Type2": {
      "@id": "http://example.com/vocab/Type2",
      "@context": {
        "term4": "http://example.com/vocab/term4"
         ↑ "Type2"에 대한 스코프된 컨텍스트가 term4를 정의합니다
      }
    }
  },
  "property": {
    "@context": {
      "term2": "http://example.com/vocab/term2"
         ↑ 임베디드 컨텍스트가 term2를 정의합니다
    },
    "@type": ["Type2", "Type1"],
    "term1": "a",
    "term2": "b",
    "term3": "c",
    "term4": "d"
  }
}

{
  "@context": {
    "@vocab": "http://example.com/vocab/",
    "property": "http://example.com/vocab/property",
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2"
  },
  "property": {
    "@context": [{
        "term1": "http://example.com/vocab/term1"
         ↑ 이전에 "property"에 대해 스코프된 컨텍스트가 term1을 정의했습니다
      }, {
        "term2": "http://example.com/vocab/term2"
         ↑ 임베디드 컨텍스트가 term2를 정의합니다
      }, {
        "term3": "http://example.com/vocab/term3"
         ↑ 이전에 "Type1"에 대해 스코프된 컨텍스트가 term3을 정의했습니다
      }, {
      "term4": "http://example.com/vocab/term4"
         ↑ 이전에 "Type2"에 대해 스코프된 컨텍스트가 term4를 정의했습니다
    }],
    "@type": ["Type2", "Type1"],
    "term1": "a",
    "term2": "b",
    "term3": "c",
    "term4": "d"
  }
}

{
  "@context": {
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2",
    "term1": "http://example.com/vocab#term1",
    "term2": "http://example.com/vocab#term2",
    ...
  }
}

{
  "@context": {
    "@version": 1.1,
    "MyType": {
      "@id": "http://example.com/vocab#MyType",
      "@context": {
        "@version": 1.1,
        "@import": "https://json-ld.org/contexts/remote-context.jsonld",
        "@propagate": true
      }
    }
  }
}

{
  "@context": {
    "@version": 1.1,
    "MyType": {
      "@id": "http://example.com/vocab#MyType",
      "@context": {
        "@version": 1.1,
        "Type1": "http://example.com/vocab/Type1",
        "Type2": "http://example.com/vocab/Type2",
        "term1": "http://example.com/vocab#term1",
        "term2": "http://example.com/vocab#term2",
        ...
        "@propagate": true
      }
    }
  }
}

{
  "@context": {
    "@version": 1.1,
    "@import": "https://json-ld.org/contexts/remote-context.jsonld",
    "@vocab": "http://example.org/vocab#",
     ↑ 이는 처리 전에 이전의 @vocab 정의를 대체합니다
    "term1": {
      "@id": "http://example.org/vocab#term1",
      "@type": "http://www.w3.org/2001/XMLSchema#integer"
    }
     ↑ 이는 처리 전에 이전 term1 정의를 대체합니다
  }
}

{
  "@context": {
    "@version": 1.1,
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2",
    "term1": {
      "@id": "http://example.org/vocab#term1",
      "@type": "http://www.w3.org/2001/XMLSchema#integer"
    },
     ↑ 주의: term1이 처리 전에 대체되었습니다
    "term2": "http://example.com/vocab#term2",
    ...,
    "@vocab": "http://example.org/vocab#"
  }
}

{
  "@context": [
    {
      "@version": 1.1,
      "Person": "http://xmlns.com/foaf/0.1/Person",
      "knows": "http://xmlns.com/foaf/0.1/knows",
      "name": {
        "@id": "http://xmlns.com/foaf/0.1/name",
        "@protected": true
      }
    },
    {
      – 이 시도는 오류를 일으키며 실패할 것입니다
      "name": "http://schema.org/name"
    }
  ],
  "@type": "Person",
  "name": "Manu Sporny",
  "knows": {
    "@context": [
      – 이 시도도 오류로 실패할 것입니다
      null,
      "http://schema.org/"
    ],
    "name": "Gregg Kellogg"
  }
}

4.2 값 설명

이 절은 비규범적입니다.

값은 문자열, 날짜, 시간 등과 같은 스칼라 값과 연관된 그래프의 리프 노드입니다. (strings, 날짜, 시간 등)

{
  ...
  "@id": "http://example.org/posts#TripToWestVirginia",
  "@type": "http://schema.org/BlogPosting",  ← 이것은 노드 타입입니다
  "http://purl.org/dc/terms/modified": {
    "@value": "2010-05-29T14:17:39+02:00",
    "@type": "http://www.w3.org/2001/XMLSchema#dateTime"  ← 이것은 값 타입입니다
  }
  ...
}

{
  "@context": {
    ...
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "@language": "ja",
    "details": {
      "@context": {
        "@language": null
      }
    }
  },
  "name": "花澄",
  "details": {"occupation": "Ninja"}
}

{
  "@context": {
    ...
    "ex": "http://example.com/vocab/",
    "@language": "ja",
    "name": { "@id": "ex:name", "@language": null },
    "occupation": { "@id": "ex:occupation" },
    "occupation_en": { "@id": "ex:occupation", "@language": "en" },
    "occupation_cs": { "@id": "ex:occupation", "@language": "cs" }
  },
  "name": "Yagyū Muneyoshi",
  "occupation": "忍者",
  "occupation_en": "Ninja",
  "occupation_cs": "Nindža",
  ...
}

{
  "@context": {
    ...
    "occupation": { "@id": "ex:occupation", "@container": "@language" }
  },
  "name": "Yagyū Muneyoshi",
  "occupation": {
    "ja": "忍者",
    "en": "Ninja",
    "cs": "Nindža"
  }
  ...
}

{
  "@context": {
    ...
    "@language": "ja"
  },
  "name": "花澄",
  "occupation": {
    "@value": "Scientist",
    "@language": "en"
  }
}

{
  "@context": {
    ...
    "@language": "ja"
  },
  "name": {
    "@value": "Frank"
  },
  "occupation": {
    "@value": "Ninja",
    "@language": "en"
  },
  "speciality": "手裏剣"
}

{
  "@context": {
    ...
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "@language": "ar-EG",
    "@direction": "rtl",
    "details": {
      "@context": {
        "@direction": null
      }
    }
  },
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "details": {"genre": "Technical Publication"}
}

{
  "@context": {
    ...
    "@version": 1.1,
    "@language": "ar-EG",
    "@direction": "rtl",
    "ex": "http://example.com/vocab/",
    "publisher": { "@id": "ex:publisher", "@direction": null },
    "title": { "@id": "ex:title" },
    "title_en": { "@id": "ex:title", "@language": "en", "@direction": "ltr" }
  },
  "publisher": "مكتبة",
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "title_en": "HTML and CSS: Design and Build Websites",
  ...
}

{
  "@context": {
    ...
    "@language": "ar-EG",
    "@direction": "rtl"
  },
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "author": {
    "@value": "Jon Duckett",
    "@language": "en",
    "@direction": null
  }
}

4.3 값 순서

이 절은 비규범적입니다.

JSON-LD 작성자는 배열을 사용하여 여러 값을 간단하게 표현할 수 있습니다. 그래프는 노드 간의 링크에 대한 순서를 설명하지 않기 때문에, JSON-LD의 배열은 기본적으로 포함된 요소들의 순서를 전달하지 않습니다. 이는 기본적으로 정렬된 일반 JSON 배열과는 정반대입니다. 예를 들어, 다음과 같은 간단한 문서를 고려하십시오:

여러 값은 확장된 형식을 사용하여 표현할 수도 있습니다:

속성의 여러 값들은 일반적으로 동일한 타입이지만, JSON-LD는 이에 대해 제한을 두지 않으며 속성은 서로 다른 타입의 값을 가질 수 있습니다:

{
  "type": "Feature",
  "bbox": [-10.0, -10.0, 10.0, 10.0],
  "geometry": {
    "type": "Polygon",
    "coordinates": [
        [
            [-10.0, -10.0],
            [10.0, -10.0],
            [10.0, 10.0],
            [-10.0, -10.0]
        ]
    ]
  }
  //...
}

{
  "@context": {
    "@version": 1.1,
    "@type": {"@container": "@set"}
  },
  "@type": ["http:/example.org/type"]
}

4.5 임베딩

이 절은 비규범적입니다.

임베딩은 작성자가 노드 객체를 속성 값으로 사용할 수 있게 하는 JSON-LD 기능입니다. 이는 두 노드 사이에 부모-자식 관계를 만드는 데 흔히 사용되는 메커니즘입니다.

임베딩이 없으면 노드 객체들은 다른 노드 객체의 식별자를 참조하여 연결될 수 있습니다. 예를 들어:

이전 예제는 Manu와 Gregg 두 개의 노드 객체를 기술하며, knows 속성은 문자열 값을 식별자로 처리하도록 정의되어 있습니다. 임베딩을 사용하면 Gregg의 노드 객체를 knows 속성의 값으로 임베드할 수 있습니다:

위와 같은 노드 객체는 JSON-LD 문서의 모든 값 위치에서 사용될 수 있습니다.

그래프에서 노드에 식별자를 부여하는 것이 모범 사례로 간주되지만, 때로는 이것이 비현실적일 수 있습니다. 데이터 모델에서 명시적 식별자가 없는 노드는 blank node라고 하며, JSON-LD와 같은 직렬화에서 blank node identifier를 사용하여 표현할 수 있습니다. 이전 예제에서 상위 수준의 Manu 노드는 식별자가 없으며, 데이터 모델 내에서 그것을 기술하는 데 식별자가 필요하지 않습니다. 그러나 Gregg에서 Manu로의 knows 관계를 기술하려면 blank node identifier를 도입해야 합니다(여기서는 _:b0).

Blank node 식별자는 플래트닝 같은 알고리즘에 의해 자동으로 도입될 수 있지만, 작성자가 이러한 관계를 직접 기술하는 데에도 유용합니다.

4.6 인덱스된 값

이 절은 비규범적입니다.

때때로 여러 속성 값을 배열을 반복하여 찾는 것보다 더 직접적으로 접근해야 할 필요가 있습니다. JSON-LD는 중간 맵을 사용해 특정 인덱스를 연관된 값과 연결할 수 있는 인덱싱 메커니즘을 제공합니다.

데이터 인덱싱

§ 4.6.1 데이터 인덱싱에 설명된 바와 같이, 데이터 인덱싱은 임의의 키로 노드나 값을 참조할 수 있게 합니다.

언어 인덱싱

§ 4.6.2 언어 인덱싱에 설명된 바와 같이, 언어 인덱싱은 언어가 문자열을 참조하도록 허용하며, 해당 문자열과 연관된 언어로 해석되게 합니다.

노드 식별자 인덱싱

§ 4.6.3 노드 식별자 인덱싱에 설명된 바와 같이, 노드 식별자 인덱싱은 IRI가 노드를 참조하도록 허용하고, 해당 IRI를 그 노드의 식별자로 해석되게 합니다.

노드 타입 인덱싱

§ 4.6.4 노드 타입 인덱싱에 설명된 바와 같이, 노드 타입 인덱싱은 IRI가 노드를 참조하도록 허용하고, 해당 IRI를 그 노드의 타입으로 해석되게 합니다.

JSON-LD에서 인덱싱의 다른 사용에 대해서는 § 4.9 명명된 그래프를 참조하십시오.

4.8 역방향 속성

이 절은 비규범적입니다.

JSON-LD는 방향성 그래프를 직렬화합니다. 이것은 모든 속성이 한 노드에서 다른 노드나 값를 가리킨다는 것을 의미합니다. 그러나 경우에 따라 역방향으로 직렬화하는 것이 바람직할 수 있습니다. 예를 들어 한 사람과 그 자녀들이 문서에 기술되어야 하는 경우를 생각해 보십시오. 사용된 어휘에 children 속성이 없고 단지 parent 속성만 제공된다면, 각 자녀를 나타내는 노드는 다음 예와 같이 부모를 가리키는 속성으로 표현되어야 할 것입니다.

이러한 데이터를 표현하는 것은 JSON-LD의 @reverse 키워드를 사용하는 것이 훨씬 간단합니다:

또한 @reverse 키워드는 다음 예시에서 보이는 것처럼 확장된 용어 정의에서도 역방향 속성을 생성하는 데 사용할 수 있습니다:

4.9 명명된 그래프

이 절은 비규범적입니다.

때때로 단일 노드뿐만 아니라 그래프 자체에 대해 서술해야 할 때가 있습니다. 이는 @graph 키워드를 사용하여 여러 노드를 그룹화함으로써 수행할 수 있습니다. 개발자는 또한 다음 예제와 같이 @graph 키워드로 표현된 데이터를 @id 키워드와 짝지어 이름을 지정할 수 있습니다:

위 예제는 명명된 그래프를 IRI http://example.org/foaf-graph로 식별하여 표현합니다. 해당 그래프는 Manu와 Gregg에 대한 문장들로 구성됩니다. 그래프 자체에 대한 메타데이터는 그래프가 생성된 시점을 지정하는 generatedAt 속성을 통해 표현됩니다.

JSON-LD 문서의 최상위 구조가 맵이고 @graph와 (선택적으로) @context 외에 다른 키를 포함하지 않는 경우(IRI나 키워드로 매핑되지 않는 속성들은 무시됨), @graph는 암묵적인 기본 그래프를 표현하는 것으로 간주됩니다. 이 메커니즘은 문서의 최상위에 동일한 컨텍스트를 공유하는 여러 노드가 존재하는 경우(예: 문서가 평탄화된 경우)에 유용합니다. @graph 키워드는 이러한 노드들을 배열로 수집하고 공유 컨텍스트를 사용할 수 있게 합니다.

이 경우 그래프에 관련 없는 노드들이 포함되어 있으므로 임베딩을 사용할 수 없습니다. 이는 배열 내에서 여러 노드 객체를 사용하고 각 노드 객체 내에서 @context를 정의하는 것과 동등합니다:

4.10 문서 로딩

이 절은 규범적이지 않습니다.

JSON-LD 1.1 처리 알고리즘 및 API 명세 [JSON-LD11-API] 는 JSON-LD 처리기에 대한 인터페이스를 정의하며, 다양한 형식의 JSON-LD를 다루는데 사용되는 여러 메서드를 포함합니다 (자세한 내용은 § 5. Forms of JSON-LD 참고). 여기에는 원격 문서(참조된 JSON-LD 문서 및 원격 컨텍스트 포함)를 로딩하는 일반적인 메커니즘과 [HTML] 등 다른 형식에서 임베드된 JSON-LD를 추출하는 기능이 포함됩니다. 이 내용은 원격 문서 및 컨텍스트 검색 에서 더 자세히 설명됩니다 ([JSON-LD11-API]).

documentLoader 는 원격 문서 로딩이 문제가 될 수 있는 다양한 상황에서 유용하게 사용될 수 있습니다:

• 원격 컨텍스트 문서는 각 요청마다 원격 컨텍스트 위치에 과부하가 걸리지 않도록 캐시되어야 합니다. 보통 HTTP 캐싱 인프라가 이를 처리할 수 있을 것으로 기대하나, 일부 환경에서는 이것이 불가능할 수 있습니다. documentLoader 구현이 이러한 캐싱을 별도의 로직으로 제공할 수 있습니다.
• 비표준 URL 스킴이 널리 구현되어 있지 않거나, 특정 애플리케이션 도메인에 특화된 동작이 있을 수 있습니다. documentLoader 를 정의하여 문서 검색 시맨틱스를 구현할 수 있습니다.
• 일부 잘 알려진 컨텍스트는 documentLoader 구현 내에 정적으로 캐시될 수 있습니다. 이는 임베디드 애플리케이션 등 원격 문서에 접근하는 것이 불가능하거나 바람직하지 않은 환경에서 특히 유용합니다.
• 보안 목적으로, 원격 문서 검색은 애플리케이션 동작 신호를 제공할 수 있습니다. documentLoader 의 적절한 사용은 애플리케이션을 격리하고 온라인 핑거프린트를 줄이는 데 도움을 줄 수 있습니다.

5.1 확장된 문서 형식

이 절은 규범적이지 않습니다.

JSON-LD 1.1 Processing Algorithms and API 명세 [JSON-LD11-API] 는 JSON-LD 문서를 확장(expanding)하는 방법을 정의합니다. Expansion은 JSON-LD 문서를 가져와 모든 IRI, 타입 및 값을 확장하여 @context가 더 이상 필요하지 않게 만드는 과정입니다.

예를 들어, 다음 JSON-LD 입력 문서를 가정해 보겠습니다:

{
   "@context": {
      "name": "http://xmlns.com/foaf/0.1/name",
      "homepage": {
        "@id": "http://xmlns.com/foaf/0.1/homepage",
        "@type": "@id"
      }
   },
   "name": "Manu Sporny",
   "homepage": "http://manu.sporny.org/"
}

위 JSON-LD 입력 문서에 대해 JSON-LD Expansion algorithm을 실행하면 다음과 같은 출력이 생성됩니다:

JSON-LD의 미디어 타입은 profile 매개변수를 정의하며 이를 통해 expanded document form을 신호하거나 요청할 수 있습니다. 확장된 문서 형태를 식별하는 profile URI는 http://www.w3.org/ns/json-ld#expanded입니다.

5.2 컴팩트된 문서 형식

이 절은 규범적이지 않습니다.

JSON-LD 1.1 Processing Algorithms and API 명세 [JSON-LD11-API]는 JSON-LD 문서를 압축(compacting)하는 방법을 정의합니다. Compaction은 개발자가 제공한 context를 적용하여 IRI를 term이나 compact IRI로 단축하고, 확장된 형식으로 표현된 JSON-LD 값을 문자열이나 숫자 같은 단순 값으로 표현하는 과정입니다. 이는 문서를 애플리케이션별 용어로 표현하여 문서 작업을 더 간단하게 만드는 경우가 많습니다. 또한 압축된 문서는 일반적으로 사람이 읽기에 더 쉽습니다.

예를 들어, 다음 JSON-LD 입력 문서를 가정해 보겠습니다:

[
  {
    "http://xmlns.com/foaf/0.1/name": [ "Manu Sporny" ],
    "http://xmlns.com/foaf/0.1/homepage": [
      {
       "@id": "http://manu.sporny.org/"
      }
    ]
  }
]

추가로, 다음과 같은 개발자가 제공한 JSON-LD 컨텍스트를 가정합니다:

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    }
  }
}

위에서 제공된 context를 사용하여 앞의 JSON-LD 입력 문서에 대해 JSON-LD Compaction algorithm을 실행하면 다음과 같은 출력이 생성됩니다:

JSON-LD의 미디어 타입은 profile 매개변수를 정의하며 이를 통해 compacted document form을 신호하거나 요청할 수 있습니다. 압축된 문서 형태를 식별하는 profile URI는 http://www.w3.org/ns/json-ld#compacted입니다.

Compaction의 세부 사항은 Compaction algorithm에 설명되어 있습니다. 이 절은 문서를 압축하는 데 사용될 컨텍스트를 작성하는 저자들을 위한 안내로서 알고리즘이 어떻게 동작하는지 간단히 설명합니다.

Compaction의 목적은 term definitions, vocabulary mapping, default language, 및 base IRI를 기존 JSON-LD 문서에 적용하여 문서가 JSON으로 직접 사용되도록 맞춤화된 형태로 표현되게 하는 것입니다. 여기에는 가능한 경우 값을 strings로 표현하고, list objects의 사용을 단순한 arrays로 줄이며, nodes 간의 관계를 반전시키고, 여러 값을 배열로 표현하는 대신 데이터 맵을 사용하여 값에 인덱싱하는 것 등이 포함됩니다.

5.3 평탄화된 문서 형식

이 절은 규범적이지 않습니다.

JSON-LD 1.1 Processing Algorithms and API 명세 [JSON-LD11-API]는 JSON-LD 문서를 flattening하는 방법을 정의합니다. Flattening은 노드의 모든 속성을 단일 맵에 수집하고, 모든 blank node에 대해 blank node identifiers를 라벨링합니다. 이는 데이터의 형태를 보장하여 특정 애플리케이션에서 JSON-LD를 처리하는 데 필요한 코드를 크게 단순화할 수 있습니다.

예를 들어, 다음 JSON-LD 입력 문서를 가정합니다:

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "knows": "http://xmlns.com/foaf/0.1/knows"
  },
  "@id": "http://me.markus-lanthaler.com/",
  "name": "Markus Lanthaler",
  "knows": [
    {
      "@id": "http://manu.sporny.org/about#manu",
      "name": "Manu Sporny"
    }, {
      "name": "Dave Longley"
    }
  ]
}

위 JSON-LD 입력 문서에 대해 JSON-LD Flattening algorithm을 실행하고 동일한 컨텍스트를 사용하면 다음과 같은 출력이 생성됩니다:

JSON-LD의 미디어 타입은 profile 매개변수를 정의하며 이를 통해 flattened document form을 신호하거나 요청할 수 있습니다. 평탄화된 문서 형태를 식별하는 profile URI는 http://www.w3.org/ns/json-ld#flattened입니다. 이는 확장된 문서 형태나 압축된 문서 형태의 profile URI와 결합하여 사용할 수 있습니다.

5.4 프레이밍된 문서 형식

이 절은 규범적이지 않습니다.

JSON-LD 1.1 Framing 명세 [JSON-LD11-FRAMING]는 JSON-LD 문서를 framing하는 방법을 정의합니다. Framing 은 예시 frame 문서를 사용해 JSON-LD 문서의 데이터를 원하는 구조로 만드는 데 사용됩니다. 이 프레임 문서는 flattened 데이터와 일치시키는 데 사용되며, 결과 데이터가 어떻게 형성되어야 하는지의 예를 제공합니다.

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

{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.org/"
  },
  "@type": "Library",
  "contains": {
    "@type": "Book",
    "contains": {
      "@type": "Chapter"
    }
  }
}

이 프레임 문서는 타입이 Library인 객체들을 최상위에 배치하고, 라이브러리 객체와 contains 속성으로 연결된 타입이 Book인 객체들을 프로퍼티 값으로 임베드하도록 하는 구조를 설명합니다. 또한 타입이 Chapter인 객체들을 해당 참조하는 Book 객체의 임베디드 값으로 배치합니다.

프레임 구성 요소와 일치하는 평탄화된 객체 집합을 사용할 때:

{
  "@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",
    "@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"
  }]
}

Frame Algorithm은 프레임의 구조를 따르는 새 문서를 생성할 수 있습니다:

JSON-LD의 미디어 타입은 profile 매개변수를 정의하며 이를 통해 framed document form을 신호하거나 요청할 수 있습니다. 프레임된 문서 형태를 식별하는 profile URI는 http://www.w3.org/ns/json-ld#framed입니다.

JSON-LD의 미디어 타입은 또한 HTML 문서 내에 프레임을 포함하는 script element를 식별하는 profile 매개변수를 정의합니다. 타입이 application/ld+json;profile=http://www.w3.org/ns/json-ld#frame인 첫 번째 script element가 frame을 찾는 데 사용됩니다.