Rework as the Linked Data Formats WG

[BigBlueHat]

This is an early stage reworking of the charter to try to address the group's interest in a more inclusive name indicative of our interest in publishing YAML-LD and CBOR-LD alongside a new/updated JSON-LD.

Much more editing to do, but I wanted to share this early to get feedback.

Cheers!
🎩

---

Preview | Diff

[gkellogg]

1. Please add me as co-chair.
2. Both Manu, and I think Ivan, suggested trimming down the explicit issues in the In Scope section. The RDF & SPARQL WG has the following in the Scope section: "The Working Group will also consider allowing new features in these recommendations, according to Section 6.3.11.4 of the W3C process, in order to render future evolutions easier."
3. Is this the current version of the document template for charters? Does it matter?
4. To get ahead of the game, the new specs should probably be "CBOR-LD 1.0" and "YAML-LD 1.0".
5. For liaison:

• The RDF Dataset Canonicalization and Hash WG is in maintenance mode, and probably doesn't have any coordination requirements.
• The RDF-Star WG is now called the RDF & SPARQL WG.
• I don't think we need to explicitly coordinate with Schema.org CG, RDF-DEV CG, or the RDF JavaScript Libraries CG.

[iherman]

• Both Manu, and I think Ivan, suggested trimming down the explicit issues in the In Scope section. The RDF & SPARQL WG has the following in the Scope section: "The Working Group will also consider allowing new features in these recommendations, according to Section 6.3.11.4 of the W3C process, in order to render future evolutions easier."

Indeed. Having such a long and detailed laundry list would make it too difficult for the AC to review.

As I said before on calls, I believe the scope section should pick 2-3 very high priority items, and commit the full recommendation work for the present charter only for those. All the other items should be formulated as possible rec-track work, but only if the high priority items are completed; otherwise, their completion should be postponed to a later charter.

In my view, the high priority items (in terms of public need) are:

1. Handling the main objection to JSON-LD, namely the security questions raised v.a.v. the reference and access to a @context; this is, I believe, Consider context by reference with metadata w3c/json-ld-syntax#108
2. Compatibility with RDF 1.2
3. RDF 1.2 compatible CBOR-LD

All other work items, including YAML-LD, should be considered as a "wouldn't it be nice", conditional items, as referred to above.

[pchampin]

As discussed during our last meeting, I believe that "JSON-LD" should still appear in the name of the WG. @BigBlueHat proposed "JSON-LD data formats" (or simply "JSON-LD formats", as D alteady means "data" 😉 )

[rubensworks]

Upon first reading the name "Linked Data Formats", I thought the goal was also to bring other formats such as Turtle, RDF/XML, and so on under the scope of this WG. But this doesn't seem to be the cause. I would suspect similar confusion to be raised outside of the WG.

[iherman]

What brings the these formats under the same roof is the fact that these formats add an rdf (a.k.a. linked data) layer on top of an existing and widespread data syntax. On could argue that this is the case of rdf/xml, and that would be true, except that people hardly care about that format anyway.

I am sure someone will find a nice term for that.

[rubensworks]

What brings the these formats under the same roof is the fact that these formats add an rdf (a.k.a. linked data) layer on top of an existing and widespread data syntax.

Perhaps something along the direction of Embedded Linked Data Formats?

[gkellogg]

We discussed this on the last call. We need to find a good name, but basically it’s appropriate for polyglot formats that can be reduced to some variation of our internal representation. This explicitly does not include other established RDF formats.

“Embedded” is a loaded term, and also describes how scripts may be embedded in HTML using the script element.

[pchampin]

formats that can be reduced to some variation of our internal representation

I believe this is the core criteria, and that's one of my argument for keeping JSON-LD in the name (in addition to showing continuity and avoiding confusion).

[TallTed]

For your consideration...

Linked Data Formats Working Group, shorthand LDF-WG.

JSON-LD, CBOD-LD, etc., can be a subheading on all relevant pages/documents. (I considered a parenthetical after "Formats" but that doesn't read well.)

[TallTed]

For your consideration...

JSON-LD and Related Formats Working Group, shorthand JSON-LD-WG.

[BigBlueHat]

For your consideration...

JSON-LD and Related Formats Working Group, shorthand JSON-LD-WG.

Maybe...
JSON-LD Linked Data Formats Working Group

[niklasl]

One thing that's bugged me is that, hitherto, JSON-LD allows you to use only JSON tooling, but if a future processor is expected to be able to ingest all formats (e.g. a JSON document referencing a context expressed in YAML), this is no longer the case (and AFAIK, a fully conforming YAML parser is (way) more complex than a JSON parser).

This depends on expected usage contexts of course; we may need to detail some scenarios to draw usable lines around them.

[TallTed]

if a future processor is expected to be able to ingest all formats (e.g. a JSON document referencing a context expressed in YAML

I think a reasonable restriction would be that any external context file must be in the same serialization as the document that references that context. A YAML-based stack should not need to understand JSON or CBOR, etc., but a tool that can translate a JSON-LD document to YAML or CBOR (or vice versa) must obviously understand both serializations.

[pchampin]

if a future processor is expected to be able to ingest all formats (e.g. a JSON document referencing a context expressed in YAML

I think a reasonable restriction would be that any external context file must be in the same serialization as the document that references that context. A YAML-based stack should not need to understand JSON or CBOR, etc., but a tool that can translate a JSON-LD document to YAML or CBOR (or vice versa) must obviously understand both serializations.

This would strongly reduce the usability of YAML-LD if only contexts published as YAML-LD could be used... I would suggest that support for JSON-LD be a baseline, and that additional syntaxes be optional.

[gkellogg]

if a future processor is expected to be able to ingest all formats (e.g. a JSON document referencing a context expressed in YAML

I think a reasonable restriction would be that any external context file must be in the same serialization as the document that references that context. A YAML-based stack should not need to understand JSON or CBOR, etc., but a tool that can translate a JSON-LD document to YAML or CBOR (or vice versa) must obviously understand both serializations.

This would strongly reduce the usability of YAML-LD if only contexts published as YAML-LD could be used... I would suggest that support for JSON-LD be a baseline, and that additional syntaxes be optional.

My feeling is that it depends on what specs an application depends on; if just JSON-LD, then it is only expecting JSON-LD content and contexts. If YAML-LD, then either JSON-LD or YAML-LD content or contexts (or a mixture). If CBOR-LD, then probably only JSON-LD contexts, but could interpret YAML-LD contexts if specifically included by the app, but this could vary between implementations, so not too good for interoperability.

My own default document loads will load based on specific libraries that are loaded alongside the core JSON-LD implementation.

[niklasl]

I agree that YAML-LD processors should also handle JSON-LD. That's probably a minor addition to implementations, but the converse is not generally true. (Aside: JSON is mostly a subset of YAML, but with some potentially gnarly edge-cases like 1e0.)

[iherman]

As far as I am concerned, one of the major advantage of YAML-LD is the ability to produce a much more readable (with the possibility for comments!) version of the context files. The complexity is usually in these context files, and they are also difficult to maintain. Compared to the context, the real data itself is, usually, way simpler.

What these tells me that, ideally, a JSON-LD processor not only SHOULD but MUST be able to import YAML-LD files. (I say "ideally" because I am aware of the difficulties.)

One way of making things a bit simpler is to refrain from using the non-JSON features of YAML. For me, YAML-LD should just be a straight syntax alternative to JSON-LD (comments put aside). In my (limited) experience, this'd mean that an off-the-shelf YAML parser would compile into the same datastructure as what a JSON parser would do, and that would greatly reduce the load.

[niklasl]

JSON is about simplicity, YAML is about convenience. If we mix up these concerns and mandate the latter, the tooling simplicity is lost. Others might claim that like JSON5 strikes the hypothetically better balance, or TOML or Pkl. (Who of course are way younger than YAML, which is older than JSON; though the latter "won" during the XML backlash. S-expressions are still patiently waiting for a comeback.) At that point I'd argue stronger for Turtle, to get rid of all the complex indirection for getting triples out (and that the real(er) problem is vocabulary choice).

I know developers tend to push these boundaries (and IM(NS?)HO sometimes to an alarming fault), and this warrants a discussion about principles, technology stacks and ecosystems. I don't know in what ways the existing deployments of JSON-LD (ActivityStreams, Schema.org, etc.) are consumed, and which of their stacks would appreciate other serializations coming back. There are strong opinions here towards both ends of the spectrum (and beyond). My own work on JSON-LD has always been about finding a workable intersection of these (which has been hard enough).

Without further research, I'd claim that JSON must remain the baseline, and that if others want to author and publish contexts in e.g. YAML, that's fine as long as the serving of that supports Content Negotiation, and serves the JSON form (also implying that you mustn't reference the YAML representation directly as a context, but the information resource you can negotiate on). One argument for that is: if converting between formats is easy and you're willing to mandate all your consumers to do so, lead by example and do so upon publication (which of course spares the consumers from doing it).

(Inserting mandatory principle references for good measure.)

[gkellogg]

As far as I am concerned, one of the major advantage of YAML-LD is the ability to produce a much more readable (with the possibility for comments!) version of the context files. The complexity is usually in these context files, and they are also difficult to maintain. Compared to the context, the real data itself is, usually, way simpler.

Yes, this is a good use case for contexts in YAML-LD.

What these tells me that, ideally, a JSON-LD processor not only SHOULD but MUST be able to import YAML-LD files. (I say "ideally" because I am aware of the difficulties.)

That upsets layering; I don't think we can require that all JSON-LD processors handle YAML-LD, but as designed, all YAML-LD processors must support JSON-LD (including application/ld+json). The community can work to make sure this becomes the norm.

One way of making things a bit simpler is to refrain from using the non-JSON features of YAML. For me, YAML-LD should just be a straight syntax alternative to JSON-LD (comments put aside). In my (limited) experience, this'd mean that an off-the-shelf YAML parser would compile into the same datastructure as what a JSON parser would do, and that would greatly reduce the load.

That's pretty much what's in YAML-LD now, although we've explored "extended" profiles that can use other YAML features, just not currently in the document. CBOR comes with its own set of features.

[anatoly-scherbakov]

Agreed with what has been said above. Let me restate that to be sure that I understand everyone correctly.

• x-LD toolkit should be compliant iff it supports JSON-LD contexts;
• x-LD toolkit is not required to support y-LD context if y ≠ JSON ∧ x ≠ y;
• I propose to address the argument about whether TOML-LD, S-Expression-LD, etc. are preferable over YAML-LD by the statement that, in the ideal world, for each JSON-like language x there should be an x-LD standard.

They do not compete with each other. Linked Data can be thought of as lingua franca, and all x-LD formats contriubte to that purpose.

Unfortunately, quoting of @-keywords in YAML-LD contexts presently cannot be avoided.

"@context":
    owl: https://www.w3.org/2002/07/owl#

    # If we import another ontology its address is an URI
    owl:import:
        "@type": "@id"

That's a nuisance. But even with that, writing contexts with YAML-LD is (IMHO) much more pleasant than writing these things by hand in JSON-LD.

[anatoly-scherbakov]

I like the Linked Data Formats WG name very much.

Should the Community Group also be renamed? Does it somehow relate to the rechartering, and renaming, of the Working Group?

[iherman]

But even with that, writing contexts with YAML-LD is (IMHO) much more pleasant than writing these things by hand in JSON-LD.

We are in agreement on this. But, according your equation (x-LD toolkit is not required to support y-LD context if y ≠ JSON ∧ x ≠ y;), the requirement is such that a JSON-LD tool is not required to support a YAML-LD context, but a YAML-LD tool is required to support a JSON-LD context. That means that, in practice, very few people will write contexts in YAML.

It may be improved if we are very strict in syntactic interoperability of YAML-LD and JSON-LD, i.e., a (putting it in js code) something

JSON.stringify(yaml.parse(yaml_content))

produces a valid and semantically equivalent JSON-LD context. But if we do so, then directly importing a YAML context file into a JSON-LD tool becomes trivial, meaning that we can safely expect a JSON-LD tool to import a YAML context...

I do not expect anyone writing context files in CBOR. CBOR-LD, in my view, is very different from YAML-LD in its audience and usage, and the comparisons are misleading. Also, I do not want to go down the hypothetical x-LD road for other than YAML and CBOR. I am not convinced that any of the other formats would respond to a real need at this point (except maybe JSON5, but that is, from our point of view, trivial).

[anatoly-scherbakov]

very few people will write contexts in YAML

This makes sense, but I personally would rather write a context in YAML-LD but convert it to JSON-LD (which is trivial) for publication. I very well know that JSON-LD toolkits are out there, and they do not support YAML-LD.

Well, I probably would have acted differently if I knew that up-to-date toolkits do support it.

hypothetical x-LD road

Yes, it is very much hypothetical, I do not propose to start working on any such format before YAML-LD and CBOR-LD come to fruition. It is just to keep the possibilities open. To prevent cutting that road off, especially bearing in mind how generic the new WG name is.

[pchampin]

That means that, in practice, very few people will write contexts in YAML.

I disagree. What that implies is that people will not publish contexts in YAML only.
I suspect that many will use YAML-LD to author context, then convert them to JSON-LD or set-up content-negociation when publishing them.
(that's what I would do, anyway)

[BigBlueHat]

@gkellogg @iherman @pchampin this is starting to feel pretty close to ready for heavy critique. 😉 We'll be talking about it today and the rest of August (if/as needed), but let me know if you see anything glaring I may have missed.

Cheers!
🎩

[gkellogg]

This is looking good, at least good enough to merge.

[BigBlueHat]

Merged based on reviews here and confirmation on today's WG call.