Pospone discussion on "$" and "@"

[ioggstream]

Proposal

JSON-LD is complex. YAML is very complex and - as the YAML community says - it's a live specification that is undergoing continuous revisions. For example:

• YAML 1.2 deprecated many 1.1 functionalities but some of them are still present in the current spec examples;
• Some deprecated but "killer" features like merge keys <<: have not been replaced by new ones, so implementers still support them;
• While YAML serialized using the flow collection styles can appear like JSON, YAML MUST not be considered a superset of JSON;
• "@" in YAML is reserved for future use since forever, and this might change.

In this context, focusing on switching "@" with "$" to avoid quoting could lead to a dead end e.g. this is both valid in YAML and JSON, and it's just the first example that come to my mind

{
  "@context": {
    "@vocab": "https://www.w3.org/2019/wot/json-schema#",
    "title": { "@id": "dct:title", "@type": "xsd:string" },
    "description": { "@id": "dct:description", "@type": "xsd:string" },
    "$id": { "@id": "@id" },
    "type": { "@id": "@type" },
    "object": "ObjectSchema"
  },
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/product.schema.json",
  "title": "Product",
  "description": "A product in the catalog",
  "type": "object"
}

I'd focus on YAML structure

imho I would focus:

• on supporting existing use cases, starting with the simple, interoperable conversion of JSON -> YAML (see https://www.ietf.org/archive/id/draft-ietf-httpapi-yaml-mediatypes-01.html#name-interoperability-considerat)

• on the benefit of using alias nodes

• on possible usage of cycles in the YAML representation graph (this is not interoperable with JSON).

Once identified the relations with these specific YAML features, I think we will be ready tame things like tags (which are not very interoperable in the wild).

The ongoing work on YAML fragment identifiers could even provide further benefits since it can reference both JSON Paths and alias nodes.

My2¢, R.

[anatoly-scherbakov]

• merge keys
• alias nodes
• cycles

Could you share any compelling use cases for these special features, to put them in context and to make it easier to understand them?

This is up to your convenience but I'd suggest creating a separate issue for each.

As to the title of this issue:

"@" in YAML is reserved for future use since forever, and this might change.

Exactly; that's also why we're not allowing @-keywords in YAML files. $ is not a reserved character, and therefore $-keywords are safer to use.

this is both valid in YAML and JSON

Yes, if a JSON-LD file author uses $ in the file then JSON-LD → YAML-LD → JSON-LD conversion will not yield a result identical to the original file. But does it matter?

The graphs resulting from each of these files will be identical. I propose to use that as the main criterion. Ultimately, the purpose of all these -LD formats is to convert something into an RDF graph, I would say.

It is also important to mention that JSON Schema $schema keyword will not be converted, it will stay as is because @schema is not a valid JSON-LD keyword.

I posted some additional thoughts at #11.

[ioggstream]

that's also why we're not allowing @-keywords in YAML files

I meant that if the problem is quoting, we could discuss with YAML folks and ask them to unreserve @ in YAML 1.3. The argument is that, since it's more than 10 years that that's reserved, it can be fair to "release" it. At this point, there will be no reason for messing with that syntax.

[anatoly-scherbakov]

I took the liberty to ask in the issue referenced above.

[VladimirAlexiev]

@ioggstream Thanks for this important issue! In fact you discuss several important issues, I wish you opened them as separate issues rather than under this unsexy title "postpone discussion"

While YAML serialized using the flow collection styles can appear like JSON, YAML MUST not be considered a superset of JSON

Can you please elaborate on this? Is there any valid JSON that's invalid YAML?

Cannot this

    "$id": { "@id": "@id" },
    "type": { "@id": "@type" },

be written more simply as

    "$id": "@id" ,
    "type": "@type" ,

$ vs @

AFAIK, JS programmers dislike punctuation in field names because they like to write var.id instead of var["@id"]. Is it allowed to write var.$id? (@anatoly-scherbakov ?) If not, is it ok to appropriate underscore and write var._id (@gkellogg what do you think?)

[ioggstream]

Is there any valid JSON that's invalid YAML?

In YAML 1.2, all valid JSON parses to valid YAML. When discussing with YAML folks, they told me that this cannot be guaranteed for YAML 1.3 and that you should parse JSON with JSON parsers, and YAML with YAML parser.

about your examples

in yaml you cannot add "," at the end. I think it's ok.

about punctuation & co

Being a pythonista, I like punctuation. Still, my experience suggests to stay away from this kind of issues when you work on an existing language and you are not the sole implementor of parsers and serializers :)

[anatoly-scherbakov]

Being a pythonista just like @ioggstream I am not very keen on Javascript but, after a brief test, it appears that var.$id is allowed in JS. @VladimirAlexiev

[VladimirAlexiev]

Closing as agreed by @ioggstream: this has a lot of great discussion but it's unfocused, so relevant stuff needs to be posted as distinct issues.