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.

Introduction

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.

Basic Concepts

FIXME.

Security Considerations

See Security considerations in JSON-LD 1.1. Also, see the YAML media type registration.

Interoperability Considerations

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]]..

IANA Considerations

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

application/ld+yaml

Type name:
application
Subtype name:
ld+yaml
Required parameters:
N/A
Optional parameters:
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
To request or specify extended YAML-LD document form.
This is a placeholder for specifying something like an extended YAML-LD document form making use of YAML-specific features.

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]].

Encoding considerations:
See YAML media type.
Security considerations:
See .
Interoperability considerations:
See .
Published specification:
http://www.w3.org/TR/yaml-ld
Applications that use this media type:
Any programming environment that requires the exchange of directed graphs. Implementations of YAML-LD have been created for FIXME.
Additional information:
Magic number(s):
Not Applicable
File extension(s):
.yamlld
Macintosh file type code(s):
TEXT
Person & email address to contact for further information:
Philippe Le H├ęgaret <plh@w3.org>
Intended usage:
Common
Restrictions on usage:
N/A
Author(s):
Roberto Polli, Gregg Kellogg
Change controller:
W3C

Fragment identifiers

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.

Perhaps more on fragment identifiers from Issue 13

Examples

FIXME