W3C

– DRAFT –
RDF-star WG

23 May 2024

Attendees

Present
AndyS, AZ, draggett, eBremer, fsasaki, gkellogg, gtw, ktk, Kurt, niklasl, ora, pchampin, pfps, Souri
Regrets
dtomaszuk, enrico, tallted, tl
Chair
ora
Scribe
draggett, dsr

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/rdf-star-wg-charter#57

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://github.com/w3c/rdf-star-wg/wiki/RDF%E2%80%90star-examples-of-profiles

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://www.rfc-editor.org/errata/rfc8785

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

Summary of resolutions

  1. Approve both sets of minutes
  2. 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
Minutes manually created (not a transcript), formatted by scribe.perl version 222 (Sat Jul 22 21:57:07 2023 UTC).

Diagnostics

Failed: s/ present!//

Succeeded: s/verifing/veryfying/

Succeeded: s/veryfying/verifying/

Succeeded: s/verifing/verifying/

All speakers: AndyS, AZ, fsasaki, gkellogg, niklasl, ora, pchampin, pfps

Active on IRC: AndyS, AZ, draggett, eBremer, fsasaki, gkellogg, gtw, ktk, niklasl, ora, pchampin, pfps, Souri