Meeting minutes
<gb> Pull Request 57 Charter extension 2024-03 (by pchampin)
Approval of minutes from the last two meetings: 1 , 2
Approval of minutes from the last two meetings
ora: Any objections to the minutes for the last 2 meetings? [no]
<ora> PROPOSAL: Approve both sets of minutes
<ora> +1
<fsasaki> +1
<pfps> +1
<Souri> +1
<gtw> +1
<ktk> +1
<gkellogg> +1
<pchampin> +1
<niklasl> +1
RESOLUTION: Approve both sets of minutes
<AndyS> +1
No meeting on May 30.
ora: many of us are unavailable next week on account of Adrian's workshop, so no call on May 30.
Re-chartering 3
<gb> Pull Request 57 Charter extension 2024-03 (by pchampin)
<eBremer> present!
ora: where are we on rechartering?
<pchampin> w3c/
pchampin: pending pull request, which basically extends the charter by one year.
<gtw> "End date: 28 August 2026" (?)
pchampin: we need a group decision on approving this and proceeding with the rechartering process, unless that is anyone has something else to add.
… probably a typo on the end date :-)
… should be 2025
… how about making it end of a Friday rather than mid-week?
<gtw> The PR also adds the language "Rechartered for two more years".
<AndyS> commit log message " 2-year extension, with explicit 'maintenance' scope once RECs are pub[lished]"
pchampin: we were talking about one year to finish the deliverables and a further year on maintenance
ora: does the process document say something about maintenance?
pchampin: working groups can be chartered just for maintenance.
AndyS: if things are converted in to living RECs, how does that apply?
pchampin: it needs a working group and these are created to specific periods of time only.
fsasaki: a precedent from the I18n WG, we chartered to handle errata rather than spec extensions
AndyS: should we rename the WG as it won't be about RDF-star at that point?
pchampin: good point.
The WG name can get into URLs ...
<ktk> s/ present!//
gkellogg: RDF WG would make more sense considering the possibility of minor updates.
pchampin: we had a similar conversation a while back, and decided a change of name might confuse the AC as we don't want to give the impression of changing course.
… At this point a name change might create some noise ...
ora: pchampin do you have enough to proceed?
pchampin summarises the changes
he will update the pull request accordingly
Proposal for next week's discussion
ora: this means 2 weeks from now!
AndyS: what do we need to discuss before we make a decision?
niklasl: we need to socialise the discussion, i.e. to test it on the use cases, and perhaps to collect some more substantive examples.
ora: considering the use cases would be a good thing
<Zakim> AndyS, you wanted to note the latest examples are not on the email list.
<AndyS> https://
AndyS: I couldn't see the latest examples on the email
ora: this could validate our ideas
niklasl: the notion of wellformedness is something we need to clarify
ora: good idea, as I would like to better understand that too
AndyS: any further proposals would need to show that they are better
ora: I look on this as we now have a good candidate to move forward with
Ora asks AndyS to propose some text on our plan
<AndyS> 1. Map the steps to then 2. vote on a working baseline and 3. map further work.
AndyS: if we get to voting next call, that would be really good
<AndyS> 1. Map the steps to get to 2. vote on a working baseline and 3. map further work.
AndyS asks niklasl where he sees the work on wellformedness fitting in
AndyS: can we change the wording from clarify to defining wellformedness
AndyS: the vote will be in 2 stages
<AndyS> 1. Map the steps to get to 2. vote on a working baseline and 3. map further work testing the use cases and verifying well-formness
ora: the key thing is to establish a baseline
<gkellogg> +1
<fsasaki> +1
<ora> +1
ora: is everyone in favor?
<pfps> +1
<niklasl> +1
<Souri> +1
<eBremer> +1
<pchampin> +1
<AndyS> +1
<gtw> +1
<ktk> +1
RESOLUTION: 1. Map the steps to get to 2. vote on a working baseline and 3. map further work testing the use cases and verifying well-formness
Review of open actions, available at 4
ora: no open actions at present
Review of pull requests, available at 5
pfps: comments on -0
<gkellogg> https://
gkellogg: Peter also raised whether data types need to refer to canonicalisation at all
… There is a possibility for canonicalisation to be handled in a future version of the JSON-LD spec rather than here
… I need some help
ora: any volunteers?
gkellogg: specifically this is about JSON datatypes
AndyS: defining a canonical form for xsd datatypes is problematic
<Zakim> pfps, you wanted to mention that rdf:XMLLiteral has a canonical form and it should probably be removed
pfps: rdf:XMLLiteral has a canonical form and it should probably be removed
AndyS: what is it in RDF 1.1?
pfps gives a short extract
<pfps> The canonical mapping
<pfps> defines a canonical lexical form [XMLSCHEMA11-2] for each member of the value space. The rdf:XMLLiteral canonical mapping is the exclusive XML canonicalization method (with comments, with empty InclusiveNamespaces PrefixList) [XML-EXC-C14N].
gkellogg expands on this
AndyS: if we are agreed on giving a canonical form where practical ...
gkellogg: the work is mostly about blank node labels
AndyS asks gkellogg if there is anything else he needs helpl with
<pfps> My concerns are that there needs to be a precise definition of the lexical space and a precise definition of the lexical to value mapping. The current PR has neither.
gkellogg: there is a way to address Peter's concerns with new language, I've tried but need help
ora: what's with the entailment algorithm in the pull request?
AZ: we can close it
pfps: it looks okay to me
ora: let's merge it
ora: anything else?
ora: end of meeting