– DRAFT –
RDF and SPARQL Working Group

Progress in Resolving Undefined Errors 1

ktk: We have a PR from james on n-quads w3c/rdf-n-quads#108

<gb> PR 108 Undefined errors (by lisp)

ktk: Should be now migrated to NTriples

<ktk> w3c/rdf-n-triples#113

<gb> PR 113 revise consequence of non-conformant documents (by lisp)

ktk: This replaces w3c/rdf-n-triples#107

<gb> MERGED PR 107 implement TAG recommendation about error handling (by pchampin) [spec:substantive]

ktk: pchampin asked to do a resolution to see if we agree on the PR

ora: What we have in the document is the minimal commitment on error

lisp: If there are other documents if they define protocol, then how to handle errors can be defined in these documents

lisp: So the resolution can be that such error management can belong to e.g. SPARQL protocol

pchampin: This PR deems that even signaling is out of scope. A better representation of the PR is "we consider any error signaling or handling as out of scope"

lisp: We agree

<Zakim> TallTed, you wanted to say maybe but I need to see the words on screen to maybe get to yes/no

<ora> How about: Any error signaling or handling is out of scope for any concrete RDF syntax specification; this will be tackled in a protocol specification

Andy: I am not sure what the intent is on "signaling or handling". I agree we should not say anything about the "mechanism".

ora: can we say "any error handling is out of scope"

ora: the purpuse of a syntax spec is to specify what is the correct language. So, maybe saying "error handling is out of scope" it says we are not committing to any mechanism

<TallTed> Maybe: "Signaling or handling of syntax errors is out of scope for this or any other specification of a concrete RDF syntax; this will be tackled in {a protocol specification}." Better to say "in the xxx protocol specification." if we can figure it out.

pchampin: this PR is reducing the requirements that is in the spec. The PR is moving from "error should be handled" to "undefined behavior on error"

ora: what about to say "this is a spec for correct language, we do not commit on how expose or handling it"

ora: "the purpose of a syntax spec is to define what correct language is". then we say "the specification is not to specify how we signal or handle error" then we say "error handling is left to protocol specifications"

<TallTed> I will have tweaks. moment.

ktk: Do we need to be explicit on what language we add to the specification?

ktk: the text now is very minimal

<Zakim> gtw, you wanted to quibble with "left to protocol specifications"

<TallTed> "The purpose of a syntax specification is to define correct language. Syntax specifications are not meant to specify how to signal or handle errors. Error handling is addressed by other specifications, mainly protocol specifications."

gtw: Not all users use a well defined protocol.

lisp: I would put reporting in the protocol spec, not handling

<Zakim> Tpt, you wanted to nitpick about handling

<TallTed> "The purpose of a syntax specification is to define correct language. Syntax specifications are not meant to specify how to signal or handle errors. Error signaling and handing are addressed by other specifications, including but not limited to protocol specifications."

Tpt: handling is a bit in protocol specs, for example stating that on a syntax error no new triple is inserted when POSTing a Turtle document to a graph store endpoint

<ora> PROPOSAL: The purpose of a concrete syntax specification is to define correct language. Syntax specifications are not meant to specify how to signal or handle errors. Error signaling and handing are addressed by other specifications, including but not limited to protocol specifications. All syntax specifications are to be amended to reflect this.

<ora> +1

<tl> +1

<lisp> +1

<gtw> +1

<TallTed> +1

<Dominik_T> +1

<doerthe> +1

<olaf> +1

<ktk> +1

<Andy> 0+

<pchampin> -0.5

<Souri> +1

<niklasl> +0

<rubensworks> +0.5

<Tpt> +1

RESOLUTION: The purpose of a concrete syntax specification is to define correct language. Syntax specifications are not meant to specify how to signal or handle errors. Error signaling and handling are addressed by other specifications, including but not limited to protocol specifications. All syntax specifications are to be amended to reflect this.

pchampin: my fear is that we might hear that we don't push for interoperability here

TallTed: I don't think our charter is to provide a full stack of spec

<ktk> +1

ktk: I see your point pchampin. My takeaway is the TAG is a very narrow use case. We have as a group agreed that there are many other scenarios.

Review of open PRs, available at 2

<lisp> rdf-tests\/pull\/324 is to be withdrawn as it has been superseded

<gb> Issue 324 not found

<doerthe> yes

ora: can we merge w3c/rdf-semantics#200

<gb> PR 200 Fix link to "substitution mapping" (by tidoust)

ktk: for the error PR, we merge in NTriples first then replicate to the other specs

<Dominik_T> IMO w3c/rdf-concepts#282 is ready to merge

<gb> PR 282 Reference RFC 9839 in Security Considerations (by domel)

<TallTed> RRSAgent's parsing keeps changing. I'll leave fixing the above to @pchampin

olaf: w3c/sparql-query#417 is new and still needs to be reviewed

<gb> PR 417 Removes blank nodes in the algebraic syntax (by hartig)

olaf: This PR changes the definition of the SPARQL abstract syntax so you don't have blank nodes in the abstract syntax

olaf: This is an outcome of discussions we had two weeks ago, and we agreed it's not needed there

olaf: note this does not prevent blank nodes in the user syntax, they are replaced by fresh variables when the user syntax is parsed into the abstract syntax

olaf: this allows to simplify some things in the semantics, and also simplify property path definitions related to triple term

olaf: I think w3c/sparql-query#400 is in good shape but I would like to see the preview of the current state

<gb> PR 400 Add SPARQL syntax sections on triple terms, reifiers, and annotations (by rubensworks)

<TallTed> https://lists.w3.org/Archives/Public/spec-prod/2026JulSep/0005.html

<ktk> w3c/rdf-turtle#157

<gb> PR 157 Move the reifiedTriple syntactic sugar explanation into the note (by domel)

w3c/rdf-turtle#157

<ktk> w3c/rdf-new#18

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

Any Other Business (AOB), time permitting

ora: We need to check that the shared ISWC/TPAC RDF WG time slot is at the same time on both schedules

<Andy> 26 October 2026, 13:45–16:45 UTC

<pchampin> https://www.w3.org/events/meetings/ed125ed5-2d0a-4ca4-aab6-bfba882ec7fd/

<Dominik_T> The overlapping period is therefore 15:45-18:00 CEST, i.e. 2 hours and 15 minutes.

<Andy> Italy -- Mon 14:45 - Mon 17:45