– DRAFT –
JSON-LD WG Meeting

Announcements and Introductions

bigbluehat: I had to change the agenda last minute, to focus on YAML-LD, but anatoly-scherbakov is not available today

YAML-LD Issues & PRs

<bigbluehat> https://github.com/w3c/yaml-ld/issues?q=is%3Aissue%20state%3Aopen%20-label%3Adefer-future-version%20-label%3A%22test%3Aneeds%20tests%22

bigbluehat: this is a somewhat filtered list of YAML-LD issues
… 2 PRs, one very old and one stalled in discussion
… two issues are very research oriented: w3c/yaml-ld#57 and w3c/yaml-ld#16

<gb> Issue 16 study CBOR-LD (by VladimirAlexiev)

<gb> Issue 57 YARRRML Lessons learned (by bjdmeest) [UCR]

bigbluehat: interesting things to do but not directly related to the spec
… I will tag them as "propose closing" them if noone objects
… there is a lot of use-case related issues
… has anyone done a YAML-LD implementation on this call?
… I know anatoly-scherbakov has one, and Gregg had another

<pchampin> for the record, I have one very partial and hacky implementation

bigbluehat: YAML-LD has schemas, used to enforce compatibility with other downstream consumers
… the YAML-LD focuses on the core schema, which is broader than the JSON schema
… does anyone remember why that was the case?

[nobody seems to remember]

bigbluehat: I would like more people having a look at the spec; it is not very long

<TallTed> it'll happen ... eventually

bigbluehat: Practically speaking, what it is doing is converting YAML to JSON, then processing the JSON
… wonder is someone implemented it with a YAML parser, without going through JSON
… Note that most of the YAML superpower are only handled in the appendix

ivan: do we or will we have round-trip tests?

bigbluehat: I believe for the most part, it uses the JSON-LD test suite under the hood

ivan: in other words, what is exactly our CR exit criteria?
… When we publish a CR snapshot, they have to be explicitly include them in the Status of this document

bigbluehat: we are not there yet

<TallTed> weird... https://w3c.github.io/yaml-ld/ is not loading stylesheets, so it renders *very* ugly and without the index sidebar

pchampin: the first public working draft should be published tomorrow

bigbluehat: note that the JSON-LD-next playground has a YAML-LD playground and a CBOR-LD playground
… Gregg requested some day to have all RDF formats there, but that would be a different playground

<niklasl> +1 (the internal data model, 1:1 with the JSON datatypes)

pchampin: note that JSON-LD is defined in terms on an "internal data model"
… so what YAML-LD does is actually specify how YAML maps to the internal data model; the rest is standard JSON-LD processing
… but you don't need to serialize YAML to JSON before you can apply JSON-LD processing

bigbluehat: in the exampes, YAML-LD files use the schema.org context, which is JSON-LD
… so YAML-LD processors are expected to accept JSON-LD contexte; the opposite is probably true
… publishing contexts in YAML-LD is attractive, especially with the transclusion feature

<ivan> +1 to pchampin

<niklasl> JSON-LD processors must not require YAML parsing. I'm not keen on YAML on the Web in general, the format is too complex, and tooling interop is sub-par.

pchampin: for me this should be handled by the document loader, which deserves to be described in more details in the spec
… (also to emphasize that it is not expected to always *load* from the web for well known contexts)

ivan: I presume this should also be true for CBOR-LD

bigbluehat: I assume so.
… there is a trend (in VC, WoT...) to encourage people to write document loaders that never fetch data

niklasl: are we saying that JSON-LD processors should be able to process YAML?

bigbluehat: what we are saying is that "document loading" is a kind of known plugin to JSON-LD parsers
… if it is seen as pluggable, then several processors could use it

niklasl: I would be -1 on suggesting that all JSON-LD processors should support YAML

dlehn: are we talking about contexts?

bigbluehat: contexts are the pivot point, but it could be any document.

dlehn: contexts and document are very different. contexts are pure JSON, not RDF.

bigbluehat: one thing we could do is to require that contexts are always *published* in JSON-LD
… people could of course *write* them in YAML-LD

<niklasl> +1

bigbluehat: we don't want a YAML-LD world distinct from the JSON-LD world
… if you write all your stuff in YAML-LD and push them online, what pushes you to ensure that your context files in JSON?
… it boils down to "whose issue does it become?"

pchampin: we do have this situation in RDF already
… we have Turtle, N3, RDF/XML, etc.
… and most processors are expected to handle many/most of them

<ivan> +1 to pchampin it is very similar

pchampin: and maybe...that's where we'd end up with the context
… not sure if we want to avoid it or embrace it

niklasl: JSON-LD came about to make their RDF data available to consumer without RDF tooling
… I don't think we want to go back to the RDF situation
… JSON has become the lowest common denominator
… Postel's law: be strict with what you produce

bigbluehat: looking at Example 1 in the YAML-LD spec, the remote context has a .jsonld extension
… so we would have (YAML/CBOR)-LD parsers that MUST support JSON and MAY support other fomats

anatoly-scherbakov: are we converging on a "star-shaped" architecture? YAML-LD and CBOR-LD would be required to parse JSON-LD contexts (plus contexts in their own specific syntax)
… but a CBOR-LD parser would not be required to support YAML-LD contexts

bigbluehat: that's what we seem to converge, yes, although Postel's law allows shortcut between "satellites" (CBOR-LD parser accepting YAML-LD)

<niklasl> Sounds fair.

anatoly-scherbakov: I have been thinking about having a pluggable system for the PyLD document loader
… so adding a given python package could add support for YAML-LD or CBORD-LD in that loader

dlehn: most library already support passing a function as document loader
… I would not add more complexity
… I assume all implementations have a naive document loader that fetches all the time

bigbluehat: I think we are converging on a "hub" model, where YAML-LD and CBOR-LD are orbitting the more central JSON-LD
… I think that the fact that many JSON-LD libraries fetch contexts from the web give feed the JSON-LD haters
… we need to call that out more clearly and more often

niklasl: we need to address issues regarding security, which this is related to
… we should put this on the agenda soon

<ivan> +1 to niklas; security issue is the main "attack vector" against json-ld

niklasl: my advice would be: either ship your context with your data, or rely on standard frozen contexts
… do not rely on someone else's context, who may update it unexpectedly

<bigbluehat> https://w3c.github.io/json-ld-api/#remote-document-and-context-retrieval

pchampin: so "do not use the schema.org context" :)

bigbluehat: there is a tension
… note that people could in theory use URLs of fixed releases of schema.org, even if nobody does it

<niklasl> I'd looked a bit more at https://www.ietf.org/archive/id/draft-farrell-decade-ni-00.html

bigbluehat: anatoly-scherbakov, we discussed the relevance of having round-trip test
… it would also be good to be more explicit about how to run the tests

anatoly-scherbakov: I believe that every implementation develop their own test runner
… maybe a language-agnostic runner would be possible

bigbluehat: thanks everybody
… we will probably split the next call between the Document Loader discussion and CBOR-LD