– DRAFT –
RDF & SPARQL WG meeting

Approval of last week’s minutes: 1

ora: last week's minutes

look OK to me

<ora> PROPOSAL: Approve minutes from two weeks ago

<ora> +1

<pfps> +1

<gtw> +1

<Souri> +1

<niklasl> +1

<pchampin> +1

<olaf> +0 (wasn't there)

<AndyS> +1

<tl> +1

<enrico> +1

<lisp> +1

RESOLUTION: Approve minutes from two weeks ago

Review of open actions, available at 2

ora: what's happening with #184

<gb> Action 184 import language from rdf-canon into rdf-concepts about the complexity of graph processing (on pchampin) due 2025-12-11

<pchampin> w3c/rdf-concepts#259

<gb> Pull Request 259 mention graph isomorphism in security considerations (by pchampin)

pchampin: I opened a PR for it, but it isn't linked

ora: the PR should appease the security people

pchampin: there are some comment, but convergence is in sight

AndyS: there are some editorial issues wrt #185

<gb> Action 185 PR to just remove the note referencing 1.2 test cases. (on afs) due 2025-12-11

<ora> w3c/rdf-new#18

<gb> Pull Request 18 what properties can or should link to triple terms? (by rdfguy)

ora: any concerns on this PR?

ora: if not, I'll merge it tomorrow

AndyS: there are some editorial issues

ora: I'll fix them

pchampin: can I close my action on graph isomorphism?

ora: there is a PR so the action can be closed

Updates from the SPARQL TF

AndyS: the meeting has been moved slightly later so that people can listen to a discussion on benchmarking

AndyS: the agenda is to bring things that need to be done

ora: anything to report

AndyS: olaf is working on EXISTS

thats EXISTStential :-)

ora: we'll make a report on SPARQL part of the WG meetings

Identifying issues to solve before CR 3

ora: horizontal reviews are ongoing

w3c/rdf-concepts#248

ora: editorial notes in Concepts mostly gone

ora: what about test cases?

AndyS: working on this

pchampin: RDF interop is being published as a draft note next Tuesday

AndyS: then that note can be resolved

ora: what working needs to be modified

pchampin: there is no more "unstar" so that needs to be changed

pchampin: a pointer to the draft note can be added now

ora: line item 6 is your work, Andy?

AndyS: yes, but there still needs to be an implementation document

w3c/rdf-n-triples#76

ora: line item 1?

pchampin: there are still some pending comments

pchampin: the suggestion is to just define the parameter w/o an IRI

AndyS: i think it is a bad idea to put an IRI in the MIME type document

pchampin: I agree, but the IRI belongs somewhere in the spec

ora: If the IRI is not in the MIME type registration what happens

AndyS: then the MIME registration just says that there can be any value

ora: that appears to be in line with the overall spirit of things

pchampin: I'll remove the IRI and make the PR generic

pchampin: The rest is not urgent

ora: who does the IANA registration?

pchampin: That would be me, on behalf of W3C

ora: we just make sure that it happens

pchampin: I'll add an action

<gb> Issue 76 Update media type registration (by afs)

Zackim, next agendum

lisp: If we have time can we discuss if there needs to be any change for the MIME type registrations

AndyS: the MIME type registration has to say that these parameters exist

AndyS: so that they can provide helpful information

ora: what happens if the IRI is unrecognized

<pchampin> +1, profiles can be ignored if you don't understand them

AndyS: you can ignore them, they can't change meaning

lisp: you are saying that this is change to the registration?

AndyS: profiles are a general feature

AndyS: version is slightly different - its a closed enumeration controlled by the WG

<AndyS> RFC 6906

ora: for this spec (XXX 1.2)

AndyS: later WGs can change the spec and add new permissable versions

AndyS: version should go in the graph store and ... protocols

AndyS: for protocol we should add something to the protocols

AndyS: if the MIME type registration doesn't mention protocols then having one would be unexpected and is either bad practice or forbidden

AndyS: protocol is open-ended and can be multiple

<niklasl> https://datatracker.ietf.org/doc/html/rfc6838#section-4.3

ora: then our spec states the version tag that we use

<AndyS> https://datatracker.ietf.org/doc/html/rfc6906

ora: so we can say that not having profile values is late-binding

AndyS: it's not just us but general usage

ora: james are you satisfied

lisp: but the wording includes "values"

lisp: I would not vote against our approach

lisp: the registration needs to mention that there are protocols and versions

pchampin: we could say that protocol can take any IRI