Meeting minutes
Thomas' proposal on rdfs:states
tl: sharing slides
tl: slide 4: discussing the intuitions about "unsasserted statements"
… what's intuitive for logic is not for the real world
… in PGs there is no such thing as unasserted assertions
… slide 5: we could have a strong link between asserted statements and annotations, with a specific predicate rdfs:states
… slide 6: we have 3 primitives, one in N-Triples and two in Turtle; I think users should only use Turtle
… slide 7: discrepancy between the user-facing syntax and what's in the database
… this creates an ambiguity about whether or not Alice endorsed that statement
… we don't want that
<pfps> I'm completely lost by this argument.
tl: slide 9: proposal: 2 different reification properties, one for the << ... >>, and one for the annotation syntax {| ... |}
<william_vw> "most of the SW is about facts" - note that this may be due to the fact that reification was underspecified / terrible until now
tl: this would make round-tripping work, and would satisfy user's intuitions IMO.
… slide 10: discuss the drawbacks of this proposal
enrico: in slide 10, 2nd bullet, I think you mean "union" instead of "join"
tl: you are probably right.
… the fact that the annotation syntax was never challenged is telling.
… So capturing the intent of the annotation syntax with rdfs:states seems valuable.
slide 11: we need to make a decision now, as we are specifying the syntax now
… [something about vocabularies for propositions]
<Zakim> pfps, you wanted to talk about the example on slide 7
pfps: I find none this compelling.
… You say it is not about propositional attitudes, but "says" in your example is a propositional attitude.
… But then again it is not about prop. attitudes, because there is no relation between Alice's endorsement and the assertedness of the triple.
… Roundtripping is a red herring; other syntactic shortcuts do not roundtrip either.
tl: w.r.t. propositional attitude, my 2nd example is not related to them.
pfps: the first example is, though.
<TallTed> the most common Turtle shorthand -- `:s a :p` -- doesn't roundtrip. it becomes `:s rdf:type :p` in a triple store.
<AndyS> https://
pfps: and we have been over these arguments again and again.
<AndyS> https://
<Zakim> pchampin, you wanted to talk about the example slide 7
TallTed: this is a different presentation.
pchampin: In reverse order: In the last slide, you said we couldn't postpone it because of syntax discussions. But, nothing is final until REC.
… Other arguments were stated by pfps. Using examples like "says" is a problem, as there are a lot of specific issues ...
… The problem with "says", is that when someone says something, they endorse it.
… We could use "quote" instead of "says". Then, I have no preconceived assumption about what they mean.
… The assertedness tells you something about alice, but having multiple perspectives represented in a graph is fraught.
… I consider that the round-tripping issue is not an issue. If the triple is endorsed by the author, it doesn't matter what non-authors say.
<Zakim> niklasl, you wanted to say "that doesn't say what Alice 'meant' anyway"
niklasl: that's basically what I thought as well.
<niklasl> :Foo :madeOf :Bar {| :rejectedBy :Alice |} {| :believedBy :Bob |} . # Invokes other "intuitions"?
niklasl: maybe the example above helps. I wouldn't say this example is strange.
… That's ok to state that alice rejects an asserted triple.
<Souri> I feel strongly about maintaining independence (i.e., having no side-effects). Presence or absence of :s :p :o, the triple, in the graph, IMO, should be independent of the presence or absence of :r rdf:reifies <<( :s :p :o )>>. Anything one says about :r is about the triple-term <<( :s :p :o )>>, not about the :s :p :o triple, as far as RDF
<Souri> semantics is concerned. Data creators can connect them if they want to.
niklasl: I disagree with what you claim is a common intuition.
<pfps> I agree with this.
tl: Niklas, you model it the other way around, then you don't have a problem.
… Of course we can educate the users to do it that way.
niklasl: the graph says what is true or not; if you want to model your interpretation process, you have to model it in the graph.
<AndyS> https://
AndyS: one of the problems I see is: taking an existing use-case that has been discussed long enough,
… and repurposing it for something different.
… See link above, the annotation syntax was meant to allow people to write less.
… You are questioning the utility of this.
… I don't think that we can or should repurpose the annotation syntax.
Souri: the more side effects we have, the more confusion it creates.
… rdfs:states would have imply the s p o in the triple term, I see that as a side effect.
… For me, the triple S P O and :r rdf:reifies << S P O >> are independant as far as RDF is concern.
… Even if users may chose to connect them.
enrico: I'm not sure what we are really discussing.
… Is it rdfs:states per se? Or whether there should be a shortcut for it?
<TallTed> "states" could be a syntactic shortcut (that would translate to some specific RDF). "rdfs:states" would be an RDF predicate.
<TallTed> "states" akin to "a"
enrico: I don't see this would be confusing for authors, as most of them would not enable RDFS entailemnt.
tl: my proposal is to change the annotation syntactic sugar to use rdfs:states
… the annotation syntax would create 2 triples, just like today, but use rdfs:states instead of rdf:reifies.
… plus, rdfs:states only would entail the triple if it was not explicit
enrico: ok, so the macro would enforce the entailment provided by rdfs:states.
… So the question is whether people want this special thing.
doerthe: I have a similar question. I was not sure how you see rdfs:states.
… enrico assumes that it would lead to some entailments, while my impression from your slide is that it would have no extra-semantics.
<tl> w3c/
<gb> Issue 128 map the annotation syntax to `rdfs:states` (by rat10) [discuss-f2f]
doerthe: We came here because you care about roundtripping the annotation syntax.
<Souri> Since rdfs:states is not part of RDF1.2 -- whether it should be added to RDFS vocabulary as an extension or not is not for us to decide right now
tl: the issue above gives the complete mapping to N-Triples.
… I acknowledge the problem you raise in the issue.
… Is it viable to tell peoplel to only use Turtle with the syntactic sugar, and only use triple terms if they really know what they are doing.
<niklasl> It would be "deleteable" *unless* RDFS entailment is used; if that is used, it would be "immutable" since the rdfs:states would imply it (*very* informally speaking). I see that as a potential problem.
doerthe: to be sure I understand, you want rdfs:states to entail the object triple term.
tl: you have to see it the other way, start with the annotation syntax.
doerthe: I would like to see it my way as well.
<pfps> I agree with doerthe - the shorthands are syntactic sugar, no more
tl: the current annotation syntax maps to 2 triples; if you destroy one of them, and serialize it back to Turtle, you get only the << ... >>
… but yes, I would like RDFS entailment to entail the triple term back.
pchampin re-purposing the annotation syntax; becoming more than syntactic sugar
pchampin when people write 2 things, they want both to stay together; that is the argument
pchampin: I find it adds complexity, and not convinced
pchampin: about educating users; the argument relies on a misunderstanding of stated triples; i.e., of how RDF works
pchampin: not convinced that it is part of people
… 's intuition
pchampin: not opposed to having entailment for the original triple
tl: I'm having trouble accepting AndyS's argument. I'm not taking away anything or repurposing anything.
… We didn't have the notion of reifier at the time.
… What I'm changing is how the annotation syntax is encoded, and ensure that with entailment, the intent of the annotation is preserved.
… About "says", I provided another example, with theories.
… There are drawbacks, but that's a small price to pay.
<niklasl> Here is my attempt to answer that question about opposing theories: https://
tl: I agree that I'm repeating myself, if you all disagree, then so be it.
TallTed: there is a regular concern about complexity. RDF is complex even if it seems simple.
… Few people get it right the first time.
… That's ok, we can't remove all complexity from the world.
… We need to decide whether we are designing syntactic sugar on Turtle (and other concrete syntaxes) or on the abstract syntax.
… I think that abstract syntax is not a good idea.
… Round-trippable is a red-herring.
… Syntactic sugar is useful for putting things in, not be able to say "this is how things were written".
… Inference is something different.
… I can infer new things from what is explicitly stated.
… Baking too much semantics in rdfs:states (or other predicates) will cause confusion.
… Putting sugar is less problematic.
<doerthe> you are assuming semantics here...
tl: slide 7 shows how you lose the info about who endorsed the triple.
pchampin: no!
AndyS: there is a difference between authoring data and accessing that data.
… They happen at different types. Entailment is available when accessing.
… What I think TallTed was getting at is: when you exchange database dumps today,
… you exchange N-Triples or N-Quads, not Turtle, so you don't keep the sugar.
… Finally, I don't believe that your examples are majority use-case, as you claim.
… If you say "this triple has a source", it does not matter whether the triple is asserted or not.
… You don't want the removal or adding of that triple to change the source.
… That's the problem of requiring rdfs:states in one place, and not in another.
tl: this is a valid argument; but if you want more, you need to add it (and query it) all the time.
william_vw: N-Triples is used to exchange data, it is the ground truth. Hiding it under the rug is not a good idea.
… Forcing some well-formedness on it is not something we can handwave.
… I think Pat Hayes once said "every RDF statements stands on itself"
… Having a constraint that prevents rdfs:state to exist without the accompanying S P O goes against that.
… In JS, you can add a semicolon at the end of a statement, but you don't have to. It is a matter of preference or policy.
… Should an editor or a linter add it if it's not there?
<Souri> Can't I use three different reifiers to separate out what ALice thinks, what Bob thinks, and what Dan thinks.
tl: someone could use 3 combinations to encode different semantics (rdf:reifies, rdfs:states + asserted, rdfs:states without asserted) but that would be a hack
niklasl: I agree with pchampin that there is a mistake in your example, where you assign an intent to the use of annotations.
… Not sure about propositional attitude.
… I also agree with william_vw that you seem to try to link the meaning of 2 triples with rdfs:states.
… I don't know how we can assess what the majority of users thinks, but in the group, most of us don't interpret it that way.
… If you want to model that Alice endorses a triple, you can model that in your own vocabulary.
… I would not say that RDF is complex. The interpretation is the complexity of it.
… Coming back to your claim that in LPGs the edges exist;
… they exist in the data, but there is no notion of assertion.
… In LPGs, some edges have a property "certainty: 0.4", this does not assert the edge.
enrico: rescuing tl, I don't have an opinion about rdfs:states or the annotation syntax.
<pfps> How does rdfs:states make anything shorter?
<doerthe> but that is not what was proposed, right? tl wanted two triples?
enrico: If the use-case is preventing to write two lines, rdfs:state is a way to do that.
<TallTed> same meaning <> round-trip
enrico: Round-trip: Turtle and N-Triples are completely round-tripable, as they have the very same meaning.
<william_vw> niklasl - but that is about syntax and not semantics
<TallTed> comments are also lost, and they *may* be semantically important to the humans involved
<pfps> +1 TallTed
<tl> @doerthe look at the tl;dr in the issue linked above for the mapping
<william_vw> TallTed - sorry but I don't think that is what enrico meant
enrico: If you want to change the graph and want to retract a triple, and you wrote rdfs:states,
… then you have to change it to rdf:reifies. You need to take seriously what you wrote.
<william_vw> @TallTed you can round-trip comments but they would be just as meaningless the first time
<william_vw> (regarding their machine-interpretable semantics)
<niklasl> Of course. In OWL you can even entail <Liz> :spouse <Richard> from an "N-ary" ;Marriage.
enrico: If I write A subClass B, B subClass C and A subClass C, even if I remove A subClass B, A subClass C remains because I stated it explicitly.
<TallTed> william_vw -- if I load Turtle, NQuads, or NTriples (which has comments) into an RDF store, and then dump that graph, I have lost the comments
<william_vw> @enrico I was talking about a well-formedness that is introduced by rdfs:states + assertion
Souri: I have a basic question: we are doing RDF. Why do we have to discuss RDFS, is it not out of scope?
<william_vw> TallTed -- say I have a system that keeps comments and can roundtrip them, it doesn'
Souri: Second question: if Alice and Bob have different opinions about SPO, we can associate two different reifies to them, and both can go their way.
<william_vw> t matter; they are meaningless from the RDF perspective
<william_vw> they are purely syntax
<TallTed> "say I have a system that keeps comments and can roundtrip them" -- that's completely jumped the rails around RDF
Souri, RDFS *is* in our scope, see the charter
enrico: RDFS semantics is defined in the same REC as RDF's semantics
Souri: wasn't RDFS defined after RDF, historically?
<william_vw> @TallTed - let me rephrase - the fact that comments are not translated into RDF means they are meaningless from a machine-interpretable semantics viewpoint
<niklasl> There is noone who "says" the graph. It's simply true (*if* you decide interpret it). That's the simplicity. What that implies is interpretation upon that.
enrico: no, they were created at the same time.
tl: if somebody writes N-Triples following the rules, they don't need entailment.
william_vw: to respond to enrico, what I meant with well-formedness: tl suggests that somebody writing rdfs:states in N-Triples should also write the asserted triple.
enrico: but with entailment, you don't *need* to add it.
william_vw: yes, but we are talking about RDF.
<niklasl> Now you are discussing the two different questions at once?
tl: this is similar to lists; you *can* write ill-formed lists, but that's not a good idea.
AndyS: if you have a lot of triples (more than memory), you would use restricted forms of Turtle, which would not necessarily preserve annotations or the rdfs:states.
william_vw: enrico, it is true that you can write OWL-entailed triples in RDF, but as far as RDF is concerned, they do not exist until you wrote them.
<pfps> You can certainly write triples that use the OWL vocabulary in an RDF graph, and they then exist in the graph.
<doerthe> indeed, I think that tl and enrico's understanding differ here
enrico: to summarize: we have again discussed about rdfs:states, which is an orthogonal choice to have multiple reifiers.
<Souri> IMO, stay within RDF. And, rdf:reifies + (rdf:asserts property or rdf:ReificationProperty class) is sufficient.
enrico: The previous discussion about reification properties rules out rdfs:states.
AndyS: why?
<william_vw> @pfps - I meant the OWL inferences do not exist as far as RDF is concerned
<pfps> I don't see that either.
<niklasl> Me neither.
<niklasl> Only if rdf:ReificationProperty is somehow owl:oneOf (rdf:reifiies) ... ?
<TallTed> ...adjourned...