diff --git a/index.html b/index.html index 7c2018f..9c7e270 100644 --- a/index.html +++ b/index.html @@ -3888,7 +3888,7 @@

Using the Document Base for the Default Vocabulary

To prevent this divergence of interpretation, JSON-LD 1.1 allows term definitions to be protected.

-

A protected term definition is a term definition with an entry @protected set to true. +

A protected term definition is a term definition with an entry @protected set to true. It generally prevents further contexts from overriding this term definition, either through a new definition of the same term, or through clearing the context with "@context": null. @@ -13015,7 +13015,35 @@

Serializing/Deserializing RDF

Security Considerations

-

See, Security Considerations in .

+

See RFC 8259, section 12 [[RFC8259]].

+

Since JSON-LD is intended to be a pure data exchange format for + directed graphs, the serialization SHOULD NOT be passed through a + code execution mechanism such as JavaScript's eval() + function to be parsed. An (invalid) document may contain code that, + when executed, could lead to unexpected side effects compromising + the security of a system.

+

When processing JSON-LD documents, links to remote contexts and frames are + typically followed automatically, resulting in the transfer of files + without the explicit request of the user for each one. If remote + contexts are served by third parties, it may allow them to gather + usage patterns or similar information leading to privacy concerns. + Specific implementations, such as the API defined in the + JSON-LD 1.1 Processing Algorithms and API specification [[JSON-LD11-API]], + may provide fine-grained mechanisms to control this behavior.

+

JSON-LD contexts that are loaded from the Web over non-secure connections, + such as HTTP, run the risk of being altered by an attacker such that + they may modify the JSON-LD active context in a way that + could compromise security. It is advised that any application that + depends on a remote context for mission critical purposes vet and + cache the remote context before allowing the system to use it.

+

Given that JSON-LD allows the substitution of long IRIs with short terms, + JSON-LD documents may expand considerably when processed and, in the worst case, + the resulting data might consume all of the recipient's resources. Applications + should treat any data with due skepticism.

+

As JSON-LD places no limits on the IRI schemes that may be used, + and vocabulary-relative IRIs use string concatenation rather than + IRI resolution, it is possible to construct IRIs that may be + used maliciously, if dereferenced.

Future versions of this specification may incorporate subresource integrity [[?SRI]] as a means of ensuring that cached and retrieved @@ -13424,193 +13452,284 @@

IANA Considerations

This section has been submitted to the Internet Engineering Steering Group (IESG) for review, approval, and registration with IANA.

+ +
+

Media Type Registration: `application/ld+json`

+
+
Type name:
+
application
+
Subtype name:
+
ld+json
+
Required parameters:
+
N/A
+
Optional parameters:
+
+
+
profile
+
+

A non-empty list of space-separated URIs identifying specific + constraints or conventions that apply to a JSON-LD document according to [[RFC6906]]. + A profile does not change the semantics of the resource representation + when processed without profile knowledge, so that clients both with + and without knowledge of a profiled resource can safely use the same + representation. The profile parameter MAY be used by + clients to express their preferences in the content negotiation process. + If the profile parameter is given, a server SHOULD return a document that + honors the profiles in the list which it recognizes, + and MUST ignore the profiles in the list which it does not recognize. + It is RECOMMENDED that profile URIs are dereferenceable and provide + useful documentation at that URI. For more information and background + please refer to [[RFC6906]].

+

This specification defines six values for the profile parameter.

+
+
http://www.w3.org/ns/json-ld#expanded
+
To request or specify expanded JSON-LD document form.
+
http://www.w3.org/ns/json-ld#compacted
+
To request or specify compacted JSON-LD document form.
+
http://www.w3.org/ns/json-ld#context
+
To request or specify a JSON-LD context document.
+
http://www.w3.org/ns/json-ld#flattened
+
To request or specify flattened JSON-LD document form.
+
http://www.w3.org/ns/json-ld#frame
+
To request or specify a JSON-LD frame document.
+
http://www.w3.org/ns/json-ld#framed
+
To request or specify framed JSON-LD document form.
+
+

All other URIs starting with http://www.w3.org/ns/json-ld + are reserved for future use by JSON-LD specifications.

+

Other specifications may publish additional `profile` parameter + URIs with their own defined semantics. + This includes the ability to associate a file extension with a `profile` parameter.

+

+ When used as a media type parameter [[RFC4288]] + in an HTTP Accept header [[RFC7231]], + the value of the profile parameter MUST be enclosed in quotes (") if it contains + special characters such as whitespace, which is required when multiple profile URIs are combined.

+

When processing the "profile" media type parameter, it is important to + note that its value contains one or more URIs and not IRIs. In some cases + it might therefore be necessary to convert between IRIs and URIs as specified in + section 3 Relationship between IRIs and URIs + of [[RFC3987]].

+
+
+
+
Encoding considerations:
+
See RFC 8259, section 11.
+
Security considerations:
+
+ See . +
+
Interoperability considerations:
+
Not Applicable
+
Published specification:
+
http://www.w3.org/TR/json-ld
+
Applications that use this media type:
+
Any programming environment that requires the exchange of + directed graphs. Implementations of JSON-LD have been created for + JavaScript, Python, Ruby, PHP, and C++. +
+
Additional information:
+
+
+
Magic number(s):
+
Not Applicable
+
File extension(s):
+
.jsonld
+
Macintosh file type code(s):
+
TEXT
+
+
+
Person & email address to contact for further information:
+
Pierre-Antoine Champin <pierre-antoine@w3.org>
+
Intended usage:
+
Common
+
Restrictions on usage:
+
N/A
+
Author(s):
+
Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler, Niklas Lindström
+
Change controller:
+
W3C
+
-

application/ld+json

-
-
Type name:
-
application
-
Subtype name:
-
ld+json
-
Required parameters:
-
N/A
-
Optional parameters:
-
-
-
profile
-
-

A non-empty list of space-separated URIs identifying specific - constraints or conventions that apply to a JSON-LD document according to [[RFC6906]]. - A profile does not change the semantics of the resource representation - when processed without profile knowledge, so that clients both with - and without knowledge of a profiled resource can safely use the same - representation. The profile parameter MAY be used by - clients to express their preferences in the content negotiation process. - If the profile parameter is given, a server SHOULD return a document that - honors the profiles in the list which it recognizes, - and MUST ignore the profiles in the list which it does not recognize. - It is RECOMMENDED that profile URIs are dereferenceable and provide - useful documentation at that URI. For more information and background - please refer to [[RFC6906]].

-

This specification defines six values for the profile parameter.

-
-
http://www.w3.org/ns/json-ld#expanded
-
To request or specify expanded JSON-LD document form.
-
http://www.w3.org/ns/json-ld#compacted
-
To request or specify compacted JSON-LD document form.
-
http://www.w3.org/ns/json-ld#context
-
To request or specify a JSON-LD context document.
-
http://www.w3.org/ns/json-ld#flattened
-
To request or specify flattened JSON-LD document form.
-
http://www.w3.org/ns/json-ld#frame
-
To request or specify a JSON-LD frame document.
-
http://www.w3.org/ns/json-ld#framed
-
To request or specify framed JSON-LD document form.
-
-

All other URIs starting with http://www.w3.org/ns/json-ld - are reserved for future use by JSON-LD specifications.

- -

Other specifications may publish additional `profile` parameter - URIs with their own defined semantics. - This includes the ability to associate a file extension with a `profile` parameter.

-

- When used as a media type parameter [[RFC4288]] - in an HTTP Accept header [[RFC7231]], - the value of the profile parameter MUST be enclosed in quotes (") if it contains - special characters such as whitespace, which is required when multiple profile URIs are combined.

-

When processing the "profile" media type parameter, it is important to - note that its value contains one or more URIs and not IRIs. In some cases - it might therefore be necessary to convert between IRIs and URIs as specified in - section 3 Relationship between IRIs and URIs - of [[RFC3987]].

-
-
-
-
Encoding considerations:
-
See RFC 8259, section 11.
-
Security considerations:
-
See RFC 8259, section 12 [[RFC8259]] -

Since JSON-LD is intended to be a pure data exchange format for - directed graphs, the serialization SHOULD NOT be passed through a - code execution mechanism such as JavaScript's eval() - function to be parsed. An (invalid) document may contain code that, - when executed, could lead to unexpected side effects compromising - the security of a system.

-

When processing JSON-LD documents, links to remote contexts and frames are - typically followed automatically, resulting in the transfer of files - without the explicit request of the user for each one. If remote - contexts are served by third parties, it may allow them to gather - usage patterns or similar information leading to privacy concerns. - Specific implementations, such as the API defined in the - JSON-LD 1.1 Processing Algorithms and API specification [[JSON-LD11-API]], - may provide fine-grained mechanisms to control this behavior.

-

JSON-LD contexts that are loaded from the Web over non-secure connections, - such as HTTP, run the risk of being altered by an attacker such that - they may modify the JSON-LD active context in a way that - could compromise security. It is advised that any application that - depends on a remote context for mission critical purposes vet and - cache the remote context before allowing the system to use it.

-

Given that JSON-LD allows the substitution of long IRIs with short terms, - JSON-LD documents may expand considerably when processed and, in the worst case, - the resulting data might consume all of the recipient's resources. Applications - should treat any data with due skepticism.

-

As JSON-LD places no limits on the IRI schemes that may be used, - and vocabulary-relative IRIs use string concatenation rather than - IRI resolution, it is possible to construct IRIs that may be - used maliciously, if dereferenced.

-
-
Interoperability considerations:
-
Not Applicable
-
Published specification:
-
http://www.w3.org/TR/json-ld
-
Applications that use this media type:
-
Any programming environment that requires the exchange of - directed graphs. Implementations of JSON-LD have been created for - JavaScript, Python, Ruby, PHP, and C++. -
-
Additional information:
-
-
-
Magic number(s):
-
Not Applicable
-
File extension(s):
-
.jsonld
-
Macintosh file type code(s):
-
TEXT
-
-
-
Person & email address to contact for further information:
-
Ivan Herman <ivan@w3.org>
-
Intended usage:
-
Common
-
Restrictions on usage:
-
N/A
-
Author(s):
-
Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler, Niklas Lindström
-
Change controller:
-
W3C
-
+

Fragment identifiers used with application/ld+json + are treated as in RDF syntaxes, as per + RDF 1.1 Concepts and Abstract Syntax + [[RDF11-CONCEPTS]].

-

Fragment identifiers used with application/ld+json - are treated as in RDF syntaxes, as per - RDF 1.1 Concepts and Abstract Syntax - [[RDF11-CONCEPTS]].

+

This registration is an update to the original definition + for application/ld+json + in [[JSON-LD10]].

-

This registration is an update to the original definition - for application/ld+json - in [[JSON-LD10]].

+
+

Examples

+

The following examples illustrate different ways in which the profile parameter may be used + to describe different acceptable responses.

-
-

Examples

-

The following examples illustrate different ways in which the profile parameter may be used - to describe different acceptable responses.

+ 
+      
+
+

Requests the server to return the requested resource as JSON-LD + in expanded document form.

- 
-    
-
-

Requests the server to return the requested resource as JSON-LD - in expanded document form.

+ 
+      
+
+

Requests the server to return the requested resource as JSON-LD + in compacted document form. + As no explicit context resource is specified, the server compacts + using an application-specific default context.

- 
-    
-
-

Requests the server to return the requested resource as JSON-LD - in compacted document form. - As no explicit context resource is specified, the server compacts - using an application-specific default context.

+ 
+      
+
+

Requests the server to return the requested resource as JSON-LD + in both compacted document form + and flattened document form. + Note that as whitespace is used to separate the two URIs, they + are enclosed in double quotes (").

+
+
+
+

Structured Suffix Registration: `+ld+json`

- 
-    
-
-

Requests the server to return the requested resource as JSON-LD - in both compacted document form - and flattened document form. - Note that as whitespace is used to separate the two URIs, they - are enclosed in double quotes (").

+

This section will be submitted to the Internet Engineering Steering + Group (IESG) for review, approval, and registration with IANA.

+ +

The following section is based on the requirements defined in + .

+ +
+ +
Name
+
JSON-based Serialization for Linked Data Structured Suffix
+ +
+suffix
+
+ld+json
+ + +
References
+
+ + A JSON-based Serialization for Linked Data + +
+ + +
Encoding considerations
+
+ See RFC 8259, section 11. +
+ + +
Interoperability considerations
+
+ Not Applicable +
+ + +
Fragment identifier considerations
+
+

+ Fragment identifiers used with +ld+json + are treated as in RDF syntaxes, as per + RDF 1.1 Concepts and Abstract Syntax + [[RDF11-CONCEPTS]]. +

+
+ + +
Security considerations
+
+ See . +
+ + +
Contact
+
Pierre-Antoine Champin <pierre-antoine@w3.org>
+ + +
Author/Change controller
+
+ W3C +
+ +
+
+

Examples

+

The following examples illustrate different ways in which this structured suffix may be used + to request and respond with more specific content types for a resource. +

+ 
+      
+
+ 
+      
+
+
@@ -13719,8 +13838,6 @@

Changes since JSON-LD Community Group Final Report

  • The processing mode is now implicitly `json-ld-1.1`, unless set explicitly to `json-ld-1.0`.
  • Improve notation using IRI, IRI reference, and relative IRI reference.
    • -
  • Warn about forward-compatibility issues for terms of the form (`"@"1*ALPHA`).
  • When creating an `i18n` datatype or `rdf:CompoundLiteral`, language tags are normalized to lower case to improve interoperability between implementations.
    • @@ -13758,6 +13875,8 @@

    Changes since Recommendation of 16 July 2020

  • Misclaneous spelling and grammar fixes.
  • Regenerated definition list, which does not attempt to filter out unused definitions.
  • Fixed typo in where "HTTP document" was intended to be "HTML document".
    • +
  • Allow further structured extensions of `application/ld+json` by using + `+ld+json` as a structured media extension. See .