RDF-star Working Group Weekly Meeting

Revisiting Use-Cases

<ktk> https://github.com/w3c/rdf-ucr/wiki/Summary

pfps: I put in a pointer for the status of the use cases.
… In summary, there is an outlier the group may not pick up about graphs. The others are agnostic about transparency, and many talk about occurrences.

AndyS: Which ones work on triple terms? (vs occurrences?)

pfps: Those which require talking about the triples per-se.
… The Labeled PG and the Wikidata use cases have multiple subject/predicate/object. They also want occurrences.
… Provenance and annotations all require occurrences.
… I don't know of any that require talking about the actual triple term.

pfps: the prov use cases require some abstraction from the original triple; they suffer from a problem similar to the seminal example.
… It could be the term or an occurrence, which may be a matter of taste.
… Prov UC don't need occurrences.

AndyS: So they can have different groups of triples to annotate the object.

pfps: It's often a bad idea to have two separate predicates that need to be used together to make a whole.

AndyS: Those with a notion of time (shop hours)

pfps: If you use something like start time and end time you need a stand-off triple.

AndyS: They also need a particular meaning of the triple.
… You can't have a triple which globally asserts open times.

pfps: Wikidata has a similar problem, as many triples have temporal qualifiers.
… If you want to know what's true right now, you need to understand the temporal qualifiers.
… That doesn't affect the formal meaning of RDF, though. A graph is a set of triples, and you can say that that set induces a set of possible worlds.
… Relating a possible world to the actual world is a separate matter.
… An asserted triple is true in our world throughout time and space, but there are other ways of mapping these possible worlds to the way we feel our world works.

AndyS: If you have a graph with some temporal assertion, and you assert more triples ...

pfps: Everything is monotonic. The graph says the way the world "could" be.
… So the triple was true in some world at some time.
… Adding qualifiers adds more information. Sounds monotonic, but formally, it's not.
… In CS, we do this all the time. It happens with arguments and results of formal functions, on one side it's monotonic, and on the other anti-monotonic.
… Purists argue against this, but somehow we keep on.

niklasl: Mostly agreeing with the assessment on the UCs.
… Some of the prov examples (from biology) uses a possible stand-off predicate. If you're careful and have only one such annotation, it can work. The others commit the seminal problem.
… The prov vocabulary uses past-tense to make it more clear that something has once been true.
… E.g. "was derived from".

<Zakim> Tpt, you wanted to talk about wikidata rank and asserted triples

Tpt: Wikidata has a system built in to know if a triple should be asserted or not. Each occurrence can have a rank; the main triple is asserted only if the rank is sufficient.
… Only the latest U.S. President will have a full rank, and previous would have a lower rank.

pfps: The Liz Taylor/Dick Burton example has all relationships with the same rank.

Discussion of Andy's post [1] and Souri's slides

https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0033.html

AndyS: It starts out with a couple of objectives: exploring what edges are and taking the RDF model that triples are unique in a graph and how RDF merge works.
… It has occurrences used as edges, which gives you the grouping to keep information together.
… We've had some proposals about not keeping triples unique, but it's pretty fundamental.
… It also extends the notion that a triple on its own is abstract, but when put in a graph you're somehow using it.
… So qualification can be different for the same triple in different graphs.

<niklasl> +1 to these objectives

Souri's proposal https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/att-0045/RDFn_Slides_Dec_14_2023.pdf

Souri: When we have an occurrence today we can either have them asserted or unasserted.
… (from slides), the example is of two occurrences of the Trump presidency.
… The second one didn't happen, but can be claimed.
… According the Trump, he won in 2020. Should we aim to be able to make such statements.

AndyS: In my email, I was trying to split that out, to separate whether a triple is asserted or not. They come together in the annotation syntax.
… In the annotation syntax, the triple is asserted.

pchampin: My reading is that the triples are asserted, not the occurrrences.

AndyS: Occurrences are resources; I'm not sure what it means to assert that.

Souri: We can get an ID for an occurrence; I could use that to make statement such that it is true.

AndyS: I'm not sure what the difference between having an occurrence and making a statemenet about it, how that is different that putting the triple in the graph.

AndyS: I think the capability is there, but it's done a different way.

Souri: I have more slides to show how RDFn and RDF-star are quite close; it's a matter of what the user sees where we have a slight difference.
… I'd like to see if we can give the user alternatives to use either style.

pchampin: In souri's example, the annotated triple said "Trump won election".

Souri: It was a presidential election that trump said he won.

pchampin: Is it the concept of an election or a specific election?
… Depending on the meaning, I could agree with its being asserted, or not.
… Triples are asserted, not occurrences. When we assert a triple we endorse some fact about the world.
… We talk about occurrences as if it's one uniform type of thing, but this is not the case. Sometimes we want to talk about multiple things.

<niklasl> +1 for occurrences being what the users need them to be

pchampin: It's true that Trump one some election, and the fact that he didn't win in 2020 does not make the triple false.

Souri: You'd like to have an event "Election 2020" and assert about that, rather than the abstract "election".

pchampin: There are cases where it's okay to present such a triple, but we need to be careful.
… There could be different cases.

Souri: It's similar to talking about who one the world cup. What if "Trump won election" was not an asserted triple.
… There could be something about 2016 and about 2020 and we could talk about them separately.

<Zakim> pchampin, you wanted to answer to Souri with another question

Souri: I want to say something about the truthfulness about each individual edge.
… I might talk about other fictional or true events. (Brazil wins world cup).
… We talk about the assertion of a triple but not an occurrence. Is this a common occurence?
… We should provide some way to do this easily and formally.

tl: We talked about different meanings. Is it asserted/endorsed or not?
… We separate the triple from its assertion as the type exists only once in the data.
… We have a gap to bridge; you have an annotation on a triple you don't want to endorse and something else may be asserted that changes your intention.
… That's why I proposed having different properties to distinguish between the uses.
… Maybe "quote" or "opaque". Endorsed or not, asserted or not.
… There's a gap between the abstract triple and different assertions.

<Souri> +1 to providing a way to describe the type of occurrence

niklasl: I understand that tl is describing and I think that is closer to the RDFn proposal than Andy's proposal.
… They are all pretty close to each other; the main difference is that you might have a graph including another graph ...

tl: Not quite

niklasl: AndyS proposal is more "classic" RDF, as a triple is asserted if its in the graph. With assertions ...

tl: The annotation syntax works only for asserted triples.
… The short-hand syntax should be easy.

niklasl: I'm trying to get at the problem with the unasserted triple, how do you want that to work? Is there something that can be tweaked?

<pchampin> tl, in the latest proposal by Andy, the chevron syntax is also a shortcut, which is entirely symmetric to the annotation syntax, without the assertion

tl: I made a proposal for that with a predicate that determines if it is asserted or not through entailment.

niklasl: You could say that an occurrence is asserted and this is sort of what rank does in Wikidata.
… I accept how things work with Andy's proposal. If an occurrence is said to be asserted, I assert it.

<pchampin> +1 to niklasl: occurrences are RDF resources; you can say whatever you want about them, using additional vocabularies, and leave this to the application level

niklasl: Perhaps the annotation syntax adds such an assertion.

pfps: Mostly on RDFn, but my issue is that we have a number of "proto-proposals" and I can't really distinguish between the quality of each (mostly RDFn)
… I'd like to break that down, and I can't really tell if they're the same or not.

enrico: The discussion so far makes me think that types should not exist.
… If we consider "John" being a "Person", I assert John, but I don't assert Person.
… What does it mean that two people marry. When, Where, Now or in the past.
… The problem of RDF is that we ...
… A triple I want to annotate is not something which is true.
… Its an n-ary relation I want to assert something about.
… If you leave out the additional attributes, it's meaningless, its just a type.
… Types are a way to refer to things. They're not something themselves.
… You need an objective function. Only one type but multiple triples.
… This makes the RDF job harder as you need different types of things.
… Types should not be explicit elements in the abstract syntax, and don't have a semantics per-se.
… You may want to say something about the class Person.
… At that point, it becomes a resource about which I can make further assertions.
… Andy's thing is fine, but in the abstract syntax you have occurrences that have types. The meaning is not the syntactic triple itself.
… It may be that the triple type is equivalent to another.
… My perception is that types should not be there.

Souri: I have a couple of slides that I might present that could clarify things.

<Souri> An RDFn graph is a set of <s, p, o, n> tuples, where n is the "triple-name" component. Some of the tuples represent triples and rest of the tuples represent occurrences.

AndyS: I'm not quite clear about the use of the word "type" if it's an rdfs:Class. I don't think a triple term is the same kind of type.
… The type is rdf:Triple, it's not the type the triple is representing.
… I didn't put types in as rdfs:Classes, and I don't really know what the answer is. I'm not sure the type/token distinction applies.
… With any of the ideas where properties have side-effects, are the proposals saying this works in N-Triples? Up until now, N-Triples has been a direct form.
… If some triples have side-effects, we've made a large change.
… Right now Turtle can incorporate N-Triples.

tl: To Andy's last point: good question, I don't know what the solution is.
… With entailment, I guess it would not be a problem.

<ktk> ack +1

<Zakim> +1, you wanted to comment on not having "side-effects" (of course, optional entailment can do more...)

tl: To Enrico, I like what you are saying. Reminds me of Pat Hayes' email to the RDF 1.1 WG, that niklasl mentioned.
… On the other hand, when we talk about types in RDF, we are really talking about deduplication, early optimization.
… We are not just talking about the type, we are talking about similarity between occurrences.
… I understand that the definitions are in line with what is usually done in logic, but it creates difficulties in understanding.

niklasl: When we say "type of triple", I think of "pattern of triple".
… I'm thinking about Andy's proposal, how it can work with triples only in the object position.
… Also thinking about using a literal in the object position to describe the triple.
… I'm not sure where to put my energy now.
… I like that Andy's position does not require us to put triple terms in triple terms, mitigating the complexity.
… Similarity with Notation3 -- I think about it a lot, even if it is out of scope for this group.

[Souri presents slides]

Souri: I wanted to explore the relation between RDFn and RDF-star
… In RDFn, the triple itself is named in the rdft: namespace, with a suffix computed from (s, p, o)
… Occurrences are named with custom identifiers.
… (next slide)
… [describes Andy's proposal using the same figure]
… As niklasl said earlier, I'm concerned about the ability to embed triple terms in triple terms
… That's where I'm coming from: some people don't like the quoted triples.

tl: I don't like the possibility of generating a name from s, p, o .
… Rather use a fresh blank node at each occurrence.
… Talking about the meta-level (the type) should be explicit.

Souri: the generation of the name is to provide the unicity of the triple.
… (something about preventing occurrence names to be used as predicates)
… the generated rdft: identifier allows the parser to determine that we are talking about the triple. Let's talk offline.

niklasl: I would like Andy's proposal to be the same as what you are proposing, but I'm not sure.
… In your proposal, can triples and occurrences both be asserted?

Souri: I'm storing whether the triple is asserted or not.
… The occurrence is only referring to the triple.
… Like AndyS said, it is useful to come back to N-Triples.
… (shows example of RDFn-N-Triples in slide)

niklasl: AndyS, is it correct that your proposal does not require triple terms in triple terms?

AndyS: that would still be possible

Souri: isn't it a requirement that you are able to also talk about the triple itself?

AndyS: what I wrote was: we would not allow the shortcut syntax of occurrences inside triple terms.
… In N-Triples anyway, the shortcut syntax does not exist and is replaced with the rdf:occurrenceOf triple.

Souri: In N-Triples for RDF-star, we can only use rdf:occurrenceOf followed by a triple term that may contain the name of another triple.

AndyS: we can't rule out that someone takes RDF 1.2 to make assertions about assertions.

Souri: what I wanted to say was that those things are very close to each other.

<pfps> I again dispute this a version of RDF based on multi-graphs is very different from one based on regular graphs.

Souri: As long as we have an N-Triples serialization to associate a name to a triple...

pchampin: I see convergence between Souri's proposal and AndyS's proposal.
… To pfps: do you consider AndyS's proposal sufficiently described?

pfps: AndyS's proposal is not too bad, because there is not too much in it. It reuses things described before.
… One problem with the RDFn is that I don't know what the names of triples are. Are they a new thing? Can they by IRIs? Lirerals?

Souri: very quicky: they are special IRIs.

pfps: you have to tell me what a "specia IRI" is.

<TallTed> an EBNF of RDFn would likely answer all our questions ... but certainly would be very formal.

Souri: just like 'rdf:' IRIs

pfps: ok, so special IRIs are IRIs in a particular namespace. Are they forbidden for use elsewhere?
… All this need to be written down in a document, so that we can look at it.

gkellogg: in my interpretation of Souri's slide: the difference between a triple type and an occurrence is determined by their name
… this is very unlike RDF. Names in RDF have no meaning.
… In AndyS' proposal, triple types do not have name, hence the need for recursion.
… AndyS's proposal leverages what we have already worked on.

niklasl: if you interpret occurrences from a LPG point of view, they are edges.

<ktk> thanks gkellogg

<ktk> and happy holidays

<AndyS> <<:s :p :o >> :p1 :z ; :p2 "abc" .

niklasl: I see an opportunity in the fact that the same name can be declared as occurrence of several triples.
… May be not ready to represent graphs right now, but a good opportunity.

enrico: we still needs at least a hint about the semantics for this proposal.
… Once we start working on this we may realize some proplems.
… The triple occurrence is some kind of shortcut for the triple term.
… Why not the other way around?
… Allowing triple terms in any position would be too extreme. But restricting them in the object position of some predicate is weird.

AndyS: if we have only occurrences, we need a way to know what are its the subject, predicate, object

pchampin: to Enrico: my proposal to restrict triple terms to only some predicates was only a *profile*, not a core constraint
… about the complexity of triple terms: if they are to be extended later to graph terms, then the complexity should not be considered an issue

tl: we need graph terms in this version of RDF, otherwise somebody else will do it.
… Some triples stores may have not much use for triple terms. They may implement the shortcut syntax using reification.
… The shortcut syntax should be in the core and mapped to standard reification, with additional mappings to triple terms and graph terms.
… The RDF 1.1 worked hard on named graphs and came up with a description of the problems. I think we can solve them.
… If no one answers to my counter-arguments on the mailing list, there is nothing more to do.

niklasl: I'm equaly concerned with the complexity of graph terms than with that of triple terms.
… I have been advocating for blank named graphs, different.
… (something about named graphs)
… I like the idea of typing annotations with rdf:Assertion .
… I like the idea of restricting the recursiveness.
… I'm less concerned about the recursiveness in the object position.
… To be discussed in the semantics TF.

AndyS: if there is a TF discussion, there needs to be feedback to the group.

pchampin: my take away is that:

<Souri> Merry Christmas and Happy New Year to everyone!

pchampin: we are generally agreeing on the concrete syntax proposed by AndyS, focusing on occurrences

<tl> what is the difference between a nested triple term and graph term?

<niklasl> Thank you all!

pchampin: we need to decide how, in the abstract syntax, to relate occurrences to what they are ocuurences of
… could be via triple terms, via standard reification
… but some of us would prefer if it didn't involve recursive structure
… (triple terms could be restricted to only contain "atomic" terms)