17:00:11 <RRSAgent> RRSAgent has joined #json-ld
17:00:15 <RRSAgent> logging to https://www.w3.org/2026/02/25-json-ld-irc
17:00:56 <Zakim> Zakim has joined #json-ld
17:01:00 <pchampin> Zakim, start meeting
17:01:00 <Zakim> RRSAgent, make logs Public
17:01:01 <Zakim> please title this meeting ("meeting: ..."), pchampin
17:01:05 <pchampin> meeting: JSON-LD WG
17:01:20 <TallTed> pchampin -- you need to `/invite` with the `/`
17:01:30 <TallTed> present+
17:01:45 <wes-smith> wes-smith has joined #json-ld
17:01:50 <bigbluehat> bigbluehat has joined #json-ld
17:01:53 <pchampin> present+
17:02:33 <pchampin> agenda: https://www.w3.org/events/meetings/de31b974-ca9c-4325-bcea-60b91a1b78d9/20260225T120000/
17:02:33 <agendabot> clear agenda
17:02:33 <agendabot> agenda+ Announcements and Introductions
17:02:33 <agendabot> agenda+ YAML-LD Issue curation (20 minutes)
17:02:33 <agendabot> agenda+ CBOR-LD Issue curation (20 minutes)
17:02:33 <agendabot> agenda+ JSON-LD Issue Discussion and Organization
17:02:36 <agendabot> agenda+ Open Discussion
17:02:56 <pchampin> previous meeting: https://www.w3.org/2026/02/18-json-ld-minutes.html
17:03:05 <pchampin> next meeting: https://www.w3.org/2026/03/04-json-ld-minutes.html
17:03:07 <pchampin> chair: bigbluehat
17:06:04 <niklasl> present+
17:06:09 <wes-smith> scribe+
17:06:20 <bigbluehat> Zakim, next item
17:06:20 <Zakim> agendum 1 -- Announcements and Introductions -- taken up [from agendabot]
17:06:40 <wes-smith> bigbluehat: Welcome to the JSON-LD WG. Any introductions or announcements?
17:06:47 <bigbluehat> Zakim, next item
17:06:47 <Zakim> agendum 1 was just opened, bigbluehat
17:06:52 <bigbluehat> Zakim, close item
17:06:52 <Zakim> I don't understand 'close item', bigbluehat
17:06:57 <bigbluehat> Zakim, next item
17:06:57 <Zakim> agendum 1 was just opened, bigbluehat
17:07:10 <ajs6f> present+
17:07:12 <ajs6f> Hi all!
17:08:31 <wes-smith> ajs6f: My name is Adam Soroka, here representing the Apache foundation. I also work at the Smithsonian institution, which is interested in JSON-LD for publishing metadata out of our collections. I have a cultural heritage/museums/libraries background.
17:08:48 <dlehn> present+
17:09:12 <bigbluehat> Zakim, next item
17:09:12 <Zakim> agendum 2 -- YAML-LD Issue curation (20 minutes) -- taken up [from agendabot]
17:09:38 <wes-smith> bigbluehat: For the next while I want to split the call as much as necessary into YAML-LD and CBOR-LD pieces.
17:09:57 <wes-smith> ... My expectation is that gradually the YAML-LD side will decrease and CBOR-LD will increase as YAML-LD is mostly down to editorial issues.
17:10:10 <wes-smith> ... There was some discussion on the mailing list of a complete reboot of YAML-LD.
17:10:45 <wes-smith> ... My recommendations on the mailing list were that the group needs to stay the course to get YAML-LD published, and if such a thing should exist it should be a separate effort.
17:11:03 <niklasl> +1
17:11:35 <wes-smith> ... Issue 170 is ready to be merged, it is just setting code owners.
17:11:46 <wes-smith> s/Issue/PR
17:11:58 <bigbluehat> subtopic: https://github.com/w3c/yaml-ld/issues/83
17:11:59 <gb> s|https://github.com/w3c/yaml-ld/issues/83|-> Issue 83 use regular expressions to resolve literals; URIs, CURIEs (by VladimirAlexiev) [UCR] [needs discussion] https://github.com/w3c/yaml-ld/issues/83
17:12:46 <wes-smith> pchampin: I think I raised a similar issue some time ago. What we might want to point out is that a lightweight form of what he is asking for is already possible with @vocab
17:13:43 <wes-smith> ... I also want to point out that this is not YAML-LD specific in my opinion.
17:15:25 <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:16:15 <ajs6f> ajs6f has joined #json-ld
17:17:59 <wes-smith> bigbluehat: I will propose closing issue 143.
17:18:22 <niklasl> q+
17:18:27 <wes-smith> ... I want to hear from folks about streaming, if it is something we should dig into.
17:18:28 <bigbluehat> ack niklasl
17:18:34 <bigbluehat> subtopic: https://github.com/w3c/yaml-ld/issues/63
17:18:35 <gb> s|https://github.com/w3c/yaml-ld/issues/63|-> Issue 63 YAML Streams and JSON Sequences (by ioggstream) [spec] https://github.com/w3c/yaml-ld/issues/63
17:19:39 <wes-smith> niklasl: We've been using NDJSON as big dataset dumps for some time and would like to do something to help out with that.
17:20:12 <wes-smith> ... We would appreciate if we were able to contribute to doing something with that, but we would need a general discussion on what the streaming use cases are. We like that you can parse each chunk and inspect it in-memory.
17:20:28 <wes-smith> ... Our consumers are more accustomed to the JSON form that we have published.
17:20:45 <wes-smith> ... You don't need a specific parser, just stream each line and then parse each line with off-the-shelf tooling.
17:21:17 <wes-smith> ... Other approaches to streaming might not adhere to JSON-LD's design principle where off-the-shelf tooling works if advanced features are not needed.
17:22:12 <wes-smith> bigbluehat: One route is for us to bring the community group back to explore progressing things like that. There is RDF streaming work ongoing with lots of discussion of topics like NDJSON. Has YAML stream stuff been reviewed by the group?
17:22:53 <anatoly-scherbakov> anatoly-scherbakov has joined #json-ld
17:22:54 <wes-smith> niklasl: I don't expect our users to want that, I have seen pushback on YAML-LD. YAML parsers aren't in browsers, standard python libraries, etc.
17:22:55 <anatoly-scherbakov> present+
17:23:03 <wes-smith> ... YAML parsers are more complex than JSON.
17:24:01 <wes-smith> bigbluehat: I know a former coworker of mine is using YAML-LD heavily, mostly via AI, to generate what would have been JSON-LD, but they want comments and other features that YAML-LD supports.
17:24:37 <wes-smith> ... I do think that before we switch lanes to CBOR-LD we should discuss if anyone has thoughts on the streaming section specifically.
17:25:02 <wes-smith> ... We might revisit this. I think we can close this issue.
17:27:44 <niklasl> +1 to use Turtle
17:28:42 <niklasl> q+
17:29:02 <bigbluehat> ack niklasl
17:29:04 <bigbluehat> q+
17:29:29 <wes-smith> bigbluehat: To recap, I encourage that the group should not entertain the discussion of reworking YAML-LD here, but instead move to finish YAML-LD and say that the lightweight alternative should be a separate technology.
17:29:35 <Teukka> Teukka has joined #json-ld
17:30:37 <wes-smith> niklasl: There are tradeoffs inherent in the designs of these things, but agreed that the tradeoffs proposed in the mailing list don't make sense for the group to focus on currently.
17:30:55 <bigbluehat> ack bigbluehat
17:31:00 <anatoly-scherbakov> q+
17:32:06 <wes-smith> bigbluehat: We should ship YAML-LD 1.0 as a cross compatible JSON-LD 1.1 expression. This gets to the last thing I wanted to say on this topic - one of the things that YAML-LD provides is that folks want to use YAML-LD to write contexts for use with JSON-LD. This means we will end up with a linked data parser that needs to be able to take a JSON-LD
17:32:06 <wes-smith> document with a schema.org context and understand a YAML-LD expression of this.
17:32:47 <wes-smith> ... I know of people saying that writing contexts in YAML-LD is easier, and it would be good to feed that to a JSON-LD processor without conversion. This falls under the space of context publication and content negotiation.
17:33:37 <wes-smith> ... The question is "when in the ecosystem do we expect the yaml to turn into json"
17:35:04 <wes-smith> anatoly-scherbakov: Regarding a YAML-LD context, I suppose that a parser that is capable of YAML-LD should be capable of understanding a YAML-LD context.
17:35:14 <bigbluehat> ack anatoly-scherbakov
17:35:38 <wes-smith> ... I argue CBOR-LD and YAML-LD should not directly integrate into JSON-LD to avoid combinatorial spec explosion.
17:35:48 <niklasl> +1 keep the core simple
17:36:40 <wes-smith> ... Regarding the mailing list discussion, I proposed we could reuse the profiles functionality of JSON-LD to define custom simplified profiles.
17:36:51 <niklasl> q+
17:36:53 <wes-smith> ... A certain profile could be defined as a subset of JSON-LD keywords.
17:36:55 <bigbluehat> ack niklasl
17:37:26 <wes-smith> niklasl: I am cautiously positive to that, we discussed it previously but there is something to say for a compact but not idiomatic form that uses @id and @type.
17:37:37 <bigbluehat> q+
17:37:53 <bigbluehat> ack bigbluehat
17:38:18 <niklasl> (well, and @context, for the compact form ;D )
17:38:32 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/25-json-ld-minutes.html TallTed
17:38:40 <wes-smith> bigbluehat: Agreed, that gets close to the requested functionality as far as I can tell. One of the things that drove 1.1's feature expansion was the idea that you can and should be able to apply an @context to "found json".
17:40:30 <wes-smith> ... before the pressure has been on JSON-LD to accommodate all JSON shapes, but we need to come to some agreement on that core question.
17:40:51 <niklasl> Agree on the thoughts. :)
17:41:13 <anatoly-scherbakov> q+
17:41:32 <bigbluehat> ack anatoly-scherbakov
17:42:09 <wes-smith> anatoly-scherbakov: There is one issue that we might have missed on YAML-LD. I have prepared a draft PR that contains an example where the id of a node is equal to an expression which is resolved to a date.
17:42:17 <wes-smith> ... That is a problem because a date cannot be concatenated to a string.
17:42:35 <wes-smith> ... This might not be an editorial PR but instead a new piece of logic in the specification.
17:43:18 <wes-smith> ... I will complete the PR and we can review on a future call.
17:43:35 <wes-smith> bigbluehat: Consequently we will table YAML-LD as a time blocked topic but will do brief updates at the beginning of each call.
17:44:08 <wes-smith> ... We will revisit YAML-LD mid-to-late march and focus on CBOR-LD for the next few weeks.
17:44:12 <bigbluehat> Zakim, next item
17:44:12 <Zakim> agendum 3 -- CBOR-LD Issue curation (20 minutes) -- taken up [from agendabot]
17:44:27 <wes-smith> scribe-
17:44:44 <anatoly-scherbakov> scribe+
17:45:03 <anatoly-scherbakov> bigbluehat: any top of mind CBOR-LD issues?
17:45:17 <anatoly-scherbakov> wes-smith: Number 47
17:45:31 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/issues/47
17:45:31 <anatoly-scherbakov> wes-smith: we've got an underspecified processing mode mechanism in the spec
17:45:32 <gb> s|https://github.com/w3c/cbor-ld/issues/47|-> Issue 47 Add discussion of processing modes and their uses. (by wes-smith) https://github.com/w3c/cbor-ld/issues/47
17:46:04 <anatoly-scherbakov> wes-smith: it allows to choose the subset/superset of compression technologies to use
17:46:15 <anatoly-scherbakov> wes-smith: this relates to CBOR-LD codices
17:46:42 <anatoly-scherbakov> wes-smith: current codices evolved organically
17:46:52 <anatoly-scherbakov> wes-smith: we want them to be more modular and extensible via processing modes
17:47:13 <anatoly-scherbakov> s/codices/codecs
17:47:26 <anatoly-scherbakov> wes-smith: we want people to be able to create their own codecs
17:48:18 <anatoly-scherbakov> wes-smith: we currently do not specify the details of these mechanisms, going to focus on this topic
17:48:39 <anatoly-scherbakov> wes-smith: contributions welcome
17:49:04 <anatoly-scherbakov> bigbluehat: which section is important in this context?
17:49:08 <anatoly-scherbakov> wes-smith: section 4.5
17:49:16 <bigbluehat> https://w3c.github.io/cbor-ld/#codecs
17:49:26 <anatoly-scherbakov> wes-smith: we expect to add codecs to, say, efficiently compress datetimes
17:50:15 <anatoly-scherbakov> (yes I heard 'codecs' as 'codex'...)
17:51:13 <dlehn> q+
17:51:20 <anatoly-scherbakov> * No, I think codec -> codecs
17:51:36 <anatoly-scherbakov> adam: any examples?
17:53:18 <bigbluehat> looking at https://github.com/digitalbazaar/cborld code
17:53:28 <anatoly-scherbakov> wes-smith: implemented codecs include datetimes, HTTP URLs, etc, where we squeeze a few bytes efficiently compressing values
17:54:33 <anatoly-scherbakov> q+
17:54:47 <pchampin> q+
17:54:49 <anatoly-scherbakov> wes-smith: registry describes a piece of logic associated with a specific type
17:54:56 <ajs6f> q+
17:55:04 <bigbluehat> ack dlehn
17:55:09 <bigbluehat> ack anatoly-scherbakov
17:55:23 <bigbluehat> scribe+
17:55:38 <bigbluehat> anatoly-scherbakov: from what I understand this ties a bit of logic to a type to do the compression
17:55:51 <bigbluehat> ... how is this described in the registry? JavaScript? Any language?
17:55:57 <bigbluehat> wes-smith: we don't know yet
17:56:02 <bigbluehat> ... it's up for discussion
17:56:16 <bigbluehat> ... it's probably not binding to a specific language
17:56:22 <bigbluehat> ... but we know that one does work
17:56:37 <bigbluehat> anatoly-scherbakov: Web Assembly?
17:56:43 <bigbluehat> wes-smith: worth considering
17:56:50 <dlehn> q+
17:57:08 <bigbluehat> anatoly-scherbakov: do you do the registry handling via any RDF related specifications?
17:57:20 <bigbluehat> ... or will it be an HTTP endpoint or REST API?
17:57:41 <bigbluehat> wes-smith: what's the machine readable form of the registry?
17:57:58 <bigbluehat> anatoly-scherbakov: yes. Is it an RDF document defining what to do?
17:58:13 <bigbluehat> ... it could be. This format `compressedWith` this logic.
17:58:19 <bigbluehat> ... and do inference, etc.
17:58:23 <bigbluehat> ... do you want to do that?
17:58:43 <bigbluehat> wes-smith: I hadn't yet thought about the machine readability of the registry
17:59:01 <bigbluehat> ... I need to think about this one more
17:59:25 <pchampin> q-
17:59:32 <bigbluehat> ack ajs6f
17:59:49 <anatoly-scherbakov> ajs6f: motivation is basically efficiency
18:00:01 <anatoly-scherbakov> ajs6f: is it formalized?
18:00:33 <anatoly-scherbakov> wes-smith: compression is primary motivation of CBOR-LD
18:00:54 <anatoly-scherbakov> wes-smith: CBOR-LD is doing an arbitrary transormation of JSON-LD which just happens to be compression
18:01:17 <anatoly-scherbakov> wes-smith: maybe it can be information hiding
18:01:25 <dlehn> q-
18:01:42 <anatoly-scherbakov> wes-smith: I see other uses for various transformations of JSON-LD
18:01:58 <pchampin> RRSAgent, make minutes
18:01:59 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/25-json-ld-minutes.html pchampin
18:02:07 <ajs6f> Bye all!
18:02:41 <ajs6f> Wow, that YAML-from-hell doc is amazing. I am now terrified to use YAML in anything. :)
18:05:52 <pchampin> present+ bigbluehat
18:05:57 <pchampin> present+ wes-smith
18:06:06 <pchampin> RRSAgent, make minutes
18:06:07 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/25-json-ld-minutes.html pchampin
18:06:43 <pchampin> Zakim, bye
18:06:43 <Zakim> leaving.  As of this point the attendees have been TallTed, pchampin, niklasl, ajs6f, dlehn, anatoly-scherbakov, bigbluehat, wes-smith
18:06:43 <Zakim> Zakim has left #json-ld