From b0db92d2730f7e7ddb57df9f32c74d7be33e33f8 Mon Sep 17 00:00:00 2001 From: Gregg Kellogg Date: Wed, 13 Dec 2023 10:04:31 -0800 Subject: [PATCH] Minutes for 2023-12-13 WG meeting. --- 2023-12-13/index.html | 333 ++++++++++++++++++++++++++++++++++++++++++ 2023-12-13/irc.log | 289 ++++++++++++++++++++++++++++++++++++ index.html | 12 +- 3 files changed, 633 insertions(+), 1 deletion(-) create mode 100644 2023-12-13/index.html create mode 100644 2023-12-13/irc.log diff --git a/2023-12-13/index.html b/2023-12-13/index.html new file mode 100644 index 0000000..0c857f0 --- /dev/null +++ b/2023-12-13/index.html @@ -0,0 +1,333 @@ + + + + + + + + + + JSON-LD Community Group + + + + +
+

The W3C JSON-LD Community Group

+

Go Back

+ +
+

W3C Logo

JSON-LD WG

+

Minutes for 2023-12-13

+ +
Anatoly Scherbakov is scribing.
+
Benjamin Young: We are going to discuss the future of the WG, future publications and the road ahead
+

+Topic: Announcements and Introductions +

+
Benjamin Young: Any announcements or introductions?
+
Gregg Kellogg: YAML-LD Final Report was published yesterday. Posted on CG blog on it.
+
Ted Thibodeau Jr.: I/scribe+/scribe: anatoly-scherbakov
+
Manu Sporny: Hello and greetings!
+
Dave Longley: Great to see everyone!
+

+Topic: Updates from the CG +

+
Benjamin Young: Any further updates from the CG for Dave and Manu?
+
Gregg Kellogg: CG was working on YAML-LD, and driving JSON-LD issues.
+
Gregg Kellogg: Latest ones revolve around `@nest` and scoped contexts.
+
Gregg Kellogg: We introduced CBOR-LD a few weeks ago and discussed it a bit last week. Looking forward to hear about DigitalBazaar's work on that.
+
Benjamin Young: Thanks! A lot of work has accumulated to the point that we're looking into formalizing it.
+
Pierre-Antoine Champin: I discussed with colleagues about Linked Data in WoT scenarios; they're interested in CBOR-LD and might join the WG.
+
Niklas Lindström: We've been talking about JSON-LD-Star and RDF-Star and thinking how to integrate these.
+

+Topic: Plans/desire to publish Best Practices doc, YAML-LD, and a CBOR-related specification +

+
Benjamin Young: Let's start with low-hanging fruit
+

+Subtopic: Best Practices +

+ +
Benjamin Young: The question about Best Practices has been there for a while. Do we need to post it as a separate note?
+ +
Pierre-Antoine Champin: I agree; I need to check with the charter and not everyone might agree
+
Gregg Kellogg: There was never a resolution to publish the BP as a Note. It shows the last published version and that leads to a 404. Might be a problem with ReSpec
+
Gregg Kellogg: We can certainly publish it as a Draft Note, even if it is incomplete
+
Gregg Kellogg: There is also a Best Practices document in the CG but it's been removed from the UI
+
Benjamin Young: Do they differ?
+
Gregg Kellogg: They're different
+
Benjamin Young: Maybe some resolving is in order. The Charter only spells out maintenance of JSON-LD normative documents and also allows non-normative documents
+
Benjamin Young: To make YAML-LD and CBOR-LD normative we need to move formally as a group to re-charter
+

+Subtopic: YAML-LD +

+
Pierre-Antoine Champin is scribing.
+
Gregg Kellogg is scribing.
+
Anatoly Scherbakov: Nice to meet Manu and Dave
+
... is it ok for the group to be named JSON-LD if we extend the scope to YAML-LD, CBOR-LD... ?
+
... Should we find an Umbrella term?
+
Manu Sporny: I agree with Anatoly, we should shift the WG name given the expanded scope.
+
Dave Longley: JSON-LD and others! WG :)? ... JSON-LD and Derivatives WG (doesn't sound as friendly)
+
... Also other formats such as CSV, Parquet... could be addressed.
+
Manu Sporny: Agree with Anatoly, makes sense to rename the group to focus on expanded scope
+
Dave Longley: Expanded JSON-LD Universe WG
+
Gregg Kellogg: There is a standard for CSV for LD, its ten years old and has moderate use
+ +
Gregg Kellogg: "Tabular data on the web" it is. It probably needs to be revisited, needs periodic updates. I think though that CBOR is definitely inspired by JSON, YAML and JSON developed together
+
Gregg Kellogg: It might be confusing to try to come up with some other name (Linked Data Working Group? - that is too broad maybe)
+
Dave Longley: JSON-LD Umbrella WG
+
Gregg Kellogg: But we can probably stick with the JSON-LD as group name as we're working on things closely related to JSON-LD
+
Benjamin Young: Agree, and let's move on though
+
Niklas Lindström: I agree this is a tricky question; I am leaning towards what Gregg said. One the reasons of JSON-LD success is because it is RDF channeled through JSON
+
Gregg Kellogg: CSV on the web came out before JSON-LD 1.0 was standardized
+
Niklas Lindström: CSV on the Web saw lower adoption. Something about JSON is very useful, I do not know how to call it more abstractly so that it rings as well as it does now
+
Niklas Lindström: There's something in the simplicity of JSON-LD itself
+
Gregg Kellogg: INFRA-LD
+
Niklas Lindström: Leaving JSON behind we miss the point how we got here
+
Niklas Lindström: "Not-XML-LD"
+
Dave Longley: JSON-LD and Friends
+
Pierre-Antoine Champin: My own opinion: I agree Tabular Data on the Web would deserve a refresh. Having one group for all kinds of data formats wouldn't be optimal though. We are focusing on JSON, one particular shape of data
+
Manu Sporny: Agree that we need to focus in the new WG.
+
Benjamin Young: +1
+
Pierre-Antoine Champin: Other concerns, other languages, should probably be addressed by other groups
+
Pierre-Antoine Champin: JSON-LD WG should care about JSON and very similar formats
+
Dave Longley: +1 That JSON-LD is the unifier / north star / commonality
+
Benjamin Young: Thanks everyone! Let'
+
Benjamin Young: Thanks everyone! Let's keep JSON in focus
+
Gregg Kellogg:
+
Gregg Kellogg:
+
Benjamin Young: CG report for YAML-LD published, thanks Gregg! what's the future of this format in the WG?
+
Dave Longley: +1 To YAML-LD going standards track
+
Manu Sporny: I support YAML-LD to go to Standards Track, as long as someone can help moving it through the process
+
Manu Sporny: It provides a signal that we're onto something, these patterns are useful in other syntaxes, it allows the RDF data model to shine
+
Manu Sporny: In the other syntaxes you can express the same data model: JSON-LD - YAML-LD - CBOR-LD and back, that's a good thing
+
Manu Sporny: We should take this to Standards Track. What about implementations?
+
Gregg Kellogg is scribing.
+
Anatoly Scherbakov: The first implementation of YAML-LD is probably gkellogg's
+
... I'm developing a Python implementation, based on PYLD, alpha stage at this point.
+
... It passes the YAML-LD test suite. My next step is to run the JSON-LD test suite.
+
... I'm using it in a little project of mine: browser and knowledge workspace for LD, mostly based on YAML-LD.
+
Niklas Lindström: This gets us two baseline implementations. Moving through WG will be about that. Any other notices about implementations?
+

+Subtopic: CBOR-LD & JSON-LD in CBOR +

+ +
Benjamin Young: Let's move on to CBOR-LD. The questions about it are centered about progressing CBOR-LD spec to match implementations
+ +
Benjamin Young: What level of compression should we use?
+ +
Dave Longley: I believe there are three implementations, one in Rust, one in Java
+
Manu Sporny: Putting the link about CBOR-LD abortions. There are presentations from 2020 we published, they go over the basics. CBOR-LD has 2-3 implementations so far: JS, Rust and something else
+
Dave Longley: One in JavaScript
+
Manu Sporny: Primary reason was Verifiable Credentials, we had a program in the US with the National Association of Convenience Stores about digital age verification program
+
Manu Sporny: The goal was privacy preserving age verification
+
Manu Sporny: So that we can prove your age without disclosing any other PII
+
Manu Sporny: That was in 2018-2019. One of the things they needed was ability to scan the verifiable credential which was a JSON-LD document
+
Manu Sporny: Thus we needed a very high density bar code so that the old hardware can scan and handle it, we needed to get a JSON-LD document down to 350 bytes
+
Manu Sporny: That's why CBOR-LD came into existence, we needed to compress digitally signed JSON-LD so that it could fit into a QR code. We're now in production
+
Manu Sporny: About 4-6 months ago, California department of Motor Vehicles launched their digital driver's license which includes a CBOR-LD QR code
+
Manu Sporny: In California you can now show that QR code which is CBOR-LD and prove your age
+
Anatoly Scherbakov: Well IMHO that's really super cool
+
Manu Sporny: The rollout is still happening but I wanted to make a point that it is already in production and in practical use
+
Manu Sporny: We put a version number on the version that's out there so that W3C WG can introduce breaking changes in a new version
+
Manu Sporny: Spec is not in a good shape, it is out of date from the implementation
+
Dave Longley: -Q
+
Manu Sporny: We've talked about the plan to merge the changes in current spec and the reality of implementations
+
Manu Sporny: We have an uncompressed mode in the spec. Even that saves a number of bytes, but compression is what the real users are interested in
+
Manu Sporny: We also are working with governments about integrating CBOR-LD into their digital ID systems
+
Manu Sporny: That's kind of where we are with CBOR-LD
+
Gregg Kellogg: I think the two different documents address different things. Pierre-Antoine's expresses basic JSON with CBOR compatible with JSON-LD. DigitalBazaar's version is mostly about how you provide that with semantic compaction.
+
Gregg Kellogg: YAML-LD sets a pattern we probably want to stick with — it is mostly API centric
+
Gregg Kellogg: It mostly involves transformation between YAML and JSON-LD Internal Representation. Compression doesn't happen in CBOR, it can happen in Internal Representation
+
Gregg Kellogg: A concern I had: CBOR-LD 1.0 version doesn't have a parallel in core CBOR
+
Pierre-Antoine Champin: Gregg summarized this very well
+
Dave Longley: About magic numbers: current implementations have tags indicating their CBOR-LD and version numbers
+
Dave Longley: Implementations support that; not sure if spec reflects it
+
Gregg Kellogg: The current spec doesn't detail that. Not sure how the tag structure with JSON-LD in it extracted from a CBOR document is distinguished against any other CBOR structure
+
Manu Sporny: CBOR has a registry, tags are registered there, what we need is to request new numbers in the registry which are granted on first come first serve basis. You don't need an official structure to claim them
+
Manu Sporny: If we're an official WG it makes it even easier to register our signature bytes in the CBOR tags registry
+
Benjamin Young: Do we want to move forward as chartered, keeping YAML-LD as a Note or a Draft Note, and bringing CBOR-LD spec to the status of a Note?
+
Benjamin Young: Or we feel we are ready to bring these to Standards Track sooner and recharter the WG at this point?
+

+Subtopic: rechartering? +

+
Gregg Kellogg: I think there is sufficient implementation done for both to move to the Recommendation Track
+
Dave Longley: +1 To gregg
+
Gregg Kellogg: I do not know if publishing CBOR-LD as a Note makes a difference. Bringing it to Rec Track will improve visibility and hopefully drive participation
+
Gregg Kellogg: Updated Charter should also help other things, like fostering JSON-LD specs
+
Gregg Kellogg: Charter doesn't specifically need to mention RDF-Star
+
Benjamin Young: Currently the charter only calls for maintenance, i.e. non breaking changes
+
Pierre-Antoine Champin: Errata is appropriate; not sure how breaking a change might be to fix a bug
+
Pierre-Antoine Champin: The Note track and the Rec track are meant for different kinds of documents
+
Pierre-Antoine Champin: It would be a pushback if we post a spec as a Note and then move it to Rec
+
Pierre-Antoine Champin: It is Rec material. Falling back to Note track if we are not allowed to push it to Rec wouldn't work. It is a document meant to be a Recommendation, not a Best Practices, not a Note
+
Pierre-Antoine Champin: Even if we could, having it on Note track can do it better than a CG report
+
Pierre-Antoine Champin: We will continue working on it in the CG of course until the WG is allowed to take it to Rec track
+
Manu Sporny: We want to move CBOR-LD out of digiatlbazaar github repo and move it to JSON-LD Github repo
+
Manu Sporny: Can we do that? secondly, CBOR-LD is way behind where YAML-LD spec is. Problem is, many of us are heads down in Verifiable Credentials WG trying to get about five specs to Rec track
+
Manu Sporny: We do not have much bandwidth to work on this spec. Maybe it becomes easier next summer
+
Manu Sporny: We're discussing going into production with CBOR-LD systems with national and state governments. They don't necessarily want to wait until the standard is done
+
Manu Sporny: But they want an acknowledgement of W3C that W3C is looking forward to standardize CBOR-LD
+
Manu Sporny: CBOR-LD as a Note doesn't make a lot of sense, we'd like it to go to Rec track
+
Manu Sporny: A new WG charter mentioning CBOR-LD could be a signal to the governments and buy us a bit of time to get the spec into proper shape
+
Manu Sporny: YAML-LD is further along and we could recharter the group putting both in scope, and focus on YAML-LD first then switching to CBOR-LD later
+
Manu Sporny: And we only have 6 months to get CBOR-LD done
+
Pierre-Antoine Champin: +1
+
Manu Sporny: Publishing a new charter would be a positive signal to the community that we're working on these
+
Niklas Lindström: +1
+
Niklas Lindström: Sounds like a good idea. I think what we define should be very minimalistic, kind of glue code defining the serialization.
+
Niklas Lindström: This could also say that JSON-LD is beyond JSON. Contextual Compaction of Linked Data with a kind of Framing is the overarching theme here
+
Benjamin Young: Suggesting we take an action today to bring CBOR-LD into CG space
+
Benjamin Young: Let's start its life there, it will need much discussion and activity
+
Gregg Kellogg: Nominally it's a CG action but we are highly overlapped and we can resolve to do that
+
Manu Sporny: Agree, gkellogg -- we should write all of the concerns / issues we have down into the issue tracker
+
Gregg Kellogg: Manu mentioned that there are open issues with the spec. Would be great if github issues reflect those. this will make it easier for people to contribute
+
PROPOSAL: Bring Digital Bazaar's CBOR-LD 1.0 editor's draft https
+
Manu Sporny: +1
+
Anatoly Scherbakov: +1
+
Gregg Kellogg: +1
+
Dave Longley: +1
+
Ted Thibodeau Jr.: +1
+
Niklas Lindström: +1
+
Pierre-Antoine Champin: +1
+
Benjamin Young: +1
+
David I. Lehn: +1
+
+RESOLUTION: Bring Digital Bazaar's CBOR-LD 1.0 editor's draft https://digitalbazaar.github.io/cbor-ld-spec/ into the JSON-LD CG for future work. +
+
Ted Thibodeau Jr.: Technically, "adopt Digital Bazaar's CBOR-LD"
+
Benjamin Young: Resolved. David you apparently hold the super powers, can you do the actual moving please?
+
David I. Lehn: Eventually it will be moved to W3C and we will have to move it again?
+
Gregg Kellogg: Yes if the WG is rechartered. We'll move the repos from the CG to the WG github org, but this might take months
+
David I. Lehn: This will mean broken links
+
Benjamin Young: We can't get it into W3C repo now because it is CG material
+
Benjamin Young: There is an ambient consensus about rechartering
+
Gregg Kellogg: Let's do a proposal
+
PROPOSAL: Recharter the JSON-LD WG to focus on YAML-LD and CBOR-LD
+
Manu Sporny: +1
+
Anatoly Scherbakov: +1
+
Dave Longley: +1
+
Gregg Kellogg: +1
+
Pierre-Antoine Champin: +1
+
Benjamin Young: +1
+
Ted Thibodeau Jr.: +1
+
David I. Lehn: +1
+
Niklas Lindström: +1 (Not excluding RDF-star alignment?)
+
+RESOLUTION: Recharter the JSON-LD WG to focus on YAML-LD and CBOR-LD +
+
Benjamin Young: This resolution doesn't need to be exclusive, it just signals we want to recharter
+
Benjamin Young: We are still continuing the maintenance of JSON-LD core specs and other things
+
Benjamin Young: We'll likely not have another CG call before the end of the year, we'll get back to this in January
+
+ + \ No newline at end of file diff --git a/2023-12-13/irc.log b/2023-12-13/irc.log new file mode 100644 index 0000000..db061bd --- /dev/null +++ b/2023-12-13/irc.log @@ -0,0 +1,289 @@ +17:00:40 RRSAgent has joined #json-ld +17:00:45 logging to https://www.w3.org/2023/12/13-json-ld-irc +17:01:03 present+ +17:01:08 RRSAgent, draft minutes +17:01:10 I have made the request to generate https://www.w3.org/2023/12/13-json-ld-minutes.html TallTed +17:01:21 RRSAgent, make logs public +17:02:35 meeting: JSON-LD WG +17:02:51 agenda: https://www.w3.org/events/meetings/1ab7df94-bb06-440e-a6b9-bc9022018c57/20231213T120000/ +17:02:51 bigbluehat, sorry, I did not recognize any agenda in https://www.w3.org/events/meetings/1ab7df94-bb06-440e-a6b9-bc9022018c57/20231213T120000/ +17:03:08 present+ +17:03:21 chair+ +17:03:31 present+ +17:03:46 present+ +17:03:47 present+ +17:04:44 present+ +17:05:57 RRSAgent, draft minutes +17:06:28 I have made the request to generate https://www.w3.org/2023/12/13-json-ld-minutes.html TallTed +17:06:34 present+ +17:06:34 manu has joined #json-ld +17:06:34 scribe+ +17:06:34 bigbluehat: we are going to discuss the future of the WG, future publications and the road ahead +17:06:34 topic: Announcements and Introductions +17:06:34 RRSAgent, draft minutes +17:06:35 I have made the request to generate https://www.w3.org/2023/12/13-json-ld-minutes.html TallTed +17:06:41 q+ +17:06:41 bigbluehat: Any announcements or introductions? +17:06:41 q+ +17:06:41 ack gkellogg +17:07:21 gkellogg: YAML-LD Final Report was published yesterday. Posted on CG blog on it. +17:07:21 i/scribe+/scribe: anatoly-scherbakov +17:07:21 ack manu +17:07:21 q+ to also say hi +17:07:25 manu: hello and greetings! +17:07:35 ack dlongley +17:07:35 dlongley, you wanted to also say hi +17:07:36 RRSAgent, draft minutes +17:07:37 I have made the request to generate https://www.w3.org/2023/12/13-json-ld-minutes.html TallTed +17:07:51 dlongley: great to see everyone! +17:07:59 topic: Updates from the CG +17:08:16 niklasl has joined #json-ld +17:08:18 bigbluehat: any further updates from the CG for Dave and Manu? +17:08:20 present+ +17:08:34 gkellogg: CG was working on YAML-LD, and driving JSON-LD issues. +17:08:51 gkellogg: Latest ones revolve around `@nest` and scoped contexts. +17:09:18 gkellogg: We introduced CBOR-LD a few weeks ago and discussed it a bit last week. Looking forward to hear about DigitalBazaar's work on that. +17:09:22 q+ +17:09:32 ack pchampin +17:09:36 bigbluehat: thanks! A lot of work has accumulated to the point that we're looking into formalizing it. +17:09:54 q+ +17:10:06 ack niklasl +17:10:07 pchampin: I discussed with colleagues about Linked Data in WoT scenarios; they're interested in CBOR-LD and might join the WG. +17:10:38 niklasl: we've been talking about JSON-LD-Star and RDF-Star and thinking how to integrate these. +17:11:10 topic: Plans/desire to publish Best Practises doc, YAML-LD, and a CBOR-related specification +17:11:49 bigbluehat: Let's start with low-hanging fruit +17:11:53 subtopic: Best Practices +17:12:11 s/Best Practises/Best Practices +17:12:14 https://w3c.github.io/json-ld-bp/ +17:12:22 bigbluehat: the question about Best Practices has been there for a while. Do we need to post it as a separate note? +17:12:48 current charter: https://www.w3.org/2023/01/json-ld-wg-charter.html +17:13:01 pchampin: I agree; I need to check with the charter and not everyone might agree +17:13:15 q+ +17:13:34 ack gkellogg +17:14:12 gkellogg: there was never a resolution to publish the BP as a Note. It shows the last published version and that leads to a 404. Might be a problem with ReSpec +17:14:40 gkellogg: we can certainly publish it as a Draft Note, even if it is incomplete +17:15:01 gkellogg: there is also a Best Practices document in the CG but it's been removed from the UI +17:15:04 bigbluehat: do they differ? +17:15:09 gkellogg: they're different +17:15:40 bigbluehat: maybe some resolving is in order. The Charter only spells out maintenance of JSON-LD normative documents and also allows non-normative documents +17:16:03 bigbluehat: to make YAML-LD and CBOR-LD normative we need to move formally as a group to re-charter +17:16:12 q+ +17:16:20 subtopic: YAML-LD +17:16:25 scribe+ +17:16:25 scribe+ +17:16:40 anatoly-scherbakov: nice to meet Manu and Dave +17:16:41 scribe- +17:16:59 ... is it ok for the group to be named JSON-LD if we extend the scope to YAML-LD, CBOR-LD... ? +17:17:15 ... Should we find an Umbrella term? +17:17:28 I agree with Anatoly, we should shift the WG name given the expanded scope. +17:17:30 q+ +17:17:31 JSON-LD and others! WG :)? ... JSON-LD and Derivatives WG (doesn't sound as friendly) +17:17:34 ... Also other formats such as CSV, Parquet... could be addressed. +17:17:36 ack anatoly-scherbakov +17:17:38 ack manu +17:17:51 manu: agree with Anatoly, makes sense to rename the group to focus on expanded scope +17:17:52 Expanded JSON-LD Universe WG +17:17:56 q+ +17:18:00 ack gkellogg +17:18:20 gkellogg: there is a standard for CSV for LD, its ten years old and has moderate use +17:18:34 q+ +17:18:53 https://www.w3.org/TR/tabular-data-primer/ +17:19:00 gkellogg: "tabular data on the web" it is. It probably needs to be revisited, needs periodic updates. I think though that CBOR is definitely inspired by JSON, YAML and JSON developed together +17:19:25 gkellogg: it might be confusing to try to come up with some other name (Linked Data Working Group? - that is too broad maybe) +17:19:30 JSON-LD Umbrella WG +17:19:41 gkellogg: but we can probably stick with the JSON-LD as group name as we're working on things closely related to JSON-LD +17:19:53 q+ +17:19:57 ack niklasl +17:19:58 bigbluehat: agree, and let's move on though +17:20:29 niklasl: I agree this is a tricky question; I am leaning towards what Gregg said. One the reasons of JSON-LD success is because it is RDF channeled through JSON +17:21:25 CSV on the web came out before JSON-LD 1.0 was standardized +17:21:45 niklasl: CSV on the Web saw lower adoption. Something about JSON is very useful, I do not know how to call it more abstractly so that it rings as well as it does now +17:22:02 niklasl: there's something in the simplicity of JSON-LD itself +17:22:12 INFRA-LD +17:22:19 niklasl: leaving JSON behind we miss the point how we got here +17:22:21 ack pchampin +17:23:11 "Not-XML-LD" +17:23:13 JSON-LD and Friends +17:23:13 q+ +17:23:15 pchampin: My own opinion: I agree Tabular Data on the Web would deserve a refresh. Having one group for all kinds of data formats wouldn't be optimal though. We are focusing on JSON, one particular shape of data +17:23:15 agree that we need to focus in the new WG. +17:23:24 +1 +17:23:40 pchampin: other concerns, other languages, should probably be addressed by other groups +17:24:04 pchampin: JSON-LD WG should care about JSON and very similar formats +17:24:08 +1 that JSON-LD is the unifier / north star / commonality +17:24:24 bigbluehat: thanks everyone! Let' +17:24:27 ack bigbluehat +17:24:32 bigbluehat: thanks everyone! Let's keep JSON in focus +17:24:33 rssagent, make logs public +17:24:46 rssagent, generate minutes +17:24:56 q+ +17:25:02 ack manu +17:25:04 bigbluehat: CG report for YAML-LD published, thanks Gregg! what's the future of this format in the WG? +17:25:13 rrsagent, generate minutes +17:25:15 I have made the request to generate https://www.w3.org/2023/12/13-json-ld-minutes.html gkellogg +17:25:21 +1 to YAML-LD going standards track +17:25:28 manu: I support YAML-LD to go to Standards Track, as long as someone can help moving it through the process +17:25:59 manu: it provides a signal that we're onto something, these patterns are useful in other syntaxes, it allows the RDF data model to shine +17:26:19 manu: in the other syntaxes you can express the same data model: JSON-LD - YAML-LD - CBOR-LD and back, that's a good thing +17:26:45 manu: we should take this to Standards Track. What about implementations? +17:26:46 q+ +17:26:50 scribe+ +17:27:09 anatoly-scherbakov: the first implementation of YAML-LD is probably gkellogg's +17:27:26 ... I'm developing a Python implementation, based on PYLD, alpha stage at this point. +17:27:54 ... It passes the YAML-LD test suite. My next step is to run the JSON-LD test suite. +17:28:19 ... I'm using it in a little project of mine: browser and knowledge workspace for LD, mostly based on YAML-LD. +17:28:35 scribe- +17:28:39 niklasl: this gets us two baseline implementations. Moving through WG will be about that. Any other notices about implementations? +17:28:48 subtopic: CBOR-LD & JSON-LD in CBOR +17:29:28 https://w3c.github.io/json-ld-cbor/ +17:29:34 niklasl: let's move on to CBOR-LD. The questions about it are centered about progressing CBOR-LD spec to match implementations +17:29:39 https://digitalbazaar.github.io/cbor-ld-spec/ +17:29:46 q+ +17:29:49 bigbluehat: what level of compression should we use? +17:29:50 ack anatoly-scherbakov +17:29:51 q- +17:29:54 ack manu +17:30:06 Introduction to CBOR-LD: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Jul/att-0004/Introduction_to_CBOR-LD.pdf +17:30:25 s/niklasl: let's move/bigbluehat: let's move +17:30:30 q+ +17:30:40 i believe there are three implementations, one in Rust, one in Java +17:30:44 manu: putting the link about CBOR-LD abortions. There are presentations from 2020 we published, they go over the basics. CBOR-LD has 2-3 implementations so far: JS, Rust and something else +17:30:46 one in JavaScript +17:31:21 manu: primary reason was Verifiable Credentials, we had a program in the US with the National Association of Convenience Stores about digital age verification program +17:31:34 manu: the goal was privacy preserving age verification +17:31:57 manu: so that we can prove your age without disclosing any other PII +17:32:35 manu: that was in 2018-2019. One of the things they needed was ability to scan the verifiable credential which was a JSON-LD document +17:33:01 manu: thus we needed a very high density bar code so that the old hardware can scan and handle it, we needed to get a JSON-LD document down to 350 bytes +17:33:31 manu: that's why CBOR-LD came into existence, we needed to compress digitally signed JSON-LD so that it could fit into a QR code. We're now in production +17:34:13 manu: about 4-6 months ago, California department of Motor Vehicles launched their digital driver's license which includes a CBOR-LD QR code +17:34:35 manu: in California you can now show that QR code which is CBOR-LD and prove your age +17:34:48 Well IMHO that's really super cool +17:35:11 manu: the rollout is still happening but I wanted to make a point that it is already in production and in practical use +17:35:21 s/Well IMHO/anatoly-scherbakov: Well IMHO +17:35:35 RRSAgent, draft minutes +17:35:37 I have made the request to generate https://www.w3.org/2023/12/13-json-ld-minutes.html TallTed +17:35:43 manu: we put a version number on the version that's out there so that W3C WG can introduce breaking changes in a new version +17:35:58 manu: spec is not in a good shape, it is out of date from the implementation +17:36:14 s/rssagent, make logs public// +17:36:20 q+ to quickly mention that existing implementations include a non-compression mode +17:36:22 s/rssagent, generate minutes// +17:36:23 -q +17:36:26 q- +17:36:33 manu: we've talked about the plan to merge the changes in current spec and the reality of implementations +17:37:01 manu: we have an uncompressed mode in the spec. Even that saves a number of bytes, but compression is what the real users are interested in +17:37:05 RRSAgent, draft minutes +17:37:07 I have made the request to generate https://www.w3.org/2023/12/13-json-ld-minutes.html TallTed +17:37:19 manu: we also are working with governments about integrating CBOR-LD into their digital ID systems +17:37:40 manu: that's kind of where we are with CBOR-LD +17:37:44 ack gkellogg +17:37:45 s/dlongley, you wanted to also say hi// +17:38:26 gkellogg: I think the two different documents address different things. Pierre-Antoine's expresses basic JSON with CBOR compatible with JSON-LD. DigitalBazaar's version is mostly about how you provide that with semantic compaction. +17:38:43 gkellogg: YAML-LD sets a pattern we probably want to stick with — it is mostly API centric +17:39:11 gkellogg: it mostly involves transformation between YAML and JSON-LD Internal Representation. Compression doesn't happen in CBOR, it can happen in Internal Representation +17:39:52 gkellogg: A concern I had: CBOR-LD 1.0 version doesn't have a parallel in core CBOR +17:39:54 q? +17:40:07 q+ to say that current implementations have tags and versions +17:40:12 pchampin: Gregg summarized this very well +17:40:12 ack dlongley +17:40:12 dlongley, you wanted to say that current implementations have tags and versions +17:40:31 dlongley: about magic numbers: current implementations have tags indicating their CBOR-LD and version numbers +17:40:44 dlongley: implementations support that; not sure if spec reflects it +17:41:42 q+ +17:41:44 gkellogg: the current spec doesn't detail that. Not sure how the tag structure with JSON-LD in it extracted from a CBOR document is distinguished against any other CBOR structure +17:41:46 ack manu +17:42:26 manu: CBOR has a registry, tags are registered there, what we need is to request new numbers in the registry which are granted on first come first serve basis. You don't need an official structure to claim them +17:42:52 manu: if we're an official WG it makes it even easier to register our signature bytes in the CBOR tags registry +17:43:41 bigbluehat: do we want to move forward as chartered, keeping YAML-LD as a Note or a Draft Note, and bringing CBOR-LD spec to the status of a Note? +17:43:54 q+ +17:44:03 bigbluehat: or we feel we are ready to bring these to Standards Track sooner and recharter the WG at this point? +17:44:09 subtopic: rechartering? +17:44:12 ack gkellogg +17:44:26 q+ +17:44:33 gkellogg: I think there is sufficient implementation done for both to move to the Recommendation Track +17:44:34 +1 to gregg +17:44:44 q+ to speak to level of effort for CBOR-LD and current production trajectory +17:45:00 gkellogg: I do not know if publishing CBOR-LD as a Note makes a difference. Bringing it to Rec Track will improve visibility and hopefully drive participation +17:45:22 gkellogg: Updated Charter should also help other things, like fostering JSON-LD specs +17:45:49 gkellogg: Charter doesn't specifically need to mention RDF-Star +17:45:53 ack pchampin +17:46:07 bigbluehat: currently the charter only calls for maintenance, i.e. non breaking changes +17:46:24 pchampin: errata is appropriate; not sure how breaking a change might be to fix a bug +17:46:36 RRSAgent, draft minutes +17:46:37 I have made the request to generate https://www.w3.org/2023/12/13-json-ld-minutes.html TallTed +17:46:45 pchampin: the Note track and the Rec track are meant for different kinds of documents +17:47:04 pchampin: it would be a pushback if we post a spec as a Note and then move it to Rec +17:47:09 s/dlongley, you wanted to say that current implementations have tags and versions// +17:47:41 pchampin: it is Rec material. Falling back to Note track if we are not allowed to push it to Rec wouldn't work. It is a document meant to be a Recommendation, not a Best Practices, not a Note +17:47:53 pchampin: even if we could, having it on Note track can do it better than a CG report +17:48:01 q? +17:48:11 pchampin: we will continue working on it in the CG of course until the WG is allowed to take it to Rec track +17:48:11 ack manu +17:48:11 manu, you wanted to speak to level of effort for CBOR-LD and current production trajectory +17:48:39 manu: we want to move CBOR-LD out of digiatlbazaar github repo and move it to JSON-LD Github repo +17:49:20 manu: can we do that? secondly, CBOR-LD is way behind where YAML-LD spec is. Problem is, many of us are heads down in Verifiable Credentials WG trying to get about five specs to Rec track +17:49:35 manu: we do not have much bandwidth to work on this spec. Maybe it becomes easier next summer +17:50:05 manu: we're discussing going into production with CBOR-LD systems with national and state governments. They don't necessarily want to wait until the standard is done +17:50:26 manu: but they want an acknowledgement of W3C that W3C is looking forward to standardize CBOR-LD +17:50:33 q+ +17:50:38 q+ +17:50:58 manu: CBOR-LD as a Note doesn't make a lot of sense, we'd like it to go to Rec track +17:51:28 manu: a new WG charter mentioning CBOR-LD could be a signal to the governments and buy us a bit of time to get the spec into proper shape +17:51:59 manu: YAML-LD is further along and we could recharter the group putting both in scope, and focus on YAML-LD first then switching to CBOR-LD later +17:52:10 manu: and we only have 6 months to get CBOR-LD done +17:52:27 +1 +17:52:31 manu: publishing a new charter would be a positive signal to the community that we're working on these +17:52:33 ack niklasl +17:52:33 +1 +17:53:03 q+ +17:53:13 niklasl: sounds like a good idea. I think what we define should be very minimalistic, kind of glue code defining the serialization. +17:53:45 niklasl: this could also say that JSON-LD is beyond JSON. Contextual Compaction of Linked Data with a kind of Framing is the overarching theme here +17:53:56 ack bigbluehat +17:54:17 bigbluehat: suggesting we take an action today to bring CBOR-LD into CG space +17:54:34 bigbluehat: let's start its life there, it will need much discussion and activity +17:54:40 ack gkellogg +17:55:03 gkellogg: nominally it's a CG action but we are highly overlapped and we can resolve to do that +17:55:40 agree, gkellogg -- we should write all of the concerns / issues we have down into the issue tracker +17:55:46 gkellogg: manu mentioned that there are open issues with the spec. Would be great if github issues reflect those. this will make it easier for people to contribute +17:56:06 PROPOSAL: Bring Digital Bazaar's CBOR-LD 1.0 editor's draft https://digitalbazaar.github.io/cbor-ld-spec/ into the JSON-LD CG for future work. +17:56:13 +1 +17:56:14 +1 +17:56:14 +1 +17:56:14 +1 +17:56:15 +1 +17:56:16 +1 +17:56:19 +1 +17:56:20 +1 +17:56:22 +1 +17:56:31 RESOLVED: Bring Digital Bazaar's CBOR-LD 1.0 editor's draft https://digitalbazaar.github.io/cbor-ld-spec/ into the JSON-LD CG for future work. +17:56:41 technically, "adopt Digital Bazaar's CBOR-LD" +17:56:44 rrsagent, generate minutes +17:56:45 I have made the request to generate https://www.w3.org/2023/12/13-json-ld-minutes.html gkellogg +17:56:58 bigbluehat: resolved. David you apparently hold the super powers, can you do the actual moving please? +17:57:12 dlehn: eventually it will be moved to W3C and we will have to move it again? +17:57:34 gkellogg: yes if the WG is rechartered. We'll move the repos from the CG to the WG github org, but this might take months +17:57:58 dlongley: this will mean broken links +17:58:11 s/dlongley: this will mean/dlehn: this will mean/ +17:58:41 bigbluehat: we can't get it into W3C repo now because it is CG material +17:59:08 bigbluehat: there is an ambient consensus about rechartering +17:59:10 gkellogg: let's do a proposal +17:59:37 PROPOSAL: Recharter the JSON-LD WG to focus on YAML-LD and CBOR-LD +17:59:41 +1 +17:59:43 +1 +17:59:43 +1 +17:59:43 +1 +17:59:46 +1 +17:59:47 +1 +17:59:47 +1 +17:59:53 +1 +17:59:56 +1 (not excluding RDF-star alignment?) +18:00:24 RESOLVED: Recharter the JSON-LD WG to focus on YAML-LD and CBOR-LD +18:00:25 bigbluehat: this resolution doesn't need to be exclusive, it just signals we want to recharter +18:00:45 bigbluehat: we are still continuing the maintenance of JSON-LD core specs and other things +18:00:53 rrsagent, draft minutes +18:00:54 I have made the request to generate https://www.w3.org/2023/12/13-json-ld-minutes.html manu +18:01:06 bigbluehat: we'll likely not have another CG call before the end of the year, we'll get back to this in January +18:01:13 s/manu, you wanted to speak to level of effort for CBOR-LD and current production trajectory// +18:01:28 rrsagent, generate minutes +18:01:29 I have made the request to generate https://www.w3.org/2023/12/13-json-ld-minutes.html gkellogg +18:01:35 rrsagent, pointer +18:01:35 See https://www.w3.org/2023/12/13-json-ld-irc#T18-01-35 diff --git a/index.html b/index.html index 3e43dac..6b66bc5 100644 --- a/index.html +++ b/index.html @@ -119,7 +119,17 @@

The W3C JSON-LD Community Group

Go Back


-

W3C Logo

Joining Teleconferences

All JSON-LD teleconferences are open to the public. Anyone may join and participate in the discussion. All teleconferences are announced at least 24 hours in advance on the JSON-LD mailing list.

  • Meetings: generally every other week
  • Time: Every other Wednesday 1800 UTC, 9am San Francisco, 12pm Boston, 6pm Berlin
  • Where: Zoom (details in W3C calendar)
  • IRC: irc://irc.w3.org/#json-ld
  • Duration: 60 minutes

Make sure you have a good headset with a microphone as any background noise is distracting to others during the call. If there is excessive noise on your connection, you will be muted until you need to speak. Make sure you join the IRC channel as links and code examples are usually shared over the chat channel.

Minutes for meetings prior to the creation of the JSON-LD Working group may be found here.

Meeting for 2023-11-29

+

W3C Logo

Joining Teleconferences

All JSON-LD teleconferences are open to the public. Anyone may join and participate in the discussion. All teleconferences are announced at least 24 hours in advance on the JSON-LD mailing list.

  • Meetings: generally every other week
  • Time: Every other Wednesday 1800 UTC, 9am San Francisco, 12pm Boston, 6pm Berlin
  • Where: Zoom (details in W3C calendar)
  • IRC: irc://irc.w3.org/#json-ld
  • Duration: 60 minutes

Make sure you have a good headset with a microphone as any background noise is distracting to others during the call. If there is excessive noise on your connection, you will be muted until you need to speak. Make sure you join the IRC channel as links and code examples are usually shared over the chat channel.

Minutes for meetings prior to the creation of the JSON-LD Working group may be found here.

Meeting for 2023-12-13

+

Topics

    +
  1. Announcements and Introductions
  2. +
  3. Updates from the CG
  4. +
  5. Plans/desire to publish Best Practises doc, YAML-LD, and a CBOR-related specification
  6. +
+

Resolutions

    +
  1. Bring Digital Bazaar's CBOR-LD 1.0 editor's draft https://digitalbazaar.github.io/cbor-ld-spec/ into the JSON-LD CG for future work.
  2. +
  3. Recharter the JSON-LD WG to focus on YAML-LD and CBOR-LD
  4. +
+

Meeting for 2023-11-29

Meeting for 2023-11-15

Topics

  1. Spinning up Working/Maintanence Group