Meeting minutes
tl: argues for needing unasserted asssertions
… Not my argument, but my interpretation of the WG position.
pfps: from the CG report, quoted triples don't need to be asserted.
<doerthe> thank you, gregg, for scribing :)
tl: A lot of people use the term "assertion" without "endorcing" them.
pfps: Let's stick with already defined RDF terms. We can say that a triple is an element of the graph. Being an element of the graph makes it asserted.
… Standard reification is a way of talking about a triple that may not be an element of the graph.
… I think standard reification works well, so why do we have RDF-star? Developers are too lazy.
… It does lead to a lot of "star" queries; it's up to implementors to make them perform.
… An implementor could create an optimization for the reification structure.
AndyS: There's another situation, which is partial reifications
<AndyS> and over specification
tl: Before the last meeting, I didn't think there was a way of speaking about a statement without endorsing it.
… If a statement was not in the graph but was annotated, and then later put into the graph, we have lost the fact that it was previously not asserted.
<niklasl> Alice isn't in the graph (well, the fictional Alice may be...).
tl: Once it's clear that the annotation is on a triple contained within the graph implies the need to explicitly tag when the triple became part of the graph.
… The connection between a tripling being in the graph and its being annotated is fragile.
… Most of the time, (for me), annotations are performed on triples that are members of the graph.
… It would be easier to model using N-ary relations.
pfps: You've lost me when you start talking about time.
… RDF has some facilities such as datasets. You could say that an IRI represents a version of a graph and talk about that.
tl: I was not referring to temporal assertions.
<niklasl> It's crystal clear. The triple is the triple.
tl: If you want different viewpoints in the same graph, it's not clear when each was added.
<pfps> Agree, the triple in an embedded triple *is* the triple. It doesn't refer to the triple or allude to the triple or anything else besides being the triple.
<Zakim> pfps, you wanted to discuss temporal aspects
doerthe: I don't really follow your reasoning.
… When you want to add knowledge to the graph ... You can do everything with predicates.
… When a triple is added it's not about Alice's relation to it, its a description of the world. It doesn't matter who added it.
<pfps> The whole point of having the rdf:reifies relationship is to allow annotations of different "incarnations" (or whatever) of the triple.
niklasl: I "think" I understand what tl means, but I think two arguments are being conflated into one.
<pfps> But when I think about it, maybe the n-ary use case doesn't need a stand-off relationship.
niklasl: I agree with pfps and doerthe; it's not contentious.
… You can't relate the triple to a graph, as the graph is a model and you can't step out of that.
<pfps> nicklasl: The graph is the graph, it is not something that changes.
niklasl: You can't say "i believe this" unless it's in the graph.
… It's important to get that clarity. You can add to your vocabulary various notions that you don't need to refer to the relationship denoted by the triple.
… A reifier that reifies such a relationship is atomic.
… I think your conflating with qualification. Specific properties are one form of qualification.
<pfps> Well, "i believe this" is not something that RDF handles.
niklasl: I don't think that standard RDF reification is enough.
tl: the agrument about N-Ary relationship can be made about anything. We're trying to make things easier.
<pfps> If all that the WG is about is to make the syntax easier, then why not just do that and only that?
tl: You could also structure the graph into N-Ary relations and primary statements.
<niklasl> LPGs don't model N-ary relationships, do they?
<pfps> There has to be something more than just bettere syntax.
tl: N-Ary relations can be hard to use, so other syntactic forms have been suggested.
<niklasl> Not all the detailing. One more granular "sublevel". LPGs cannot relate relators, for instance.
<pfps> That depends on the meaning of "models". If you mean this in a strong sense, there is nothing in LPGs (syntax, data structures, semantics) that is n-ary.
tl: You can do that with N-Ary relations if you base your annotations on that.
… Using RDF-star for qualification, but this can add to the confusion.
<niklasl> You are using that relation in natural language right now (:endorses).
<doerthe> why can't we use two different predicates?
tl: If two people make a statement about a triple, you can't distinguish if one acts as if it was asserted, and the other does not.
<pfps> But triples are sufficient for encoding anything, so both RDF 1.1 and LPGs can encode n-ary relations. The standard way of doing this is reification - not standard RDF reification but creating a node for the n-ary relationship and linking it to the n arguments.
tl: Most of the use cases will want annotations to be about statements in the graph.
<doerthe> :Bob :saysAndMeans << :s :p :o>>. :Alice :says << :s :p :o>>. :s :p :o.
enrico: I don't like the discussion of "asserted"; it's yet another use case. The current RDF-star can capture this.
… If you want asserted stuff, you may lobby for a different thing.
… Overloading "RDF reifies" is just wrong.
<pfps> +1 to doerthe (with the provisio that a stand-off relationship may be needed)
enrico: You can use best practices for deciding how to represent somthing.
<niklasl> +1 also to doerthe
enrico: RDF only expresses facts. Any name is meaning less until you have a schema. Otherwise, it's just a convention.
<pfps> And it is perfectly fine to have a graph that contains only :Bob :saysAndMeans << :s :p :o>>. :Alice :says << :s :p :o>>.
tl: I'm frustrated that the pitfalls of what we're taking about are unacknowledged.
… Reifiers can refer to unasserted triples, and qualifies to N-Ary relations.
… The qualified thing would be asserted.
… A thing is asserted if it is qualified.
<niklasl> Enrico means the {| |} and only that.
Souri: I'm trying to understand what you're looking for. There's rdf:qualifies, which applies to :q1 (a qualifier).
… For the triple :alice :buys :car, it has to be in the graph to be true.
<pfps> "A thing is asserted if it is qualified." Really? That's a fundamental change to RDF that overturns just about everything.
tl: We want to be sure people don't mis-understand the annotation.
niklasl: I've been thinking if the annotation syntax could expand to both the assertion (qualifies or asserts). Once the triple appears, what would that mean?
… What if it's not there?
… If it's in the graph and you have a reifier of it, that's all you need.
<pfps> +1 to niklasl
niklasl: If you want to say something more about a reifier, you can use a specific type.
… If you have both a start and end date, it's reasonable to expect that the associated triple is no longer in the graph.
… You can do most things using sub-properties, but if you want the annotation syntax to be shortcut for that, you need more.
tl: I would loose the annotation syntax.
niklasl: Turtle syntax would look horrible.
<Souri> Would a graph that, in its entirety, contains just the following "statement", be considered invalid (because it does NOT have any asserted triples to go with the qualification)? q1. rdf:qualifies <<( :alice :buys :car )>> .
tl: you'd have to state ever annotation that needs to be asserted. Or, you don't have unasserted annotations.
… I'm annotating something I want to express.
<AndyS> If x rdf:qualifies T , does ?a rdf:refies ?b match it?
niklasl: You do this when you created the graph. doerthe showed an example of this.
tl: We can't always mint new properties.
<niklasl> Yes, gregg is correct; a graph is an immutable state, "adding" or "removing" results in new graphs.
gkellogg: Want's to point out that graphs are static and immutable.
<doerthe> but isn't RDF also about adding properties? You define your vocabulary, use it and hopefully others use the same vocabulary and we have an agreement. So, from your point of view: if we add two (better named) predicates to RDF itself, are we then fine? (I try to understand the problem, please see me question like that :) )
tl: Saying that we support the use case of unasserted assertions is wrong.
AndyS: If you've used the "qualifies" predicate, would that match "reifies" in a query?
tl: As I unerstand querying you can with << >> syntax.
<niklasl> You can use both << >> and {| |} in SPARQL-star.
tl: I presume we need to support both syntaxes.
AndyS: You're not able to treat all qualifies as reifies; you have to look for both.
… The trouble with super-types and super-properties it is the only time SPARQL would need to make this happen.
AndyS: If we talk about graph merge, I believe that's not a set operation. Once you merge two graphs, you are endorsing them both.
tl: My example doesn't have anything to do with merging. It might contain multiple viewpoints.
pfps: I was trying to reiterate that point that we're going into temporal aspects; Let's not do that.
Souri: You're saying that rdf:qualifies can be used only on things which are asserted.
… Using it one something that is unasserted doesn't make sense.
… If someone uses "qualifies" you need to ensure that the triple is asserted.
… Using qualifies implies that the triple as asserted.
<niklasl> So tl, you just want a different syntax for the annotation macro? It doesn't sound like that's all you want.
pfps: It doesn't get added to a graph, it becomes an implication of the graph.
Souri: When I query a graph using "qualifies" where the associated triple is not asserted would be an error.
tl: If you use the <<>> syntax, it gets converted into N-Triples, there you get the rdf:qualifies predicate.
Souri: I might get an N-Triples file with a single statement.
tl: That would be incomplete.
<niklasl> And now you're arguing for entailment instead.
<niklasl> PG mode expected it to be asserted, but it wasn't an expansion macro, it was ... entailment? Wishful thinking?
AndyS: In Olaf's paper, all triples were asserted. If you only have assertion mode, you can't talk about false things.
… Where are ocurrances.
tl: I'm always talking about occurrences.
<niklasl> Do you want sugar for assertion of triple plus the triple as a term, or a singleton property which is a subPropertyOf the property?
doerthe: Looking at your example, you talk about two levels, but there are three things: what one says, what the other says, and what is true.
… Independently of Alice and bob, there is what is true.
… The act of adding a thing to a graph becomes confusing.
… What is missing in our examples is a shortcut syntax.
tl: The shortcut syntax is not part of N-Triples.
<niklasl> The annotation syntax: <s> :p <o> {| a :Reifier |} .
<niklasl> Expands to: <s> :p <o>. _:r1 rdf:reifies <<( <s> :p <o> )>>. _:r1 a :Reifier .
<niklasl> Nothing is lost. _:r1 is clearly related to the same <s> :p <o> that is in the graph (the abstract relationship itself).
tl: This is many to one, not many to many. Qualifying things that are many to many doesn't make sense.
<niklasl> Yes, if you're looking for singleton properties, that is many-to-one. And *not* n-ary.
tl: If you use reification it's an object to which you can add more triples.
niklasl: I think you would have an easier time arguing for singleton properties.
tl: I'm conflating issues.
niklasl: I think Kurt is arguing for something similar. His solution is reification in one case, and singleton properties in the other.
… I try to keep many to one and many to many separate.
… The annotation syntax represents both the assertion and the reifier.
… Thanks to transparency, they refer to exactly the same thing.
… If this is hard to understand, and people can't understand many to many, it's going to be a problem.
enrico: rdf:reifies should be called "rdf:blob", the point is how you use it.
… The many to one I've discussed and produced a Wiki about why you don't need it. You get it from many to many.
… Can the current spec represent what you want to express? If it can, this will be a new chapter.
… If there's no confusion about what reification is (no conflations, please), can we capture our use cases correctly?
… The use cases are satisfied, why do we need something new?
… If you can do anything you want with our language, you need a strong argument to add something new.
tl: Everyone would need to add another triple to say they mean it.
… You can do it, but it's not feasible.
… Using rdf:blob is so undefined, we would get into the same situation as with named graphs.
enrico: No, it is defined. we should use "blobifier". It's intended to define different relations.
… The concept has been used for a very long time.
<niklasl> Well, rdf:relationOf then (another round of naming?)
enrico: relations capture many different things.
<niklasl> Or rdf:relatorOf (I'll stop here)
enrico: <<John Loves Mary>> :added :yesterday.
<Zakim> pfps, you wanted to comment about infeasbility
pfps: tl said something about infeasibility; as far as I can tell, there is no extra burden placed by adding the possibility of annotating triples that are not in the graph.
… To have embedded triples, you need more complicated data structures. To talk about them as being in the graph, you need a bit more, but that's it. I don't see where in infeasibility comes in.
tl: Bob annotates a statement in the graph. He'd also need to add another annotation "and I mean it".
… First you had Olaf's version that asserted and annotated at the same time.
… Now, you have a triple, you annotated it, and then you talk about it.
<doerthe> it has nothing to do with the opacity, that is a different discussion (which we should not have now :) )
tl: If it's a use case we should support it unambiguously.
<tl> :s :p :o .
niklasl: I don't see your graph clearly. I'm not sure if your example is ambiguous.
<tl> << : s :p :o >> a :Whatever ;
<tl> :and :IacctuallyMeanIt .
tl: I you need to say that I think the triple should be there.
niklasl: The relator/reifier is also described. And the triple is in the graph.
… That's epistemology.
tl: N-Ary makes this clear.
niklasl: Your argumentation is ambiguous.
tl: I'm trying to deal with the performance issues of singleton properties.
[Discussion too rapid to capture]
<pfps> I don't buy that there is any significant extra effort - on the part of users or implementors.
<pfps> But even if all embedded triples have to be in the graph, then there is still three triples :s :p :o . :bob :says <<:s :p :o >> . :bob :asserts <<:s :p :o >> .
<pfps> The only distinction is that with embedded triples that are not in the graph, implementations have to be able to handle triples that are not in the current graph, which they more-or-less have to do if they implement RDF datasets.
<pfps> Now you could have a semantic extension to RDF where :bob :asserts <<:s :p :o >> . entails :s :p :o .
<Zakim> pfps, you wanted to talk about extra triples
pfps: Allowing embedded triples to not be in the graph adds no extra burden other than for implementors.
… If they're implementing datasets, they need to do that anyway.
… Presumably, you could require that triple IDs are unique to a graph, but that's wasteful, as there will be overlap.
… The added extra implementation burden should be minimal.
… Even if all embedded triples have to be in the graph, you still need triples for each. (in the graph, bob said, bob asserted).
… Then SPARQL is no longer simple entailment.
<pfps> But putting that into SPARQL means that SPARQL querying is simple entailment.
pfps: Standard SPARQL entailment is simple entailment.
… A syntactic shortcut makes it looks like there are fewer triples.
tl: Once you go to N-Triples, the sugar is gone and you need to write three triples.
pfps: If you're writing N-Triples, then you do. If you require people to do that and not use Turtle, you're doing a dis-service to your users.
tl: The mapping needs to add a new triple.
pfps: I don't expand Turtle before I send it to you.
AndyS: You're fighting between expressivity and ease of expression.
<tl> :s :p :o {| :a :b |}
<pfps> +1 to gkellogg
<enrico> +1 to gkellogg (but I am optimist)
<pfps> bye all
<doerthe> I also am an optimist :) We can still come together
<doerthe> (but I share the concerns)
<enrico> The current baseline is the way to go - I don't see still why we should diverge from it.
<Souri> Would multiple sets of qualifying attributes be allowed? :alice :buys :car . :q1 rdf:qualifies <<( :alice :buys :car )>> . :q2 rdf:qualifies <<( :alice :buys :car )>> . :q1 :paidWith :cash ; :amount 500 . :q2 :paidWith :creditCard ; :amount 1000 .
<Souri> I see "isAsserted?" as a global variable (within a graph scope). It either is true or false. Use of rdf:reifies does not affect that global variable in any way.
<Souri> This is how we have it today.
<doerthe> I also have to leave. It could help to take a break before we further discuss. So, please consider to take a break :) Bye
<niklasl> Thomas, I *think* you might want something like: ex:singletonPropertyOf rdfs:subPropertyOf rdfs:subPropertyOf ; owl:propertyChainAxiom ( ex:qualifies rdf:predicate ) . # *if* a triple term entails an rdf:Statement. Then you have turned the reifier into a qualification of the property used as a predicate (specifically a subproperty, and that
<niklasl> specific relationship would be entailed by the chain axiom).
<niklasl> Actually, no, it needs even more convolution.( Still, a subproperty is already possible; and could be related from the reifier.)