YAML-LD-star

[VladimirAlexiev]

As an information architect.
I want to be able to represent embedded triples and annotations.
So that I can reap the benefits of RDF-star in YAML (YAML-LD-star).

Given the JSON-LD-star effort https://json-ld.github.io/json-ld-star/, I think YAML-LD should support the same.

Examples from that spec can be translated to YAML in a straight-forward way.
Notes:

• Ex 8 & 9 are omitted
• There are more examples in https://json-ld.github.io/json-ld-star/tests/
• Using $ instead of @ to avoid quotes
• Contexts omitted for brevity in many cases

Turtle-star example 3

<< :bob :age 42 >> :certainty 0.8 .

YAML-LD-star example 3:

$id:
  $id: bob
  age: 42
certainty: 0.8

YAML-LD-star example 4:

$id:
  $id: bob
  age: 
    $value: 42
    $annotation:
      certainty: 0.8

Turtle-star example 5

:alice :claims << :bob :knows :alice >> .

YAML-LD-star example 5:

  $context:
    $base: http://example.org/
    $vocab: http://example.org/
    knows: {$type: $id}
    claimedBy: {$reverse: http://example.org/claims, $type: $id}
  $id:
    $id: bob
    knows: alice
  claimedBy: alice

Turtle-star example 6

:bob :knows :alice .
<< :bob :knows :alice >> :accordingTo :alice .
:bob :claims << :bob :knows :alice >> .

YAML-LD-star example 6

  $id: bob
  knows:
    $id: alice
    $annotation:
      accordingTo: alice
      claimedBy: bob

Turtle-star example 7

<< :bob :knows :alice >> :certainty 0.8 .
<< << :bob :knows :alice >> :certainty 0.8 >> :claims :ted .

YAML-LD-star example 7

  $id:
    $id: bob
    knows: {$id: alice}
  certainty: {
    $value: 0.8,
    $annotation: {claims: ted}}

---

But there is a more YAMLish way to represent these examples:
In YAML, keys may be arbitrary nodes, so example 3 can be represented like this in flow style:
YAML-LD example 3F:

{$id: bob, age: 42}: {certainty: 0.8}

And like this in block style:
YAML-LD example 3B:

? $id: bob
  age: 42
: certainty: 0.8

YAML-LD example 7F:

  {{$id: bob, knows: {$id: alice}}: {certainty: 0.8}}: {claims: ted}

[ioggstream]

You can use \@ instead of $ so you don't need quotes, nor custom parsers :)

[gkellogg]

Presumably, YAML-LD should not require anything specific to support -star; it should follow from the generalized support for JSON-LD representation in YAML. Being too explicit would require regular maintenance of YAML-LD to follow. Better figure out how to establish principles for representing JSON-LD in YAML without getting into each individual feature defined in JSON-LD, JSON-LD-star, or whatever else we may come up with.

[VladimirAlexiev]

@gkellogg
Because YAML doesn't have the JSON restriction that keys must be strings, it offers a much more natural way to represent RDF-star data.

We all agree that the default route (JSON-LD->YAML-LD using the standard conversion JSON->YAML) is the base case (and an important one).

The default conversion will make YAML-LD-star example 3.

$id:
  $id: bob
  age: 42
certainty: 0.8

But YAML-LD example 3F is much nicer (easier on the eyes and easier to understand):

{$id: bob, age: 42}: {certainty: 0.8}

So Gregg, do you vote for or against this UCR?

[gkellogg]

That certainly is an interesting capability, but also contradicts #8 and other concerns about round-trip ability, at least at the syntactic level.

[ioggstream]

@gkellogg I think we should leave this issue open and write some test cases. I don't think that we will close this issue in 2022.

YAML doesn't have the JSON restriction that keys must be strings, it offers a much more natural way to represent RDF-star data.

I don't know RDF* but I think that we need proper investigation.

[TallTed]

@ioggstream -- I realize this may seem like a quibble, but please note that while the name RDF* was used in early drafts and discussion, it was changed to RDF-star several months ago, for all purposes going forward.

Discussion of the thing called RDF* (which evolved into the thing called RDF-star) tends to devolve into issues (including regarding the name itself) which were raised on those early drafts and addressed in subsequent discussions among the RDF-star subgroup of the RDF-DEV CG.

A charter for an RDF-star WG (which will take up the RDF-star draft spec incubated by the RDF-star subgroup) is currently under review by the W3C-AC, aiming toward a relatively near-future commencement (which would allow for such "proper investigation" as you desire).

[VladimirAlexiev]

The RDF-star WG will have a lot of work because it needs to produce an update to a whole bunch of W3C specs: https://www.w3.org/2022/06/proposed-rdf-star-wg-charter.html. However, the delta https://w3c.github.io/rdf-star/cg-spec/editors_draft.html is pretty much settled (IMHO): the WG will need to take care of a whole lot of important details, but I don't expect any surprises at the conceptual level.

[westurner]

• decide on the short names of the specifications w3c/rdf-star-wg#4 (comment) :

Note that the JSON-LD group will likely end up publishing JSON-LD12, JSON-LD12-API, and JSON-LD12-FRAMING eventually.

• Should there be a SPARQL12-RESULTS-JSONLD ?
• Should there be a SPARQL12-RESULTS-CSVW ?
• Should there be a SPARQL12-RESULTS-JSONLD-CSVW ?

• Should there be a SPARQL12-RESULTS-YAMLLD
• Should there be a SPARQL12-RESULTS-CSVW ?
• Should there be a SPARQL12-RESULTS-YAMLLD-CSVW ?

[VladimirAlexiev]

I guess there should be SPARQL12-RESULTS-YAMLLD (for CONSTRUCT results).
As for the CSVW variants, I asked in w3c/rdf-star-wg#4