– DRAFT –
RCH bi-weekly meeting 2022-11-09

markus_sabadello: We'll try and get some scribe diversity in future!

New members

No new members

Timing of the calls

markus_sabadello: TIming for our friends in Japan is even worse than it was now that DST has ended.
… For Dan and Kazue it's 01:00 tomorrow. Can we think about an earlier time?
… We have people on US West Coast, so it's challenging
… option is to stick with one time, maybe a bit earlier. Other option is to alternate between 2 times but that mean we never have everyone

markus_sabadello: One option is to move this call one or two hours earlier. 2 Hours makes is 23:00 Japan, 06:00 West Coast

<Zakim> manu, you wanted to ask about west coast vs. Japan participation.

manu: Given that Gregg is west coast, 06:00 is difficult but of course 01:00 is bad for Kazue and Dan

manu: The question is how many people will we lose with either option

<TallTed> 2 hours earlier also slams into just-set Solid CG weekly

manu: How many other west coast people besides Gregg?

kazue: I wouldn't request 2 hours earlier, but one hour would e very nice

markus_sabadello: That would be midnight for Japan - that's very generous of you to suggest that.

gkellogg: I can do 07:00 yes

markus_sabadello: Dan, how about you?

yamdan: I can join if we meet just one hour earlier

<TallTed> A doodle poll also seems worthwhile, to try to get opinions of anyone not on *this* call

markus_sabadello: Then I think I can say thank you to everyone. For me in Europe it's always easy

markus_sabadello: So we'll start an hour earlier next time (2 weeks time)

TallTed: It seems worthwhile taking a Doodle Poll to include people who are not on *this* call

markus_sabadello: I would propose, rather than a Doodle which will be difficult to get everyone to vote, we'll just send a note to the list and ask for comments
… We'll give it a week or so and of no one objects, we'll go for it

phila: +1

<TallTed> sure. a poll is a poll. :-)

FPWD of the RCDH deliverable

markus_sabadello: We still have an open question whether it's going to be one or two docs. Time will tell. We can figure that out
… but important I think to start with something concrete
… latest state of the doc - we have 2 algorithms

<markus_sabadello> https://github.com/w3c/rch-rdc/issues/4

<markus_sabadello> https://github.com/w3c/rch-rdc/issues/6

markus_sabadello: We've had some opinions on the two options and how to start with something concrete

<markus_sabadello> https://github.com/w3c/rch-rdc/

markus_sabadello: I don't think we've come to a decision yet. At the same time, in practice, the repo has a lot of activity
… Gregg has done a lot of work based on the URDNA2105 doc
… That's what's now in the repo

gkellogg: I believe that we are tasked with bringing that as a FPWD.

gkellogg: That doesn't pre-decide the output.
… I've prepared everything so that we can make a decision today

markus_sabadello: We haven't decided formally how we want to start. In theory, we could start from scratch but in reality, best way os to start with that doc as a basis but add issues to the doc
… to explain that there are multiple choices to be made

markus_sabadello: Want to find a balance between having a concrete starting doc and not precluding or assuming anything

<manu> +1 to adding issues and publishing what we have right now.

markus_sabadello: I think starting with what we have now makes sense - with issues added

gkellogg: There are issue markers. Phil put in a PR to make sure the open issues are mentioned within the doc. From what you say, Markus, maybe we need something in the intro that makes that more explicit

gkellogg: That would make it more obvious and easier to give feedback

markus_sabadello: I agree. Maybe a sentence or so. I was thinking just linking to that one issue where we have been discussing those two algorithms

gkellogg: There is a link - that's there, but it's one of several

<Zakim> manu, you wanted to support the approach, and note that Data Integrity needs to reference /something/, right now it's the CCG spec.

manu: Just a +1 to support the notion of let's publish what Gregg has published to date. Make it clear that there are open issues and that we're looking for feedback

manu: One of the things I'm worried about is that the Integrity Spec links back to the CCG spec in a non-normative way and is going to FPWD tomorrow

manu: So I'd like to be able to link to the RDC spec as soon as possible.

<dlongley> +1 to Ivan and Manu, +1 to get FPWD out

ivan: I wouldn't worry too much about that. But I am also very much in favor of getting the RDC FPWD out as soon as as we can.

<gkellogg> https://w3c.github.io/rch-rdc/spec/

<gkellogg> https://github.com/w3c/rch-rdc/pull/26

gkellogg: There were two PRS

gkellogg: This one adds some more descriptions and examples, including diagrams, which make it easier to follow.
… and the PR ...

<gkellogg> https://github.com/w3c/rch-rdc/pull/14

gkellogg: This just is bookkeeping. The original spec. The question is around the short name.

<manu> +1 to the diagrams in #26

gkellogg: The auto-generated short name is rch-rdc but there's a longer version

markus_sabadello: Do you think both of these PRs should be included before FPWD?

gkellogg: The examples make it easier to follow and sets up a template for future exmaples

gkellogg: if you look at the PR, the prview version doesn't seem to show the diagrams but I've linked to those.
… There are issues around a11y that we will address in due course

ivan: Gregg said most of what I wanted to say. If I can play staff contact for a moment. Yes Gregg we need to decide on a short name and that must be part of the resolution that we pass

<manu> +1 to use Echidna for publishing.

ivan: We need as a separate resolution or as part of the main one that we want to use Echidna. It means that once FPWD is set up, then any PR merge triggers a new publication

ivan: It's normal that the preview doesn't include diagrams - that's life.

manu: Looks to me as if `rdf-dataset-canonicalization' is the best short name
… The other alternative is `rdf-dataset-c14n'
… And +1 to using Echidna

<Zakim> manu, you wanted to note would prefer a more descriptive shortname.

Issue 1

phila: I haven't had a change to look at them yet, but I'm really pleased ... as far as examples are concerned, we can probably close that issue because you've done it.

phila: Given that you've put examples in, I would propose that can be closed, thank you for doing it.

phila: On the short name, "rdf-dataset-canonicalization" is not short.

phila: Actually, I would prefer "rdc".

phila: I actually type in the names of these things directly, I don't want to do that.

sebastian: You can also spell canonicalization differently depending on where you live.

ivan: There is a minor thing we have to decide... when we put docs into the official publishing list, we have to give them a category for search terms
… It's not urgent but PA will be asked. We could say 'security' and 'semantic web'?? But we need an agreement

markus_sabadello: Do we have to do that for FPWD?

ivan: We have to it for when the staff contact makes th official publication request. It doesn't require a formal WG resolution

gkellogg: I put some other ideas forward. rdf-c14n, rdf-canon

<AndyS> +1 to rdf-c14n

gkellogg: For the Echidna process, we created some GitHub actions that would push the publication when PRs were made to a specific branch

gkellogg: That's probably the way we want to go

markus_sabadello: I think Echidna on the main branch makes most sense to me. Saves additional admin work

gkellogg: That means every PR creates a new publication. If we have a separate branch, we can agree informally to then push ones we ant to publish to that branch

markus_sabadello: That sounds like additional friction

gkellogg: I think we always have to link to the previous draft - is that automated?

ivan: Yes

markus_sabadello: On the name, I assume the short name would be the same as the GH repo?

ivan: Doesn't have to be

markus_sabadello: It seems good practice even if not technically required

gkellogg: I would support making the GH repo name the same - saves later confusion

gkellogg: We should also consider short names for the other docs

markus_sabadello: We're not yet sure whether there will be one or two docs. So we should avoid a name that implies only one

markus_sabadello: Calling it canonicalization can include hashing, but if we put in hash we coldn't include c14n

<ivan> https://www.w3.org/TR/

ivan: Coming back to the tags issue. If you go to the /TR page, the search bar ives you a pull down for tags. We could create a new one, but I think data and security probably cover it

ivan: I have been in WGs that use the model that Gregg describes, but I've also been in ones that use the main branch. When I had my arm twisted in the DID spec to use the main branch it turned out to be simpler

<seabass> +1 to rdf-canon, personally :)

<Tobias_> +1 to rdf-canon from me too

ivan: So I am in favor of auto publishing from the get go.

ivan: You can have PRs merged several times in a day and it will do the right thing. Dates and all that are taken care of

<yamdan> +1 to rdf-canon

<dlongley> +1 to letting the robots do what they like to do

ivan: We've never hot any problem on that front with Echidna, so I'm in favor of using the main branch.

<Zakim> manu, you wanted to favor automatic publication, it's easier on everyone.

manu: Just to underscore what Ivan was saying. I've had nothing but good experiences using the main branch.

<aalobaid> +1 to rdf-canon

<Tobias_> can somebody share a link for Echidna? I am not familiar with it.

<manu> https://labs.w3.org/echidna/

<markus_sabadello> POLL: Which short name should we use for our first deliverable? Options: rdf-rdc, rdf-dataset-canonicalization, rdf-c14n, rdf-canon, or any other.

<Tobias_> thanks, manu!

<gkellogg> rdf-canon or rdf-c14n

<manu> +1 to rdf-canon

phila: rdf-canon

<ivan> rdf-canon

<seabass> rdf-canon

<yamdan> rdf-canon

<AndyS> rdf-c14n > rdf-canon > rdf-rdc > rdf-dataset-canonicalization

<aalobaid> rdf-canon

<Tobias_> rdf-canon

<kazue> rdf-canon

<dlongley> rdf-canon > rdf-rdc

<markus_sabadello> rdf-c14n > rdf-canon > rdf-cdc

<TallTed> rdf-canon > rdf-c14n > rdf-rdc > rdf-dataset-canonicalization

markus_sabadello: That looks like a clear preference

markus_sabadello: Anyone opposed to rdf-canon?

<ivan> +1

gkellogg: Should we merge the two outstanding PRs

<gkellogg> +1

Proposed resolution: Merge PR 26 (examples) and PR 14 (remove old boilerplate) and mention Issue 6 in the intro

<gkellogg> +1

<dlongley> +1

<ivan> +1

<yamdan> +1

<manu> +1

<TallTed> +1

<markus_sabadello> +1

<Tobias_> +1

<dlehn1> +1

<kazue> +1

<AndyS> +1

<aalobaid> +1

+1

RESOLUTION: Merge PR 26 (examples) and PR 14 (remove old boilerplate) and mention Issue 6 in the intro

Proposed resolution: close issue 1 that asks for examples

<dlongley> +1

<AndyS> +1

+1

<gkellogg> +1

<yamdan> +1

<ivan> +1

<manu> +1

<dlehn1> +1

<markus_sabadello> +1

RESOLUTION: close issue 1 that asks for examples

<aalobaid> +1

Proposed resolution: That the draft at https://w3c.github.io/rch-rdc/spec/ be published as a First Public Working Draft with a requested short name of "rdf-canon" and make use of the Echidna tooling. We suggest tags of "data" and "security"

<gkellogg> +1

<dlongley> +1

<manu> +1

<ivan> +1

<TallTed> +1

<aalobaid> +1

<yamdan> +1

+1

<AndyS> +1

<Tobias_> +1

<markus_sabadello> +1

<kazue> +1

<dlehn1> +1

<seabass> +1

RESOLUTION: That the draft at https://w3c.github.io/rch-rdc/spec/ be published as a First Public Working Draft with a requested short name of "rdf-canon" and make use of the Echidna tooling. We suggest tags of "data" and "security"

gkellogg: We do have to decide on renaming the repo

<aalobaid> +1

gkellogg: if we do so then someone will need to make that happen

<seabass> I would be in favour of renaming the repository - much better to do it before FWPD

<aalobaid> +1

Proposed resolution: that the rch-rdc GitHub repository should be renamed to rdf-canon to match the short name of the draft spec

<gkellogg> +1

<dlongley> +1

<markus_sabadello> +1

<ivan> +1

<TallTed> +1

<Tobias_> +1

<aalobaid> +1

+1

<yamdan> +1

<kazue> +1

<manu> +1

<AndyS> +1

<dlehn1> +1

<seabass> +1

<markus_sabadello> seabass: Why do we have the resolution twice?

RESOLUTION: that the rch-rdc GitHub repository should be renamed to rdf-canon to match the short name of the draft spec

<markus_sabadello> phila: One is just to draft the resolution text, second time is to actually vote on it

markus_sabadello: I just want to mention the issue of editors

Editors

markus_sabadello: Right now we have Dave and Gregg. Phil and I contacted yamdan to see if he would also be interested in being an editor, would be able to review PRs and give his input that way

yamdan: I have to study/catch up, but I would like to contribute. I am willing to be a co-editor if possible

seabass: I'd be happy to help with editing, but that would be an editorial review more than a technical one

<markus_sabadello> yamdan:

<Zakim> gkellogg, you wanted to note that all members should review, and significant contributions would suggest becoming an editor.

gkellogg: Great to have more editors. There's a lot to be done. My experience is that the expectation is that WG do review PRs and the state of the doc
… and we have a call to the wider world to review. If your make a significant contribution, you'd be asked to be an editor

markus_sabadello: You don't have to be an editor to contribute to the doc - anyone in the Wg can write a PR

ivan: The practical admin steps to be done once the PRs have been done need to be done by Pierre-Antoine

markus_sabadello: we will reach out to him

ivan: This is one of the things that must have a staff contact

markus_sabadello: We'll re-group in 2 weeks, probably an hour earlier

<TallTed> most important for different time will be updating the calendar item