15:59:43 <RRSAgent> RRSAgent has joined #json-ld
15:59:47 <RRSAgent> logging to https://www.w3.org/2026/03/25-json-ld-irc
15:59:47 <Zakim> RRSAgent, make logs Public
15:59:48 <Zakim> please title this meeting ("meeting: ..."), pchampin
16:00:07 <wes-smith> wes-smith has joined #json-ld
16:00:12 <pchampin> meeting: JSON-LD WG
16:00:17 <pchampin> agenda: https://www.w3.org/events/meetings/de31b974-ca9c-4325-bcea-60b91a1b78d9/20260325T120000/#agenda
16:00:17 <agendabot> clear agenda
16:00:17 <agendabot> agenda+ Announcements and Introductions
16:00:17 <agendabot> agenda+ YAML-LD check-in
16:00:17 <agendabot> agenda+ CBOR-LD Issues
16:00:17 <agendabot> agenda+ Open Discussion
16:00:51 <TallTed> TallTed has joined #json-ld
16:01:21 <niklasl> niklasl has joined #json-ld
16:02:21 <wes-smith> wes-smith has joined #json-ld
16:02:26 <wes-smith> present+
16:02:39 <pchampin> present+
16:03:22 <anatoly-scherbakov> present+
16:03:27 <ivan> present+
16:03:49 <TallTed> present+
16:05:01 <niklasl> present+
16:05:32 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/25-json-ld-minutes.html TallTed
16:06:36 <bigbluehat> bigbluehat has joined #json-ld
16:06:51 <TallTed> chair: bigbluehat
16:08:34 <TallTed> previous meeting: https://www.w3.org/2026/03/18-json-ld-minutes.html
16:08:34 <TallTed> next meeting: https://www.w3.org/2026/04/01-json-ld-minutes.html
16:09:35 <pchampin> scribe+
16:10:18 <pchampin> zakim, open next item
16:10:18 <Zakim> agendum 1 -- Announcements and Introductions -- taken up [from agendabot]
16:10:50 <pchampin> [none]
16:10:53 <pchampin> zakim, open next item
16:10:55 <Zakim> agendum 1 was just opened, pchampin
16:10:59 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/25-json-ld-minutes.html TallTed
16:11:05 <pchampin> zakim, close item 1
16:11:05 <Zakim> agendum 1, Announcements and Introductions, closed
16:11:05 <Zakim> I see 3 items remaining on the agenda; the next one is
16:11:05 <Zakim> 2. YAML-LD check-in [from agendabot]
16:11:05 <pchampin> zakim, open next item
16:11:05 <Zakim> agendum 2 -- YAML-LD check-in -- taken up [from agendabot]
16:11:21 <pchampin> anatoly-scherbakov: several comments on PR, thanks to the commenters
16:11:30 <pchampin> s/on PR/on PRs
16:11:41 <pchampin> ... some PRs merged
16:11:45 <anatoly-scherbakov> https://github.com/w3c/yaml-ld/pull/184
16:11:46 <gb> https://github.com/w3c/yaml-ld/pull/184 -> Pull Request 184 [#36]: Add informative JSON literals section with YAML examples after Scalar Value Types (by anatoly-scherbakov)
16:11:51 <pchampin> this PR needs reviews
16:11:58 <pchampin> s/this/... this
16:12:19 <pchampin> ... one question: as an informal rule that with 2 approvals, I would go and merge the PR
16:12:22 <ivan> q+
16:12:27 <pchampin> ... do we have more formal rules?
16:12:33 <bigbluehat> ack ivan
16:12:38 <bigbluehat> q+
16:12:39 <pchampin> ivan: each WG decides on its own
16:13:26 <pchampin> ... my practice in other WGs is to give a minimum time (usually a week), that plus a number of approval is enough IMO
16:13:39 <pchampin> ... that depends on the PRS (editorial or substantive)
16:13:44 <pchampin> ... labelling PRs is also a good idea
16:13:49 <pchampin> q+
16:14:02 <pchampin> ... if a PR is clearly labelled as editorial, you could have more power
16:14:05 <dlehn> present+
16:14:08 <bigbluehat> ack bigbluehat
16:14:26 <pchampin> bigbluehat: that matches what we have discussed before
16:14:45 <pchampin> ... editorial PRs are "polishing the apple"
16:14:53 <pchampin> ... if something is controversial, it should get call time
16:15:00 <TallTed> +1 minimum PR life of a few working days, preferably a week, before merge
16:15:00 <TallTed> +1 wait for two or more approvals, or no objection during a call with quorum
16:15:10 <pchampin> ... we have a 'needs-discussion' label for marking such PRs
16:15:26 <pchampin> q-
16:15:41 <pchampin> ... I think a week cooldown for a PR is useful
16:15:55 <pchampin> pchampin: +1 to what was said
16:16:22 <pchampin> bigbluehat: is there any PR that you want to draw attention to?
16:16:30 <pchampin> anatoly-scherbakov: not necessarily
16:17:35 <pchampin> ... PR yaml-ld#84 is a clarification about idiomatic YAML representation of JSON literals
16:17:36 <gb> https://github.com/json-ld/yaml-ld/issues/84 -> Issue 84 Downgrading from Extended Internal Representation should use value objects (by gkellogg) [enhancement] [spec] [defer-future-version]
16:17:57 <pchampin> bigbluehat: this is the kind of PR that benefits for more reviews
16:18:14 <ivan> q+
16:18:34 <pchampin> s/yaml-ld#84/yaml-ld#184
16:18:45 <bigbluehat> ack ivan
16:19:33 <pchampin> ivan: I have no problem with this, but is it a general YAML thing, or something specific to what we do?
16:20:20 <bigbluehat> q+
16:20:57 <bigbluehat> ack bigbluehat
16:21:19 <ivan> q+
16:21:31 <pchampin> anatoly-scherbakov: this is related to the use of the `"@type": "@json"`
16:21:32 <ivan> q-
16:21:55 <ivan> +1 to bigbluehat
16:21:57 <pchampin> bigbluehat: I remember an earlier discussion where it was suggested that `@raw` would have been a better name
16:22:25 <pchampin> q+
16:22:29 <niklasl> Makes sense to me to point it out; it needs to be the same subset as or YAML-LD in general.
16:22:30 <bigbluehat> scribe+
16:22:42 <niklasl> s/as or/as for/
16:22:43 <bigbluehat> pchampin: not sure I caught all that
16:23:31 <anatoly-scherbakov> q+
16:23:34 <bigbluehat> ... but the second example is indeed not JSON
16:23:35 <niklasl> (And agreed, it's not json (the serialization) internally in JSON-LD either, it's the internal representation".)
16:23:46 <bigbluehat> ... I agree the `@json` name is misleading
16:23:52 <bigbluehat> ... so, I think having both examples is good
16:24:17 <bigbluehat> ... but the current second example should be updated to be explicitly JSON to help clarify
16:24:22 <bigbluehat> ack pchampin
16:24:52 <bigbluehat> ivan: so what's the problem exactly?
16:25:05 <bigbluehat> pchampin: I want to be sure that any/all of these will be parsed by the YAML parser
16:25:07 <niklasl> +1 to pchampin
16:25:36 <pchampin> anatoly-scherbakov: we can keep only the example that is YAML idiomatic
16:25:36 <bigbluehat> ... and that the `@value` is still parsabl via YAML
16:25:53 <bigbluehat> s/parsabl/properly parsed
16:26:42 <pchampin> s|https://github.com/json-ld/yaml-ld/issues/84 -> Issue 84 Downgrading from Extended Internal Representation should use value objects (by gkellogg) [enhancement] [spec] [defer-future-version]|
16:27:03 <pchampin> bigbluehat: I also find the "WebContent" thing confusing
16:27:12 <anatoly-scherbakov> +1
16:27:18 <pchampin> pchampin: +1 or simply "schema.org description (of a WebContent)"
16:27:57 <bigbluehat> q?
16:28:04 <bigbluehat> ack anatoly-scherbakov
16:28:07 <pchampin> zakim, open next item
16:28:07 <Zakim> agendum 3 -- CBOR-LD Issues -- taken up [from agendabot]
16:28:09 <TallTed> https://schema.org/WebContent is a VERY big bucket
16:28:58 <pchampin> subtopic: https://github.com/w3c/cbor-ld/pull/61
16:28:59 <gb> s|https://github.com/w3c/cbor-ld/pull/61|-> Pull Request 61 Update top-level encoding/decoding algorithms to support uncompressed use cases. (by wes-smith) https://github.com/w3c/cbor-ld/pull/61
16:29:15 <pchampin> wes-smith: we started covering this PR last week
16:29:42 <pchampin> ... it is simple, the algorithm assumes semantic compression, while the text says you don't need to use it
16:30:02 <pchampin> ... the PR adds a top-level condition in the algorithm, testing if semantic compression is present, bypassing that part of it is not
16:30:27 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/25-json-ld-minutes.html TallTed
16:30:59 <bigbluehat> q?
16:31:08 <pchampin> bigbluehat: does it relate to the mailing list conversation at https://lists.w3.org/Archives/Public/public-json-ld-wg/2026Mar/0004.html ?
16:31:16 <TallTed> present+ bigbluehat
16:31:33 <pchampin> wes-smith: it is related, but this PR is not a change in a spec in reaction to the conversation
16:31:41 <pchampin> ... the spec was never intended to impose semantic compression
16:32:20 <pchampin> ... the algorithms were named "compression" and "decompression".
16:32:34 <ivan> q+
16:32:38 <pchampin> ... People not interested in "compression" per se were fairly confused.
16:32:47 <bigbluehat> ack ivan
16:33:07 <pchampin> ivan: what is the use of CBOR-LD without semantic compression?
16:33:21 <pchampin> wes-smith: let's table this question until the next PR
16:33:56 <pchampin> bigbluehat: no objection to merge this?
16:34:07 <pchampin> [none raised]
16:34:27 <pchampin> subtopic: https://github.com/w3c/cbor-ld/pull/63
16:34:27 <gb> s|https://github.com/w3c/cbor-ld/pull/63|-> Pull Request 63 Add discussion of processing model and semantic compression. (by wes-smith) https://github.com/w3c/cbor-ld/pull/63
16:34:42 <pchampin> wes-smith: this is a larger PR, related to ivan's question
16:35:02 <pchampin> ... rewording of the text clarifying the goals of the technology, what you can and can't do with CBOR-LD
16:35:28 <pchampin> ... [comments the summary of the PR]
16:36:24 <pchampin> ... please read the intro of "Basic Concept"; it describes 3 types of compression
16:37:09 <pchampin> ... semantic compression is based on concepts
16:37:13 <pchampin> ...  typed value compression with codec is based on understanding of the datatypes
16:37:28 <pchampin> ... typed value compression with registry is based on static dictionaries
16:37:35 <pchampin> ... each of them is optional
16:38:17 <pchampin> ... there is a "default processing mode" (use semantic compression + codecs described in the scep), but registry entries can override that
16:38:45 <bigbluehat> q?
16:40:03 <bigbluehat> pchampin: what you said about registry entries and what they can specify--especially processing models
16:40:18 <ivan> q+
16:40:22 <bigbluehat> ... is there a way for an implementation to discover everything it needs to do from the registry?
16:40:32 <bigbluehat> ... or do I need to hard code all this in advance?
16:40:37 <bigbluehat> wes-smith: it's an open question
16:40:59 <bigbluehat> ... can we make a machine readable registry such that code could pull down the registry and do the right things
16:41:10 <bigbluehat> ... there's some f that in place now and issues for exploring it further
16:41:29 <bigbluehat> ... there are more challenges, though, if we go that route fully, like expressing logic
16:41:43 <bigbluehat> ... and how we express that logic would be an open question
16:41:56 <bigbluehat> ... it would essentially be a template logic language thing that any implementer could use
16:42:01 <pchampin> q+
16:42:09 <bigbluehat> ... and some of those could be very hard
16:42:20 <bigbluehat> ... and we need to decide if the "juice is worth the squeeze"
16:42:22 <bigbluehat> ack ivan
16:42:51 <pchampin> ivan: I'm a bit worried, beyond the technical details, that we are going in a direction with work work than we can handle
16:43:03 <pchampin> ... we need to setup mechanisms for managing the registry
16:43:19 <pchampin> ... we need a test suite that handles things that are not LD
16:43:28 <wes-smith> q+
16:43:37 <pchampin> q-
16:43:53 <bigbluehat> ack wes-smith
16:43:57 <pchampin> ... is there a way to separate the non-LD things, and make them optional?
16:44:19 <pchampin> wes-smith: that's a good point; we need to think practically on how we want to cut up the work
16:44:29 <ivan> q+
16:44:31 <pchampin> ... at least the basics of what we are discussing are not huge lifts
16:44:39 <bigbluehat> q+
16:44:52 <pchampin> ... opening the doors to a fully machine-readable registry is making things difficult
16:45:13 <pchampin> ... we could say in the spec that users can do whatever they want in the registry
16:46:16 <pchampin> ivan: absolutely; have the concepts clearly put in the document is really good
16:46:37 <pchampin> ... whenever we touch on territory were non-LD applications can do this and this, we should state "but we do not define it"
16:46:42 <pchampin> q+
16:46:45 <wes-smith> +1
16:46:55 <bigbluehat> ack ivan
16:47:00 <pchampin> ... not even defer to future versions
16:47:26 <pchampin> bigbluehat: I'm wondering how to test these things if they are not machine readable
16:47:36 <ivan> q+
16:47:45 <ivan> ack bigbluehat
16:48:10 <pchampin> wes-smith: you take a JSON-LD document and encode it using a dictionary
16:48:34 <pchampin> ... you roundtrip it without collusion between the encoder and the decoder
16:48:59 <ivan> q-
16:49:26 <pchampin> ... let's examine the registry entry 31000000
16:49:48 <pchampin> https://github.com/json-ld/cborld-registry/blob/main/tables/31000000.yml
16:49:52 <ivan> q+
16:50:04 <bigbluehat> q+
16:50:27 <bigbluehat> ack pchampin
16:50:27 <dlehn> q+
16:50:55 <bigbluehat> pchampin: just to be clear. I'm not insisting the registry be fully machine readable, but I agree with ivan that the complexity is likely more that we can handle
16:51:11 <bigbluehat> ... but it would be nice to have some registry entries that point to human readable specifications
16:51:26 <bigbluehat> ... with regard to testing, it would be good to see how that is/will be done
16:51:40 <bigbluehat> ... we could shy away from that and say each registry entry is not ours to test
16:51:51 <bigbluehat> wes-smith: +1 to what you said
16:51:51 <pchampin> wes-smith: +1 to what you said
16:52:27 <pchampin> ... we are discussing which part of the registry can or can't be made machine readable
16:52:40 <pchampin> ... managing the registry does not imply that we have to test each entry
16:53:07 <pchampin> ... a registry entry can even mandate a table that is not included in the entry
16:53:10 <bigbluehat> ack ivan
16:53:49 <pchampin> ivan: thinking out loud; a registry entry like this one could have a link to a specification
16:54:28 <pchampin> ... we could test only the "transparent" registry entries, and explicitly not test the "opaque" ones that point to a specification
16:55:00 <pchampin> wes-smith: I mostly agree; we sort of already have what you are describing
16:55:11 <pchampin> ... entry 0 is default processing mode without semantic compression
16:55:19 <pchampin> ... entry 1 is default processing mode with semantic compression
16:55:40 <pchampin> ... they are implicitly pointing to our specification
16:56:26 <pchampin> bigbluehat: how do we distinguish between the two? 0 and 1 look identical
16:56:42 <bigbluehat> ack bigbluehat
16:56:44 <pchampin> wes-smith: yes, we need to refine the description (boolean flag for semantic compression, list of codecs)
16:57:48 <bigbluehat> ack dlehn
16:58:08 <pchampin> dlehn: are the entries will eventually contain the codecs?
16:58:33 <pchampin> wes-smith: the codecs that we currently use are supposed to go into the spec and be part of the default processing mode
16:58:53 <pchampin> dlehn: some of them are very use-case specific; people may come up with others
16:59:09 <bigbluehat> q+
16:59:18 <pchampin> wes-smith: we still want to provide a default list of codecs, and provide a way to add more in the registry entry
16:59:37 <pchampin> dlehn: maybe some implementations will not implement everything
16:59:56 <bigbluehat> ack bigbluehat
17:00:26 <pchampin> bigbluehat: wes-smith could you draft something about codec expression for the next call?
17:00:54 <pchampin> wes-smith: that would be a usefulthing to do, but I can't promise to do that rapidly
17:01:16 <pchampin> ... you can look at our code
17:01:16 <pchampin> bigbluehat: please send a link to the mailing list
17:01:18 <pchampin> RRSAgent, make minutes
17:01:20 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/25-json-ld-minutes.html pchampin
17:02:37 <pchampin> pchampin has left #json-ld