– DRAFT –
JSON-LD WG

Announcements and Introductions

pchampin: no update on auto-scribing

pchampin: verifiable credentials is experimenting with some kind of auto-scribing tech

dlehn: it's difficult to talk off the record with an auto-scribe tool

bigbluehat: there is some kind of tool available from Zoom that can help with off-the-record discourse

dlehn: also the auto-scribe output is really verbose, it gets _every_ word

dlehn: but it's fine

documentLoader spec planning

bigbluehat: discussing confirmation with a hash or checksum of what you have loaded
… but we have been discussing that our current presentation of the need for documentLoader isn't great, not clear
… we don't explcitly tell people not to go to the web for every load, also the checksum/integrity thing
… need to do this for the 1.2 Syntax doc
… and perhaps in the BP doc

anatoly-scherbakov: been thinking about the property documentLoaders
… quite a bit of redundancy in different loaders
… which work with the same kind of media
… you can imagine requesting contexts via a file:/// URL
… and libraries do support this
… one thing a docLoader does is retrieve content, another is parse content
… and a third is to verify integrity
… should we split up documentLoaders into retrievers and parsers
… where the parser is responsible for parsing into internal representation but the loader is responsible for loading and verifying
… one can imagine many protocols, e.g. IPFS
… but the parsers could remain the same

and the loader varies
… and the loader varies

bigbluehat: that is how it works now
… most current parsers ship a HTTP(S) focused loader, but that can be overriden
… when overridden, it tends to be use-case specific
… e.g. you might expect to retrieve only YAML
… don't believe that any loader does any parsing beyond up to JSON
… if the developer wants a system that handles a mix of content, you could do that now
… we drifted into document loading in order to avoid boiling the ocean in terms of the variety of possible loads
… the idea from last time was to lift documentLoader as a key part of the spec and we could then call out these possibilities
… we still need to specific hash-loading
… we do want to get to CBOR-LD today

anatoly-scherbakov: yes, that makes sense
… documentLoader could fetch a stream or string and then a parser could get to an internal reporesentation
… but we don't want to overcomplicate things

bigbluehat: take a look at how documentLoader works int he API

phchampin: the spec is vague about what documentLoader returns
… the spec says "IF the results can be converted to internal representation"

<bigbluehat> https://www.w3.org/TR/json-ld11/#loading-documents

phchampin: not sure what to make of this
… what strikes me is the use of the term "remote"
… which insists on things being retrieved from the web
… maybe we want a more neutral term?

<TallTed> consider s/remote/dereferenced/

pchampin: you can find this by finding "document callback" in the docs

<pchampin> https://www.w3.org/TR/json-ld11-api/#dom-jsonldprocessor-expand

<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.

niklasl: nothing too much to add, don't want the specs to include more parser structure
… let's talk about what to do with external contexts

bigbluehat: is the tension here between return a string and returning a parsed object

niklasl: yes, I think we could clarify that
… just a note
… I have the sense that W3 don't want more WebIDL

bigbluehat: RemoteDocument exists, is anything that is not a context doc

pchampin: that could convery the wrong message

bigbluehat: can we have an issue about bikeshedding "RemoteDocument"

TallTed: how about "dereferenced" instead of "remote"?

<niklasl> +1 to dereferenced

TallTed: that would be what got retrieved from _wherever_

bigbluehat: I'd like to put a cap on this for now, got to get to CBOR-LD

anatoly-scherbakov: I have a vague understanding of verifiable credentials, do we expect to publish contexts _as_ VC?
… it's possible, do we want to?

bigbluehat: that would be amazing!
… 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
… could be a much more functional object
… it would be cool, but we don't need to take it up as a task

TallTed: I recommend against that
… a VC is basically a collection of claimns
… usually one subject, but could be multiple, it's signed and verifiable

<ivan> +1 TallTed

TallTed: the plumbing pipeline is much more complex than a JSON-LD pipeline
… if you want signed contexts, just sign it!
… no need for VC machinery
… no need for encryption, most people won't need more

dlehn: seems like there are a whole nuch of issues, we need to write it all down,
… probably overlapping questions
… we need to write down the pros and cons for these problems, lots of use cases with different needs

<TallTed> +1 tradeoffs everywhere. "Horses for courses", at all times.

bigbluehat: would be great if you can "unleatherbind" your thoughts
… just write stuff down! don't worry about polish

wes-smith: +1 to what TallTed said
… if you want context integrity, separate the integrity mech from the JSON-LD mech
… you can do this with a hashing technique
… you _could_ use VC for that, but it's a separate thing

pchampin: VC are about signing a set of claims, ultimately an RDF graph. a context is _not_ a graph.
… in fact a context alone is an _empty_ graph
… VC is not appropriate

<TallTed> A hammer is not the tool for every job. Even if it looks appealing to be hammered.

anatoly-scherbakov: I work with scientific claims expressed in RDF, they are crypto-signed, with provenance and a signature, sounds a lot like VC
… people are talking about a CG to work on that, maybe this has crossover with VC?

bigbluehat: maybe so, bring that to the mailing list, let's get to CBOR-LD

<TallTed> maybe start with a reading of the VCDM 1.0...?

bigbluehat: (there are some real differences)

bigbluehat: let's talk CBOR-LD!

<anatoly-scherbakov> pchampin: yes, that is the thing

bigbluehat: wes-smith, what should we talk about?

wes-smith: couple of things, including larger questions that need resolution
… big picture stuff, how to manage a registry, but also how do we make this model extensible
… then there's what _I_ need to nail down, start with issue #51

<gb> CLOSED Issue 51 Images should be accessible (by gkellogg) [spec:editorial]

wes-smith: this would be a good place to contribute
… also the codecs question
… we don't have all the codecs that impls support listed in the spec
… bigbluehat: [relabels stuff in GH]

wes-smith: is that editorial?

bigbluehat: yes
… another label is "needs discussion"
… we don't have that label for GH issues yet
… e.g. number 59, 47, 46

wes-smith: I need to go read number 50 again

bigbluehat: this happens in all our repos, we get side quests popping up
… nothing concrete to discuss in some of these
… more community discussion, not actionable by the board

ivan: this came up during the recharter, I didn't want to be too tough
… whether or not you like CBOR, that's besides the point, it's got uptake, it's a standard

<wes-smith> +1 ivan

ivan: tooling is available
… if you want a pipeline that produces a QR code, CBOR is how you do it
… just because someone did some great academic work with a tool doesn't mean we are interested

bigbluehat: we have some Netflix people coming to visit, they chose CBOR over Jelly for some reasons they can explain when we meet
… this sort of thing always happens during chartering

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"
… we don't need to invent fresh tech when there is good stuff already available

bigbluehat: I'm drafting something for that issue now
… [types stuff into GH]
… [continues to type silently]

ivan: is it correct that the request originally came from the CBOR community?
… we didn't choose CBOR because of specific reasons

TallTed: I think it came about because it was easy and quick for Digital Bazaar to impl for some govt project
… it had to do with exposing VC as a QR code

wes-smith: CBOR has been around since before I showed up
… it must be easy for people to invert a serialization
… must be a mature ecosystem
… once you push out a QR code with JSON-LD in it, you aren't the consumer any more
… we wanted a mature ecosystem into which to publish

ivan: if we answer the request, we have distinguish our motivation from what the issue-filer is thinking it is
… the dichotomy the issue-filer implies is false

TallTed: it wasn't what is generically a good compact encoding, it was to a specific use case
… i.e. what is available now, easy and quick to impl
… and it worked for QR codes on drivers' licenses, and that was the point-- working code wins

anatoly-scherbakov: CBOR-LD is not in competition with other semantic formats
… RDF is universal
… if the format exists and is in wide use, it should be posible to convery semantics in it
… so if you want to use X format, great, but that's not CBOR-LD, that's X-LD

bigbluehat: this was based in fear that W3 would displace an extant effort

wes-smith: brings a bag of nuance to the table, publication in space-constrained media drove CBOR-LD
… but there's more to CBOR-LD, maybe you have other resource contraints, these are all situations where a compact representation can be useful
… we do need to make clear that you have lots of use cases here, not just QR codes

<TallTed> "CBOR-LD is more generally useful and more space and time efficient than JSON-LD.gz"

pchampin: the Jelly format mentioned in the issue is represented by one of the commenters in the issue
… and the comments from that person are nuanced
… and open-minded, even came to an early call

bigbluehat: the comparison linked in the issue is good, if wes-smith wants to look at it might be informative to us

ivan: the main line of argument is that we want to be space-friendly, and there are other techs that could be space-friendly
… but this isn't the only motivation to use CBOR

<wes-smith> +1 ivan, we are miscommunicating if you think that is different from my perspective

ivan: there is also the widespread adoption of CBOR outside the RDF worlds
… let's not say "sure to all your evidence but we are better"

bigbluehat: am I doing that?

ivan: we should be clear that we chose CBOR for its mature ecosystem and wide adoption

TallTed: get your grammar straight!

bigbluehat: I will close the issue with this commnt
… [closes issue]

oh, my tired hands!