YAML-LD context and frame

[VladimirAlexiev]

A YAML-LD Context defines the conversion of a YAML-LD document to RDF. It should include:

• same as JSON-LD context, but represented in YAML, maybe using a more convenient char than @ (#9)
• definitions of datatype tags (#17)
• TODO anything else?

A YAML-LD Frame, together with the context, defines the serialization of some RDF data to YAML-LD. It should include:

• same as JSON-LD frame
• maybe some anchor-related options, to handle shared and cyclic structures (#13)
• presentation options (#42)

[VladimirAlexiev]

@ioggstream asked a relevant question in #42, so let's take a simple ACID test to see how people feel about this:

Should I as information provider be able to state in a standardized way: "I want 3 spaces used for indentation in my YAML". eg by specifying indent_spaces: 3 where this term resolves to eg https://w3c.github.io/yaml-ld/presentation#indent_spaces

Please vote with :+1: or :-1:

[anatoly-scherbakov]

If two YAML documents, one with 3 spaces and another with 4 spaces, are semantically equivalent, — why would we want this?

Also, I believe the indentation size can be easily changed using an auto formatter.

This is very similar to Python programming language which is also based on indentation.

[gkellogg]

JSON-LD does not say anything about the specifics of JSON encoding, other than ordering. Particularly, the treatment of whitespace.

IMO, as an RDF serialization, two documents are equivalent if they produce equivalent RDF C14N Hashes. Otherwise, getting into YAML C14N if fraught. Even JCS (JSON C14N) can result in different serializations if blank nodes are involved.

[VladimirAlexiev]

JSON-LD says a lot about various JSON encodings of the same RDF model. Everything except the formatting.

YAML-LD should take all this from JSON-LD. But YAML is all about readability, so I think it should also address formatting.

@anatoly-scherbakov

1. If semantic meaning is all that matters, why do we even bother with YAML-LD ? Let's stick with JSON-LD. A few extra quotes and brackets never hurt anyone, right?
2. You could use a prettyprinter. Just like you could use other tools to convert between JSON representations. But that's not an argument why I should not be able to express how exactly I want my YAML to look.

Formatting does not matter to machines, but it matters to people.

[gkellogg]

A YAML-LD Frame, together with the context, defines the serialization of some RDF data to YAML-LD. It should include:

• same as YAML-LD frame

JSON-LD frame?

• maybe some anchor-related options, to handle shared and cyclic structures (Define anchor usage in yaml-ld #13)
• presentation options (YAML presentation ("cosmetic") controls #42)

Unless we want to describe a separate YAML-LD Framing algorithm, this may prove to be challenging. The JSON-LD Framing algorithm is quite complicated as it is. This gets into more general YAML-LD presentation issues from #42. IMO, we really need to either avoid such considerations within the spec, or define a single mechanism similar to the Compaction Algorithm that makes use of information in the context to perform presentation, but it seems like a violation of the separation of concerns principle.

[TallTed]

YAML is all about readability, so I think it should also address formatting

Sure. YAML should also address formatting, and YAML-LD should simply inherit this from YAML.

[VladimirAlexiev]

@gkellogg

Fixed same as JSON-LD frame.

maybe some anchor-related options, to handle shared and cyclic

The JSON-LD Framing algorithm is quite complicated as it is.

Let's continue this in #13

@TallTed

YAML should also address formatting, and YAML-LD should simply inherit this from YAML.

Ideally yes, and YAML-LD will just pick URLs for formatting terms. Similarly for #43, we'll defer to https://github.com/yaml/yaml-spec/issues/289 if and when resolved. But if the YAML community is not active enough to do that, I think we should.