The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD CG

Minutes for 2023-11-29

Present
Gregg Kellogg, David I. Lehn, Gregory Saumier-Finch, Ted Thibodeau Jr., Benjamin Young, Niklas Lindström, Anatoly Scherbakov
Chair(s)
Gregg Kellogg
Scribe(s)
Gregg Kellogg, Benjamin Young, Pierre-Antoine Champin
Agenda
https://www.w3.org/events/meetings/1ab7df94-bb06-440e-a6b9-bc9022018c57/20231129T120000/
Topics
  1. YAML-LD
  2. CBOR-LD
  3. JSON-LD Issue Discussion
Gregg Kellogg is scribing.

Topic: YAML-LD

Gregg Kellogg: Email sent to semweb mailing list on YAML-LD and CBOR-LD

Topic: CBOR-LD

Benjamin Young is scribing.
David I. Lehn: I'm not too familiar with CBOR-LD.
Gregg Kellogg: I think we discussed modeling the CBOR-LD spec on the YAML-LD spec.
... most of it is about content types
... and then transforming
... into the internal representation and back
... there was some discussion on how to deal with extra semantic capabilities
... like date and datetime in YAML
... CBOR has similar functionality
... but not sure we're making use of any of those
Niklas Lindström: "CBOR is based on the wildly successful JSON data model: numbers, strings, arrays, maps (called objects in JSON), and a few values such as false, true, and null."
... pchampin do you recall using any of those?
Pierre-Antoine Champin: The idea was to specify how CBOR was first translated into JSON
Pierre-Antoine Champin: In my version, the idea was to specify how CBOR is translated into JSON (using hints from spec), and then the traditional JSON-LD processing.
... there are some hints in the CBOR spec, but not fully specified
... For producing CBOR-LD from JSON-LD, there are some decisions. For example, how numbers are converted.
... and for producing CBOR-LD from JSON-LD there were many questions around numbers
... It boils down to a mapping between the base syntaxes.
... There's also a potential CBOR datatype.
Gregg Kellogg: When I was looking at the CBOR spec, if there was no decimal, it's an int, but if not, it's a float
... all JSON numbers would go across as doubles
... and then you would detect the actual int's and compress those things
Pierre-Antoine Champin: I'll take your word for that
... the idea was to aim at the most compact representation
JSON-LD in CBOR (by pchampin?) - https://w3c.github.io/json-ld-cbor/
David I. Lehn: I'm not sure the direction we are taking; we have a spec and implementation which may not be aligned.
... I think one of the things in ours is we're keeping the same structure, just using CBOR.
... We have a special codex and known values.
... For example, there's a codex for dealing with base64 data.
Gregg Kellogg: The best I can tell, the Digital Bazaar version is targeting JSON-LD in the form of an object rather than an array of objects
... and the keys and the like are turned into indices
... and additionally requires external contexts
... and that seems to go against current trend in practice of inlining contexts
... and there are magic numbers to signal if your encoding compact or expanded form in the CBOR document
... there are also a number of other compression opportunities we should discuss
... we do need to be able to handle more use cases than are currently called for in there
... and maintaining binary compatibility
Pierre-Antoine Champin is scribing.
... but we may not need to restrict ourselves to that
Benjamin Young: We have the 2 specs; we need to decide if we want to compare them in terms of pros/cons
... or expand on Digital Bazaar's version as it is already implemented.
... The "JSON-LD in CBOR" spec echoes a lot of what we did in YAML-LD spec.
... It is not taking advantage of special things that CBOR can do.
... The "CBOR-LD" spec uses a number of CBOR-specific things.
... As far as I know, there is only one "CBOR-LD" implementation.
Gregg Kellogg: I see the two specs as being largely orthogonal
Pierre-Antoine Champin: +1, I also see them as orthogonal
... maybe we come out with a base CBOR-LD spec along the lines of YAML-LD
... and a compressed one that is more inline with what's in the current CBOR-LD 1.0 spec
... with an eye toward how to signal these different types of CBOR encodings of JSON-LD
Gregg Kellogg: Anyone else plan on their own CBOR-LD implementation?
David I. Lehn: From the DB perspective, we're using this stuff and moving it forward as needs. But, we'd like to have a wider viewpoint.
... We haven't put forward the effort to consider all the use cases.
... I'm not sure how alternate approaches would factor in.
Gregory Saumier-Finch: Aside, could someone share the link to the YAML-LD spec? I am having trouble finding it. Thanks in advance.

Topic: JSON-LD Issue Discussion

Gregory Saumier-Finch: https://json-ld.github.io/yaml-ld/spec/ [scribe assist by Anatoly Scherbakov]
David I. Lehn: I have some issues that have come up in jsonld.js.
... We have people that have questions about defining terms such as "a:b" and "a/b".
https://github.com/digitalbazaar/jsonld.js/issues/542 -> CLOSED Issue 542 how to handle a legacy context (by lemoustachiste)
https://github.com/digitalbazaar/jsonld.js/issues/543 -> Issue 543 Forward slash in JSON key treated as error (by jakubklimek)
... This is mostly a usability thing, but people still have data that does it.
Pierre-Antoine Champin is scribing.
David I. Lehn: I wasn't sure where it is discussed in the spec.
... Maybe we can call that out better.
Benjamin Young: I was wondering about how to best surface issues. Should we just make issues on the spec?
... There's also the json-ld.org repo for issues.
... It's mainly wanting a single location to point to.
... The community needs some guidance for doing this.
... Right now it's a big bucket.
Niklas Lindström: This seems to be explained at https://www.w3.org/TR/json-ld11/#iri-expansion-within-a-context but I cannot find the corresponding error code at https://www.w3.org/TR/json-ld11-api/#jsonlderrorcode
... The discussions feature in GitHub is useful, and could be turned on in json-ld.org, and route people there.
... That results in issues that can't be closed.
David I. Lehn: We can point people to https://stackoverflow.com/questions/tagged/json-ld too
Niklas Lindström: I think I found the place where this is mentioned in the JSON-LD syntax spec, but can't find the error code for it, or where it's explicitly handled.
... My implementation doesn't through an error, which I would have thought it would.
... I checked the playground, but it didn't through an error until I had data.
David I. Lehn: I think the JS implementation doesn't see the problem until parsing the data.
Pierre-Antoine Champin: What about [14.2.4.2](https://w3.org/TR/json-ld11-api#ctd-contains-colon)?
Niklas Lindström: I don't recognize the rule, but I could mis-remember.
Pierre-Antoine Champin: Going back to the previous discussion on where issues belong ...
... Recently, I tried to submit an issue on a repo, and ended up with the previoius
... Three of the four are not templets, but links. Maybe we can use a similar trick on json-ld.org, which would put them in the spec repo if appropriate.
... I'm happy to do that, if you have suggestions on what you'd like to see.
Gregg Kellogg: Let's start with the json-ld.org repo.
Benjamin Young: I did turn on discussion on json-ld.org repo, and is essentially json-ld.org's discussion space. Maybe we'll catch other people there.
Ted Thibodeau Jr.: I think we should note that discussions are really a Q&A space and not really a discussion space.
... The initial post is a question, and follow-ons are answers; it's not really a threaded discussion
... NNTP and email lists are more discussions.
Niklas Lindström: I checked my code and commented that bit out as I failed some tests.
... It's probably because it was a 1.0 tests that I didn't detect.
Anatoly Scherbakov: https://github.com/json-ld/yaml-ld/pull/128 & https://github.com/json-ld/yaml-ld/pull/129; dlehn: https://github.com/digitalbazaar/pyld/pull/182
Anatoly Scherbakov: I wanted to share some updates; since the last meeting I submitted some YAML-LD PRs.
... They are worth another look.
... I shared the spec in a couple of groups without getting any feedback.
Niklas Lindström: ... Actually.. create term definition step 14.2.4.2, should it have a "If processing mode is not json-ld-1.0" check before it raises the error ...?
... Another update, the PyLd library has some PRs I've submitted against it.
... It enables git sub-modules and changes the tests to run against the sub-modules, which should improve developer experience.
... Maybe dlehn and bigbluehat could look at that.
... If that's okay, I'll prepare a PR to address an issue about logging and reacting on skipped keys.
Niklas Lindström: If anyone has time to check my last question in IRC? (Checked, and I believe that the processing mode test should be added there. – gk)