Meeting minutes
ora: TPAC planning
TPAC goals & topics 1
ora: earlier idea was refining details
… reserve some time for semantics and model
AndyS: another thing to be aware of is that we may have a visitor, of note.
… We might want to prep him about the current state of the WG. This would make things easier.
… We have to a general briefing anyway, for other's sake.
ora: may prepare a few slides
… 1 - where are we?
… 2 - points of contention - areas of debate
… there will be questions about syntax but I'd like to the focus abstract syntax and semantics
… concrete syntax can be done afterwards
… I had discussion with LPG person. Hard to explain reifiers and named graphs
tl: I made a proposal about named graphs
… noted at the time - they were in use for other things
<niklasl> Are we debating this, or mentioning it?
ora: This is not reopening the discussion. The concern is explaining to the wider audience.
tl: Don't want to reopen the discussion
enrico: We could defer until the basics are stable.
<niklasl> We need to present the differences clearly and concisely. And anchor this in the group?
enrico: what we are doing is many-many naming which can capture the ideas of named graphs / quads.
<niklasl> It's not the same as the named graph notion. There are some crucial differences.
enrico: reifier id is the 4th element of a quad. This is my observation.
niklasl: we need to clearly explain the differences. Maybe if not done in time for TPAC we should defer.
<niklasl> I can have a go.
AndyS: one of the things that can be relevant for TPAC is the fact that N3 graphs are opaque.
<niklasl> That's one important difference.
<doerthe> if you want some connection to N3, I can also help with the slides ora
AndyS: This was part of last year's discussion. We can bring that up and explain about transparency.
… The other thing is: we found it too hard. It is too big to reinvent RDF with graph literals, whatever graph literals are in this case.
<niklasl> The other main difference is that there is a named relationship between the reifier and each triple (term). This can also be "SHACL:d" and/or OWL-constrained.
ora: Will draft some slides.
… when slides done., will send out to interested parties.
… what else at TPAC
ktk: Process backlog?
ora: I gave a talk at tech user community of LDBC
… interesting points raised
… support for multiple reifiers of a triple
… may relate to some ongoing LPG thinking
<niklasl> (And just as I'm not friends with a set of people, but with each of my friends, a reifier reifies one or more triples (not the set of them)?)
ora: trying to schedule time with Alistair Green
… I had not expected LPG to be a dynamic target
… some discussion at TPAC to bring people up-to-date.
ktk: how do we align the areas e.g. schema
… whatever that means. Better to be proactive.
enrico: I have been invited to contribute to LPG schema graph.
… "Relational AI" - strong on data modelling
<Souri> Regarding undirected edges, couldn't we actually extend s-p-o in RDF to include a 3-valued direction value: forward, reverse, and none?
enrico: bringing traditions of LDBC starting from relational databases - ER c.f. RDFS.
… will be weekly meetings from mid-September
ora: there has some activity already
… interesting to see joint work starting
enrico: subset of PG-schema + PG keys
<Zakim> tl, you wanted to ask if the two TPAC meetings (Tuesday and Thursday) have different purposes
tl: Two meetings at TPAC - different purposes?
pchampin: some missing stuff on the calendar
… may not be accurate
… I think we have 4 slots overall
<niklasl> https://
pchampin: 2 full half days = 4 slots
… one is shared with JSON-LD
… about triple terms and all that in JSON-LD
ora: the chairs will sketch out the TPAC time.
ktk: 18:00 CET start , Tuesday and Thursday
gkellogg: I see 2 AM entries Tuesday and Thursday 9am Pacific time
Proposed resultion by Semantics TF (cont.) 2
ktk: we did not finish the discussion from Semantics TF.
ora: we were not ready to vote.
<AndyS> s/PG-keys/PG keys + PG-types/
enrico: Summary --
<william_vw> sorry, what does LDBC stand for?
enrico: issue is whether well-formed fragment with rdf:reifies + triple term.
<olaf> LDBC = Linked Data Benchmark Council
<olaf> https://
<william_vw> thanks olaf
enrico: want other properties allowed and it becomes a rdf:ReificationProperty
… we can get remove the s/well-formed RDF condition / syntax restriction.
… if you do something bizarre , bizarre things happen. i.e. no hard restriction
ora: if we say don't mix with old reification then what?
… we have to do answer that.
enrico: old style continues to work., It is a mix of old+new (triple terms) - RDF 1.1 data does not have triple terms so not affected.
gkellogg: we need to consider RDF 1.1 reification for mapping to classical RDF
… I think an intuition is that rdf:reifies + triple terms gives a translation to RDF 1.1
… RDF/XML ... unclear.
gtw: no probs only true for data - not tooling.
… e.g. unexpected triple term.
… such tooling will break
… Not restricted to reification
… new data will break existing modelling
pchampin: This is like RDF Collection vs RDF Seq (RDF 1.1 and RDF 1.0)
… RDF 1.1 WG decision was not to deprecate rdf:Seq - marked "archaic" to suggest using new forms.
enrico: Two elements - I'm unclear what to do. Anything with new forms will break RDF 1.1 tools.
… triple terms only have a meaning if used in a certain way.
… not clear the problem will appear.
niklasl: SPIN (https://
… RDF 1.1 reification is a pattern.
… any property that might reference a triple term is a rdf:ReifierProperty
<doerthe> I currently don't see how we can align with N3 because of the opacity, but maybe it is possible
niklasl: SPIN is (was) doing something meta.
enrico: misunderstanding about statements and triple terms
… the reifier denotes the triple term.
… the triple term is the triple term.
… tomorrow ...
<doerthe> that is btw. why I want to emphasize that much that there is a difference between triples and triple terms
ktk: similar problems at RDF 1.1 e.g. PREFIX
<doerthe> even in the semantics
ktk: some tools got left behind
… some tools update
doerthe: to Gregory: whether the class of reification property makes sense in the examples.
… can use the property with things other than triple terms.
<pchampin> +1 to what doerthe said
tl: not seeing a problem
… in general, "tools may break" is inevitable
william_vw: I disagree that it is not a problem.
… as I understood it, a triple term is used and has a reifier
… what gtw points out there are other contexts
… a statement which is not to assign a reifier
… but the inferences mix in
is this a condition for the unstar work?
ora: a continuing discussion
enrico: Semantics meeting tomorrow
<ktk> s/reslution/resolution/