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

[pchampin]

"expression" used twice, making the sentence cumbersome.

Suggested change

	<p>This growth in the applied use of JSON-LD has resulted in community interest in additional expressions of
	JSON-LD's underlying Linked Data expression into other formats. YAML-LD has been created by the
	<p>This growth in the applied use of JSON-LD has resulted in community interest in additional expressions of
	JSON-LD's underlying Linked Data structure into other formats. YAML-LD has been created by the

[gkellogg]

Maybe just keep the group title "JSON-LD Working Group" and then expand in the group description, and/or in a subtitle, that it is for JSON and related formats.

[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.)