14:56:08 <RRSAgent> RRSAgent has joined #rch
14:56:12 <RRSAgent> logging to https://www.w3.org/2023/01/18-rch-irc
14:56:12 <Zakim> RRSAgent, make logs Public
14:56:13 <Zakim> please title this meeting ("meeting: ..."), phila
14:56:26 <phila> meeting: RCH regular meeting
14:56:29 <phila> agenda: https://www.w3.org/events/meetings/37f00d57-ebca-49d0-a0cd-b894f99fb7e7/20230118T100000#agenda
14:56:37 <phila> chair: phila
15:00:33 <ivan> present+
15:01:49 <Kazue> Kazue has joined #rch
15:01:50 <yamdan> yamdan has joined #rch
15:02:09 <Kazue> present
15:02:15 <aalobaid> aalobaid has joined #rch
15:02:39 <dlongley> present+
15:02:53 <yamdan> present+
15:03:01 <Kazue> present+
15:03:08 <pchampin> present+
15:03:16 <gkellogg> gkellogg has joined #rch
15:03:39 <aalobaid> present+
15:03:47 <phila> present+
15:04:02 <gkellogg> present+
15:04:08 <markus_sabadello> markus_sabadello has joined #rch
15:04:15 <markus_sabadello> present+
15:05:09 <pchampin> scribe+
15:05:41 <pchampin> phila: first meeting since a long time
15:05:54 <dlongley> +1 to all of Gregg's excellent work!
15:06:03 <pchampin> ... kudos to gkellogg (and others) for improving the readability of the spec
15:06:24 <pchampin> topic: updates around the room
15:06:32 <pchampin> phila: anything new in Japan?
15:07:00 <pchampin> Kazue: Dan and I discussed about his implementation of the algorithm
15:07:12 <pchampin> ... some points need clarifying, looking forward to discuss this
15:07:42 <pchampin> yamdan: my implementation is almost finished, and passes 99% of the tests
15:07:54 <pchampin> ... will submit issues about the problems I encountered
15:08:14 <ivan> +1 to the issues of yamdan
15:08:27 <pchampin> phila: thanks for a very useful work, yamdan
15:09:07 <pchampin> Kazue: I recognize that we have an alternative between two algorithm
15:09:32 <pchampin> ... the one that we picked to this point is more complex, but is already deployed
15:10:04 <pchampin> dlongley: I don't know how different the two algorithms are, in terms of complexity to implement
15:10:37 <pchampin> ... I don't think the choice was a trade-off between "complex to implement" and "widely deployed"
15:10:39 <pchampin> q+
15:11:14 <dlongley> q+
15:11:14 <pchampin> Kazue: there were 3 of us working on this algorithm,
15:11:24 <pchampin> ... and we had a hard time figuring it out
15:11:35 <gkellogg> q?
15:11:51 <pchampin> phila: dlongley, any report from Digital Bazaar?
15:12:04 <phila> ack dlongley
15:12:04 <pchampin> dlongley: the work we are doing here is still very relevant in VC space
15:12:10 <phila> ack pchampin
15:12:28 <pchampin> ... implemented by @@1 in North America
15:12:35 <phila> pchampin: Jut to comment on Kazue's remark about complexity of the algorithm
15:12:46 <phila> ... IIRC, Dan's implementation is in RUST
15:12:48 <gkellogg> scribe+ phila
15:13:07 <dlongley> +1 to what you said, Kazue -- the algorithm isn't "simple" ... it's just not, IMO, significantly more complex than other options, so I think we're mostly in agreement
15:13:12 <phila> ... I have also implemented in RUST. I Didn't find it too hard although I have some comments to make.
15:13:25 <phila> ... But it's my first time implementing something Gregg wrote
15:13:46 <phila> ... The way the algorithm is written is oriented towards weakly typed languages
15:13:48 <ivan> q+
15:13:53 <phila> ... It takes more effort in RUST
15:14:11 <phila> ... I had some training that made it easier, but some hints might be helpful.
15:14:14 <phila> ack ivan
15:14:24 <dlongley> +1 to what Pierre-Antoine is saying where implementing in a strongly typed language (and one without memory management, etc.) would require more thought ... same with purely functional languages.
15:14:30 <pchampin> ivan: my implementation was in Typescript
15:14:47 <pchampin> ... not sure if it can be considered weakly or strongly typed,
15:15:05 <pchampin> ... but I faced the same kind of difficulties as pchampin, although in the end it worked
15:15:40 <pchampin> ... Note that I tried to comply with the interfaces of the RDF-JS CG.
15:15:52 <pchampin> ... https://www.w3.org/community/rdfjs/
15:16:43 <pchampin> ... I have contacted Ruben Verborgh about it. They may be interested.
15:16:50 <pchampin> ... And this may trigger interest from the Solid community.
15:17:02 <pchampin> phila: markus_sabadello, anything to share?
15:17:28 <pchampin> markus_sabadello: not directly related to this group,
15:17:47 <pchampin> ... but started a number of big EU-funded projets, around digital identity
15:18:11 <pchampin> ... supposed to start this year, all of them are going to use VCs and depend to our work
15:19:24 <dlongley> s/@@1/point of sale systems/
15:19:48 <pchampin> gkellogg: I have been busy.
15:20:26 <pchampin> ... (stuff from the issues to implement in the spec)
15:21:29 <pchampin> ... The RDF-star WG has created 22 github repos, including for N-Triples and N-Quads,
15:21:29 <pchampin> ... in which we plan to include sooner than later text we need in this group.
15:21:29 <pchampin> ... Question from Manu about what we need to go to CR.
15:21:33 <pchampin> ... We would need to refer to WD, which we don't have at the moment.
15:23:01 <pchampin> phila: GS1 is getting more and more traction around VC work
15:23:01 <pchampin> ... I'm running a session in a coming event, with multiple speakers.
15:23:21 <pchampin> ... Certification bodies are interested in VCs, from all around the world.
15:23:37 <pchampin> ... About internation trade, product certification, age verification.
15:23:47 <pchampin> q+
15:24:12 <phila> pchampin: I've heard about GAIA-X using VCs
15:24:28 <phila> ... in order to do data trade. You sign a contract to get access to a dataset using VCs
15:24:39 <phila> ack pc
15:24:56 <ivan> q+
15:25:11 <pchampin> topic: Implementation tracking Issue 65
15:25:12 <phila> -> https://github.com/w3c/rdf-canon/issues/65
15:25:16 <phila> ack ivan
15:25:33 <pchampin> ivan: there is an issue and a wikipage about implementations
15:25:39 <gkellogg> https://github.com/w3c/rdf-canon/wiki/List-of-available-implementations
15:25:39 <ivan> https://github.com/w3c/rdf-canon/wiki/List-of-available-implementations
15:25:55 <pchampin> currently references gkellogg and my implementation
15:26:16 <pchampin> ... we should probably add those from pchampin, yamdam and dlongley (JS and Python)
15:26:26 <pchampin> s/currently/... currently/
15:26:42 <pchampin> q+
15:27:03 <pchampin> ... Re. Manu's question, what we should urgently do is to require horizontal review
15:27:17 <phila> ack pchampin
15:27:18 <pchampin> ... not much to expect from i18n, but the Tag and Security groups will want to chime in
15:27:21 <TallTed> q+ to ask if there's a switch to flip, to enable edits by me (and presumably some others)
15:29:00 <phila> ack TallTed
15:29:01 <Zakim> TallTed, you wanted to ask if there's a switch to flip, to enable edits by me (and presumably some others)
15:29:16 <pchampin> TallTed: is there a switch to flip on the wiki? I don't seem to be able to edit
15:29:31 <dlongley> ivan, gkellogg: added 3 implementations (JS, C++ w/node.js wrapper, Python) to the wiki
15:30:01 <pchampin> gkellogg: the settings restricts editing to people with push access
15:32:07 <pchampin> phila: how to we start the horizontal review?
15:32:30 <pchampin> pchampin: most (all?) horizontals have a self-assesment questionnaire
15:32:44 <pchampin> ... we fill them in and create an issue for them, and put the appropriate label on the issue
15:33:03 <pchampin> ... this notifies the relevant people for the horizontal review
15:33:17 <pchampin> phila: how familiar must someone be to fill the questionnaire?
15:33:42 <pchampin> ... I'll look at them, and ask for help if I need.
15:34:38 <pchampin> Topic: Issue 4 (What is the output)
15:34:49 <pchampin> https://github.com/w3c/rdf-canon/issues/4
15:35:02 <pchampin> phila: most active issue recently
15:35:10 <dlongley> q+
15:35:13 <pchampin> ... are we near a resolution of this?
15:35:15 <pchampin> q+
15:35:27 <pchampin> dlongley: my hope is that we are.
15:35:37 <phila> ack dlongley
15:36:11 <pchampin> ... We have proposed a few options.
15:36:11 <pchampin> ... One is a "special abstract dataset" with canonically labelled blank nodes
15:36:21 <pchampin> ... Another is a list of blank nodes that would be sorted
15:36:22 <gkellogg> q+
15:36:56 <phila> ack pchampin
15:36:57 <pchampin> ... Recent discussions about a mapping output (input bn to output bn), but my understanding is that it is different from the"special abstract dataset"
15:37:46 <phila> pchampin: I was advocating for a mapping at the beginning. I've seen arguments about how complex that is and I've become more convinced it's not a good idea. Dan has convinced me that hte mapping way is too complex
15:38:34 <phila> ... For the 2 options Dave proposed - I'm OK with the abstract dataset idea but it might be hard to define. For me, sth that is a serialization seems more structured. A list of lines of terms
15:38:54 <phila> ... defining sth between the abstract model and serialization sounds too complex and too subtle
15:38:58 <phila> q?
15:39:01 <phila> ack gkellogg
15:39:38 <pchampin> gkellogg: in what we currently have , the result is a kind of normalized dataset (with canonical labels on blank nodes)
15:39:41 <ivan> q+
15:39:47 <pchampin> ... this might not be adequate
15:40:22 <pchampin> ... in the test cases, what is checked is the canonical n-quads serialization of the normalized dataset
15:40:48 <dlongley> +1 to the concatenation of the sorted N-Quads list / array being the same as the N-Quads output
15:40:56 <pchampin> ... I heard proposal about a list of N-Quads strings, whose concatenation would be equal for the N-Quad file
15:41:50 <phila> ack next
15:41:52 <pchampin> ... We have option, they require some work. Do we want to create another spec to specify that stuff?
15:42:12 <TallTed> *sighs* it's always something...  GitHub doesn't produce notifications for changes made to wiki pages, even though I'm watching "all activity" on the repo
15:42:12 <pchampin> ivan: clearly we need the canonical N-Quads
15:42:47 <pchampin> ... the spec should describe what are the steps to get to this canonical N-Quads
15:43:23 <pchampin> ... there could be other outputs, but that mostly an editorial issue
15:43:48 <pchampin> ... We know that any implementation of RDF has internal labels for blank nodes,
15:44:01 <pchampin> ... but I don't know if the RDF spec itself states that a bnode must have a label.
15:44:17 <gkellogg> q+
15:44:52 <pchampin> ... If it does not, it might be tricky to word our own spec.
15:45:14 <pchampin> gkellogg: blank node labels are specific to concrete syntaxes
15:45:29 <pchampin> ... the labels do not exist in the abstract syntax.
15:45:29 <pchampin> q+
15:45:29 <phila> ack gkellogg
15:46:04 <pchampin> ... Implementation do assign labels and try to preserve them.
15:46:22 <phila> ack pchampin
15:47:00 <pchampin> ... In our spec, we define a "normalized dataset", where we normatively define that blank nodes are labelled.
15:47:25 <dlongley> or Infra
15:47:28 <pchampin> ivan: so we have our own definition of dataset? some people may raise an eyebrow on that.
15:47:58 <pchampin> gkellogg: we need something that is more abstract than a serialization.
15:48:40 <pchampin> ... maybe it needs to be more formally defined?
15:49:00 <pchampin> ivan: shouldn't this definition be taken over by the RDF-star WG?
15:49:16 <gkellogg> q+ to discuss the relationship with the JSON-LD Internal Representation.
15:49:31 <pchampin> phila: I don't think so. Canonicalization is our job.
15:49:42 <pchampin> ... And making canonical means making more concrete.
15:49:48 <pchampin> ... So this is not the job of the abstract syntax.
15:49:52 <phila> ack gkellogg
15:49:52 <Zakim> gkellogg, you wanted to discuss the relationship with the JSON-LD Internal Representation.
15:50:16 <pchampin> gkellogg: JSON-LD also has an intermediate model between abstract and concrete
15:51:06 <pchampin> ... JSON-LD works on an "internal representation", which is a little more than JSON
15:51:25 <pchampin> ... we are trying to leverage this for YAML-LD, and possibly also for Turtle
15:51:41 <ivan> q+
15:51:50 <phila> ack ivan
15:51:52 <pchampin> ... Pushing the notion of normalized dataset to RDF-concepts may muddy the water.
15:52:22 <pchampin> ivan: I think we are converging to say that the output is this normalized dataset
15:52:25 <dlongley> +1 to Ivan
15:52:28 <ivan> https://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/
15:52:45 <pchampin> +1 to ivan
15:53:25 <pchampin> ... This very old document is a precursor to what RDF-JS is doing,
15:53:37 <dlongley> and the RDFJS community has updated that, i think ... for which we could use Infra to describe what we want
15:53:38 <pchampin> ... it precisely defines what a blank node is.
15:54:04 <dlongley> q+
15:54:07 <pchampin> ... We could "take over" (not aggressively) this document
15:54:11 <phila> ack dlongley
15:54:32 <pchampin> dlongley: in my original implementation, I used this spec for internal representation
15:54:41 <pchampin> ... the RDF-JS has updated it; we might also use Infra
15:54:59 <dlongley> https://rdf.js.org/data-model-spec/
15:55:03 <dlongley> ^not sure if that's the latest
15:55:23 <pchampin> phila: trying to turn this into an action
15:55:27 <dlongley> blank node interface: https://rdf.js.org/data-model-spec/#blanknode-interface
15:56:08 <pchampin> RRSAgent, make minutes
15:56:09 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/18-rch-minutes.html pchampin
15:58:50 <pchampin> previous call: https://www.w3.org/2022/12/07-rch-minutes.html
15:59:18 <pchampin> next call: https://www.w3.org/2023/02/01-rch-minutes.html
15:59:28 <pchampin> RRSAgent, make minutes
15:59:29 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/18-rch-minutes.html pchampin
16:01:12 <pchampin> s/previous call:/previous meeting:/
16:01:20 <pchampin> s/next call:/next meeting:/
16:01:24 <pchampin> RRSAgent, make minutes
16:01:25 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/18-rch-minutes.html pchampin
16:29:37 <gkellogg> gkellogg has joined #rch
16:45:07 <gkellogg> gkellogg has joined #rch
16:46:09 <gkellogg> gkellogg has joined #rch
17:46:40 <gkellogg> gkellogg has joined #rch
17:51:41 <gkellogg> gkellogg has joined #rch
18:06:01 <Zakim> Zakim has left #rch
18:08:56 <gkellogg> gkellogg has joined #rch
18:11:19 <gkellogg_> gkellogg_ has joined #rch
18:16:33 <gkellogg> gkellogg has joined #rch
18:33:46 <gkellogg> gkellogg has joined #rch
18:50:02 <gkellogg> gkellogg has joined #rch
19:00:22 <gkellogg> gkellogg has joined #rch
19:10:34 <gkellogg> gkellogg has joined #rch
19:15:24 <gkellogg_> gkellogg_ has joined #rch
19:31:54 <gkellogg> gkellogg has joined #rch
19:38:16 <gkellogg_> gkellogg_ has joined #rch
19:55:00 <gkellogg> gkellogg has joined #rch
20:03:44 <gkellogg_> gkellogg_ has joined #rch
20:07:34 <gkellogg> gkellogg has joined #rch
20:25:19 <gkellogg> gkellogg has joined #rch
20:30:23 <gkellogg_> gkellogg_ has joined #rch
20:45:43 <gkellogg> gkellogg has joined #rch
20:48:15 <gkellogg_> gkellogg_ has joined #rch
21:05:27 <gkellogg> gkellogg has joined #rch
21:10:30 <gkellogg> gkellogg has joined #rch
21:27:41 <gkellogg> gkellogg has joined #rch
21:44:42 <gkellogg> gkellogg has joined #rch
21:45:00 <TallTed> TallTed has joined #rch
22:00:42 <gkellogg> gkellogg has joined #rch
22:01:58 <gkellogg_> gkellogg_ has joined #rch
22:17:37 <gkellogg> gkellogg has joined #rch
22:23:19 <gkellogg> gkellogg has joined #rch
22:38:46 <gkellogg> gkellogg has joined #rch
22:58:34 <gkellogg> gkellogg has joined #rch
23:05:20 <gkellogg> gkellogg has joined #rch
23:15:09 <gkellogg> gkellogg has joined #rch
23:21:25 <gkellogg_> gkellogg_ has joined #rch
23:22:56 <gkellogg> gkellogg has joined #rch
23:29:55 <gkellogg_> gkellogg_ has joined #rch
23:46:44 <gkellogg> gkellogg has joined #rch