16:00:48 <RRSAgent> RRSAgent has joined #json-ld
16:00:53 <RRSAgent> logging to https://www.w3.org/2026/04/22-json-ld-irc
16:00:53 <Zakim> RRSAgent, make logs Public
16:00:54 <Zakim> please title this meeting ("meeting: ..."), bigbluehat
16:00:57 <wes-smith> present+
16:00:58 <bigbluehat> meeting: JSON-LD WG
16:00:58 <bigbluehat> chair: bigbluehat
16:00:58 <bigbluehat> present+
16:01:19 <bigbluehat> agenda: https://www.w3.org/events/meetings/6b4e5e27-1b27-4e63-979b-40e90e450949/20260422T120000/
16:01:19 <agendabot> clear agenda
16:01:19 <agendabot> agenda+ Announcements and Introductions
16:01:19 <agendabot> agenda+ YAML-LD check-in
16:01:19 <agendabot> agenda+ CBOR-LD PRs & Issues
16:01:19 <agendabot> agenda+ Open Discussion
16:01:23 <TallTed> present+
16:01:34 <niklasl> niklasl has joined #json-ld
16:03:08 <bigbluehat> Zakim, next item
16:03:08 <Zakim> agendum 1 -- Announcements and Introductions -- taken up [from agendabot]
16:03:09 <ivan> present+
16:03:38 <niklasl> present+
16:03:43 <bigbluehat> scribe+
16:03:55 <bigbluehat> wes-smith: what's the FPWD status for CBOR-LD?
16:04:07 <bigbluehat> ivan: I don't know where it stands
16:04:17 <bigbluehat> ... but the AC meeting in China this week maybe delayed things
16:04:21 <bigbluehat> wes-smith: ah. good to know
16:04:28 <bigbluehat> ivan: they usually approve on Friday's
16:04:33 <bigbluehat> ... so maybe by next week?
16:05:05 <bigbluehat> bigbluehat: I'll check with PA about it
16:05:40 <wes-smith> scribe+
16:05:43 <bigbluehat> Zakim, next item
16:05:43 <Zakim> agendum 2 -- YAML-LD check-in -- taken up [from agendabot]
16:06:04 <wes-smith> ivan: looking at the issue list for the transition request, it was created last week.
16:06:51 <wes-smith> anatoly-scherbakov: we have a big pull request re: extended profiles that separates that into a new document.
16:07:04 <bigbluehat> https://github.com/w3c/yaml-ld/pull/193
16:07:04 <gb> https://github.com/w3c/yaml-ld/issues/193 -> https://github.com/w3c/yaml-ld/pull/193
16:07:07 <wes-smith> ... I have created more tickets from the discussion of that PR.
16:07:33 <wes-smith> ... I also had a thought - there is an ontology for JSON-LD and a namespace for that ontology, and it defines a number of terms.
16:07:50 <wes-smith> ... It also defines profiles of JSON-LD documents. However, I don't know what use cases for which this ontology was created.
16:08:09 <bigbluehat> q+
16:08:12 <ivan> q+
16:08:15 <wes-smith> ... I wonder if a version of that ontology tailored to YAML-LD would be useful.
16:08:19 <bigbluehat> ack ivan
16:08:28 <wes-smith> ivan: I have not seen any usage of that ontology.
16:08:31 <bigbluehat> JSON-LD ontology https://www.w3.org/ns/json-ld
16:08:35 <wes-smith> ... Implementers may have done something.
16:09:19 <wes-smith> bigbluehat: The intention was that JSON-LD contexts are a unique JSON format, as I understand the ontology provides a way to turn contexts into RDF.
16:10:19 <wes-smith> ... Did you have something in mind to use it for?
16:10:19 <bigbluehat> commit history of the ontology https://github.com/w3c/json-ld-wg/commits/dfd1827c95a66bc36c01368e10b6e4f4bbb5c8b3/ns/json-ld.jsonld
16:10:31 <wes-smith> anatoly-scharbakov: I was hoping to describe YAML-LD behavior into an ontology.
16:10:41 <wes-smith> s/scharbakov/scherbakov
16:11:03 <wes-smith> ... I like things to be machine readable.
16:11:14 <niklasl> q+
16:11:16 <wes-smith> ... I created an issue but we might decide to defer to another version.
16:11:30 <bigbluehat> ack bigbluehat
16:11:37 <bigbluehat> subtopic: https://github.com/w3c/yaml-ld/issues/192
16:11:37 <gb> s|https://github.com/w3c/yaml-ld/issues/192|-> https://github.com/w3c/yaml-ld/issues/192 "Issue 192 Create a YAML-LD namespace ontology (similar to https://www.w3.org/ns/json-ld) (by anatoly-scherbakov)"
16:12:11 <wes-smith> niklasl: agree to defer it, it is academic at the moment.
16:12:17 <bigbluehat> q+
16:12:19 <bigbluehat> ack niklasl
16:12:27 <bigbluehat> ack bigbluehat
16:13:46 <wes-smith> bigbluehat: there is value here for working with JSON-LD contexts. will be good to revisit this if we explore it further.
16:13:59 <ivan> q+
16:14:27 <bigbluehat> ack ivan
16:14:54 <wes-smith> ivan: I raised an issue on the YAML spec, #195
16:14:55 <gb> https://github.com/w3c/json-ld-syntax/pull/195 -> MERGED Pull Request 195 Describe that type-scoped contexts are only in affect on the node objects in which they're used (by gkellogg)
16:15:05 <bigbluehat> subtopic: https://github.com/w3c/yaml-ld/issues/195
16:15:06 <gb> s|https://github.com/w3c/yaml-ld/issues/195|-> Issue 195 Move anchors & aliases to Extended Profile? (by anatoly-scherbakov) [needs discussion] https://github.com/w3c/yaml-ld/issues/195
16:15:22 <anatoly-scherbakov> q+
16:15:31 <bigbluehat> q+
16:15:41 <wes-smith> ... my goal is to make things as simple as possible and make YAML-LD human friendly. The current structure, with anchors/aliases, is the only thing in the spec that is not a JSON feature.
16:16:00 <wes-smith> ... I was wondering if we want to do that.
16:16:01 <bigbluehat> ack anatoly-scherbakov
16:16:09 <niklasl> +1 from me (same motivation)
16:18:10 <wes-smith> anatoly-scherbakov: I agree that this feature is unusual compared to JSON but I would be hesitant to forbid it because it is useful in contexts. If we forbid these, YAML parsers might break.
16:18:46 <wes-smith> ... Usually parsers have extension points/customizability, but I'm not sure how standard it is to disable a YAML feature.
16:19:14 <niklasl> q+
16:19:28 <wes-smith> ... Currently anchors and aliases are transparent from the spec's POV - we rely upon the yaml parser to do so.
16:20:29 <wes-smith> ... Currently we do not assign semantic meaning to YAML tags - we say this is up to the parser.
16:20:49 <wes-smith> ... The parser will fail if it encounters an unknown tag.
16:20:53 <bigbluehat> ack bigbluehat
16:21:59 <ivan> q+
16:22:02 <wes-smith> bigbluehat: The advantage is not repeating yourself, the disadvantage is text-based parsing.
16:22:39 <wes-smith> ... I'll put an example up.
16:22:49 <bigbluehat> ack niklasl
16:22:58 <wes-smith> niklasl: I agree with anatoly-scherbakov, I wouldn't want the spec to advise altering parsers.
16:23:24 <bigbluehat> q+
16:23:55 <anatoly-scherbakov> q+
16:23:59 <wes-smith> ... YAML is also allowed to have cycles, which we need to restrict.
16:24:14 <bigbluehat> ack ivan
16:25:12 <wes-smith> ivan: clearly we cannot just say "it's forbidden", so maybe what we can do is say "if you use this feature you get something that is different from the JSON-LD equivalent".
16:25:43 <niklasl> +1 to ivan to call this out
16:25:49 <bigbluehat> ack bigbluehat
16:27:11 <wes-smith> bigbluehat: in my head I've had it positioned between YAML and JSON - run YAML parse with some settings to constrain the schema - so that it's constrained YAML parsing, then do other errors/warnings based on that internal representation.
16:27:26 <bigbluehat> ack anatoly-scherbakov
16:28:05 <wes-smith> anatoly-scherbakov: That's what we suggest doing, parse YAML with certain settings/version, we specifically say that cycles are not allowed, and we say that some documents are not round trappable.
16:28:16 <wes-smith> bigbluehat: wouldn't that mean the YAML is invalid?
16:28:44 <wes-smith> anatoly-scherbakov: If the YAML document contains a cycle it is not YAML-LD. Cycles are forbidden. Anchors/aliases without cycles are valid YAML-LD but are not roundtrippable.
16:28:50 <bigbluehat> q+
16:29:58 <ivan> q+
16:30:04 <ivan> ack bigbluehat
16:30:07 <bigbluehat> ack bigbluehat
16:30:29 <bigbluehat> bigbluehat: did we ever want YAML-LD w/anchors => JSON-LD to "round trip" back to YAML-LD w/anchors?
16:30:44 <bigbluehat> ivan: I'd certainly want to use anchors in a complicated context file
16:31:02 <bigbluehat> ... I know I need to generate a JSON-LD context that was fully "hydrated"
16:31:05 <bigbluehat> q+
16:31:08 <bigbluehat> ack ivan
16:31:12 <anatoly-scherbakov> q+
16:31:35 <bigbluehat> bigbluehat: you'll loose anchors only, correct
16:31:52 <dlehn> present+
16:31:56 <ivan> ack bigbluehat
16:32:09 <anatoly-scherbakov> bigbluehat: json-ld ecosystem should only carry around json-ld contexts
16:32:24 <anatoly-scherbakov> bigbluehat: json-ld is in the middle and other formats circle around it
16:32:48 <anatoly-scherbakov> bigbluehat: yaml-ld contexts referenced from CBOR-LD registry mean we have a combinatorial explosion
16:33:52 <anatoly-scherbakov> bigbluehat: getting back from a JSON-LD doc to something with anchors might be a stylistic choice
16:34:03 <wes-smith> bigbluehat: I feel like it's a feature unrelated to the practical use of JSON-LD.
16:34:09 <anatoly-scherbakov> * thanks Wes!
16:34:21 <wes-smith> ... You could use any number of other scripts, that's not the responsibility of the JSON-LD layer.
16:34:39 <ivan> q+
16:35:21 <wes-smith> ... the "rehydrated" document with anchors in it is a side quest that is unrelated to the JSON-LD ecosystem, but there is nothing that I've heard that says we shouldn't allow it. I do have an ambient fear about cycles.
16:35:26 <wes-smith> q+
16:35:39 <bigbluehat> ack anatoly-scherbakov
16:35:58 <bigbluehat> q+
16:36:01 <wes-smith> anatoly-scherbakov: I wanted to mention that anchors/aliases are not the only thing that prevents roundtrippability etc - another is comments.
16:36:02 <wes-smith> q-
16:36:18 <wes-smith> ... there are also YAML streams where you can put multiple documents in a single file.
16:36:45 <wes-smith> ... We would have to create an ontology to describe those minutia.
16:36:57 <wes-smith> ... There are also formatting differences, like per-line list items.
16:37:28 <bigbluehat> ack ivan
16:37:28 <wes-smith> ... byte-to-byte roundtrips are difficult and messy.
16:38:06 <wes-smith> ivan: We all agree that there should be a callout in the spec telling users to be careful with features that are not in JSON-LD.
16:39:11 <wes-smith> bigbluehat: Historically YAML processing has been a hot topic within W3C.
16:39:48 <wes-smith> ... The takeaway as I understand it is not that it should move to the extended profile, but that we need to say "you can do this but be careful".
16:40:06 <wes-smith> ... We should not implicitly or accidentally suggest that JSON-LD is going to carry the water for any part of the YAML-LD processing model.
16:41:22 <bigbluehat> ack bigbluehat
16:41:59 <bigbluehat> Zakim, next agenda
16:41:59 <Zakim> agendum 3 -- CBOR-LD PRs & Issues -- taken up [from agendabot]
16:42:24 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/pull/75
16:42:24 <gb> s|https://github.com/w3c/cbor-ld/pull/75|-> https://github.com/w3c/cbor-ld/issues/75 "https://github.com/w3c/cbor-ld/pull/75"
16:42:31 <bigbluehat> bigbluehat: yeah...I still need to finish that one
16:44:14 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/issues/71
16:44:14 <gb> s|https://github.com/w3c/cbor-ld/issues/71|-> Issue 71 Discrepancy between the spec and the current registry? (by iherman) https://github.com/w3c/cbor-ld/issues/71
16:44:24 <bigbluehat> wes-smith: ivan noted a discrepency
16:44:31 <bigbluehat> ... with which I agree
16:44:37 <bigbluehat> ... things are still under discussion
16:44:48 <bigbluehat> ... so once some of that is settled, we can make the text(s) match
16:45:00 <bigbluehat> ... not sure this needs discussion so much as time
16:45:08 <bigbluehat> ... so I will tag this as editorial
16:45:20 <bigbluehat> ... probably class 2 since it doesn't change the function of the document
16:45:44 <bigbluehat> ivan: are there definitions changing?
16:46:18 <bigbluehat> wes-smith: yes, they do change
16:46:24 <bigbluehat> bigbluehat: don't bother with picking classes.
16:46:30 <bigbluehat> ... just pick "editorial"
16:46:45 <bigbluehat> wes-smith: I think other issues will make this one happen tangentially
16:47:18 <bigbluehat> ... so, yes, this is an issue, but likely to be addressed by other PRs indirectly
16:47:40 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/issues/67
16:47:40 <gb> s|https://github.com/w3c/cbor-ld/issues/67|-> Issue 67 Example needed to demonstrate the difference between forms of compression (by wes-smith) https://github.com/w3c/cbor-ld/issues/67
16:47:43 <VictorLu> VictorLu has joined #json-ld
16:47:54 <bigbluehat> wes-smith: this one is about different approaches to compression
16:48:04 <bigbluehat> ... we need an example that takes the same JSON-LD document
16:48:13 <bigbluehat> ... and runs it through different compression approaches
16:48:34 <bigbluehat> ... and shows the compression difference based on which algorithm(s) were active
16:48:38 <bigbluehat> q?
16:48:47 <bigbluehat> ... marking this one as editorial
16:49:06 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/issues/66
16:49:07 <gb> s|https://github.com/w3c/cbor-ld/issues/66|-> Issue 66 Algorithms should use <var> instead of <code> (by pchampin) [editorial:class 1] https://github.com/w3c/cbor-ld/issues/66
16:49:17 <bigbluehat> wes-smith: this is just an editorial change in HTML tags
16:49:21 <bigbluehat> ... help welcome!
16:49:30 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/issues/65
16:49:31 <gb> s|https://github.com/w3c/cbor-ld/issues/65|-> Issue 65 The spec lacks a "terminology" section (by pchampin) [substantive:class 3] https://github.com/w3c/cbor-ld/issues/65
16:49:41 <bigbluehat> wes-smith: this one is tagged as substantive
16:50:05 <bigbluehat> ... am I understanding that these just need to be made linkable?
16:50:13 <bigbluehat> ivan: yes, they need clear definitions for the terms
16:50:24 <bigbluehat> ... it's also editorial
16:50:50 <bigbluehat> ... it's done in all/most W3C specs
16:50:56 <bigbluehat> wes-smith: good to note
16:51:05 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/issues/64
16:51:06 <gb> s|https://github.com/w3c/cbor-ld/issues/64|-> https://github.com/w3c/cbor-ld/issues/64 "Issue 64 Codecs: discussion, algorithms, registry example. (by wes-smith) [needs discussion]"
16:51:12 <bigbluehat> wes-smith: this one surrounds codecs
16:51:23 <bigbluehat> ... it's about compressing typed values
16:51:39 <bigbluehat> ... we need to add the codecs that will be part of the base processing model
16:51:50 <bigbluehat> ... and clarify what the base processing model is fully
16:52:02 <bigbluehat> ... as well as how to define other codecs in the registry
16:52:06 <bigbluehat> ... any questions?
16:52:25 <bigbluehat> ... k. removing the "needs discussion" label
16:52:35 <bigbluehat> ... and adding "substantive" and "Priority 1"
16:52:44 <bigbluehat> ... as this needs to happen as it's a core feature
16:53:05 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/issues/29
16:53:06 <gb> s|https://github.com/w3c/cbor-ld/issues/29|-> Issue 29 Ensure "processing model" is included as a registry entry option (by dlongley) [editorial] https://github.com/w3c/cbor-ld/issues/29
16:53:18 <bigbluehat> wes-smith: this is another "collateral damage" issue
16:53:35 <bigbluehat> ivan: collateral, but not damage!
16:53:41 <bigbluehat> bigbluehat: "collateral benefit"?
16:53:54 <bigbluehat> wes-smith: collaterally closable
16:54:08 <bigbluehat> ... many of the rest of the issues fall into this category
16:54:19 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/issues/46
16:54:19 <gb> s|https://github.com/w3c/cbor-ld/issues/46|-> Issue 46 Define registration process (by dlongley) https://github.com/w3c/cbor-ld/issues/46
16:54:39 <bigbluehat> wes-smith: removing the "needs discussion" label since we talked about this one
16:55:04 <bigbluehat> ... adding a "substantive" label instead
16:55:09 <bigbluehat> ... well...
16:55:51 <bigbluehat> ivan: definitely "substantive" since we can't move ahead without this
16:55:55 <bigbluehat> bigbluehat: the spec depends on it
16:56:01 <bigbluehat> wes-smith: thank you for the help
16:56:06 <bigbluehat> ... still getting good at labels
16:56:13 <bigbluehat> ... I think that's it for today, then
16:56:24 <bigbluehat> ... bigbluehat we that links PR
16:56:31 <bigbluehat> Zakim, next item
16:56:31 <Zakim> agendum 4 -- Open Discussion -- taken up [from agendabot]
16:56:52 <bigbluehat> bigbluehat: short bit on PyLD from anatoly-scherbakov ?
16:57:03 <bigbluehat> anatoly-scherbakov: thanks, was thinking about modular document loaders
16:57:14 <bigbluehat> ... allowing one to install them together
16:57:24 <bigbluehat> ... so YAML-LD would be a plugin to PyLD
16:57:41 <bigbluehat> ... and then other systems could do the same or something similar
16:57:49 <bigbluehat> ... I'll write an issue about it
16:58:17 <bigbluehat> bigbluehat: the idea being that the document loaders would do the document transformation?
16:58:28 <bigbluehat> anatoly-scherbakov: yes, via separate packages/plugins
16:59:18 <dlehn> might want to write up the ideas before coding too much.  finding a good pattern for that sort of design might be tricky.
16:59:37 <ivan> q+
17:00:25 <bigbluehat> bigbluehat: ...there be dragons
17:00:39 <bigbluehat> ivan: the only thing I'm asking is that this doesn't have much to do with this spec
17:02:06 <anatoly-scherbakov> present+
17:02:52 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/22-json-ld-minutes.html TallTed
17:03:06 <bigbluehat> bigbluehat: yeah, it effects the specs in when/how contexts are dereferenced and what we should/can expect them to be
17:03:06 <bigbluehat> ... we're past time...thanks everyone
17:03:07 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/22-json-ld-minutes.html TallTed
17:03:28 <TallTed> Zakim, end meeting
17:03:28 <Zakim> As of this point the attendees have been wes-smith, bigbluehat, TallTed, ivan, niklasl, dlehn, anatoly-scherbakov
17:03:30 <Zakim> RRSAgent, please draft minutes
17:03:31 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/22-json-ld-minutes.html Zakim
17:03:36 <Zakim> I am happy to have been of service, TallTed; please remember to excuse RRSAgent.  Goodbye
17:03:39 <Zakim> Zakim has left #json-ld
17:03:42 <TallTed> RRSAgent, bye
17:03:42 <RRSAgent> I see no action items