W3C

– DRAFT –
RCH regular meeting

15 March 2023

Attendees

Present
dlehn, dlongley, gkellogg, ivan, manu, markus_sabadello, phila, seabass, TallTed, yamdan
Regrets
-
Chair
markus_sabadello, phila
Scribe
dlongley, gkellogg

Meeting minutes

markus_sabadello: I don't think we have any introductions.

markus_sabadello: We can skip that. General updates.

markus_sabadello: Anything to share?

phila: Just briefly, this is tangential interest. OASIS is looking at starting some work that is relevant to us as GS1. It's a lightweight vocab for VCs. This thing has been checked over there by those people over there. OASIS is starting work on that, we'll be involved as much as we can which isn't very much. I'd like to highlight that another standards body that is working on a vocab deliberately designed to work on VCs and using RDF

canonicalization.

markus_sabadello: Do you have a link?

phila: I'll try to find it.

pchampin: I wanted to mention that I'm sharing the co-chair of The Web Conference at the W3C track. From the beginning of May to the 14th of April.

pchampin: We've invited Clare Nelson to give a talk. It will be related to DIDs.

pchampin: Since the DID group isn't meeting at the moment this seems like a good place to make the announcement.

<phila> The Oasis draft charter on lightweight VC schema and process

manu: A link to share? Anything for this group to contribute?

pchampin: I can't think of anything specific, just wanted to let people know if you are around. I'll put a link in.

<Zakim> manu, you wanted to update on Data Integrity feature freeze.

manu: Two things, I'll put the links into chat.

manu: This is an update on Data Integrity in the VCWG.

<pchampin> https://www2023.thewebconf.org/calls/webdeveloper-w3c/

manu: Three updates. The first one is that we're trying to get two cryptosuites that depend on URDNA2015 into the group.

<manu> Demonstration of Support for ECDSA Cryptosuite Adoption into VCWG: https://lists.w3.org/Archives/Public/public-vc-wg/2023Mar/0035.html

manu: One of the calls for support is today. This is for the ECDSA cryptosuite. We have a good long healthy list of W3C and non-W3C members. We expect it to do well today, but if you have an inclination please show up to vote in favor today.

manu: That cryptosuite depends on the work we're doing in this group.

<manu> Work item suggestion: BBS Cryptosuite for Data Integrity: https://lists.w3.org/Archives/Public/public-vc-wg/2023Mar/0033.html

manu: Another item that went out is a precall for adoption for BBS.

manu: This cryptosuite does selective disclosure and unlinkable signatures which are important for privacy use cases and it also uses the work from this group.

manu: We're collecting support and signatures again in another doc -- if you're interested in this, please add your signature.

<manu> Add json-eddsa-2022 cryptosuite: w3c/vc-di-eddsa#26

manu: The third announcement is that the EdDSA cryptosuite has a PR open to add another canonicalization scheme called JCS. That's driven by a conversation driven by this group as alternatives for any possible failures of URDNA2015 or if people don't want to use it. This alternative is there now.

manu: This just signs the presentation bytes not the semantic bytes.

manu: This relieves some of the pressure on this group for getting everything absolutely right out the door, which we still want to do of course, but there's a backup.

markus_sabadello: That's good, anything else from anyone?

markus_sabadello: Hearing none, let's move ahead.

markus_sabadello: RDF quad canonicalization is the next topic. There's been discussion on the list already.

markus_sabadello: Gregg has pointed out that we have a dependency on the RDF star working group.

markus_sabadello: Where RDF quad canonicalization is being defined. There was an issue with how we can reference that and if that is stable and when it becomes stable and where it should be defined.

markus_sabadello: The chairs of this WG and the RDF star WG will have a meeting to discuss this dependency. I think there was general agreement that the RDF quad canonicalization should stay in the RDF star WG and some of the updates and fixes that Gregg has been proposing -- to update that spec ... there's agreement that there's a good thing.

<markus_sabadello> w3c/rdf-n-quads#17

markus_sabadello: And that that algorithm should be standardized in the RDF star WG and we would reference that.

markus_sabadello: There's a link in the chat for one of the PRs.

markus_sabadello: There was also a bit of a discussion of the status of the documents. In what stage do the docs have to progress to prevent blocking anyone?

markus_sabadello: My understanding was that the N-Quads docs in the RDF Star WG has to be published as a FPWD by the time that we here proceed to CR.

markus_sabadello: If we want to move to CR we depend on that other group, RDF Star WG, to publish that other spec to FPWD. With those other missing pieces that Gregg is working on my understanding is that we should be fine.

phila: That's my understanding too.

phila: I think Ora (sp?) seemed comfortable with that.

phila: I don't think that spec was at the top of their priority list but it's been moved up now.

markus_sabadello: Yes, my understanding is that things are on track and Gregg can speak to that more.

<gkellogg> w3c/rdf-n-quads#16

gkellogg: In addition to the PR to identify ... there's an issue that I asked this group to comment on that would update the escaping rules that leads to one incompatibility.

gkellogg: But I think that's probably the right thing to do. This group needs to take a position to proceed with that or not. This group needs to decide if this is the right thing to do. This really comes down to displaying the N-Quads and leading to a problem. It's not about our algorithm to create a hash over them.

gkellogg: On the other hand, if you look at the purpose of canonicalization RDF statements that it's clear that this sort of thing should be escaped.

gkellogg: It's a chicken and egg sort of thing. I'd like to get an opinion from this group about whether to include this because the RDF Star WG needs to hear about it.

gkellogg: I've been gone for a couple of weeks so other than reading the minutes of RDF Star WG I'm a bit out of the loop. The RDF Star WG put the breaks on making changes a while ago and I've been in processing conversations and hopefully those are resolved so editors can make changes like this.

gkellogg: Regarding FPWD ... the RDF Star wants to bring all docs to FPWD at the same time, but I don't think there's anything that prevents the work from going to FPWD today but that WG has to decide it. I think all that's needed is picking a publication date and then we can move forward.

gkellogg: I think the last thing to mention when we started with regards to dependencies ... the RDF Star WG hasn't made any progress really on what the quoted triple considerations are ... there's been a debate around that. There's no text in there around an "unstar" operation that the CG had described.

gkellogg: That "unstar" op has been suggested as the best way to include quoted triples in canonicalization. We need a placemarker there so there's something for us to vote that as part of the input dataset.

gkellogg: I can take an action to enable such a function and to invoke it as part of the initialization steps of the algorithm.

markus_sabadello: So that would be in our algorithm.

gkellogg: Yes, similar as we have a placeholder for RDF N-Quads canonicalization, we also need a placeholder for "unstar". We also need to communicate to the RDF Star WG that something be put into place to describe such an operation.

ACTION: gkellogg to create issue on "unstar" operation.

<Zakim> pchampin, you wanted to notice that applying 'unstar' changes RDF1.1 graphs

markus_sabadello: I have to say that I'm unfamiliar personally with the "unstar" operation.

pchampin: The background analysis is still out. The "unstar" mapping is a mapping from RDF Star to RDF 1.1. So, start by applying "unstar" may modify graphs that even do have unquoted triples. So I think we need two different versions of the algorithm. I think we need two different versions of the algorithm for this reason.

pchampin: We aren't there yet anyway, we need to see if the WG adopts this "unstar" thing or goes another way.

manu: Just to mention -- that sounds scary and dangerous and something we don't want to do. Noting that URDNA2015 is dated ... it has a date on it and we should strive to modify it as little as possible and we can always rev an URDNA2023 or something like that.

manu: Modulo what Gregg's been working on with character escaping, it feels like something we can safely put in URDNA2015, I don't think we have many instances where we've needed to escape things and I don't think there's anything in the wild that would really be changed by that.

manu: That's a question to Gregg, do you feel like any of these rules would contain things that the vast majority of graphs would be effected by the new escaping rules?

gkellogg: As I mentioned, I have implemented those escaping rules and run it against the canonicalization test suite as it exists and there's one test that specifically does introduce literals with odd characters in it, that therefore has a different result. But it seems unlikely...

gkellogg: ... if you consider the types of things that this canonicalization algorithm is intended for, you wouldn't expect them to include escape sequences. There's already a provision for new line returns but nothing changes with that.

gkellogg: If they were in there I'd be suspect but it seems like only a good thing to do here.

gkellogg: It does change the algorithm, but in practical terms I don't think it would really have an effect.

gkellogg: The same would be true of the "unstar" types of things -- it's there to include / anticipate datasets that would include unquoted triples. I think there's some form of backwards compatibility there but PA's warnings about potentially modifying things that don't include quoted triples is pertinent there.

<pchampin> agreed, the cases where unstar changes an RDF 1.1 graph are really corner cases, probably not found in the wild

<Zakim> phila, you wanted to ramble on incoherently

dlongley: +1 to include escaping if it solves a real problem and is a practical change

phila: As I understand it correctly this "unstar" function, as Manu says is scary. I was assuming that an RDF star dataset has an extra column on it and we could just include it. Gregg if you put an RDF star dataset into unstar and then get a RDF 1.1 dataset? Can't we just say, if you have an RDF star dataset *then* you run "unstar"?

phila: But as Manu says, this is scary because it could hold us up.

gkellogg: We've had an issue since the very beginning about supporting RDF star. So it shouldn't be a surprise.

phila: No, it's not.

gkellogg: I'm suggesting what you said -- either a prestep for this algorithm or one of the first steps for this algorithm would be to put in the input dataset over a form that it's designed to operate over. Hypothetically, if we were to do some other type of modified version, perhaps N3 that can have literals as subjects.

gkellogg: You could imagine a similar entailment that would create an informing RDF dataset from that input. It's basically take anything that we don't recognize and perform the operations to make it what we do recognize.

gkellogg: With respect to RDF star and quoted triples it's something they should define.

gkellogg: It's just not there yet -- whether we say it in informative text and this algorithm applies to... it's not strictly RDF 1.1 datasets, it applies to RDF 1.2, but it's the class of data sets that don't include quoted triples. We just say it doesn't include that and the inputs must be transformed into datasets that don't include quoted triples.

gkellogg: Or we include that as the first step as the first normative step in the algorithm -- the effects are pretty much the same.

phila: Thank you.

seabass: Isn't RDF star just a syntactic extension to RDF and it doesn't need that translation?

gkellogg: No, sorry, it affects the definition of the abstract syntax, it has an update to include another type of resource. Up until now RDF resources are IRIs, literals, and blank nodes. This includes a new class, that being a quoted triple itself.

gkellogg: It's not simply a syntactic thing -- it's possible that that will end up happening since the RDF Star WG is still debating it. There was consensus from the CG that a WG starts but different people get involved and different issues come to light, that's how the sausage gets made.

gkellogg: We're not there yet, there's something to be said about keeping it syntactic. The quoted triple could be syntactic sugar for traditional reified triples in RDF.

seabass: Thanks for explaining it.

pchampin: Nothing to add, that's a good account of the current situation.

markus_sabadello: To summarize this regarding RDF star, perhaps there's something we could add or say about that in our algorithm if I understood that correctly. Just going back to the main topic, the N-Quad canonicalization -- it sounds to me like there's an open PR #17 and that's fine.

markus_sabadello: And then there's issue #16 that you mentioned, string escaping and it does sound like there's support here for that even if it's not 100% compatible with all the tests but it sounds like it's scope limited and a good thing to do.

markus_sabadello: What would be the next step then, Gregg to create a PR update that?

gkellogg: I think the cleanest thing for this group to do would be to create a proposal and resolution that it supports the updates and we put something in the issue so there's no miscommunication between the groups about whether to do that or not.

markus_sabadello: That sounds great, resolutions are fun, we haven't done one in a while, let's try to do one.

TallTed: I'm not currently on IRC.

<ivan> Copying this on behalf of TallTed for the minutes: Technical objection to pieces of what we concluded in the CG would be strongly appreciated, rather than just not fully reading that report which is the prime input to this group!

TallTed: It would be much appreciated if we would do anything like what was just suggested ... like dropping whatever is in a CG final report ... and going back to an earlier report I'd like to see technical conclusions about what was concluded vs. not reading that report.

markus_sabadello: Thanks.

<gkellogg> s|pulls/17|issues/16|

<gkellogg> s|pulls/17|issues/16|

<phila> This WG supports the escaping methods as discussed in Issue 16 for the N-Quads spec w3c/rdf-n-quads#16

<phila> PROPOSAL: This WG supports the escaping methods as discussed in Issue 16 for the N-Quads spec w3c/rdf-n-quads#16

<manu> +1

<pchampin> +1

<gkellogg> +1

dlongley: +1

<markus_sabadello> +1

<phila> +1

<yamdan> +1

<ivan> +1

<dlehn> +1

RESOLUTION: This WG supports the escaping methods as discussed in Issue 16 for the N-Quads spec w3c/rdf-n-quads#16

<seabass> +1

markus_sabadello: Ok, so we can mention this resolution in issue #16 and I imagine a PR can be created to update those rules.

markus_sabadello: Once the PR #17 is merged then we can create a new PR to modify that.

markus_sabadello: Anything still needed for PR #17?

markus_sabadello: Just clarification from RDF star management to go ahead and do so. I hadn't seen anything, PA, perhaps you can say whether I'm authorized to continue.

pchampin: I think it's prudent at this stage but hopefully we can make some progress tomorrow.

markus_sabadello: So some minor administrative things to take care of but then PR #17 will be merged and then we expect a PR to address issue #16 and then FPWD at some point and we're fine.

phila: Just thinking -- should we also, rather than opening an issue and going through that, I wonder if we go with Gregg's explanation just now. Perhaps we just limit the types of input we can handle and take a resolution straight away without raising an issue.

phila: That spec text will make it clear that the input of this algorithm is limited to the types we can handle, phrased better of course.

phila: I'm trying to work out if we can avoid raising another issue: the input of this algorithm is RDF that doesn't include quoted triples.

<manu> I'd be +1 to agreeing to do something along the lines of what phila said.

gkellogg: I don't know that we can simply ... I think that needs discussion. It's one of the inputs to the WG to consider RDF Star so I don't think we can just say we're not going to do that. Or we need to refer to something that is as yet undefined ... the RDF star WG has not defined the concept of a dataset that doesn't include quoted triples, if indeed it has quoted triples.

gkellogg: There are a couple of things that need to be in place to even make that statement.

gkellogg: That said, handling it by saying that the inputs are to be put into a form of a dataset, however it's defined, not including quoted triples would be superior. That would include that work.

<phila> Issue 2 is 'Consider RDF Star'

gkellogg: Such definitions do not exist yet.

phila: Nothing has happened about issue #2 since September, so it's wide open and could be used as the issue to discuss this.

markus_sabadello: I'm not so familiar with RDF star and the "unstar" operation but as others have said it is adding some complexity. Couldn't we say that the input is an RDF dataset and there could be optional steps before that to get to that.

markus_sabadello: We could make that clear and there could be preprocessing steps.

gkellogg: I'm completely onboard with that but we're waving our hands on the definitions we're referring to and those definitions are in the RDF star WG ... and we should go to that group perhaps and tell them more of what we need.

gkellogg: We need the basic terminology so we can talk about those things and it's not appropriate for us to define those things.

pchampin: I kind of like Phil's proposal. It's a fact that the algorithm currently doesn't support quoted triples or any other stuff ... that the RDF 1.2 specification may bring into an RDF dataset.

pchampin: I'd rather stick to this naming ... to go beyond quoted triples. Having this text at the beginning, that is the current state of the algorithm -- looks like a good idea. That doesn't prevent us from, in the future, to make it more robust and support more / refer better.

pchampin: The resolution could be if you have other animals in your graph you have to convert them this or that way so the algorithm knows how to handle them.

TallTed: +1 that RCH input staging could include transforming RDF-star to classic RDF
… (Or RDF 1.2 to RDF 1.1)

ivan: I think we overcomplicate things. Our algorithm is defined on RDF 1.1 dataset, full stop, no lie. We don't have to say anything else.

ivan: If the new working produces that has a new 1.2 dataset that is an extension to 1.1 -- we don't have to say anything about it.

ivan: We can just say we rely on 1.1 datasets, we're creating an unnecessary headache on ourselves.

<pchampin> I was about to counter-argue that we are going to depend on N-Quads 1.2 -- but that's for the output only, so actually +1 to ivan

markus_sabadello: I agree, we shouldn't change our inputs, we are called the RDF Canonicalization and Hash WG -- it would be useful if this can be compatible with RDF star and things but I agree that we worry so much.

TallTed: Not to be too much of a contrarian.

TallTed: One of the major headaches of today ... things that are compatible with 1.1 and not compatible with other 1.1 things -- or 1.0 things ... the RDF star should be making 1.2 fix these problems. Having this group operating at this time is problematic ... and having this group work on the 5-10 year old stuff and that's that ... is problematic.

Recall the issues of SPARQL 1.1 depending on RDF 1.0 semantics.

TallTed: I am ok with saying that this algorithm here transforms to the older version that's OK. But choking on it is not OK.

TallTed: It doesn't help anyone who reads it when 1.2 comes out.

TallTed: People will assume that RDF 1.2 stuff will just work and it won't.

seabass: It seems like RDF 1.2 would add something that was fundamentally incompatible with tooling, then that would be a 2.0.

seabass: So I'm not sure how the semantic versioning would work if you're expressing some entirely new way of expressing data beyond the simple triple.

ivan: That's not up to us to decide.

<Zakim> phila, you wanted to make a suggestion

phila: I hope my suggested proposal "The input of the c14n algorithm is an RDF Dataset as defined in RDF 1.1, which may be derived from pre-processing of later versions of RDF" would handle Ted's objection.

<manu> +1 to the proposal.

<seabass> +1

TallTed: It's better than nothing, but we can massage it later.

gkellogg: I think that is a way to do it.

gkellogg: I think getting the RDF star WG to create a definition for something that is a classic RDF dataset that would be defined in 1.2 and we could refer to it would be an equivalent way of handling that and it would keep everything fully modern.

gkellogg: The other language still is pointing back to a 10 year old specification rather than the concurrent specification.

gkellogg: The groups are operating with pretty much entirely overlapping timeframes. I think there's no reason we can't have language ... we will indeed have references to the 1.2 version of N-Quads. So I think we also need references to the 1.2 versions of RDF concepts and have what's in there that's compatible with what we need.

gkellogg: A dataset definition for what was compatible with what was expressed in 1.1.

markus_sabadello: In general, would you say that this proposal goes in the right direction?

gkellogg: In as much as the proposal says it applies to something ... that is equivalent to an RDF 1.1 dataset. We just need a term to reference that and we have a dependency for them to come up with there and we need to communicate that to the group and there should be a way to reference these things so we can use them.

markus_sabadello: If anyone has a proposed update to Phil's proposal please prep it.

ivan: I think we closing to a bikeshedding issue. My preference would be ... my proposal would be to say normatively that the algorithm is based on 1.1. We add some sort of a note into the text referring to the problem and that we know about it -- and then in a year depending on where we are and where the other WGs are, we put more things into the note.

ivan: But we don't need any additional statement in the normative text. But we have to go through CR again if we mess with that statement and we have a major pain in our backside.

ivan: So, normatively, 1.1 -- but we have notes referring to the problems and that's what the notes are for in specifications.

seabass: So I think the thing I'd like to point out -- given that RDF 1.2 might add new features which require breaking changes. We can expect lots of people to continue with RDF 1.1 for the time being. And up until now we've created canonicalization to 1.1 -- I think it would be a problem to ask everyone to wait to upgrade to 1.2 to use it.

<manu> +1 sebastian!

phila: I don't think we're quite there yet for my proposal. People are sympathetic but given the time we're not quite there.

markus_sabadello: Ok, so maybe we put that language into issue #2 if you haven't already and we try to iterate on that.

gkellogg: Briefly, I think another change that could come from RDF 1.2 ... would be support for text direction and we also have i18n requirements.

gkellogg: If it's handled at the data model level that would be new.

markus_sabadello: Are we tracking that anywhere?

gkellogg: I don't recall if we have such an issue.

phila: We punted that to the N-quads spec.

gkellogg: RDF star will handle text direction but the implication is that if they include something we'd want to benefit from that. We would do so implicitly because we're only depended on it in the canonicalization step but it may change the representation in some way and it wouldn't be RDF 1.1.

phila: Yup.

markus_sabadello: Ok, thanks everyone we're a few minutes over time. We have some good progress and clarity on the N-Quads dependency.

markus_sabadello: This discussion we just had will continue in issue #2 about the inputs and what we want to say about preprocessing steps or not. The other item on the agenda -- which was what is the output, we'd really like to get a conclusion on that.

markus_sabadello: And whether we want one or two documents as deliverables, we'll talk about that next time. Please continue on issues.

markus_sabadello: See the privacy consideration issue too.

Summary of action items

  1. gkellogg to create issue on "unstar" operation.

Summary of resolutions

  1. This WG supports the escaping methods as discussed in Issue 16 for the N-Quads spec w3c/rdf-n-quads#16
Minutes manually created (not a transcript), formatted by scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).

Diagnostics

Succeeded: s/?/The Web Conference/

Succeeded: s/Claire Nelson/Clare Nelson/

Succeeded: s/hWork/Work/

Succeeded: s/Aura/Ora/

Succeeded: s/note/vote

Succeeded: s/the types of things that the types of things that/the types of things that/

Succeeded: s/RDF>/RDF.

Failed: s|pulls/17|issues/16|

Failed: s|pulls/17|issues/16|

No scribenick or scribe found. Guessed: dlongley

Maybe present: pchampin

All speakers: dlongley, gkellogg, ivan, manu, markus_sabadello, pchampin, phila, seabass, TallTed

Active on IRC: dlehn, dlongley, gkellogg, ivan, manu, markus_sabadello, pchampin, phila, seabass, TallTed, yamdan