– DRAFT –
RDF-star WG meeting

<j22phone> Hi my main internet just went down

<pchampin> https://www.w3.org/mid/CAGqTOeda5LHd77dURz4X6BMJZL3OCFoq1k+zmeJRUd97mD-cLQ@mail.gmail.com

<j22phone> Scribing is not going to work

<ktk> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2026Apr/0019.html

Approval of last week’s minutes: 1

minutes look acceptable to me

<ora> PROPOSAL: Approve last week's minutes

<niklasl> +1

<pfps> +1

<ora> +1

<ktk> +1

<Dominik_T> +0 (not pressent)

<TallTed> +1

<gtw> +1

<AndyS> +1

<j220> +1

<pchampin> +0 (absent)

<lisp> +1

RESOLUTION: Approve last week's minutes

TAG Turtle family concerns, followup 2 3

ora: we received some concerns from the TAG

ora: we discussed this in the chairs' meeting

pchampin: the thing that I didn't see mentioned in last week's minutes is ...

pchampin: something that is in the conversation

pchampin: we do not specify what happens when a parser encounters [syntax] it does not understand

pchampin: their preference would be to give a new media type

pchampin: I think that we should not do this

ora: I'm not entirely sure I understand what the drawbacks are if we do not have a new media type

ora: this appears to me to be a solution to a problem that may not exist at all

ora: what bad thing is going to happen?

pchampin: the problem is limited to broken RDF documents

pchampin: HTML systems are supposed to gracefully handle unknown syntax

pchampin: RDF is different

pchampin: the TAG appears to be OK with not having a new media type

pchampin: so long as we acknowledge that there is an issue here

pchampin: if an RDF parser drops triples then it is just missing some information

<Zakim> TallTed, you wanted to ask for a more precise link for the second (3, above)

pchampin: this is why there is no requirements on what a parser does when it sees unknown syntax

TallTed: what are the links about?

ktk: they are bits of minutes from several TAG meeting

<TallTed> https://github.com/w3ctag/meetings/blob/gh-pages/2026/telcons/03-30-minutes.md#design-reviews1161-wg-new-spec-rdf-12-n-triples-github---csarven

<pfps> TallTed: a better link is above

<j220> pfps: pchampin Points out that RDF is open, pfps: thinks that is not the case in reality. Systems might do something bad if a triple term is dropped on the floor

<pfps> pfps: the problem is that not all uses of RDF use the open world semantic

pfps: so dropping a triple on the floor could produce incorrect (not just imcomplete) results

niklasl: we have mechanisms that make it easy for existing systems to do a right thing

niklasl: forward incompatability is inevitable

niklasl: so maybe the way forward is to note the problem and move on

niklasl: breaking old clients with new data is a problem

AndyS: the analogy with HTML is not exact because there is a human

AndyS: RDF data is more consumed by machine

AndyS: a robust application should read all the data before proceeding

AndyS: there is the W3C position - that compatability is very important

<pchampin> +1 AndyS

AndyS: there is the RDF position - that splitting would be painful

j22: what happened with the new syntax in Turtle 1.1

AndyS: the change that had impact was strings being XSD strings

TallTed: I don't recall any issues with the new prefix syntax, partly because the syntax was already in SPARQL

TallTed: the old syntax still worked in both Turtle and SPARQL

AndyS: the Turtle one is somewhat more complicated because Turtle 1.1 was the first Turtle

AndyS: the new syntax has been specified for quite some time (5 years) and there are systems that already use it

AndyS: the language direction has been sort of forced on us, and it has the same issues

ora: the WG needs to make a decision

tl: does having a new media type mean a new name and a new file extension?

pfps: along with making a decision we need to document and explain it in the Turtle spec

AndyS: maybe something needs to go into Concepts

AndyS: yes to tl - there likely needs to be these new things

AndyS: file extensions make a difference in systems

pfps: some servers might have to be changed to allow the new media type

ora: it seems to me that splitting the world has considerable implications

j22: if what we want is that no parser does something wrong then what about RDF/XML

AndyS: RDF/X

AndyS: RDF/XML has its own issues, especially ITS

j22: for RDF/XML a parser might get different triples, not just fewer

AndyS: there are implications with streaming large documents

niklasl: RDF/XML has to be a special case because of the details of RDF/X

AndyS: there are unusual aspects of RDF/XML that have to be taken into account

ora: let's do a straw poll

<ora> STRAWPOLL: "Splitting the world" via media-types and file extensions is unacceptable

<niklasl> +1

<ora> +1

<pchampin> +1

<ktk> +1

<j220> +1

<Tpt> +1

<lisp> +1

<Dominik_T> +0.9

<pfps> +1

<olaf> +1

<gtw> +1

<Souri> +1

<AndyS> +1

<TallTed> +1 with regret

ora: that seems definitive

TallTed: I wish there was a way for 1.2 software to have to treat documents as 1.1 if there is no version

ora: there is no simple answer

<Dominik_T> assume `media type = type "/" subtype [ ";" parameter ]*`, changing `type` and/or `subtype` - no, changing `parameter` possibly yes

ora: I worry about new media types, etc., in the RDF ecosystem

TallTed: consider CSS :-)

<tl> +0 (belatedly)

ora: here is a proposal

<ora> PROPOSAL: "Splitting the world" via media-types and file extensions is unacceptable

<ora> +1

<j220> +1

<gtw> +1

<pchampin> +1

<niklasl> +1

<ktk> +1

<olaf> +1

ora: then the chairs+ will meet with the tag next Tuesday

<TallTed> +1

<tl> +0

<Souri> +1

<Dominik_T> +0.9

<AndyS> +1 -- and would like to see general text somewhere that makes this clear

<pfps> +1, with the provisio that no matter what there needs to be something in the documents

<lisp> +1

<niklasl> What about the text already in

<niklasl> https://www.w3.org/TR/rdf12-turtle/#sec-version

AndyS: it might be that part of the problem is that we were not adequately clear

RESOLUTION: "Splitting the world" via media-types and file extensions is unacceptable

ora: OK, we will take this to the TAG

ora: we might be in good shape

niklasl: there is this section in the document about 1.1 vs 1.2 and negotiation

pchampin: should we take an action to add clarifying text (somewhere)?

ora: do we have a volunteer for this?

<niklasl> +1 to that (in concepts, refering to e.g. that turtle section)

AndyS: what we do might depend on talking to the TAG

ora: we could go to the TAG and say that we will add clarifying language

pchampin: sounds acceptable

<niklasl> I _think_ the relevant TAG questions are: 1) "If they reject new syntax, that's like CSS. But in an RDF context, maybe that's the wrong behavior.", and 2) "how changeable the parsers are in the wild." ...

ora: regrets for me for next week's meeting

Review of open PRs, available at 5

AndyS: what about i18n inputs?

ora: will this come up in the TAG?

ora: let's do PRs first

AndyS: nquads is editorial and small

ora: do it

ora: what else?

ora: what's the problem with named graphs no longer recent

TallTed: the text refers to named graphs as "recent"

ora: why did the check fail

pchampin: I'm looking at that

TallTed: I suggest an empty commit to cause a rerun

ora: where are we with tests?

AndyS: line item 14 is a draft to cover surrogate pairs

AndyS: some parsers let them through, some do not

ora: so we need to wait on that one

AndyS: yes

ora: what about the others?

ora: what is a d-note

pchampin: draft note

pchampin: what about short names?

ora: ok

policy for version-less short names

pchampin: there are versioned short names (1.1., etc) and non-versioned short names

pchampin: non-versioned short names are handled differently by different WGs

pchampin: we decided to have non-versioned short names only point to recommendations

<Dominik_T> s/\(not pressent\)/(not present)/

pchampin: it was suggested to also have this when there is a CR

pchampin: I support this change

ora: the CRs point to the previous REC?

pchampin: yes

ora: seems reasonable

ora: any objections

lisp: I'm more interested in consistency, so that non-versioned short names should switch all at once

pchampin: that would be a change compared to what the WG has adopted

lisp: yes, but let's not confused naive users

pchampin: what is the scope here? all RDF? all SPARQL?

lisp: all the documents of the WG

AndyS: I lean towards CR being adequate and consider RDF and SPARQL different

AndyS: I am slightly hesitant about making the change now because of the TAG issue

AndyS: if non-versioned short names point to a CR document it should be stable

ora: let's defer to next week

lisp: I had heard that a 1.1 client could request only 1.1 content

lisp: I don't see that in the document

AndyS: isn't that what profile gives you?

<niklasl> Accept: text/turtle; version=1.2

lisp: The Turtle document should mention that

AndyS: yes

TallTed: how can I eavesdrop on the TAG meeting

ora: we will provide that information

niklasl: the example with the GET request should be clarified

niklasl: "a server that receives an accept without a version should not expect anything from the client and should be conservative."

lisp: that's fine, but it should be mentioned

ora: thanks all

<niklasl> I'm also happy to report something we *don't* need to address on our own: my (year-old) "fix dark mode for stuff" PR on respec got merged this week: https://github.com/speced/respec/pull/4925#event-24421876933 :)

<gb> MERGED Pull Request 4925 Support dark mode toggle for SVGs and highlight.js (by niklasl)

ora: SPARQL tomorrow?

<Dominik_T> s/\(not pressent\)/\(not present\)/

AndyS: yes, but no agenda

regrets for me for tomorrow

AndyS: let's skip the meeting tomorrow