Meeting minutes
<Kazue> present
phila: first meeting since a long time
<dlongley> +1 to all of Gregg's excellent work!
phila: kudos to gkellogg (and others) for improving the readability of the spec
updates around the room
phila: anything new in Japan?
Kazue: Dan and I discussed about his implementation of the algorithm
… some points need clarifying, looking forward to discuss this
yamdan: my implementation is almost finished, and passes 99% of the tests
… will submit issues about the problems I encountered
<ivan> +1 to the issues of yamdan
phila: thanks for a very useful work, yamdan
Kazue: I recognize that we have an alternative between two algorithm
… the one that we picked to this point is more complex, but is already deployed
dlongley: I don't know how different the two algorithms are, in terms of complexity to implement
… I don't think the choice was a trade-off between "complex to implement" and "widely deployed"
Kazue: there were 3 of us working on this algorithm,
… and we had a hard time figuring it out
phila: dlongley, any report from Digital Bazaar?
dlongley: the work we are doing here is still very relevant in VC space
… implemented by point of sale systems in North America
pchampin: Jut to comment on Kazue's remark about complexity of the algorithm
… IIRC, Dan's implementation is in RUST
<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
pchampin: I have also implemented in RUST. I Didn't find it too hard although I have some comments to make.
… But it's my first time implementing something Gregg wrote
… The way the algorithm is written is oriented towards weakly typed languages
… It takes more effort in RUST
… I had some training that made it easier, but some hints might be helpful.
<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.
ivan: my implementation was in Typescript
… not sure if it can be considered weakly or strongly typed,
… but I faced the same kind of difficulties as pchampin, although in the end it worked
… Note that I tried to comply with the interfaces of the RDF-JS CG.
… https://
… I have contacted Ruben Verborgh about it. They may be interested.
… And this may trigger interest from the Solid community.
phila: markus_sabadello, anything to share?
markus_sabadello: not directly related to this group,
… but started a number of big EU-funded projets, around digital identity
… supposed to start this year, all of them are going to use VCs and depend to our work
gkellogg: I have been busy.
… (stuff from the issues to implement in the spec)
… The RDF-star WG has created 22 github repos, including for N-Triples and N-Quads,
… in which we plan to include sooner than later text we need in this group.
… Question from Manu about what we need to go to CR.
… We would need to refer to WD, which we don't have at the moment.
phila: GS1 is getting more and more traction around VC work
… I'm running a session in a coming event, with multiple speakers.
… Certification bodies are interested in VCs, from all around the world.
… About internation trade, product certification, age verification.
pchampin: I've heard about GAIA-X using VCs
… in order to do data trade. You sign a contract to get access to a dataset using VCs
Implementation tracking Issue 65
https://
ivan: there is an issue and a wikipage about implementations
<gkellogg> https://
<ivan> https://
ivan: currently references gkellogg and my implementation
… we should probably add those from pchampin, yamdam and dlongley (JS and Python)
… Re. Manu's question, what we should urgently do is to require horizontal review
… not much to expect from i18n, but the Tag and Security groups will want to chime in
<Zakim> TallTed, you wanted to ask if there's a switch to flip, to enable edits by me (and presumably some others)
TallTed: is there a switch to flip on the wiki? I don't seem to be able to edit
<dlongley> ivan, gkellogg: added 3 implementations (JS, C++ w/node.js wrapper, Python) to the wiki
gkellogg: the settings restricts editing to people with push access
phila: how to we start the horizontal review?
pchampin: most (all?) horizontals have a self-assesment questionnaire
… we fill them in and create an issue for them, and put the appropriate label on the issue
… this notifies the relevant people for the horizontal review
phila: how familiar must someone be to fill the questionnaire?
… I'll look at them, and ask for help if I need.
Issue 4 (What is the output)
https://
phila: most active issue recently
… are we near a resolution of this?
dlongley: my hope is that we are.
… We have proposed a few options.
… One is a "special abstract dataset" with canonically labelled blank nodes
… Another is a list of blank nodes that would be sorted
… Recent discussions about a mapping output (input bn to output bn), but my understanding is that it is different from the"special abstract dataset"
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
… 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
… defining sth between the abstract model and serialization sounds too complex and too subtle
gkellogg: in what we currently have , the result is a kind of normalized dataset (with canonical labels on blank nodes)
… this might not be adequate
… in the test cases, what is checked is the canonical n-quads serialization of the normalized dataset
<dlongley> +1 to the concatenation of the sorted N-Quads list / array being the same as the N-Quads output
gkellogg: I heard proposal about a list of N-Quads strings, whose concatenation would be equal for the N-Quad file
… We have option, they require some work. Do we want to create another spec to specify that stuff?
<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
ivan: clearly we need the canonical N-Quads
… the spec should describe what are the steps to get to this canonical N-Quads
… there could be other outputs, but that mostly an editorial issue
… We know that any implementation of RDF has internal labels for blank nodes,
… but I don't know if the RDF spec itself states that a bnode must have a label.
… If it does not, it might be tricky to word our own spec.
gkellogg: blank node labels are specific to concrete syntaxes
… the labels do not exist in the abstract syntax.
… Implementation do assign labels and try to preserve them.
… In our spec, we define a "normalized dataset", where we normatively define that blank nodes are labelled.
<dlongley> or Infra
ivan: so we have our own definition of dataset? some people may raise an eyebrow on that.
gkellogg: we need something that is more abstract than a serialization.
… maybe it needs to be more formally defined?
ivan: shouldn't this definition be taken over by the RDF-star WG?
phila: I don't think so. Canonicalization is our job.
… And making canonical means making more concrete.
… So this is not the job of the abstract syntax.
<Zakim> gkellogg, you wanted to discuss the relationship with the JSON-LD Internal Representation.
gkellogg: JSON-LD also has an intermediate model between abstract and concrete
… JSON-LD works on an "internal representation", which is a little more than JSON
… we are trying to leverage this for YAML-LD, and possibly also for Turtle
… Pushing the notion of normalized dataset to RDF-concepts may muddy the water.
ivan: I think we are converging to say that the output is this normalized dataset
<dlongley> +1 to Ivan
<ivan> https://
+1 to ivan
… This very old document is a precursor to what RDF-JS is doing,
… it precisely defines what a blank node is.
… We could "take over" (not aggressively) this document
<dlongley> and the RDFJS community has updated that, i think ... for which we could use Infra to describe what we want
dlongley: in my original implementation, I used this spec for internal representation
… the RDF-JS has updated it; we might also use Infra
<dlongley> https://
<dlongley> ^not sure if that's the latest
phila: trying to turn this into an action
<dlongley> blank node interface: https://