search

json-ld / yaml-ld

CG specification for YAML-LD and UCR
https://json-ld.github.io/yaml-ld/spec
Other
22 stars 8 forks source link

YAML-LD context and frame #44

Open VladimirAlexiev opened 2 years ago

VladimirAlexiev commented 2 years ago

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

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

VladimirAlexiev commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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?

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 commented 2 years ago

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 commented 2 years ago

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