Meeting minutes
Relation between quoted triples, graph terms, and named graphs
pchampin: the goal of long meetings is to make progress on more technical topics.
… at half of our charter, we are late on our schedule
… important to keep in mind. We do have a charter that was deliverately kept narrow.
… Let's not get too deep in rabbit hole. Deal with the technical problems.
niklasl: The things I've been trying to put down [in emails] what is possible, what is necessary.
… Are quoted triples related to named graphs?
… Escence of why I raised the question is that if it's not only reification...
<thomas> i forgot how to cue up indicate that i'd like to say somenthing
niklasl: Opacity is one of the things that makes reification impossible.
<ktk> thomas: q+
niklasl: Opacity and type-token distinction are not necessarily possible with reification if you use OWL-Full.
… Within named graphs, you could say entailment happens in another graph.
… I think that given named graphs can be used for provenance, and any way you like, try to figure out if they are conceptually related, or could converge.
… given there have been many questions raised over the years (timbl, Pat Hayes), there are opposing thoughts.
… they don't have counter proposals, but I think it's important to see what it means.
… Idea of transparency enabling properties, there's something to that.
… If we talk about graph terms instead of named graphs, might define a better semantics.
… What happens when we introduce quoted triples? Opens up pandoras box...
… There's no way to avoid addressing question of if they are related. Are there semantics that can be codified for named graphs and quoted triples?
… Named graphs have defined a pair of a name and a graph term. Name doesn't denote the graph. Graph is the set of triples.
… Quoted triples as defined are the latter. The mathematical defn of the triple.
… The want of knowing what the named graphs are... We answer the question for a single triple.
… Single triple a specialization of a graph.
… Seems to complicate set of options you have when modeling your data with RDF (especially regarding provenance).
… Whatever the name is seems to be an occurrence.
… Something that entails the graph.
… Then we go into the same examples that quoted triples in RDF-star use. They seem to be about the same things.
… Proposal is circling around whether the thing denoted is an occurrence.
… Most use cases seem to be some kind of occurrence. Many seem to be able to utilize the annotation syntax.
… Those using Annotaiton syntax do not talk about mathematical triple but about occurrences.
… All of these cases are very hard to model upon the triple itself.
… Abstract syntax has a place. I'm not using N3 for anything, but believe I can see why it's necessary to have a strict mathematical definition of a graph term.
… Triple and math defn. are important to have and build upon.
… Annotation syntax could use an indirection.
… pchampin proposal is interesting. Named graphs could be modeled like that.
… Name-graph pair cold be a triple.
<Zakim> pfps, you wanted to mention labelled property graphs and Wikidata
pfps: One thing worries me about going from single quoted triples to multiple...
… I'm not sure what this thing is.
… doesn't seem to be an RDF graph. Not a set of triples – not for N3.
… multiplicity of RDF triples.
… this switch takes us a long way from a couple of main motivations.
… modeling LPG, wikidata.
<doerthe> (I just wanted to say what AZ wrote above)
pfps: modeling is problematic, but they don't have ability to attach decorations to multiplicities of RDF triples.
… just individual things.
… I worry we're leaving behind these motivations.
<Zakim> pchampin, you wanted to suggest that we don't try to fix the semantics of named graphs / datasets in general
pchampin: I woldn't like us to fix semantics of datasets. "This is what the named graph means..."
… RDF 1.1 WG gave up on that for good reasons.
… we would break number of use-cases if we did that.
… it was right to not do that 10 years ago. Still right now.
… we might want to define a profile of datasets which could be a profile on the content types nq/trig/etc.
… for those datasets that have particular semantics that we could specify.
<pfps> I also worry that the WG would have to do some original work to determine the semantics of named graphs. There are a lot of potential choices and creating something that covers a sufficiently-large fraction of them is going to be difficult.
pchampin: semantics on quoted triples (or graphs).
… the purpose of rdf-star will provide us with tools to provide such a semantics.
… I'm worried when I hear general claims about named graphs do this... do that...
… we shouldn't shoehorn them into one particular view.
AndyS: I think named graphs has become a distraction. How we got here.
… At the time there was intention to try re-apply a feature that was out there.
… The language we've been using in talking about graph terms means we've moved beyond saying it must be named graphs.
… We have graph terms. If we have a theory that works with those, can work backwards.
… close to where pchampin was. Named graphs might wither away.
… Used for data management.
… We may be further down this road than we believe.
niklasl: I agree with you all.
… Regarding pfps, that is something that troubles me.
… I think one of the things that made me jump into this deep end of pool was paper "Named Graphs" (Pat Hayes)
… they attempt to define semantics of named graphs
… this is before RDF 1.1.
… It was that named triples may be combined with reification.
<niklasl> https://
niklasl: I'm worried if it's even possibole. Not versed in set theory.
… Axiom of regularity that seems to conflict with that triples-are-singluar-graphs.
<Tpt> "Named Graphs" paper: https://
niklasl: Not sure if multiplicty of triples not being a set/graph. Not sure if I grasped that.
<doerthe> I do not see the problem because the triple term is also not a triple and it could be seen as a set constaining one triple
niklasl: Indeed if we were to define annotation of a triple (assertion, description, occurrene), if that was the same thing as a (blank) name, how would you ask "what is the subject of this"?
… Would work if it was one triple. If it was two, it wouldn't work.
… If two, subject isn't for one of the triples. It's for both.
… Could define an entailment if it is a singleton graph, it's an occurrence of a triple.
… Set theory trouvbles me there.
… pfps's worry is mine as well. Want to support wikidata case. Related LPG case.
… I'm not sure regarding pchampin's worry that we might break use-cases.
… It depends on if the predicate in the relation could be a weak predicate that could be entailed by any predicate.
… If that's the case, worry might be mitigated.
… I'm betting long-shot bet on proposed entailment mechanism for equating singleton graph and triple.
… If that works, that might mitigate pchampin's worry.
<Zakim> gkellogg, you wanted to ask how I know, when given a dataset, what profile applies to it?
gkellogg: Regarding pchampin's notion of profile. As a practical consideration, how do I know what profile applies to a dataset?
… with quoted triples, I can infer that. Dataset includes the quoted triples.
… I think of datasets in terms of quads.
… there's a slot that's used to name a graph. Could be an IRI or blank node.
… maybe could be some other thing - proprietary term.
… semantics in which graphs were their own terms.
… so that I'm not placed in having one slot within a quad include an entire graph. Then you'd have to get into how to delimit that. Very complicated.
… practical dynamics without abandoning quads are going to require that we consider what this might look like using somthing like quads.
… or quads are obsolete.
… quads have problems. can't talk about empty graphs.
… TriG has notation for it, but it doesn't result in anything.
<pchampin> gkellogg the problem you raise about profile already exists today with graph: is this graph supposed to be interpreted using RDF-entailment? D-entailment (which D)? RDFS-entailment?
gkellogg: next thing is this notion of duality if a graph term is a multiplicity of triples...
… and I have an annotation on that, if there were 3 triples included in graph and I annotated with creation date...
… I was annotating each triple individually.
… OTOH, annotation might only apply to that unique set of triples.
… that "graph".
… what about graph with single triple. Is annotation same as annotating the triple the graph contains?
… I don't think so without adding more information to the graph.
… if we do consider a name-graph pair being a triple, then that provides a way to say other things about the graph.
thomas: no good moment to come into this. The reaons I'm here in WG is that I have been working on something that is graph based.
… we came from two directions.
… My concern was usability concern. I wrote in wiki that it's a problem if you can query for provenance an dembedded triples, and don't know ahead of time where you'll find that information.
… There can't be clear guidance on what goes into the graph vs. goes into the rdf-star slot.
… much more complicated than it already is.
… We're working out a proposal. Not expecting to discuss it here.
… Thought going in a good direction after TPAC. What others have said, I had the feeling that we have solutions for that.
… Want to announce that next week we'll mail the list with discussion about the way we would have done this.
… we have occurrences, nest graphs, graphs have names.
… we have mapping to triples. complicated but can be done.
… we can leave named graphs alone as they are today.
… otherwise it only needs vocab to define semantics for them.
… SPARQL provides semantics for named graphs.
doerthe: I do not see problem with the set theory.
… in former life I have been set theorist. What you mean here is that the problem is having triple and set containing triple.
… if you ahve triple term, not the triple itself.
… don't see the problem here.
… whether we want to do this is another question.
… I'm worried as pchampin if we go with named graphs, we break the named graphs.
… maybe we go for graph terms. Not want to go for named graphs.
… because it has different semantics.
… I would like to have one semantics for that, but it has been tried and did not work out.
… should have separate WG for that.
… what thomas said, things can be done with named graphs. yes and no. no fixed semantics.
… can be done, but what does it mean?
<Zakim> pchampin, you wanted to reflect on the duality of "graph terms" and "triple terms", as design choices
pchampin: agree with thomas on importance of usability. my belief is that momentum around rdf-star is usability cf. what existed before.
… promoted use cases could be addressed before. never was afraid of reification.
… but the way you do it and tools provided matter.
… to doerthe, I would not be against providing a way to encode whatever rdf-star extension we have into named graphs.
… NG people understand they have implementations for that.
… RDF 1.2 full graph to RDF 1.2 "classic" dataset would be nice for people worried about complexity.
<niklasl> (rdf 1.2 basic?)
pchampin: if we found a way to do that, it would be nice. that's where having a profile to say "this dataset has semantics" would be useful.
pchampin: bold proposal, just testing: I'd like to rename quoted triples again.
… I'd prefer to talk about "triple terms".
… hear references to what quotation is. At least my personal goal with chosing this term is to avoid going down rabbit hole.
… easier to grasp.
… in the end those new terms are building blocks to address different use cases.
… more neutral we call them the better off we are.
… "triple term" may be a better choice.
<thomas> "quoted triples" also was a refernce to the propose semantics
pchampin: that being said, there is a duality whether we chose to make "triple terms" the building block in RDF 1.2 or "graph terms".
… both have pros and cons.
… when it comes to wikidata, triple terms is more natural.
… then we can build graphs as collections of triples.
… a bit more work than having a built-in "graph term" kind of term.
… this could be a way.
… the other way around if we have "graph terms" we can still emulate single triples with singleton graphs.
… as some have pointed out, this is not neutral. kind of punning. this could work.
… I believe that both solutions ... we can do what we want with either choice. Coming back to our use cases is ipmortant to make best choice
AndyS: appologies for late email right before meeting. Shows how we can re-use nquads to write down details of what we have without needing syntax.
… treating data .. a unit which is a graph and a number of other graphs you can reference. reference is entirely syntactic. no meaning in RDF abstract data model.
… what i would interpret as what JSON-LD is trying to achieve carrying around graphs.
… I took the issue of named graphs out of the abstract data syntax.
… partially this is necessary if you reference a graph in the data.
… It is the recognition that I think we are already talking about graph terms. Like the term "triple term".
… Appeals to me as an element in the RDF syntax. "Triple term" is neutral.
niklasl: We are converging on something.
<Souri> +1 to triple-term
niklasl: The forth position in a quad is the key. AndyS's email is an illustration of that.
… I also embedded in my reply to doerthe that I am exploring unstar operation in what we're looking at.
… Wondering if we can have special names in RDF 1.1 (not 1.2). Terms we're talking about is in the abstract syntax for 1.2.
… to emulate that in RDF 1.1 using quads or named graphs with special names.
… like the opposed meaning in how you can do skolemization.
… create IRIs which are not IRIs. If we could create IRIs which are triple terms or graph terms...
<pchampin> Andy's email: https://
niklasl: Compose graph terms from triple terms. Possible to compact in implementations, but logic doesn't need to expose that.
… Sounds like something that could work for various things brought up here.
… Also to define triple terms and graph terms in a proper way.
… Not sure how we address opacity in that. Other than in the way you can mechanically do it.
<pchampin> I think the opacity discussion is totally orthogonal to what we are discussing here
niklasl: I have speculated on this in my text, but perhaps we could say which are in the union graph.
… perhaps we have occurenes of triples and of graphs. Related with this special property named something nice ... "entails".
… that thing it denotes is the mathematical triple. Solves wikidata issue.
… possibel to model named graphs on that.
… no need to have named graphs as fundamental thing.
… forth position could be triple term or graph term.
… sets of triples terms. the rest is optimization.
<Zakim> niklasl, you wanted to comment on what is in the fourth position of a quad
AZ: wanted to go back to remark about "we could do similar things with named graphs".
… "problem is that named graphs do not have formal semantics." quoted triples neither have formal semantics.
… not sure that's a good argument to reject using named graphs.
… both cases lack formal semantics.
… have several proposals for those semantics.
… if there's a reason why we don't want to use named graphs or standardize semantics for named graphs, we need to provide the right argument.
Tpt: Useful to not use "named graph".
… Probably a lot of systems that have interpretation of "named graphs".
... and won't be able to adopt our semantic if we reuse named graphs
AZ: A reaction to Thomas: do you think that there are SPARQL systems that implements a semantic on their own that does some semantic operation
Tpt: I am not aware of any.
AZ: my intuition is that triple stores that does some kind of dataset reasoning will do what they need to implement SPARQL 1.1 entailment regimes.
AZ: defining a semantic of RDF dataset would maybe not introduce much changes. Most triple store don't implement semantics anyway
pchampin: My problem with defining a semantic for named graphs is that they have a lot of use cases. Indeed, there is not semantic on quoted triples but I wish we find a semantic for them.
pchampin: to AZ: what you said on entailment regimes is interesting I was not aware it works across named graphs.
AZ: nothing happens across named graphs but you can define some semantic across named graphs in extensions. But it won't affect SPARQL
niklasl: I am convinced that named graph are @x but the name always has some relationship with the graph
<gb> … @y
<pfps> As far as I can tell, the different dataset semantics do have an effect on SPARQL as there are some semantics that take some of the named graphs in the dataset and assert their triples in the default graph.
<niklasl> https://
niklasl: datasets should be able to declare which entailment regimes they use
<Zakim> pfps, you wanted to talk about transparency
pfps: The big problem with this WG is the notion of transparency. Switching to graph terms would fix this problem or make it worse
AndyS: The same issues come up with graph terms or triple terms
AndyS: Whatever rules apply with triple terms apply to graph terms.
AndyS: There is one case of semantic of dataset: dataset where people consider the union of all named graphs that includes the one that is the schema/ontology and you get inference across named graphs
<pfps> What I see as the problem is that graph terms appear to be useful for modals where opaqueness may be desired. With triple terms the majority of use cases appear to ask for transparency.
<Zakim> AndyS, you wanted to note that using graph terms means that they do not occur when enumerating "named graphs".
AndyS: using blank node as names will be very complicated because we can't prevent them to appear with entailment
<AZ> Yes, AndyS, the way the default graph relates to named graphs (or vice versa) is implemented differently in different triplestores, which affects the semantics (or conversely, fixing the semantics may affect the way to implement this)
AndyS: graph terms don't appear in the SPARQL "GRAPH" keyword
AndyS: and here we have the issues to use the notion of quads to talk about quoted graphs
<pchampin> GRAPH <http://
thomas: The graph name used in RDF triples relation to the graph is currently undefined. We might provide a vocabulary to describe the relation between the graph name occurences and the graph
pchampin: Something that appens in the wild, the way SPARQL and RDF understand the relation between the graph and the graph name is very different
doerthe: I would propose to separate the semantic of triple terms with their mapping to named graphs.
doerthe: I have a question to AndyS: if would have fixed namespace for quoted graph identifier instead of blank node, would it fix the problem
AndyS: The key to keeping away from blank node is to not have a name of the graph but a reference/key to the graph.
niklasl: I agree with AndyS. With nquads the 4th slot might be special namespace. Could we have a hash of the triple combined with some namespace to transport the graph term as RDF 1.1 data
AndyS: The 4th slot is not a graph in the dataset, it's literally a symbol. It's a namespace if you like. The scope is the document.
AndyS: We could describe how to use blank nodes for RDF 1.1 system. With care you can do that
AndyS: It's not so much un-star but un-1.2
niklasl: I agree with it. I was thinking from a RDF 1.1 perspective. This notion distinct with IRI and blank node provides an insulated way
AndyS: If we provide a clever scheme we are effectively restricting RDF 1.3, 1.4...
AndyS: My instinct is that we need to learn from user unacceptance of RDF 1.0 reification
<niklasl> _:occurence-of-spo a :Event .
<niklasl> _:occurence-of-spo SYSTEM:tokenof SYSTEM:hash-of-spo .
<niklasl> <s> :p <o> SYSTEM:hash-of-spo .
niklasl: I will put a few quads to give an example of what un-star to RDF 1.1 looks in my mind
niklasl: This is a hack. It will fall apart with entailment
<Zakim> gkellogg, you wanted to discuss C14N considerations of document-local graph labels
gkellogg: Regarding the use of local graph identifiers: it may not be blank node but it has to act very much like a blank node with respect to things like isomorphism/canonicalization
gkellogg: ... just like blank node but the namespace is completely disjoint. They would be always associated with the graph
gkellogg: We are thowing around as graph terms/triple terms. They seems to always move together. Is a graph term a replacement of triple terms or are graph terms containing triple terms?
<thomas> we are all having audio problems
<ktk> I think so
<pchampin> who can't you kick?
<ktk> pchampin, you, we didn't hear you
<ktk> and it nuked the audio completely
enrico: There are many different aspects. If we consider to use named graphs as a basic for our quoted graphs. People might soon use owl:sameAs to relate to named graphs. A graph term is a "term" because it is meant to resolve to a resource. In this sense they denote something
enrico: ... the intuition is that the label have them same term as the graph term instead
enrico: ... so far we did not had these issues because we did not have names for graph terms
enrico: ... it seems to me we should consider graph terms without terms
<pchampin> enrico the whole point ov Andy's proposal is that the "graph names" or "graph identifiers" are not part of the abstract syntax
enrico: ... we should suspend semantic task force meeting. What we did the last week is to discuss these things but we are now discussing with everyone
pchampin: The issue you raise enrico is not a problem in fact because it is only in the concrete syntax
pchampin: To try to find an aligment with flat dataset and quoted triples/graph term is that we would have a nice path to use RDF canonicalization
pchampin: I wanted to ask AndyS what about {} in his proposal
AndyS: I would like to avoid it. By using it too early we are introducing a lot of assumptions
AndyS: semanticaly there is not need to have two things in the abstract RDF model. We define the semantic with triple terms we almost have a semantic for graph terms
AndyS: One thing we left out is that N3 has a very specific set of requirements on the semantic
niklasl: I agree that triple terms and graph terms denotes themselves
niklasl: I need to explore the relation between triple terms and graph terms
<pchampin> nitpicking: it is not accurate to say that literals denotes themselves (although I'm sometimes guilty of this approximation myself), but that's a discussion for offline :-)
<doerthe> maybe we can take that as a separate discussion?
<ktk> doerthe: can you give me the exact topic so I will note this down
<doerthe> (I will answer mails about that or an github issue, if you want niklas :) )
niklasl: We should be able to allow a graph under a name in a dataset to use quoted graphs
<doerthe> The discussion should be how triple terms and graph terms relate and I would like to convince niklas that it is not as muc of a problem as he thinks
<ktk> tnx
ktk: In 5mns I would like to close
<Zakim> pchampin, you wanted to propose two strawpolls
pchampin: I wanted to propose two strawpolls
pchampin: 1 do we keep the abstract syntax with quote triples or upgrade them to quoted graphs or introduce both
pchampin: to know what is the preference of everyone
<thomas> another option: no new term
<thomas> (which is what i would like to present soon)
<pchampin> +1
<pchampin> STRAWPOLL: do we keep the abstract syntax with quote triples or upgrade them to quoted graphs or introduce both
<pchampin> STRAWPOLL: do we agree that the choices that we have are: we keep the abstract syntax with quoted triples, upgrade them to quoted graphs, introduce both
<AZ> +0
<pfps> -0
<pchampin> +1
<thomas> -1
<gkellogg> +1
<AndyS> +1 Yes, they are the options.
<ktk> +1
<Dominik_T> +1
<Souri> +0
<enrico> +1
<TallTed> +1
<olaf> +1
<Tpt> +1
<doerthe> 0
<niklasl> +0
<pfps> -0 because named graphs should still be on the table
<gtw> +0
<thomas> same as pfps
<pfps> we can't rule out named graphs because there is no full proposal
ktk: We are done and have things to work on
ktk: Please have a look at the minutes
<pchampin> I consider the discussion of named graphs to be orthogonal -- I didn't mean to exclude them completely
enrico: Do we cancel tomorrow meeting?
niklasl: I agree it would not be a semantic call
AndyS: we want to keep discussion within the working group
enrico: We suspend for a couple of weeks