Meeting minutes
Discussion of Peters remarks 1 & the proposal by the chairs 2
presentation by @pfps
pfps: "Stick to the Basics", i.e., do what we should be doing before going on tangents
… syntax is less important than what is intended to be communicated through that syntax
… quoted/named/blank graphs substantially complicate matters
… proposes satisfying the charter, and declaring victory
… THEN considering other stuff
<pfps> I'm rather astonished that Zoom worked well for me. :-)
presentation by tl
<pfps> My slides are on the mailing list at https://
tl's slides: https://
presentation by pchampin
pchampin: sympathizes with pfps concerns of the list of work to be done
… work around N3 for graph terms, but need to not import all of N3
… making large changes between early-adopter implementations of un-spec'ed RDF-star, and our output, could break implementer momentum, marking importance of use cases
… there are issues with repurposing named graphs for quoted/annotated triples ... could work through resolving these issues instead of taking them as reason to invent something else for quoted/annotated triples
<fsasaki> Apologies that I have to leave early today. Just my +1 to pfps presentation about keeping the focus on rdf-star.
<ora> Thanks fsasaki
pchampin: our overarching goal should be to produce the smallest spec to satisfy the largest community
<gkellogg> +1 to pchampin
<niklasl> +1 from me too
TallTed: I'm concerned by the references to "concentrating on RDF-star". It does not exist until we say it does.
<Dominik_T> +1 to pchampin
<niklasl> +1 also to Ted: RDF-star is not yet a standard
TallTed: The pre-existing implementation, the "early adopters", they didn't implement a standard. They don't interoperate.
… This is red hearring and discard a lot of what we have already done.
<niklasl> ... but GraphDB examples seem to make the seminal example mistake...
olaf: GraphDB implements exactly what we have in the CG report
tl: could pchampin elaborate on convergence of named graphs and quoted triples?
pchampin: doesn't have a clear idea right now, but mailing list content suggests some threads worth pursuing
presentation by AndyS
Slides -- https://
<Zakim> TallTed, you wanted to suggest thinking of "blank nodes" as "pronouns" can help with clarity, and by revealing hidden issues
TallTed: it can be helpful to think about blank nodes as pronouns
… without an antecedent, a pronoun has no meaning, but with an antecedent it has a lot of meaning
… the same for blank nodes: the context makes all the difference
… blank nodes can be challenging but are necessary
tl: did you say that we should standardize graphs?
<niklasl> I think Andy's point is important; and wonder if bnode skolemization is a "dead end" for accessing bnodes over the web, or a possibility?
AndyS: I didn't say anything strong one way or another. My point was to insist on "it's the web"
… I happen to think that if we don't have groups of triples, I'm less confident about triples on their own.
… But that's not an absolute MUST do.
… My idea would be a modest way of going forward with quoted graphs.
presentation by niklasl
niklasl: [ slidedeck "Talking about Occurrences": https://
AndyS: general comment, not specifically on deck from niklasl -- can't quite square our replacing a chunk of RDF Concepts, with the idea that we have not changed the RDF data model
ora: Any other presentations waiting?
gkellogg: another comment... the only way we have to talk about things is through syntax, but we need to be careful about relying on syntax when discussing abstracts
… nested graphs are graphs within graphs but they don't seem to be represented via triples
[ please clean and supplement that, as needed ... I've failed to track speech sufficiently to capture even a skim ]
gkellogg: in my mind, blank nodes have always had something of a wave/particle dual-nature
… among other things, you can only refer to them indirectly, and this inevitably loses some pieces of the original through that indirect reference
Discussion
ora: various opinions were presented
ora: I'm leaning towwards what pfps proposed
ora: I'm worried about finishing the work
enrico: I agree with you (ora & pfps)
… we should provide well thought hooks for those who want to extend the work to graph terms
… the work is already complex
… we should have something in a final report about what we know is not going to extend well in the future
niklasl: I'd like to clarify something on what was proposed by pfps
… what I proposed as simple solution, having just syntactic sugar
… I'm worried that ??? would complicate things and may harm adoption
enrico: reification is something we should not refer to at all when we talk about triple terms/etc
… if we use reification we lose the model theory
<niklasl> on the contrary, the subject of a reification is the thing referred to
enrico: a triple term denotes a resource in the real world and we can talk about
… but the property rdf:subject, rdf:object are meaningless
pfps: I'd be happy to get behind something like quoted triple as syntactic sugar for reification
… I thought it was stil an option on the table
niklasl: happy to hear that [what pfps said]
enrico: if quoted triple are syntactic sugar for reiffication,
… you have in the model theory those spurious properties that are just here to encode a syntactic construct
… these properties represent "tricks" to represent a triple
… they are meaningless in the real world
tl: nested graphs have a name, and you know what the name denotes
… and they can be nested
… graphs compared to triples, going for graphs is much easier than having only triples
… what matters is I query graphs for information, comparing graphs is not important
… maybe I'm missing something and I'd like to understand, but otherwise I'm for graphs
pchampin: comparing graphs is important for some tasks
… I disagree with enrico about reification not really meaning anything
… I don't see much difference with triple terms
… RDf-star provided an alternative way of expressing reification that people adopted
… I would support triple terms rather than graph terms for acceeptability by the community
gkellogg: quoted triple (as it is defind now) has the same meaning wherever it appears (it's a type, not token)
… while reified triples are tokens
<pchampin> +1 gkellogg, this would mean that
<pchampin> << s p o >> :a :b, :c.
<pchampin> and
<pchampin> << s p o >> :a :b.
<pchampin> << s p o >> :a c.
<pchampin> would parse to different graphs
gkellogg: [SOMETHING] made the problem more apparent
… with triples only we can only talk about one triple if we have an identifier for it
niklasl: you can always use an identifier for a triple term or anything
… if quoted triple are syntactc sugar for reification,
… then it make it a token
… you could still have a way to have types, for instance with owl keys
… we don't really talk about the abstract tripples, we talk about occurrences
… named graphs are, imo, much more powerful
… they have grouping capability
<olaf> s/abstrac ttripples/abstract triples
niklasl: is there something wrong iin the named graphs paper from 2005 wrt singleton edge
tl: the named graphs paper does too many things
… the semantics of the NG paper is opaque
… grouping triples is what people need in practice
… rdf-star CG discussed adding a proeprty "occurrenceOf"
… but I don't like that, nested graphs solves the issue
pchampin: reaction to gkellogg's comment
<pchampin> << s p o >> would be equivalent to
<pchampin> [ rdf:subject s; rdf:predicate p; rdf:object o ]
pchampin: I don't think there is a problem with N-triples
… in N-triples, there would not be the syntax sugar appearing
… another issue I would raise is SPARQL
… in PSARQL if a varibale matches a quoted triple
… I retrieve the quoted triple with its sub, pred, obj
… if we go for syntactic sugar, we would retrieve a bnode, which is useless
… which is another reason for not going towards syntactic sugar
<niklasl> But the case for lists today is even worse!
ora: you mean it would introduce a bnode identifier
pchampin: if the double angle bracket was syntactic sugar, it could be replaced with square brackets
niklasl: I was typing the example that I mentioned
<niklasl> Here are all our use cases using quotation dashes (and variant annotation): https://
niklasl: beware it's using the notations to differentiate different things
pchampin: I wanted to respond to tl
… the angle bracket notation is fairly recent
… and I think it was a mistake
… with the current abstract syntax, there can be other ways of writing it
tl: I think it would be better if the notation could expend to something with an identifier
… RDF-star is way too focused on type and that's inpractical
… it's easier to define but it's much harder to use
<niklasl> Here are my motivations for -- and {[...] [...]} or {<...>}: https://
pchampin: the situation with the seminal example
… it was not future proof
… quoted triples were always types from the very first definitions
… the seminal example was maybe bad modelling but it did not change what quoted triples are
tl: it took years to realise that this was a problem
AndyS: eventually, we need to have types
… if you have occurrences of the same thing, you at some point want to know what they refer to, which is the type
tl: we could use literals to refer to types
<niklasl> Pat wrote: all we are ever needing to identify are graph tokens, not abstract graphs. You name a graph by identifying a token of it.
AndyS: a literal is self denoting
<niklasl> +1 to Andy, they are all self-denoting
<niklasl> "the meaning of meaning is its meaning"
ora: I'd like to know the way forward, considering these discussions
… we need to look at use cases
… are there UCs that require one of these proposals
… also what these proposals would look like in terms of abstract syntax
… how much things should be changed/extended
<pfps> One problem with using use cases to push everytthing is that several views of quoted triples are equally expressive.
ora: especially for nested graphs
… I propose as homework:
<niklasl> My slides at 32 and 33 address "what do we do now" (and the use cases we've collected are covered). But there are questions in those two slides.
ora: find what use cases are supported by each proposal
<niklasl> +100 for what are people currently doing with RDF
ora: and to understand the abstract syntax better to know what it implies for the work to be done
niklasl: with my proposal, the case of occurrences come for free
… I'm not sure it implies changes to the abstract syntax
… I would need to know the implementation [not sure I got the point]
tl: we may not need any change [to semantics] if nested graphs are just surface syntax
olaf: about what ora mentioned and gkellogg
… anything we propose can be defined in terms of the existing concepts or concepts that we build on top
<tl> correctio tl: we may not need any change [to abstract syntax] if nested graphs are just surface syntax
olaf: I disagree with tl about the nested graphs proposal requiring no change
… but that's my interpretation from the examples
<pchampin> that's also my interpretation
olaf: on the ML tl's proposal seemed to change the definition of an RDF graph
… to include nested graphs as terms
tl: at line 215 of my example file, there is something releveant
AndyS: I don't find the large examples particularly useful
niklasl: the syntax I propose reduces to Nquads
… I don't think my proposal requires additions to the syntax but maybe to the semantics
… I'm not strictly focused on blank graphs
ora: now we need to understand better the merrits of each of these proposals
… I'm giving a talk tomorrow about OneGraph
enrico: the agenda of the semantics TF is to attend ora's talk!
<niklasl> Yes, thanks all!