15:59:25 <RRSAgent> RRSAgent has joined #json-ld
15:59:29 <RRSAgent> logging to https://www.w3.org/2026/03/18-json-ld-irc
15:59:29 <Zakim> RRSAgent, make logs Public
15:59:30 <Zakim> please title this meeting ("meeting: ..."), bigbluehat
15:59:44 <bigbluehat> meeting: JSON-LD WG
15:59:44 <bigbluehat> chairs: bigbluehat, VictorLu
16:00:00 <bigbluehat> present+
16:00:21 <bigbluehat> agenda: https://www.w3.org/events/meetings/de31b974-ca9c-4325-bcea-60b91a1b78d9/20260318T120000/
16:00:22 <agendabot> clear agenda
16:00:22 <agendabot> agenda+ Announcements and Introductions
16:00:22 <agendabot> agenda+ YAML-LD PR check-in
16:00:22 <agendabot> agenda+ CBOR-LD Issues
16:00:22 <agendabot> agenda+ Open Discussion
16:00:27 <anatoly-scherbakov> present+
16:00:34 <pchampin> present+
16:00:55 <bigbluehat> chair: bigbluehat
16:00:58 <bigbluehat> chair: VictorLu
16:01:17 <dlehn> dlehn has joined #json-ld
16:01:17 <denkeni> denkeni has joined #json-ld
16:01:17 <hadleybeeman> hadleybeeman has joined #json-ld
16:01:17 <raboof_> raboof_ has joined #json-ld
16:01:17 <dlongley> dlongley has joined #json-ld
16:01:26 <wes-smith> wes-smith has joined #json-ld
16:01:29 <wes-smith> present+
16:02:40 <ivan> present+
16:03:20 <TallTed> TallTed has joined #json-ld
16:03:20 <dlehn> dlehn has joined #json-ld
16:03:20 <denkeni> denkeni has joined #json-ld
16:03:20 <hadleybeeman> hadleybeeman has joined #json-ld
16:03:20 <raboof_> raboof_ has joined #json-ld
16:03:20 <dlongley> dlongley has joined #json-ld
16:04:06 <niklasl> niklasl has joined #json-ld
16:04:08 <pchampin> scribe+
16:04:50 <ajs6f> ajs6f has joined #json-ld
16:04:50 <TallTed> TallTed has joined #json-ld
16:04:50 <dlehn> dlehn has joined #json-ld
16:04:50 <denkeni> denkeni has joined #json-ld
16:04:50 <hadleybeeman> hadleybeeman has joined #json-ld
16:04:50 <raboof_> raboof_ has joined #json-ld
16:04:50 <dlongley> dlongley has joined #json-ld
16:06:00 <bigbluehat> Zakim, next item
16:06:00 <Zakim> agendum 1 -- Announcements and Introductions -- taken up [from agendabot]
16:06:29 <bigbluehat> Zakim, close item
16:06:29 <Zakim> I don't understand 'close item', bigbluehat
16:06:34 <bigbluehat> Zakim, next item
16:06:34 <Zakim> agendum 1 was just opened, bigbluehat
16:06:38 <ajs6f> ajs6f has joined #json-ld
16:06:38 <TallTed> TallTed has joined #json-ld
16:06:38 <dlehn> dlehn has joined #json-ld
16:06:38 <denkeni> denkeni has joined #json-ld
16:06:38 <hadleybeeman> hadleybeeman has joined #json-ld
16:06:38 <raboof_> raboof_ has joined #json-ld
16:06:38 <dlongley> dlongley has joined #json-ld
16:06:51 <pchampin> zakim, close agendum 1
16:06:51 <Zakim> agendum 1, Announcements and Introductions, closed
16:06:52 <Zakim> I see 3 items remaining on the agenda; the next one is
16:06:52 <Zakim> 2. YAML-LD PR check-in [from agendabot]
16:06:55 <bigbluehat> Zakim, agendum 2
16:06:55 <Zakim> I don't understand 'agendum 2', bigbluehat
16:07:00 <pchampin> zakim, next item
16:07:00 <Zakim> agendum 2 -- YAML-LD PR check-in -- taken up [from agendabot]
16:07:07 <ajs6f> present+
16:07:28 <niklasl> present+
16:07:32 <bigbluehat> https://github.com/w3c/yaml-ld/pulls
16:07:33 <ajs6f> ajs6f has joined #json-ld
16:07:33 <TallTed> TallTed has joined #json-ld
16:07:33 <dlehn> dlehn has joined #json-ld
16:07:33 <denkeni> denkeni has joined #json-ld
16:07:33 <hadleybeeman> hadleybeeman has joined #json-ld
16:07:33 <raboof_> raboof_ has joined #json-ld
16:07:33 <dlongley> dlongley has joined #json-ld
16:08:26 <bigbluehat> subtopic: https://github.com/w3c/yaml-ld/pull/180
16:08:26 <gb> s|https://github.com/w3c/yaml-ld/pull/180|-> Pull Request 180 [#103]: Anchor names do not convey semantic information (by anatoly-scherbakov) https://github.com/w3c/yaml-ld/pull/180
16:09:07 <pchampin> anatoly-scherbakov: this is a simple change.
16:09:14 <dlehn> dlehn has joined #json-ld
16:09:14 <ajs6f> ajs6f has joined #json-ld
16:09:14 <TallTed> TallTed has joined #json-ld
16:09:14 <denkeni> denkeni has joined #json-ld
16:09:14 <hadleybeeman> hadleybeeman has joined #json-ld
16:09:14 <raboof_> raboof_ has joined #json-ld
16:09:14 <dlongley> dlongley has joined #json-ld
16:09:38 <pchampin> ... it confirms that anchor names in YAML-LD have no bearing in the output
16:10:00 <TallTed> q+
16:10:01 <pchampin> ... this PR also adds a note to the spec demonstrating the usefulness of anchors in the JSON-LD context
16:10:51 <bigbluehat> ack TallTed
16:11:20 <pchampin> TallTed: just to confirm that I understand; anchor names are basically equivalent to fragment ids?
16:11:24 <bigbluehat> q+
16:11:47 <pchampin> anatoly-scherbakov: you can fetch fragment IDs, I don't think that you can fetch anchors
16:12:19 <pchampin> TallTed: you actually don't fetch a fragment; you fetch the whole document, and then find the fragment ID in it
16:12:45 <pchampin> ... I don't understand what an anchor name is, where it is defined.
16:12:50 <pchampin> bigbluehat: it is a YAML thing.
16:12:57 <pchampin> q+
16:13:35 <pchampin> bigbluehat demonstrates anchors in transform.tools
16:13:39 <bigbluehat> ack bigbluehat
16:14:00 <bigbluehat> ack pchampin
16:14:11 <bigbluehat> scribe+
16:14:19 <bigbluehat> pchampin: there are two sides to TallTed's question
16:14:30 <bigbluehat> ... maybe they work like fragment IDs...I don't know
16:14:34 <bigbluehat> ... we'd have to check
16:14:49 <bigbluehat> ... because it may be possible to use an anchor name as a fragment identifier in a URL
16:15:09 <bigbluehat> ... but how it's being used in this example is from the "macro" case
16:15:20 <bigbluehat> ... where the named content is copied into other locations
16:16:22 <niklasl> +1 It's a part of the data structure, not it's.. ehrm... "semantics" (afaict)
16:16:24 <pchampin> TallTed: "anchor" is a bad name, then, but we can not change it so...
16:16:25 <bigbluehat> ... and since the JSON-LD processing happens after the macros
16:16:42 <pchampin> s|TallTed: "anchor" is a bad name, then, but we can not change it so...|
16:16:45 <pchampin> TallTed: "anchor" is a bad name, then, but we can not change it so...
16:17:01 <pchampin> bigbluehat: anatoly-scherbakov maybe we should add some clarifying text to the PR
16:17:04 <bigbluehat> present+
16:17:06 <bigbluehat> q+
16:17:16 <pchampin> anatoly-scherbakov: I like the analogy with macros
16:18:09 <bigbluehat> ack bigbluehat
16:18:42 <pchampin> bigbluehat: and we should avoid the "fragment ID" discussion
16:19:04 <pchampin> anatoly-scherbakov: I will make a seperate PR for the clarification
16:19:50 <pchampin> bigbluehat: we said earlier that contexts should be published in JSON-LD, so examples of contexts in YAML-LD should also make it clear that not all JSON-LD processors are expected to understand those contexts "as is"
16:20:29 <bigbluehat> subtopic: https://github.com/w3c/yaml-ld/pull/182
16:20:29 <gb> s|https://github.com/w3c/yaml-ld/pull/182|-> Pull Request 182 [#181]: YAML-LD requires YAML ⩾ 1.2 (by anatoly-scherbakov) https://github.com/w3c/yaml-ld/pull/182
16:20:53 <ajs6f> Did we not invent Unicode?
16:21:40 <pchampin> anatoly-scherbakov: I looked into the changelog of YAML. The most changes appeared between YAML 1.1 and 1.2. The changes in 1.2.1 and 1.2.2 are cosmetic
16:22:17 <bigbluehat> pchampin: I raised https://github.com/w3c/yaml-ld/issues/181 in response to a good bit of negative feedback
16:22:18 <gb> https://github.com/w3c/yaml-ld/issues/181 -> Issue 181 should YAML-LD require YAML ≥ 1.2 ? (by pchampin)
16:22:26 <bigbluehat> ... and many mentions of the "Norway problem"
16:22:50 <bigbluehat> ... which disappeared 15 years ago or so with the advent of YAML v1.2
16:23:05 <bigbluehat> ... but many libraries are still only doing YAML v1.1
16:23:05 <ivan> q+
16:23:29 <bigbluehat> ... so clarifying that this is v1.2 based should avoid the "Norway problem" and many other things
16:23:31 <anatoly-scherbakov> q+
16:24:00 <bigbluehat> ... requiring v1.2 in YAML-LD should provide a clearer foundation
16:24:01 <bigbluehat> ack ivan
16:24:08 <pchampin> ivan: my question is: how big is the problem?
16:24:29 <dlehn> present+
16:24:35 <pchampin> ... if I take a YAML parser, are they 1.2 these days?
16:24:44 <pchampin> ... it is important to be precise, but is it a practical problem?
16:24:54 <bigbluehat> ack anatoly-scherbakov
16:25:41 <pchampin> anatoly-scherbakov: someone pointed out that PyYAML is 1.1, and suffers from the "Norway problem"
16:25:44 <ivan> q+
16:25:49 <duanin2> duanin2 has joined #json-ld
16:25:50 <pchampin> ... but a 1.2 library is available
16:26:14 <pchampin> ... it is important to point out to developers that their library might be outdated
16:26:24 <bigbluehat> ack ivan
16:26:27 <pchampin> ... also we already test that 'no' is interpreted correctly
16:26:44 <pchampin> ivan: my question was about users rather than implementers
16:26:55 <bigbluehat> q+
16:27:02 <pchampin> ... when I create a YAML file, I have to be sure that I don't dammage it on the way
16:27:37 <niklasl> +1 to @ivan (to be fair, "on" and "no" are safe afaics)
16:27:43 <pchampin> ... Could we provide guidance to users about how to stay away from problems
16:27:47 <bigbluehat> ack bigbluehat
16:27:48 <pchampin> s/problems/problems?
16:28:28 <pchampin> bigbluehat: there is more in the YAML-LD spec than "convert your YAML to JSON and hope for the best"
16:28:35 <anatoly-scherbakov> q+
16:28:40 <pchampin> ... the spec should help authors navigate that space
16:29:30 <pchampin> ... as pchampin mentioned, a lot of people reacted negatively to the announce of YAML-LD because of YAML's bad reputation
16:29:31 <bigbluehat> ack anatoly-scherbakov
16:29:44 <pchampin> ... we need to explain "when we say YAML, we mean this particular subset"
16:30:14 <pchampin> anatoly-scherbakov: the spec says that you need to use YAML 1.2; that you can only use string as keys (YAML allows other types)
16:30:27 <pchampin> ... you must not use infinite and NaN numbers
16:30:55 <pchampin> ... you can use YAML anchors (with restrictions) and tags, but its is up to the parser to interpret tags
16:31:35 <pchampin> ... some parsers will interpret things that look like dates into the native date datatype of the language: this also is not supported
16:32:25 <pchampin> bigbluehat: we might want to make the point that users need a proper YAML-LD parser, rather than any tool able to convert YAML to JSON
16:32:49 <ivan>  /me I do not agree; a YAML-LD parser does not necessarily generate a JSON-LD...
16:32:55 <pchampin> ... anatoly-scherbakov, feel free to merge the PRS if they get enough approval
16:33:26 <bigbluehat> topic: CBOR-LD issues
16:34:26 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/pull/62
16:34:27 <gb> s|https://github.com/w3c/cbor-ld/pull/62|-> Pull Request 62 Update tag processing algorithms. (by wes-smith) https://github.com/w3c/cbor-ld/pull/62
16:34:58 <pchampin> wes-smith: the current spec does not match the current state of the register
16:35:05 <pchampin> ... there was some back-and-forth with IANA
16:35:19 <pchampin> ... this PR updates the algorithm to match the current state
16:35:30 <pchampin> s/state/state of the tag system
16:35:43 <pchampin> ... as you can see, this is mostly a simplification
16:36:30 <pchampin> bigbluehat: each CBOR tag would normally have to be registered with IANA, but there is now a range usable by W3C, right?
16:37:09 <pchampin> wes-smith: IANA were not in favor of that, there is now a single CBOR-tag, with an array of 2 elements
16:37:26 <ivan> q+
16:37:28 <bigbluehat> ack ivan
16:37:33 <pchampin> ... the first one contains a registry ID, the second one contains the payload
16:38:02 <wes-smith> +1 ivan
16:38:04 <pchampin> ivan: in principle, this PR must be merged, as it is the agreement with IETF
16:38:48 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/pull/61
16:38:49 <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:39:18 <pchampin> wes-smith: the specification and the registry says you can use CBOR-LD either with or without semantic compression
16:39:54 <pchampin> ... CBOR-LD is a syntax for encoding linked data in JSON; the semantic compression is a specific feature, but it is not a requirement
16:40:40 <pchampin> ... registry entry 0 means "no compression", but the algorithm currently does not account for "no compression"
16:41:18 <pchampin> s/currently does not account for "no compression"/currently assume semantic compression
16:41:21 <bigbluehat> q+
16:41:22 <pchampin> ... this PR fixes that
16:42:25 <pchampin> q+
16:43:25 <pchampin> wes-smith describes the "Person" example in CBOR-LD in the next playground,
16:43:46 <ivan> q+
16:43:58 <pchampin> wes-smith: it would be nice to have, in the playground, a way to change the registry entry for CBOR-LD
16:44:01 <bigbluehat> ack bigbluehat
16:44:18 <pchampin> ... by default it uses registry entry 1, which is generic semantic compression
16:44:18 <bigbluehat> ack pchampin
16:44:48 <bigbluehat> pchampin: registry entry 1 is generic semantic compression
16:45:04 <duanin2> duanin2 has joined #json-ld
16:45:18 <bigbluehat> ... is the compression based on schema.org? or some other process in the playground example?
16:45:40 <bigbluehat> wes-smith: the compression is done by what context is provided in the registry when you do the compression
16:45:50 <bigbluehat> ... we take all the terms in the provided contexts in the document
16:45:59 <bigbluehat> ... we do a term to an integer map
16:46:19 <bigbluehat> ... doing that well and correctly is what almost all of the algorithmic text is about
16:47:51 <pchampin> wes-smith: for each registry entry, people can chose whether it uses semantic compression or not, whether it includes features specific to their own context...
16:48:42 <pchampin> ... registry entry 100 (Verifiable Credential) is interesting, because it addresses compressing keys but also *values*
16:50:15 <pchampin> https://w3c-ccg.github.io/vc-barcodes/#example-the-term-to-id-map-created-by-cbor-ld-when-compressing-a-utopia-dl shows an example of the mapping generated by semantic compression
16:51:09 <duanin2> duanin2 has joined #json-ld
16:52:27 <bigbluehat> q?
16:52:52 <bigbluehat> registry entry https://json-ld.github.io/cborld-registry/tables/100.yml
16:52:55 <bigbluehat> ack ivan
16:53:16 <pchampin> ... this entry defines compressed value for contexts and for cryptosuite
16:53:39 <pchampin> ivan: how does it relate to the discussion we had with Leonard Rosenthol. What does he wants us to do?
16:54:07 <pchampin> s/discussion/email discussion/
16:54:20 <bigbluehat> q+
16:54:37 <pchampin> wes-smith: ther are two things; one is to decouple semantic compression from the basics of CBOR-LD, that's what this PR is doing
16:55:29 <pchampin> ... the other question is: is there some CBOR linked data that does not serialize to JSON-LD?
16:56:02 <pchampin> ... We need to further discuss this with the WG
16:56:04 <wes-smith> q+
16:56:49 <pchampin> ivan: I'm not sure I understand this question. My understanding is that C2PA want to use VCs, but that boils down to JSON-LD
16:57:51 <pchampin> bigbluehat: my understanding of what Leonard is asking for is, first, registry entry 0 (although I'm not sure that what he needs); and he wants to stay in CBOR land when processing the data, without going into JSON land
16:57:52 <pchampin> q+
16:58:01 <bigbluehat> ack bigbluehat
16:58:05 <bigbluehat> ack wes-smith
16:58:06 <pchampin> ... we will meet him to clarify
16:58:14 <pchampin> wes-smith: +1 to what you said
16:58:33 <pchampin> ... in addition to that, he also wants some CBORD-LD that didn't start from JSON-LD
16:58:40 <bigbluehat> ack pchampin
16:59:09 <bigbluehat> pchampin: about processing without going into JSON-LD land is not a problem
16:59:18 <bigbluehat> ... because you can stay within the processing environment
16:59:46 <pchampin> ivan: that's what I responded :)
17:00:12 <pchampin> https://www.w3.org/mid/CH8PR02MB1097022D57EA195433A5F11E4CD43A@CH8PR02MB10970.namprd02.prod.outlook.com
17:01:00 <ajs6f> bye all!
17:01:13 <pchampin> RRSAgent, make minutes
17:01:14 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/18-json-ld-minutes.html pchampin
17:01:22 <TallTed> present+
17:01:27 <TallTed> RRSAgent, draft minutes
17:01:29 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/18-json-ld-minutes.html TallTed
17:01:38 <m2gbot> m2gbot has joined #json-ld
17:02:27 <TallTed> previous meeting: https://www.w3.org/2026/03/11-json-ld-minutes.html
17:02:37 <TallTed> next meeting: https://www.w3.org/2026/03/25-json-ld-minutes.html
17:02:43 <TallTed> RRSAgent, draft minutes
17:02:44 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/18-json-ld-minutes.html TallTed
17:04:13 <duanin2> duanin2 has joined #json-ld