RDF and SPARQL Working Group

Meeting minutes

TAG's advice on error processing (vote)

ktk: we had another round of discussion last week; I think we agreed that we don't want to formalize any further what parsers are doing
… we came to the conclusion that it would require more time that we have
… we could not confer with the chair earlier to send a proposal in advance

pchampin: I would like to make some progress. Ideally some actions, like have someone writing some text on what we agreed on, as plain text.
… We would not get further in a more formal way, because many applications have different use cases and the most useful way is to keep it undefined.
… Maybe not a very formal text but if someone could do a PR we can have a look at it next week.
… What might help for the TAGs concern is to require that any further version (above 1.2) would require the presence of a version announcement. Currently we don't require it because we want to be nice on old parsers. But if we say that RDF 1.3 MUST announce it, it might reassure the TAG that current parsers will not be completely at loss with future data. Which is the summary of their concerns.

AndyS: I think it is a good idea, although MUST might be too strong

<TallTed> "The WG expects that RDF 1.3 and above will require..."

ktk: any other opinion? any volunteer to propose a PR?

<TallTed> perhaps "modulo future events"

Dominik_T: I was not present in the last week, so I may not be in the best position to make a proposal

lisp: my position is that we should just say "the result is undefined"
… I can look at the document and send a note to its editors about where I think this should be added

pchampin: feel free to make a PR; then the editors can decide to merge it or not

ktk: great; we can discuss on this next week

Review of open PRs, available at 1

ktk: as we didn't have time to review PRs last week, I propose we do it now
… any specific PR someone wants to discuss?

<ktk> w3c/rdf-turtle#150

<gb> PR 150 Version fix (by pchampin)

<Dominik_T> +1 for both

<ktk> w3c/rdf-turtle#152

<gb> PR 152 address erratum 14 (by pchampin) [ms:CR]

ktk: any reason we didn't merge these ones? I see green ticks...

AndyS: there are outstanding comments on the latter, that need to be incorporated

<ktk> w3c/rdf-concepts#280

<gb> PR 280 refactor considerations on versions (by pchampin) [ms:REC]

<ktk> w3c/rdf-concepts#275

<gb> PR 275 add note about sets of quads vs. dataset (by pchampin)

AndyS: we have a style in this WG that people who make comments to not come back after

<ktk> w3c/rdf-tests#325

<gb> PR 325 Align xml-canon to previous behavior (by afs)

pchampin: I'm sorry for having been unresponsive on these PR that I opened. I won't take offense if the editors decide to apply suggestions and/or merge them

<TallTed> May I suggest reviewing the oldest last-change first, in order, which we can quickly pass over if appropriate, but this keeps them from just lying fallow because we have more exciting, more recently touched at the top of the list (and if we add a comment "skipped this week", that will keep them from being the same "oldest" every time)?

AndyS: 325 is on tests with XML literals; if Tpt and gtw are ok, it can be merged

Tpt: I'm ok with it

gtw: I'm not up-to-speed on this, but go do it

<ktk> w3c/sparql-query#327

<gb> PR 327 Clarify that unaggregated variables in SELECT raise an error (by Tpt) [spec:bug]

ktk: this one has been stale for a while; are we waiting for something?

AndyS: it's on me to revise it; it should remain a draft in the meantime

<ktk> w3c/rdf-new#18

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

ktk: then we have a bunch of CSS PRs

Tpt: I did rebase them, now waiting for reviews from editors

AndyS: I suggest to put them in and see what happens