Meeting minutes
Approval of minutes from the last two meetings: 1 2
<ktk> PROPOSAL: Approve minutes from 2026-06-04 and 2026-06-11
<niklasl> +1
<rubensworks> +0
<ktk> +1
<AndyS> +1
<Souri> +1
<tl> +1
<pfps> minutes look acceptable - some misplaced bits but nothing that needs to be fixed
<Tpt> +1
<TallTed> +1
<olaf> +0 (didn't attend)
RESOLUTION: Approve minutes from 2026-06-04 and 2026-06-11
Review of open actions, available at 3
<lisp> +1
niklasl: No news
AndyS: I've prepared the PRs, action can be closed.
<ktk> w3c/
<gb> Issue 60 RDF & SPARQL Working Group (by ktk) [session]
ktk: Re: ISWC - we're now committed for TPAC joint session Monday afternoon block 14:15-17:15 (presumably CEST)
AndyS: Dublin time?
… Yes, CEST -1 h.
ktk: Reserve Monday after lunch then to be safe. Confirmed from schedule: All times are Dublin, Ireland.
niklasl: We discussed voting on if WG should publish the "OWLish note" eventually.
ktk: I'll add that as a topic for next week.
Review of open PRs, available at 4
ktk: Any PR that needs discussion or can be merged?
<rubensworks> w3c/
<gb> Pull Request 388 Fix triple patterns being acceptable in subject position of triple patterns (by rubensworks)
rubensworks: I think this PR can be closed. We allowed triple patterns as subjects and opened PR to fix this; but this is an intentional structure due to property paths. So this can be closed I believe.
<lisp> +1
olaf: It can be closed. This issue might come up again. I initially had a note about why this is supported. That was requested to be removed, but now I wonder if we don't actually need such a note.
AndyS: We've got the note about literals, and what can only be determined at runtime. I'm not sure why to justify this particular case, but we can discuss it on github.
olaf: I mean specifically for the property paths rewrite.
… I suspect we will get this specific question again. It's not so obvious right now.
AndyS: Not just for paths; it's for construct templates as well.
… I'm not against a note; it's just difficult to make it clear with more words.
tpt: Since we also have symmetry also for literals, it makes sense to mention both.
AndyS: There is a note about literals already, but it's more historical.
ktk: So the discussed PR will be closed and a new one made for the note?
olaf: Yes
ktk: Anything to be merged? The PR for a note in concepts?
<ktk> w3c/
<gb> Pull Request 275 add note about sets of quads vs. dataset (by pchampin)
<ktk> w3c/
<gb> Pull Request 150 Version fix (by pchampin)
<ktk> w3c/
<gb> Pull Request 115 Add commas for clarity (by afs)
<ktk> w3c/
<gb> Pull Request 47 Adds dark mode and simplify CSS (by Tpt) [spec:editorial]
<ktk> w3c/
<gb> Pull Request 55 Dark mode, CSS and presentation simplifications (by Tpt) [spec:editorial]
<ktk> w3c/
<gb> Pull Request 260 Beginning of manifest validations using SHACL (by Tpt)
tpt: We can merge the dark mode PRs; for the last one I need to work on the SHACL shape.
<ktk> w3c/
<gb> Pull Request 107 implement TAG recommendation about error handling (by pchampin) [spec:substantive]
ktk: We'l wait for Pierre-Antoine to be back for this one.
<ktk> w3c/
<gb> Issue 86 Evolving 1.2 triple term features : rdf:parseType, rdf:annotation (by afs) [ms:CR]
AndyS: We need to go through the document and have a consistent policy for e.g. requiring the version directive or not.
… At the moment there are different policies for different parts of the document.
Identifying issues to solve before CR 5
niklasl: Looks like just a question.
AndyS: Yes, I can close unless anyone objects.
Tpt: It might be nice to have a SPARQL session to triage some of these.
ktk: In the SPARQL group or reserve time for this next week?
Tpt: Prefer on Thursday personally.
rubensworks: I can next Thursday.
ktk: We'lll add that to the agenda.
<olaf> I think Tpt created the list.
<Tpt> this one: w3c/
<gb> Issue 326 Remaining errata and errata-like issues (by Tpt)
Tpt: I'll update it before the weekend so it's in order for next meeting.
lisp: An issue for RDF concepts which arose when implementing. There appears to be a significant issue, that triple terms needs to be indexed both according to their constituent properties, and as terms. In a system with ACL, on needs to record them and identify them, and these introduce a risk of side-channeling information disclosure, which is
more intricate than with just IRIs, as these record specific relationships.
… Mechanism could be introduced to isolate them in a multitenant system. I haven't seen discussion on this, therefore I bring it up.
… If you have a dictionary-based implementation, triple terms will show up there.
<ktk> w3c/
<gb> Issue 281 where is a discussion of risks inherent in representing triple terms (by lisp)
niklasl: A joint session for JSON-LD and RDF at TPAC has been suggested. JSON-LD WG has no dedicated slots planned.
… To discuss general alignment, and specifics re. annotations and triple terms.
Any Other Business (AOB), time permitting
AndyS: The external context security issue would be good to discuss as well.
rubensworks: I'd be interested in this too.
<ktk> s/We’l/We’ll/