– DRAFT –
RDF-star WG meeting

Approval of last week’s minutes: 1

<Souri> +1

<pchampin> +1

<Dominik_T> +0 (not present)

<AZ> +1

<ora> proposal: Approve last week's minutes

<tl> +1

<niklasl> +1

<AndyS> +1

<gtw> +1

<olaf> +1

<ktk> +0

<lisp> +1

<pfps> +1

<ora> +0 (not present)

RESOLUTION: Approve last week's minutes

Next Horizontal Reviews

pchampin: We can go forward with next docs to go to horizontal review.
… TTL, NQ, TriG
… some pending PRs but these are not blocking
… remaining changes are not substanive
… good time for a group review of the doc
… we should record we agree to move towards CR

AndyS: to clarify: we are talking about Turtle, TriG and N-Quads, right?

pchampin: yes

<ora> proposal: Declare WG's intent to move Turtle, N-quads, and TriG specs to CR, and initiate horizontal reviews

<ora> +1

<niklasl> +1

<pchampin> +1

<Dominik_T> +1

<lisp> +1

<TallTed> +1

<olaf> +1

<AZ> +1

<AndyS> +1

<ktk> +1

<Souri> +1

<tl> +1

RESOLUTION: Declare WG's intent to move Turtle, N-quads, and TriG specs to CR, and initiate horizontal reviews

Updates from the SPARQL TF

AndyS: nothing particular from me

lisp: some topics that might be intersting to the WG --
… service description - need something for new features of RDF 1.2
… could be just "1.2 supported" or more detailed
… TF response - would people use more detail?
… 3 ways : (1) in REC (2) std vocab, not required (3) too complex - just SPARQL 1.2
… for automation
… I have an alt draft fro service description
… will add to "discussions" on github

lisp: Another topic: SPARQL protocol
… I have an alternative manifest which has tests in JSON/javascript.

gtw: Current tests are RDF manifest. The perl code was used for development not in the manifest.
… it was a tool used for verification

<TallTed> JavaScript would *seem* to be more "portable" as it wouldn't require a Perl ecosystem, but rather run in a browser ... but then there's the question of whether all browser JavaScript implementations are created equal

gtw: it "may" work - unproven - but we should get away from it being the "source of truth"
… the manifest should be the "source of truth".

lisp: does it depend on showing the manifest works?

<TallTed> "source of truth" must be spec. Manifest is derived from spec. Tests are derived from manifest.

TallTed: Are all JS platforms equal? e.g. in browser, outside brower.
… perl better versioned (?)

AndyS: two points
… as far as what the source of truth is, I agree it should be the manifest
… to assess the existence of interoperable implementations, they need to pass the manifest

<niklasl> Is this also relevant (as an alternative runner): ad-freiburg/sparql-conformance ? (Just trying to see what this would entail.)

AndyS: I also wanted to put on the table that this is starting to take time in the SPARQL TF
… we also have a lot of errata to address

<pfps> +1 to do the stuff that needs to be done first

AndyS: to niklas: this uses the protocol to use *other* tests, so not relevant

ora: if the manifest is the source of truth, we are moving away from the significance of the runners
… I'm assuming some prose explains how the manifest is to be used; that's also part of the source of truth

lisp: the manifest will be in good shape.

<gtw> there are at least 3 manifests. the official one (with bugs). james' version. and Gregg's updated version in a github PR.

niklasl: impl report could say which test runner was used.

ora: next - wait for james updated version then demonstrate its usable?
… (to james) how to show how the manifest is used?

lisp: I heard that impl reports would be runner+impl results

<gtw> re: black box, that's what we currently do for *all* the tests, right?

lisp: we could have a reference implementation

ora: they (ref impls) tend to bit-rot

<TallTed> a "reference implementation" substitutes for a "spec" as the source of truth. Don't want a "reference implementation".

gtw: This is like our other tests.

<TallTed> it's not entirely unreasonable to say "where there is disagreement between the output of the reference implementation's black box and the spec, the spec is the intended SoT".

AndyS: for other tests, we specify the input and the expected output; this is simple
… in the case of the protocol, it is harder to describe what you send and what to expect
… we need to be more precise on what "equality" for the expected result

lisp: an issue is that Gregg had attempted to capture the details of necessary input +output + declaring expected output

<gtw> for context, here's Gregg's PR that re-models the protocol manifest: w3c/rdf-tests#79

<gb> Pull Request 79 Fix protocol manifest (by gkellogg)

ora: keep this simple but sufficient.

niklasl: interested in this work

<ktk> https://httpie.io/

Review of open actions, available at 2

<gb> Action 188 check with domel that he is OK to move forward to Horizontal review and CR for n-quads, turtle and trig (on pchampin) due 2026-02-26

pchampin: can close #188

<gb> Action 188 check with domel that he is OK to move forward to Horizontal review and CR for n-quads, turtle and trig (on pchampin) due 2026-02-26

<niklasl> No change for me (my question in the last comment is about further direction).

Identifying issues to solve before CR 3

Any Other Business (AOB), time permitting

<ktk> w3c/rdf-concepts#265

<gb> Pull Request 265 improve discussion on text direction - fix #262 (by pchampin) [needs discussion]

pchampin: we need confirmation from i18n before merging
… then i18n review is done
… i18n have tracking items for other specs - unclear if they will get new feedback.

<ktk> w3c/rdf-concepts#269

<gb> Pull Request 269 GH-268: Some URI schemes are not path-hierarchical (by afs)

AndyS: we have a dependabot PR on rdf-tests

pchampin: I have a Dockerfile to run the automations locally, I'll test this PR with it