W3C

RDF-star WG biweekly focused meeting

10 July 2025

Attendees

Present
AndyS, AZ, doerthe, draggett, enrico, gkellogg_, gtw, james, ktk, niklasl, ora, pchampin, pfps, Souri, TallTed, tl
Regrets
fsasaki, olaf
Chair
ora
Scribe
draggett

Meeting minutes

definition of reifiers is non-normative and seems vague 1

Ora introduces the meeting.

<enrico> I will be listening from a bus the meeting of today.

<enrico> Regarding #169, I made clear my opinion in the GitHub discussion.

<gb> Issue 169 definition of reifiers is non-normative and seems vague (by rat10) [needs discussion]

ora: let's give 20 minutes each for the first two agenda items, does that work for people [yes]

tl: introduces definition of reifiers is non-normative and seems vague

tl: a related point is that I am not sure how the new reification mechanism relates to the old one

tl: the editors have different opinions on this

tl: maybe I had misunderstood something, I used the issue to ask for clarification

tl: is there a connection between the reifier and the triple as I thought?

tl: the semantics of the reifier clear?

tl: pchampin claimed the reifier refers to the triple

tl: let's clear up the semantics for the reifier

<enrico> I said literally "By convention, we call reifier the subject of a rdf:reifies triple"

<enrico> What more do you want to know??

pchampin: I disagree that the concept of reifier is insufficiently defined in the spec

pchampin: the domain is left deliberately open

pchampin: the new definition is clearer

tl: the old definition is clearer in my opinion. The new definition is vague, intentionally so

pchampin: I disagree with what you claim I said

tl: there are 2 very different opinions and I have no idea how to reconcile them

niklasl: pchampin's account is clear

tl: I am interested in what the reifier means as that is the only things we allow people to use

tl wants to better understand the model theory perspective for reifiers

enrico: the reifier refers to the triple term, a precise connection, end of story

<niklasl> +1 to enrico

<niklasl> Re. @pchampin 's comment of <some-reifer> a rdf:Statement . There's an example of that already in https://www.w3.org/TR/rdf12-primer/#section-turtle-reifier-representation :)

<niklasl> Also, the discussion in issue 169 seems to veer into w3c/rdf-star-wg#152

<gb> Issue 152 Explain how classic RDF reification relates to triple terms and rdf:reifies (by niklasl)

ora: my worry is that this group should represent the best understanding of RDF, so what should we do about this, I trust the group to sort it out

Adrian: is this clear for the rest of the group?

<pfps> my part of the currently-silent majority feels that this has all been hashed out over and over again with no progress

ora: we can always use external validation, but I get the sense that the majority of the group doesn't agree with Thomas

<pchampin> w3c/rdf-concepts#214

<gb> Pull Request 214 Clarify section about triple terms and reification (by niklasl)

pchampin: niklasl has a PR to improve the wording

pchampin: the discussion threads can be hard to follow.

pchampin: I would rather Thomas propose a PR for us to discuss

ora: we have run out of time on this agendum

gkellogg_: specs should be minimal in our spec wording.

<pchampin> +1

gkellogg_: reifiers are used across multiple syntaxes, so it makes sense to have a single definition for them to refer to

ora asks tl if he would be willing to create a PR as pchampin suggests?

tl: not really

<pfps> My view is that the request has been unclear.

tl: I haven't heard a clear answer in respect to the semantics

language strings missing a language tag 2

<pchampin> tl, as I think you pointed out, I did provide an answer to your question about the connection : w3c/rdf-star-wg#169 (comment)

<gb> Issue 169 definition of reifiers is non-normative and seems vague (by rat10) [needs discussion]

<pchampin> unless an editor of Concepts or Semantics steps out and disagrees with me, I think you have your answer

ora: in respect to the previous topic, let's wait for external feedback

<enrico> I volunteer to create the core of a best practices note which should provide examples answering Thomas' questions

<TallTed> Conclusion of a timebox does not imply conclusion of the issue discussed therein... Timebox has expired. Further discussion on this issue should be later.

<pfps> +1

pchampin introduces the language tag issue

<ora> +1 to enrico

pchampin: I described 3 possible behaviours, and I would be happy to let parsers implement more than one of them

pchampin: gkellogg_ has a PR for n-triples that relates to option 2'

ora: I find it undesirable for parsers to quit on the first error

<pchampin> my summary: https://lists.w3.org/Archives/Public/public-rdf-star-wg/2025Jul/0005.html

gkellogg_: I was trying to layout some choices for discussion

gkellogg_: parsers vary in their behaviour

<pchampin> gkellogg_'s PR on N-Triples: w3c/rdf-n-triples#68

<gb> Pull Request 68 Add language to require that only valid IRIs ... (by gkellogg) [needs discussion] [spec:substantive] [test:needs tests]

gkellogg_: I am not seeing consensus on what we should agree to

AndyS: quite concerned about specifying error behavior, my suggestion is that parsers should raise the error, but the spec should leave it there

AndyS cites the Wikimedia graph as an example that has lots of errors

TallTed: we should not make RDF 1.2 parsers more strict

TallTed: it would make RDF less attractive to necomers

TallTed: let errors come up and allow people to deal with them

<pchampin> <%> <x:p> "foo"@abcdefghi, "bar"^^ rdf:langString .

TallTed: RDF graphs evolve and may have errors during that proces

TallTed: let it be lax until we decide otherwise

ora: sounds akin to XHTML, which was very strict, whilst the world wild web was not

pchampin: I don't think we are facing that problem here

pchampin talks through some examples

pchampin: we could have the spec be more relaxed

pchampin: the spec should avoid overly strict requirements on implementations

pchampin: there is a discrepancy between the syntax and the concept

<pchampin> james, the decision about ill-typed literals was "accept whetever is valid in the abstract syntax, even if semantically inconsistent"

TallTed: this is a question of where and how the error is raised

<pchampin> the problem raised her is about things that are not valid in the abstract syntax

<pfps> one point with ill-typed literals is that determining whether they are ill-typed depends on whether the datatype is recognized.

TallTed describes some clarifications

TallTed: we will have a better reception if the collision occurs at a later point when parsing a file

TallTed: when I do a SPARQL query on dirty data I won't get trustworthy results

ora: for practical reasons I want parsers to report when they detect breaches

<Zakim> TallTed, you wanted to mention "strict" vs "lax" flagging options

ora: should we endorse certain behaviors in that respect

TallTed: some parsers offer the means to set strict parsing

AndyS: the community has a general agreement on when to abort parsing

AndyS: I want to match community expectations

gkellogg_: we should use words such as MAY, as in implementations may ...

gkellogg_: let's not require any specific behavior, but at least call out the corner cases

<pfps> RDF 1.2 Triples defines a conformant N-Triples parser as one that creates an RDF graph. Changing this would be a spec change.

<TallTed> I fully support tests *and* tools that have strict/lax flags.

pchampin: gkellogg_'s PR is reasonable

<TallTed> (Virtuoso has ways to be more and less strict about what gets loaded, and about what happens when data is more and less compliant.)

ora: please take a look at gkellogg_'s PR

<gb> Pull Request 68 Add language to require that only valid IRIs ... (by gkellogg) [needs discussion] [spec:substantive] [test:needs tests]

Proposed for closing, available at 3

<pfps> Similarly for Turtle - conformance requires producing an RDF graph.

ora: why is 83 still open? Can we close it now?

AndyS: yes, as the editors agreed

TallTed: has my latest suggestion been applied?

AndyS: that was on semantics

TallTed: I see general acceptance of my PR

TallTed: don't close this just yet

gkellogg_: the language strings can be closed once we have sorted n-triples

ora: we are at the end of the call

<m2gbot> comment created: w3c/rdf-star-wg#169 (comment)

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Succeeded: s/let's give/ora: let's give/

Succeeded: s/james: let's look at AndyS//

Succeeded: s/but/but the spec should/

Succeeded: s/syntax/syntax and/

Succeeded: s|agendum 2 -- language strings missing a language tag -> 2 https://github.com/w3c/rdf-turtle/issues/37 -- taken up [from agendabot]|

Succeeded: s|Topic: Proposed for closing, available at 3|

Succeeded: s|Topic: Issue 169|Topic: w3c/rdf-star-wg#169

Succeeded: s|Topic: w3c/rdf-star-wg#169|

Succeeded: s|https://www.w3.org/2025/07/10-rdf-star-minutes.html|

Succeeded: s|m2gbot, link issues with transcript|

Succeeded: s|Topic: language strings missing a language tag 2|Topic: language strings missing a language tag -> 2 https://github.com/w3c/rdf-turtle/issues/37

Maybe present: Adrian

All speakers: Adrian, AndyS, enrico, gkellogg_, niklasl, ora, pchampin, TallTed, tl

Active on IRC: AndyS, AZ, doerthe, draggett, enrico, gkellogg_, gtw, james, ktk, m2gbot, niklasl, ora, pchampin, pfps, Souri, TallTed, tl