This document describes use cases that justify the extension of RDF in the current work in RDF star community group. It is collaborative work and is a non-normative part of this group output.

This document is a community working draft.


This document collects together use cases and requirments for YAML-LD. These use case were provided by members of the W3C JSON-LD Community Group on the JSON-LD CG mailing list and issues of the community's GitHub repository.

Contributing Use Cases and Requirements

Create a GitHub issue following the dedicated template. The suggested form is:

          WHO:  As an <actor>
          WHAT: I want a <feature>
          WHY:  So that <benefit>

This is not mandatory.

Submitted Use Cases

#### Compatibility with existing libraries [Submitted Use Case]( As a developer of YAML-LD processors. I want to be able to use off-the-shelf libraries for converting between JSON-LD and YAML-LD serialization formats. So that data produced in JSON-LD can be easily represented in YAML-LD and visa-versa.

There seems to be general compatibility between YAML libraries that produce equivalent results when serializing data originally parsed from JSON. This should be verified, but indicates an easy way of providing a YAML-LD serialization fully round-trippable with JSON-LD.

Distinguish "plain" YAML-LD from "ideomatic" YAML-LD

Submitted Use Case

As a processor. I want to easily distinguish between "plain" YAML-LD and "ideomatic" YAML-LD based on the use of local tags (or similar) which may require post-parsing processing to be interpreted using the JSON-LD processig algorithms. So that more complicated processing steps can be avoided.

          $type: Person
          name: Pierre-Antoine Champin

The previous example uses two such mechanisms:

  • The use of `$` instead of `@` to denote JSON-LD keywords. (Note, other than for `@context`, this could be done using a standardized context defining appropriate keyword aliases).
  • The hypothetical `!yaml-ld` processing instruction