15:59:48 <RRSAgent> RRSAgent has joined #json-ld
15:59:53 <RRSAgent> logging to https://www.w3.org/2026/03/11-json-ld-irc
15:59:53 <Zakim> RRSAgent, make logs Public
15:59:54 <Zakim> please title this meeting ("meeting: ..."), bigbluehat
16:00:04 <bigbluehat> meeting: JSON-LD WG
16:00:07 <bigbluehat> chair: bigbluehat
16:00:13 <bigbluehat> chair: VictorLu
16:00:20 <bigbluehat> present+
16:00:44 <anatoly-scherbakov> anatoly-scherbakov has joined #json-ld
16:00:50 <TallTed> present+
16:00:51 <bigbluehat> agenda: https://www.w3.org/events/meetings/de31b974-ca9c-4325-bcea-60b91a1b78d9/20260311T120000/
16:00:52 <agendabot> clear agenda
16:00:52 <agendabot> agenda+ Announcements and Introductions
16:00:52 <agendabot> agenda+ documentLoader spec planning
16:00:52 <agendabot> agenda+ CBOR-LD Issue Discussion and Organization
16:00:52 <agendabot> agenda+ Open Discussion
16:01:01 <anatoly-scherbakov> present+
16:01:21 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/11-json-ld-minutes.html TallTed
16:02:10 <TallTed> previous meeting: https://www.w3.org/2026/03/04-json-ld-minutes.html
16:02:11 <TallTed> next meeting: https://www.w3.org/2026/03/18-json-ld-minutes.html
16:04:29 <ajs6f> ajs6f has joined #json-ld
16:04:33 <niklasl> niklasl has joined #json-ld
16:05:36 <pchampin> present+
16:06:21 <wes-smith> wes-smith has joined #json-ld
16:07:00 <dlehn> present+
16:07:02 <ajs6f> scribe+
16:07:04 <wes-smith> present+
16:07:06 <ajs6f> present+
16:07:16 <bigbluehat> Zakim, next item
16:07:16 <Zakim> agendum 1 -- Announcements and Introductions -- taken up [from agendabot]
16:07:41 <ajs6f> pchampin: no update on auto-scribing
16:08:29 <ajs6f> pchamping: verifiable credentials is experimenting with some kind of auto-scribing tech
16:08:50 <ajs6f> s/pchamping/pchampin
16:08:51 <dlehn> q+
16:08:57 <bigbluehat> ack anatoly-scherbakov
16:09:00 <ivan> present+
16:09:01 <niklasl> present+
16:09:20 <bigbluehat> ack dlehn
16:09:40 <ajs6f> dlehn: it's difficult to talk off the record with an auto-scribe tool
16:09:58 <ajs6f> bigbluehat: there is some kind of tool available from Zoom that can help with off-the-record discourse
16:10:40 <ajs6f> dlehn: also the auto-scribe output is really verbose, it gets _every_ word
16:10:51 <ajs6f> dlehn: but it's fine
16:11:32 <bigbluehat> Zakim, next item
16:11:32 <Zakim> agendum 2 -- documentLoader spec planning -- taken up [from agendabot]
16:12:21 <ajs6f> bigbluehat: discussing confirmation with a hash or checksum of what you have loaded
16:12:42 <ajs6f> ... but we have been discussing that our current presentation of the need for documentLoader isn't great, not clear
16:13:27 <ajs6f> ... we don't explcitly tell people not to go to the web for every load, also the checksum/integrity thing
16:13:49 <ajs6f> ... need to do this for the 1.2 Syntax doc
16:13:56 <ajs6f> ... and perhaps in the BP doc
16:14:08 <anatoly-scherbakov> q+
16:14:13 <bigbluehat> ack anatoly-scherbakov
16:14:31 <ajs6f> anatoly-scherbakov: been thinking about the property documentLoaders
16:14:35 <bigbluehat> q+
16:14:40 <ajs6f> ... quite a bit of redundancy in different loaders
16:14:48 <ajs6f> ... which work with the same kind of media
16:15:37 <ajs6f> ... you can imagine requesting contexts via a file:/// URL
16:15:53 <ajs6f> ... and libraries do support this
16:16:26 <ajs6f> ... one thing a docLoader does is retrieve content, another is parse content
16:16:35 <ajs6f> ... and a third is to verify integrity
16:16:51 <ajs6f> ... should we split up dodLoaders into retrievers and parsers
16:17:08 <bigbluehat> s/dodLoaders/documentLoaders
16:17:43 <ajs6f> ... where the parser is responsible for parsing into internal representation but the loader is responsible for loading and verifying
16:17:55 <ajs6f> ... one can imagine many protocols, e.g. IPFS
16:18:07 <ajs6f> ... but the parsers could remain the same
16:18:21 <ajs6f> and the loader varies
16:18:26 <ajs6f> ... and the loader varies
16:18:38 <ajs6f> bigbluehat: that is how it works now
16:18:55 <ajs6f> ... most current parsers ship a HTTP(S) focused loader, but that can be overriden
16:19:11 <ajs6f> ... when overridden, it tends to be use-case specific
16:19:36 <ajs6f> ... e.g. you might expect to retrieve only YAML
16:19:56 <ajs6f> ... don't believe that any loader does any parsing beyond up to JSON
16:20:30 <ajs6f> ... if the developer wants a system that handles a mix of content, you could do that now
16:21:01 <bigbluehat> ack bigbluehat
16:21:07 <ajs6f> ... we drifted into document loading in order to avoid boiling the ocean in terms of the variety of possible loads
16:21:37 <ajs6f> ... the idea from last time was to lift documentLoader as a key part of the spec and we could then call out these possibilities
16:21:44 <ajs6f> ... we still need to specific hash-loading
16:21:52 <ajs6f> ... we do want to get to CBOR-LD today
16:21:57 <ajs6f> anatoly-scherbakov: yes, that makes sense
16:22:23 <pchampin> q+
16:22:41 <ajs6f> ... documentLoader could fetch a stream or string and then a parser could get to an internal reporesentation
16:22:49 <ajs6f> ... but we don't want to overcomplicate things
16:22:57 <bigbluehat> ack pchampin
16:23:00 <ajs6f> bigbluehat: take a look at how documentLoader works int he API
16:23:25 <ajs6f> phchampin: the spec is vague about what documentLoader returns
16:23:57 <ajs6f> ... the spec says "IF the results can be converted to internal representation"
16:23:59 <bigbluehat> https://www.w3.org/TR/json-ld11/#loading-documents
16:24:03 <ajs6f> ... not sure what to make of this
16:24:46 <ajs6f> ... what strikes me is the use of the term "remote"
16:24:59 <ajs6f> ... which insists on things being retrieved from the web
16:25:06 <ajs6f> ... maybe we want a more neutral term?
16:25:07 <TallTed> consider s/remote/dereferenced/
16:25:10 <bigbluehat> q+
16:25:31 <bigbluehat> ack bigbluehat
16:25:42 <ajs6f> pchampin: you can find this by finding "document callback" in the docs
16:25:50 <pchampin> https://www.w3.org/TR/json-ld11-api/#dom-jsonldprocessor-expand
16:26:08 <niklasl> +1 I don't think JSON-LD should specify a data parser API (the internal representation is the basis for interop). It might do to explain that part a bit (in a paragraph). The crucial thing is to highlight the security concerns when loading contexts from origins different from the data origin.
16:26:19 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/11-json-ld-minutes.html TallTed
16:27:28 <ajs6f> niklasl: nothing too much to add, don't want the specs to include more parser structure
16:27:36 <ajs6f> ... let's talk about what to do with external contexts
16:27:52 <ajs6f> bigbluehat: is the tension here between return a string and returning a parsed object
16:28:09 <ajs6f> niklasl: yes, I think we could clarify that
16:28:15 <ajs6f> ... just a note
16:28:40 <ajs6f> ... I have the sense that W3 don't want more web
16:29:19 <ajs6f> bigbluehat: RemoteDocument exists, is anything that is not a context doc
16:29:20 <niklasl> s/more web/more WebIDL/
16:29:28 <ajs6f> pchampin: that could convery the wrong message
16:29:35 <ajs6f> s/convery/convery
16:29:56 <TallTed> q+
16:30:05 <bigbluehat> ack TallTed
16:30:16 <ajs6f> bigbluehat: can we have an issue about bikeshedding "RemoteDocument"
16:30:33 <ajs6f> TallTed: how about "dereferenced" instead of "remote"?
16:30:43 <niklasl> +1 to dereferenced
16:30:54 <ajs6f> ... that would be what got retrieved from _wherever_
16:31:18 <anatoly-scherbakov> q+
16:31:19 <ajs6f> bigbluehat: I'd like to put a cap on this for now, got to ge tto CBOR-LD
16:31:21 <bigbluehat> ack anatoly-scherbakov
16:31:41 <bigbluehat> s/to ge tto/to get to
16:31:49 <ajs6f> anatoly-scherbakov: I have a vague understanding of verifiable credentials, do we expect to publish contexts _as_ VC?
16:31:53 <bigbluehat> q+
16:31:57 <TallTed> q+
16:32:03 <ajs6f> ... it's possible, do we want to?
16:32:05 <bigbluehat> ack bigbluehat
16:32:12 <ajs6f> bigbluehat: that would be amazing!
16:32:46 <ajs6f> ... the context doc that is returned is part of an @context value, which gives us a lot of space, could be much else besides the context in there
16:32:59 <ajs6f> ... could be a much more functional object
16:33:09 <bigbluehat> ack TallTed
16:33:10 <ajs6f> ... it would be cool, but we don't need to take it up as a task
16:33:14 <dlehn> q+
16:33:17 <ajs6f> TallTed: I recommend against that
16:33:27 <ajs6f> ... a VC is basically a collection of claimns
16:33:47 <ajs6f> ... usually one subject, but could be multiple, it's signed and verifiable
16:33:58 <ivan> +1 TallTed
16:34:06 <wes-smith> q+
16:34:06 <ajs6f> ... the plumbing pipeline is much more complex than a JSON-LD pipeline
16:34:13 <ajs6f> ... if you want signed contexts, just sign it!
16:34:14 <pchampin> q+
16:34:23 <ajs6f> ... no need for VC machinery
16:34:40 <ajs6f> ... no need for encryption, most people won't need more
16:34:45 <bigbluehat> ack dlehn
16:34:47 <anatoly-scherbakov> q+
16:35:07 <ajs6f> dlehn: seems like there are a whole nuch of issues, we need to write it all down,
16:35:14 <ajs6f> ... probably overlapping questions
16:35:38 <ajs6f> ... we need to write down the pros and cons for these problems, lots of use cases with different needs
16:35:42 <TallTed> +1 tradeoffs everywhere. "Horses for courses", at all times.
16:36:06 <ajs6f> bigbluehat: would be great if you can "unleatherbind" your thoughts
16:36:13 <ajs6f> ... just write stuff down! don't worry about polish
16:36:18 <bigbluehat> ack wes-smith
16:36:34 <ajs6f> wes-smith: +1 to what TallTed said
16:37:00 <ajs6f> ... if you want context integrity, separate the integrity mech from the JSON-LD mech
16:37:21 <ajs6f> ... you can do this with a hashing technique
16:37:36 <bigbluehat> ack pchampin
16:37:39 <ajs6f> ... you _could_ use VC for that, but it's a separate thing
16:38:07 <ajs6f> pchampin: VC are about signing a set of claims, ultimately an RDF graph. a context is _not_ a graph.
16:38:23 <ajs6f> ... in fact a context alone is an _empty_ graph
16:38:29 <bigbluehat> ack anatoly-scherbakov
16:38:33 <ajs6f> ... VC is not appropriate
16:38:34 <TallTed> A hammer is not the tool for every job. Even if it looks appealing to be hammered.
16:39:17 <ajs6f> anatoly-scherbakov: I work with scientific claims expressed in RDF, they are crypto-signed, with provenance and a signature, sounds a lot like VC
16:39:32 <bigbluehat> q+
16:39:41 <ajs6f> ... people are talking about a CG to work on that, maybe this has crossover with VC?
16:39:55 <ajs6f> bigbluehat: maybe so, bring that to the mailing list, let's get to CBOR-LD
16:39:57 <TallTed> maybe start with a reading of the VCLD 1.0...?
16:40:05 <ajs6f> ... (there are some real differences)
16:40:11 <bigbluehat> q?
16:40:14 <bigbluehat> ack bigbluehat
16:40:15 <TallTed> s/VCLD/VCDM/
16:40:47 <ajs6f> bigbluehat: let's talk CBOR-LD!
16:41:24 <anatoly-scherbakov> pchampin: yes, that is the thing
16:41:34 <ajs6f> bigbluehat: wes-smith, what should we talk about?
16:41:57 <ajs6f> wes-smith: couple of things, including larger questions that need resolution
16:42:26 <ajs6f> ... big picture stuff, how to manage a registry, but also how do we make this model extensible
16:42:44 <ajs6f> ... then there's what _I_ need to nail down, start with issue #51
16:42:45 <gb> https://github.com/w3c/json-ld-syntax/issues/51 -> CLOSED Issue 51 Images should be accessible (by gkellogg) [spec:editorial]
16:43:07 <ajs6f> ... this would be a good place to contribute
16:43:30 <ajs6f> ... also the codecs question
16:43:48 <ajs6f> ... we don't have all the codecs that impls support listed in the spec
16:44:25 <ajs6f> ... bigbluehat: [relabels stuff in GHG]
16:44:29 <ajs6f> s/GHG/GH
16:44:40 <ajs6f> wes-smith: is that editorial?
16:44:45 <ajs6f> bigbluehat: yes
16:45:17 <ajs6f> ... another label is "needs discussion"
16:45:32 <ajs6f> ... we don't have that label for GH issues yet
16:45:56 <ajs6f> ... e.g. number 59, 47, 46
16:46:11 <ajs6f> wes-smith: I need to go read number 50 again
16:46:50 <ajs6f> bigbluehat: this happens in all our repos, we get side quests popping up
16:47:10 <ajs6f> ... nothing concrete to discuss in some of these
16:47:37 <ivan> q+
16:47:41 <bigbluehat> ack ivan
16:47:48 <ajs6f> ... more community discussion, not actionable by the board
16:48:02 <ajs6f> ivan: this came up during the recharter, I didn't want to be too tough
16:48:21 <ajs6f> ... whether or not you like CBOR, that's besides the point, it's got uptake, it's a standard
16:48:24 <wes-smith> +1 ivan
16:48:27 <ajs6f> ... tooling is available
16:48:41 <bigbluehat> q+
16:48:42 <ajs6f> ... if you want a pipeline that produces a QR code, CBOR is how you do it
16:48:50 <wes-smith> q+
16:49:05 <bigbluehat> ack bigbluehat
16:49:05 <ajs6f> ... just because someone did some great academic work with a tool doesn't mean we are interested
16:49:40 <ajs6f> bigbluehat: we have some Netflix people coming to visit, they chose CBOR over Jelly for some reasons they can explain when we meet
16:49:57 <bigbluehat> ack wes-smith
16:49:57 <ajs6f> ... this sort of thing always happens during chartering
16:50:37 <ajs6f> wes-smith: this discussion is useful, but the question we are trying to solve is not "how to make a space-efficient encoding of JSON-LD"
16:50:54 <ajs6f> ... we don't need to invent fresh tech when there is good stuff already available
16:51:09 <ajs6f> bigbluehat: I'm drafting something for that issue now
16:51:15 <ajs6f> ... [types stuff into GH]
16:51:33 <ajs6f> ... [continues to type silently]
16:52:01 <ajs6f> ivan: is it correct that the request originally came from the CBOR community?
16:52:16 <ajs6f> ... we didn't choose CBOR because of specific reasons
16:52:33 <anatoly-scherbakov> q+
16:52:43 <ajs6f> TallTed: I think it came about because it was easy and quick for Digital Bazaar to impl for some govt project
16:52:58 <ajs6f> ... it had to do with exposing VC as a QR code
16:53:19 <ajs6f> wes-smith: CBOR has been around since before I showed up
16:53:34 <ajs6f> ... it must be easy for people to invert a serialization
16:53:40 <ajs6f> ... must be a mature ecosystem
16:54:01 <ajs6f> ... once you push out a QR code with JSON-LD in it, you aren't the consumer any more
16:54:14 <ajs6f> ... we wanted a mature ecosystem into which to publish
16:54:45 <ajs6f> ivan: if we answer the request, we have distinguish our motivation from what the issue-filer is thinking it is
16:55:20 <ajs6f> ... the dichotomy the issue-filer implies is false
16:55:45 <ajs6f> TallTed: it wasn't what is generically a good compact encoding, it was to a specific use case
16:55:59 <ajs6f> ...  i.e. what is available now, easy and quick to impl
16:56:27 <bigbluehat> ack anatoly-scherbakov
16:56:34 <ajs6f> ... and it worked for QR codes on drivers' licenses, and that was the point-- working code winds
16:56:40 <ajs6f> s/winds/wins
16:57:06 <ajs6f> anatoly-scherbakov: CBOR-LD is not in competition with other semantic formats
16:57:13 <ajs6f> ... RDF is universal
16:57:37 <ajs6f> ... if the format exists and is in wide use, it should be posible to convery semantics in it
16:57:55 <ajs6f> ...  so if you want to use X format, great, but that's not CBOR-LD, that's X-LD
16:58:04 <wes-smith> q+
16:58:18 <ajs6f> bigbluehat: this was based in fear that W3 would displace an extant effort
16:58:19 <bigbluehat> ack wes-smith
16:59:07 <ajs6f> wes-smith: brings a bag of nuance to the table, publication in space-constrained media drove CBOR-LD
16:59:17 <pchampin> q+
16:59:39 <ajs6f> ... but there's more to CBOR-LD, maybe you have other resource contraints, these are all situations where a compact representation can be useful
16:59:51 <ivan> q+
17:00:02 <ajs6f> ... we do need to make clear that you have lots of use cases here, not just QR codes
17:00:03 <TallTed> "CBOR-LD is more generally useful and more space and time efficient than JSON-LD.gz"
17:00:24 <bigbluehat> ack pchampin
17:01:09 <ajs6f> pchampin: the Jelly format mentioned in the issue is represented by one of the commenters in the issue
17:01:22 <ajs6f> ... and the comments from that person are nuanced
17:01:51 <ajs6f> ... and open-minded, even came to an early call
17:02:23 <bigbluehat> ack ivan
17:02:24 <ajs6f> bigbluehat: the comparison linked in the issue is good, if wes-smith wants to look at it might be informative to us
17:03:03 <ajs6f> ivan: the main line of argument is that we want to be space-friendly, and there are other techs that could be space-friendly
17:03:05 <bigbluehat> q+
17:03:14 <ajs6f> ... but this isn't the only motivation to use CBOR
17:03:34 <wes-smith> +1 ivan, we are miscommunicating if you think that is different from my perspective
17:03:40 <ajs6f> ... there is also the widespread adoption of CBOR outside the RDF worlds
17:04:00 <ajs6f> ... let's not say "sure to all your evidence but we are better"
17:04:08 <ajs6f> bigbluehat: am I doing that?
17:04:35 <ajs6f> ivan: we should be clear that we chose CBOR for its mature ecosystem and wide adoption
17:04:54 <ajs6f> TallTed: get your grammar straight!
17:05:16 <ajs6f> bigbluehat: I will close the issue with this commnt
17:05:26 <ajs6f> ... [closes issue]
17:05:33 <ajs6f> oh, my tired hands!
17:05:35 <pchampin> RRSAgent, make minutes
17:05:36 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/11-json-ld-minutes.html pchampin
17:05:45 <ajs6f> bye all