(Registered 2013-08-16, last updated 2020-03-17)

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] 
   <https://www.w3.org/TR/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] <https://www.w3.org/TR/rdf11-concepts/>.

   This registration is an update to the original definition for 
   application/ld+json in [JSON-LD10] 
   <https://www.w3.org/TR/2014/REC-json-ld-20140116/>.