Meeting minutes
ora: new member William van Woensel
william: member of Notation3 CG
… interested in RDF-star for quite a while, quoted graph terms in N3
… identifiers welcome
… invited expert
Approval of minutes from the last two meetings: 1 , 2
<Souri> +1
<ora> PROPOSAL: Approve minutes from 2024-08-01 and 2024-08-08
<gkellogg> +1
<niklasl> +1
<gtw> +1
<ktk> +1
<ora> +1
<AndyS> +1
<tl> +1
<doerthe> +1
<TallTed> +1
<olaf> 0 (abstain, as I wasn't there)
<william_vw> 0 (also abstaining)
<TallTed> s/interested in RDF\*/interested in RDF-star
<eBremer> +!
<eBremer> +1
<fsasaki> +1
RESOLUTION: Approve minutes from 2024-08-01 and 2024-08-08
Proposal for next week's discussion
ora: would like to have a final discussion on profiles
adrian: please provide a proposal in writing before next call
ora: will do, probably next week, at least to clarify what it is we are looking for
… would be interested to know about any objections to having profiles
… OpenCypher over RDF now supported in AWS
… any objections?
peter: very much too early for a discussion about profiles, because we're still trying to put the baseline in place
ora: understand, but ... would like to have a discussion about if we even support the idea of profiles, and I know that you Peter are against it.
… would it be considered haarmful to have profiles
pfps: profiles are an evil, but sometimes a necessary evil
ora: much rather like to have a single standard, but my organisation has specific needs
gkellogg: we do have different profiles already - classic and full
<ora> Neptune Analytics now supports openCypher over RDF: https://
ora: have a more general discussion about profiles?
tl: discuss more details about AWS problems/profile requirement
ora: would like to have a profile that allows us to say we support RDF 1.2 but still not support many-to-many reifications
<niklasl> Thomas' mentioned mail after last week's discussion (about "LPG many-to-many"): https://
enrico: but that's a major problem for the RDF side
… maybe best practice
ora: if someone suggests this might disrupt RDF, implementations, or similar, then I'm happy to discuss
fsasaki: would prefer to have this discussion related to profiles rather sooner than later
<ora> PROPOSAL: Next week: general discussion about profiles (esp. "LPG-profile"), what's possible, what's not, caveats/pitfalls
adrian: is marcel otto using the many-to-many reifications?
niklas: he has re-invented them, because he used an earlier version of RDF-star
<ora> +1
<AndyS> +1
<Dominik_T> +0.5
<fsasaki> +1
<gtw> +1
<ktk> +1
<TallTed> +1
<Souri> +1
0 (scribing)
<enrico> +1
<doerthe> +1
<niklasl> +1
<olaf> +1
<gkellogg> +1
RESOLUTION: Next week: general discussion about profiles (esp. "LPG-profile"), what's possible, what's not, caveats/pitfalls
niklas: discussion about consequences of profiles (ups and downs), not so much about many-to-many
Review of pull requests, available at
<AndyS> https://
ora: interested in possible consequences of profiles, things that may be blowing up
ora: item 4 seems like an obvious candidate. is it old enough?
gkellogg: update to turtle
… changed name of reified triple production, to "reifying triple", maybe let this sit another week
… like to hear andy's opinion
andys: time constraints...
gkellogg: probable that we will be able to merge after next week
… changes in turtle that I would like to have eyes on
ora: what about the readme
ora: what about "informative definition of reified triple"?
gkellogg: not sure if it really belongs in RDF concepts
… best practices need a definition
olaf: about sparql specs, some examples with shorthand notation sensible, but not all of them
… some examples will need standard notation
… so we shouldn't change ALL examples to shorthand notation
gkellogg: agrees
AndyS: working on sparql grammar reflecting recent syntax changes
… testing ongoing
ora: guess that's it for pull requests
Issue Triage, available at
<ktk> https://
gkellogg: a lot of things in there probably just need to be disposed of
… should take time to trim this down to things we actually work on
… maybe at TPAC
ora: agrees w.r.t. TPAC
<TallTed> +1 to focus a call on triage. TPAC time is a possibility.
ora: did get travel approval for TPAC, so will be there
… anything we could dispose now?
… many small editorial things that shouldn't take much time to take care of
<gkellogg> w3c/
<gb> Issue 34 Terminology for graph/dataset without triple terms. (by gkellogg) [propose closing] [spec:editorial]
gkellogg: rdf concepts line 9
… could be closed, is all done
aaaand ... closed
ora: a lot of untagged ones. would someone volunteer to tag them before we go through them?
<pfps> at various times I have gone through the list and tagged the ones that I could. I think I ended up tagging 20 or 30.
gkellogg: when they come from outside they should not be just closed but get some formal response
Any Other Business (AOB), time permitting
ora: thanks pfps
gkellogg: rdf:states needs discussion
ora: good idea, thoughts?
<Souri> https://
gkellogg: prefers other ways that don't rely on more predicates, might look hackish
souri: the more i think of it i find it is essential, not a hack
… (shares screen)
<enrico> I agree with gkellogg
souri: explains an example where :Bob is associated with different companies, annotated with different time periods, overwrites "unassertedness"
… we need rdf:reifies AND rdf:states
… it's not a hack. most things in the world are actually asserted. would like to have a 1:1 correspondence from annotations to asserted facts
enrico: we can model this from the baseline
… there's not so much difference as to warrant another predicate
… also: what does it mean to be asserted
… a triple may mean a wedding, a certificate, a xxx
… for that we have different term identifiers
… time dimension is more an extension
TallTed: struggling to understand example (provides detail)
ora: you make statements about statements. s can be asserted or not. those two things are independent
Souri: (screen again)
… rdf:reifies is the only triple that has triple term as range
rdf: reifies is not some arbitrary property, the spec defines it
… https://
… we need an association between triple and what we say about it
… but this is different from reification
<TallTed> "reification" is *exactly* "associating an identifier"!
rdf: especially LPG and ??? need a 1:1 association
<doerthe> @tl (I write, as this meeting is about to end) your statement about asserting triples in the original RDF-star proposal is not entirely true as the semantics back then was defined through rdf-reification, if we have that, it is still possible to remove the asserted triple itself. So basically, we only had no shortcut for only reifying a triple
<doerthe> without asserting it, but that was always possible. (But you scribe, I should write a mail to not stress you)
<enrico> Announcement for tomorrow's Semantics TF: Discussion on the semantics of rdf:states, in comparison with LPG, relational DBs, and other use cases.
<gkellogg> This remindes me of the RISC vs CISC processor wars (reduced vs complex instruction sets).
rdf: rdf:states is not a hack, but a very important thing to have. I feel very strongy about it and would like to discuss this more
<TallTed> right, it's the *shortcut*, the *syntactic sugar* that we're adding. Being able to both assert and annotate in one "statement", rather than having to repeat what is being asserted in order to annotate it.
ora: out of time, suggest to pick this up at our earliest opportunity
enrico: will be on agenda for tomorrows semantics TF
<ktk> s/haarful/harmful/
<ktk> s/aaand.../and.../
<ktk> s/have a discussion about profiles/let's explore and clarify the use of profiles/
<ktk> s/rdf: /tl: /