17:02:12 <RRSAgent> RRSAgent has joined #json-ld
17:02:16 <RRSAgent> logging to https://www.w3.org/2026/03/04-json-ld-irc
17:02:16 <TallTed> TallTed has changed the topic to: JSON-LD WG -- 2026-03-04 agenda: https://www.w3.org/events/meetings/de31b974-ca9c-4325-bcea-60b91a1b78d9/20260304T120000/
17:02:16 <Zakim> RRSAgent, make logs Public
17:02:17 <Zakim> please title this meeting ("meeting: ..."), bigbluehat
17:02:24 <pchampin> present+
17:02:30 <bigbluehat> present+
17:02:36 <bigbluehat> chair+
17:02:50 <TallTed> agenda: https://www.w3.org/events/meetings/de31b974-ca9c-4325-bcea-60b91a1b78d9/20260304T120000/
17:02:50 <agendabot> clear agenda
17:02:50 <agendabot> agenda+ Announcements and Introductions
17:02:50 <agendabot> agenda+ YAML-LD Issues & PRs
17:02:50 <agendabot> agenda+ Open Discussion
17:03:00 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/04-json-ld-minutes.html TallTed
17:04:24 <bigbluehat> Zakim, next item
17:04:24 <Zakim> agendum 1 -- Announcements and Introductions -- taken up [from agendabot]
17:04:30 <niklasl> present+
17:04:43 <TallTed> TallTed has joined #json-ld
17:05:25 <ajs6f> ajs6f has joined #json-ld
17:05:45 <ivan> present+
17:06:09 <pchampin> scribe+
17:06:54 <pchampin> bigbluehat: I had to change the agenda last minute, to focus on YAML-LD, but anatoly-scherbakov is not available today
17:06:57 <ajs6f> present+
17:07:25 <bigbluehat> Zakim, next item
17:07:25 <Zakim> agendum 2 -- YAML-LD Issues & PRs -- taken up [from agendabot]
17:07:31 <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
17:07:41 <TallTed> present+
17:07:43 <TallTed> meeting: JSON-LD WG Meeting
17:07:52 <TallTed> previous meeting: https://www.w3.org/2026/02/25-json-ld-minutes.html
17:07:52 <pchampin> bigbluehat: this is a somewhat filtered list of YAML-LD issues
17:07:52 <TallTed> next meeting: https://www.w3.org/2026/03/11-json-ld-minutes.html
17:07:52 <pchampin> present+
17:07:57 <dlehn> present+
17:08:01 <pchampin> ... 2 PRs, one very old and one stalled in discussion
17:08:57 <pchampin> ... two issues are very research oriented: w3c/yaml-ld#57 and w3c/yaml-ld#16
17:08:58 <gb> https://github.com/w3c/yaml-ld/issues/16 -> Issue 16 study CBOR-LD (by VladimirAlexiev)
17:08:58 <gb> https://github.com/w3c/yaml-ld/issues/57 -> Issue 57 YARRRML Lessons learned (by bjdmeest) [UCR]
17:09:06 <pchampin> ... interesting things to do but not directly related to the spec
17:09:16 <pchampin> ... I propose closing them if noone objects
17:09:37 <pchampin> s/propose closing/will tag them as "propose closing"
17:09:40 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/04-json-ld-minutes.html TallTed
17:09:54 <pchampin> ... there is a lot of use-case related issues
17:10:08 <pchampin> ... has anyone done a YAML-LD implementation on this call?
17:10:17 <pchampin> ... I know anatoly-scherbakov has one, and Gregg had another
17:10:21 <pchampin> q+
17:10:40 <pchampin> q-
17:10:54 <pchampin> <pchampin> for the record, I have one very partial and hacky implementation
17:11:29 <TallTed> present+ VictorLu
17:11:30 <pchampin> bigbluehat: YAML-LD has schemas, used to enforce compatibility with other downstream consumers
17:11:37 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/04-json-ld-minutes.html TallTed
17:11:48 <pchampin> ... the YAML-LD focuses on the core schema, which is broader than the JSON schema
17:12:09 <pchampin> ... does anyone remember why that was the case?
17:12:45 <pchampin> [nobody seems to remember]
17:13:04 <pchampin> bigbluehat: I would like more people having a look at the spec; it is not very long
17:13:13 <TallTed> it'll happen ... eventually
17:13:42 <pchampin> ... Practically speaking, what it is doing is converting YAML to JSON, then processing the JSON
17:14:10 <pchampin> ... wonder is someone implemented it with a YAML parser, without going through JSON
17:14:23 <ivan> q+
17:14:29 <bigbluehat> ack ivan
17:14:36 <pchampin> ... Note that most of the YAML superpower are only handled in the appendix
17:14:57 <pchampin> ivan: do we or will we have round-trip tests?
17:15:34 <pchampin> bigbluehat: I believe for the most part, it uses the JSON-LD test suite under the hood
17:15:49 <pchampin> ivan: in other words, what is exactly our CR exit criteria?
17:17:52 <pchampin> ... When we publish a CR snapshot, they have to be explicitly include them in the Status of this document
17:18:02 <pchampin> bigbluehat: we are not there yet
17:18:42 <TallTed> weird... https://w3c.github.io/yaml-ld/ is not loading stylesheets, so it renders *very* ugly and without the index sidebar
17:19:03 <pchampin> pchampin: the first public working draft should be published tomorrow
17:20:04 <pchampin> bigbluehat: note that the JSON-LD-next playground has a YAML-LD playground and a CBOR-LD playground
17:20:34 <pchampin> ... Gregg requested some day to have all RDF formats there, but that would be a different playground
17:21:04 <pchampin> q+
17:21:21 <bigbluehat> ack pchampin
17:23:10 <niklasl> +1 (the internal data model, 1:1 with the JSON datatypes)
17:23:25 <pchampin> pchampin: note that JSON-LD is defined in terms on an "internal data model"
17:23:50 <pchampin> ... so what YAML-LD does is actually specify how YAML maps to the internal data model; the rest is standard JSON-LD processing
17:24:06 <pchampin> ... but you don't need to serialize YAML to JSON before you can apply JSON-LD processing
17:24:47 <pchampin> bigbluehat: in the exampes, YAML-LD files use the schema.org context, which is JSON-LD
17:25:05 <pchampin> ... so YAML-LD processors are expected to accept JSON-LD contexte; the opposite is probably true
17:25:16 <pchampin> q+
17:25:47 <bigbluehat> ack pchampin
17:25:55 <pchampin> ... publishing contexts in YAML-LD is attractive, especially with the transclusion feature
17:26:59 <ivan> +1 to  pchampin
17:27:19 <ivan> q+
17:27:57 <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.
17:28:04 <pchampin> pchampin: for me this should be handled by the document loader, which deserves to be described in more details in the spec
17:28:21 <pchampin> ... (also to emphasize that it is not expected to always *load* from the web for well known contexts)
17:28:29 <bigbluehat> ack ivan
17:28:49 <pchampin> ivan: I presume this should also be true for CBOR-LD
17:29:17 <pchampin> bigbluehat: I assume so.
17:30:10 <pchampin> ... there is a trend (in VC, WoT...) to encourage people to write document loaders that never fetch data
17:30:25 <niklasl> q+
17:30:31 <bigbluehat> ack niklasl
17:31:23 <pchampin> niklasl: are we saying that JSON-LD processors should be able to process YAML?
17:31:39 <dlehn> q+
17:31:43 <pchampin> bigbluehat: what we are saying is that "document loading" is a kind of known plugin to JSON-LD parsers
17:32:22 <pchampin> ... if it is seen as pluggable, then several processors could use it
17:32:37 <bigbluehat> ack dlehn
17:32:48 <pchampin> niklasl: I would be -1 on suggesting that all JSON-LD processors should support YAML
17:33:12 <pchampin> dlehn: are we talking about contexts?
17:33:24 <pchampin> bigbluehat: contexts are the pivot point, but it could be any document.
17:33:48 <pchampin> dlehn: contexts and document are very different. contexts are pure JSON, not RDF.
17:34:18 <pchampin> bigbluehat: one thing we could do is to require that contexts are always *published* in JSON-LD
17:34:26 <pchampin> ... people could of course *write* them in YAML-LD
17:34:39 <niklasl> +1
17:35:38 <pchampin> bigbluehat: we don't want a YAML-LD world distinct from the JSON-LD world
17:36:08 <pchampin> ... if you write all your stuff in YAML-LD and push them online, what pushes you to ensure that your context files in JSON
17:36:13 <pchampin> q+
17:36:22 <anatoly-scherbakov> present+
17:36:40 <pchampin> s/files in JSON/files in JSON?
17:37:10 <bigbluehat> ack pchampin
17:37:11 <pchampin> ... it boils down to "whose issue does it become?"
17:37:49 <bigbluehat> scribe+
17:37:59 <bigbluehat> pchampin: we do have this situation in RDF already
17:38:06 <bigbluehat> ... we have Turtle, N3, RDF/XML, etc.
17:38:15 <bigbluehat> ... and most processors are expected to handle many/most of them
17:38:20 <niklasl> q+
17:38:22 <ivan> +1 to pchampin it is very similar
17:38:26 <bigbluehat> ... and maybe...that's where we'd end up with the context
17:38:43 <bigbluehat> ... not sure if we want to avoid it or embrace it
17:38:50 <bigbluehat> scribe-
17:39:07 <pchampin> niklasl: JSON-LD came about to make their RDF data available to consumer without RDF tooling
17:39:21 <pchampin> ... I don't think we want to go back to the RDF situation
17:39:53 <anatoly-scherbakov> q+
17:39:55 <pchampin> ... JSON has become the lowest common denominator
17:39:59 <bigbluehat> ack niklasl
17:40:13 <pchampin> ... Postel's law: be strict with what you produce
17:41:06 <bigbluehat> ack anatoly-scherbakov
17:41:10 <pchampin> bigbluehat: looking at Example 1 in the YAML-LD spec, the remote context has a .jsonld extension
17:41:40 <pchampin> ... so we would have  (YAML/CBOR)-LD parsers that MUST support JSON and MAY support other fomats
17:43:42 <pchampin> 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)
17:43:59 <pchampin> ... but a CBOR-LD parser would not be required to support YAML-LD contexts
17:44:59 <pchampin> bigbluehat: that's what we seem to converge, yes, although Postel's law allows shortcut between "satellites" (CBOR-LD parser accepting YAML-LD)
17:45:11 <niklasl> Sounds fair.
17:45:53 <pchampin> anatoly-scherbakov: I have been thinking about having a pluggable system for the PyLD document loader
17:46:06 <dlehn> q+
17:46:12 <bigbluehat> ack dlehn
17:46:17 <pchampin> ... so adding a given python package could add support for YAML-LD or CBORD-LD in that loader
17:47:02 <pchampin> dlehn: most library already support passing a function as document loader
17:47:09 <pchampin> ... I would not add more complexity
17:49:04 <pchampin> ... I assume all implementations have a naive document loader that fetches all the time
17:50:17 <pchampin> bigbluehat: I think we are converging on a "hub" model, where YAML-LD and CBOR-LD are orbitting the more central JSON-LD
17:50:59 <niklasl> q+
17:51:08 <pchampin> ... I think that the fact that many JSON-LD libraries fetch contexts from the web give feed the JSON-LD haters
17:51:14 <bigbluehat> ack niklasl
17:51:19 <pchampin> ... we need to call that out more clearly and more often
17:51:25 <anatoly-scherbakov> q+
17:51:50 <pchampin> niklasl: we need to address issues regarding security, which this is related to
17:52:02 <pchampin> ... we should put this on the agenda soon
17:52:21 <ivan> +1 to niklas; security issue is the main "attack vector" against json-ld
17:52:54 <pchampin> ... my advice would be: either ship your context with your data, or rely on standard frozen contexts
17:53:16 <pchampin> ... do not rely on someone else's context, who may update it unexpectedly
17:53:49 <bigbluehat> https://w3c.github.io/json-ld-api/#remote-document-and-context-retrieval
17:55:31 <pchampin> pchampin: so "do not use the schema.org context" :)
17:55:35 <pchampin> bigbluehat: there is a tension
17:55:57 <pchampin> ... note that people could in theory use URLs of fixed releases of schema.org, even if nobody does it
17:56:10 <niklasl> I'd looked a bit more at https://www.ietf.org/archive/id/draft-farrell-decade-ni-00.html
17:56:12 <pchampin> RRSAgent, make minutes
17:56:14 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/04-json-ld-minutes.html pchampin
17:57:19 <pchampin> bigbluehat: anatoly-scherbakov, we discussed the relevance of having round-trip test
17:57:39 <pchampin> ... it would also be good to be more explicit about how to run the tests
17:58:06 <pchampin> anatoly-scherbakov: I believe that every implementation develop their own test runner
17:59:02 <pchampin> ... maybe a language-agnostic runner would be possible
17:59:21 <pchampin> bigbluehat: thanks anybody
17:59:46 <pchampin> ... we will probably split the next call between the Document Loader discussion and CBOR-LD
17:59:53 <pchampin> s/anybody/everybody
18:00:15 <pchampin> RRSAgent, make minutes
18:00:17 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/04-json-ld-minutes.html pchampin