In recent years, YAML emerged as a more concise format to represent information serialized as JSON, including Linked Data. This document defines how to serialize linked data in YAML documents. Moreover, it registers the application/ld+yaml media type.
This is an unofficial proposal.
JSON-LD is a JSON-based format to serialize Linked Data. In recent years, YAML emerged as a more concise format to represent information serialized as JSON, including API specification, data schemas, and Linked Data.
Since YAML is more expressive than JSON, both in the available data types and in the document structure (see I-D.ietf-yaml-mediatypes), this document identifies constraints on YAML documents such that they can be used to represent JSON-LD documents.
A YAML-LD document complies with this specification if ...
Define YAML-LD document somewhere.
This specification makes use of the following namespace prefixes:
Prefix | IRI |
---|---|
ex | http://example.org/ |
rdf | http://www.w3.org/1999/02/22-rdf-syntax-ns# |
xsd | http://www.w3.org/2001/XMLSchema# |
These are used within this document as part of a compact IRI
as a shorthand for the resulting IRI, such as dcterms:title
used to represent http://purl.org/dc/terms/title
.
FIXME.
See Security considerations in JSON-LD 1.1. Also, see the YAML media type registration.
For general interoperability considerations on the serialization of JSON documents in YAML, see [[YAML]] and the Interoperability consideration of application/yaml [[I-D.ietf-httpapi-yaml-mediatypes]]..
This section has been submitted to the Internet Engineering Steering Group (IESG) for review, approval, and registration with IANA.
profile
A non-empty list of space-separated URIs identifying specific
constraints or conventions that apply to a YAML-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 allows the use of the `profile` parameters listed in and additionally defines the following:
http://www.w3.org/ns/json-ld#extended
When used as a media type parameter [[RFC4288]]
in an HTTP Accept header field [[RFC9110]],
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]].
Fragment identifiers used with application/ld+yaml are treated as in RDF syntaxes, as per RDF 1.1 Concepts and Abstract Syntax [[RDF11-CONCEPTS]].
The YAML media type supports both alias nodes and JSON Pointers [[RFC6905]] as fragment identifiers (see [[I-D.ietf-httpapi-yaml-mediatypes]]). Since named anchors are serialization details, when using alias nodes to reference nodes in external documents, an implementation needs to be confident that the serialization of the resource is preserved.
FIXME