W3C

RDF-Star WG

10 August 2023

Attendees

Present
AndyS, DaveRaggett, doerthe, enrico, gkellogg, gtw, niklasl, olaf, ora, pfps, richard-lea, rubensworks, Souri, Tpt
Regrets
-
Chair
ora
Scribe
doerthe

Meeting minutes

Scribe: Haudebourg, Timothée (alternate: Arndt, Dörthe)

Approval of last week's minutes: 1

<pfps> minutes look good

gkellogg: outstanding item should be discussed, apart from that fine

<ora> proposal: Accept last week's minutes

<gkellogg> +1

ora: we add that if there is time

<rubensworks> +1

<pfps> +1

<niklasl> +1

<doerthe> +1

<ora> 0

<AndyS> +1

<olaf> 0

<Souri> +1

RESOLUTION: Accept last week's minutes

Brainstorming: “What still needs to be done” (Ora)

ora: I would like to make a list what needs to be done, just to keep the overview and organise the work

<rubensworks> w3c/sparql-update#17

<rubensworks> w3c/sparql-query#53

rubenworks: incorporation of the RDF-star community report to the sparql-update and sparql-query (w3c/sparql-update#17 https://github.com/w3c/sparql-query/issues/53)

gkellogg: the dashboard also contains open issues

gkellogg: transparency vs. opacity is open, also concrete/abstract syntax

niklas1: I am having a hard time teaching RDF-star for example relationships to named graphs

niklas1: maybe we should add at least a note to clarify

niklas1: transparency is a big part of the confusion

ora: that would indeed be good to clarify

ora: how do we maintain the list we create here? only git? something more?

AndyS: one problem for SPARQL is that changes might arise from changes to the semantics (e.g.; simple entailment), That should be resolved.

AndyS: we need more than just a list of issues, we also need tracking. Maybe the github project part is a good solution here, but this would need supervision, maybe by the chairs?

ora: Adrian and I are happy to do the gate keeping here and that would be a good idea to have

ora: this will be picked up in the chairs meeting

enrico: The use cases are related to the semantics discussion, the absence of use cases blocks the process here

<niklasl> +1 for concrete use cases informing the choice of semantics

ora: welcome to Dave Raggett

Review of open actions, available at 2

Review of pull requests, available at 3

ora: my action is open, as pchampin is absent, we cannot ask him, so issues remain open

ora: proposal to merge editorial things

<gkellogg> gkellogg: hold off on w3c/rdf-concepts#57 until next week.

<gb> Pull Request 57 Adds a definition for "IRI reference". (by gkellogg) [spec:editorial]

gkellogg: hold off on w3c/rdf-concepts#57 until next week since it is new

ora: we now have a dependency of a living spec, is that a problem, do we have experience there?

ora: what do we do concretely? Do we have to state that the dependencies were good at some point in time?

TallTed: normally there is a dated version and this is used

gkellogg: I do not find time stamps

<gkellogg> Snapshot https://dom.spec.whatwg.org/commit-snapshots/2a24a2779199ce1d7e46a3fb068b683a5b84b954/

TallTed: I think it is there but can't check at the moment

AndyS: Are there guarantees about what stays valid?

ora: either we need guidance or we need to come up with our own principles how to handle it

DaveRaggett: If you make a concrete question, I can look up how this can be don/is done by others

gkellogg: Maybe we need an infrastructure to get a closest snap shot to our publication?

Any Other Business (AOB), time permitting

ora: so far we only have one dependency to a living spec, to dom

<gkellogg> https://github.com/orgs/w3c/projects/20/views/5

gkellogg: we should go over issues which need discussions (as discussed in last meeting)

gkellogg: problem that language tags have different representation (https://github.com/orgs/w3c/projects/20/views/5?pane=issue&itemId=34414553) should be discussed

AndyS: we should ask the community

ora: options are 1. ask community and wait, then put it in the spec, 2. we make a proposal, 3. give it to RDF canonicalization spec

AndyS: It is not really a canonicalization problem

gkellogg: I also added issues. Forcing implementations to use lower case language tags will break a lot of implementations

gkellogg: RDF canonicalization is bound to RDF 1.1, so we can only make people aware of the problem

ora: could we make a use case for the problem?

gkellogg: how to best do it? wiki?

ora: actual real use case as all other use cases?

gkellogg: I will formulate such a use case

ACTION: gkellogg to formulate use case on language tag canonicalization

<gb> Created action #82

<gkellogg> Semantics TF calendar: https://www.w3.org/groups/tf/rdf-star-semantics/calendar/

Tpt: add to what needs to be done: a few erratas on the SPARQL query spec

<gb> Created action #83

Summary of action items

  1. gkellogg to formulate use case on language tag canonicalization

Summary of resolutions

  1. Accept last week's minutes
Minutes manually created (not a transcript), formatted by scribe.perl version 222 (Sat Jul 22 21:57:07 2023 UTC).

Diagnostics

Succeeded: s/+2/+1/

Succeeded: s/how do I start scribing? :)//

Succeeded: s/Reggett/Raggett

Succeeded: s/daveRegget/DaveRaggett/

Succeeded: s/gkellog/gkellogg/

Succeeded: s/[missed the point, please help]/a few erratas on the SPARQL query spec/

Maybe present: niklas1, rubenworks, TallTed

All speakers: AndyS, DaveRaggett, enrico, gkellogg, niklas1, ora, rubenworks, TallTed, Tpt

Active on IRC: AndyS, doerthe, dsr_, enrico, gkellogg, gtw, niklasl, olaf, ora, pchampin, pfps, richard-lea, rubensworks, Souri, Tpt