Meeting minutes
<TallTed> agenda:
<TallTed> https://
<TallTed> I have primed the bots, but cannot scribe
AndyS: There was a statement made that rdf:reifies is a special predicate.
… It would be useful to know why it is pulled out to be special in the RDF Semantics.
… How do we write extensions of such properties?
… For example, provenance. But, we need to establish the reasoning for rdf:reifies to be called out.
enrico: Given the baseline with rdf:reifies, what is an accepted syntax? Do we separate entailment regimes?
… In the baseline, rdf:reifies is just like any other predicate.
… In the RDF semantics, it is called out.
… Because of the well-formed restriction, we can derive axiomatic triples.
… If someone wants to create a sub-property of rdf:reifies, they are free to do so.
ora: I thought thinking about Souri's points. For example, someone may not expect to assert a statement but someone else may.
… This brings in the notion that a graph is a multi-user database.
… Thinking about old reification, there was nothing about this.
… We never considered that a graph may be composed of statements from different people with different perspectives.
… Then we may need to track _who_ made specific statements, and it rapidly gets out of control.
thomas: It is an integration technology, so the data does need to be self-contained in some sense.
… Niklas posted an example about posting data from different sources with different kinds of things.
… This works, as long as you have full control over your graph.
… If the information that something is asserted or not depends on a few triples, we have no way to connect information about different triples.
… we use lots of triples in simple RDF that come from OWL or RDFS.
… IMO, rdf:states assumes that the triple term is also stated.
… Then we fake entailment, which the annotation syntax does.
… We need to do the same on the SPARQL side, so if a triple term is related via rdf:states, the ground statement should always be returned from queries.
… There are cases when entailment really needs to be just for a single statement.
… We define what we mean, but systems may or may not enforce this.
<doerthe> this last idea brings owl:sameAs through the backdoor to RDF, that is dangerous
thomas: We have syntactic sugar for the list vocabulary, which is similar to what we have for reifying triples.
TallTed: Talking about who did an annotation and such is similar to auditing information in SQL databases.
… We should be able to do that, but not enforce it.
<TallTed> If `:r rdf:reifies << :a :b :c >>` can be sugar for `:r a rdf:tripleterm; rdf:subject :a ; rdf:predicate :b ; rdf:object :c`, much of this seems solved. Note that this does not put `:a :b :c` into the graph. Annotation+assertion syntax can be sugar for that *plus* putting `:a :b :c` into the graph.
TallTed: We might want to be verbose about this, where we might not be able to use named graphs.
… the idea that people are expressing things in RDF-star is the ability to identify a triple and talk about it a) without asserting it, and b) with asserting it.
… The first one is doable with the old rdf reification syntax, but maybe syntax makes this work.
… Some particular predicate might mean to use the verbose/expanded notation.
… It's not a subject in the graph, but is written as a subject.
… you can say there is a triple term for which I want a label.
<niklasl> I must be tired, this sounds like just the old option 1 (sugar for classic reification), but slightly confused with an (if so) unnecessary rdf:reifies...
Souri: The motivation I have is that I'm trying to do the simplest thing we can.
… in LPG, there's nothing like an edge which is not stated.
… My approach is based on evidence without entailments. I don't think a triple without an ID makes sense.
… This may be one reason that LPGs have taken off.
… We need triple identifiers, but may not need reification.
… I use rdf:asserts rather than rdf:states to be explicit about this. I believe the ID should be part of the graph for every triple.
… SPO is independent from ISPO, and if we support reifies (I don't care).
… If we have SPO and ID asserts SPO and ID reifies SPO, they are completely independent.
… With that independence, SPARQL can do something.
… If you use an SPO pattern it will not do anything with an ID.
… The independence is important, and my main target is to get rdf:assesrts as simply as possible.
<doerthe> But why do I need two different predicates in that case if they behave the same?
Souri: Same thing for relational data if I want to turn it into RDF.
… rdf:asserts is my use case and it should not be based on rdf:reifies.
… It's a nice thing to make RDF a little more useful.
… I want to separate hypothetical statements from true statements.
… I want to keep entailment out of RDF 1.2
enrico: You cannot re-construct the original reification.
… I don't understand Thomas's statements. But, I believe this requires RDFS.
… If you want many-to-one mappings, this will make other things hard.
… If you want an ID to describe one triple term, this will be a major complication with Souri's description.
… If you want to say that an ID identifies only one triple term ...
Souri: I'm okay with many-to-many
enrico: I think that people don't understand what a triple in a graph means.
… A triple is something that says two resources are related.
… When you reify, you can say many more things.
… When you have a reification, you may want to also say it's in the graph. The fact that they are described in a triple term in some sense says that this relationship exists in the graph.
… A reification may says that people are married even though the triple is not in the graph.
… A triple saying that they are married is different from the fact that they are married.
… We should discourage the use of reificaetion in RDF, maybe just use for corner-cases like provenance.
<thomas> so according to Enrico a reification is the fact, whereas a statement is just ... what? imprecise?
enrico: we're now using reification to "fix" legacy RDF graphs.
… reification shouldn't be used except for some narrow use cases.
… Souri's arguments relate to relational databases and is a mismatch for RDF.
… The reification buisiness is not meant to encode relationships directly.
<enrico> ackk enrico
niklasl: The marriage example I understand, but I want to make sure that the relationship ...
… If it was reified because of provenance it could mean something else.
… LPGs have no simple relationships.
<Souri> Just to emphasize, in my approach the following three triples related to s-p-o do not influence one another in any way within RDF semantics=> :s :p :o . :id1 rdf:asserts <<( :s :p :o )>> . :id2 rdf:reifies <<( :s :p :o )>> .
niklasl: You also said to avoid entailment as a hack for modeling. I agree in theory, but in practice, I suspect that the ergonomics of the annotation syntax makes it more comfortable to stay within too-simple semantics.
… Modeling marriage is a good example for entailment.
<Souri> ... and I care a lot about rdf:asserts (because it is required for data conversion between RDF and LPG, relational data), but rdf:reifies is optional and nice to have some extra capabilities to RDF compared to LPG and relational.
niklasl: Rows are entities with multiple predicates.
… I wouldn't model things this way and would tend to use just reified triples.
… I don't hear strong arguments for changing what an assertion is in simple entailment, so maybe we can put that to rest.
… Adding rdf:states would not, in itself, mean that the triple is stated.
… We don't "fake" RDF schema, if we did, you'd need to "hunt down" all entailed statements.
thomas: I don't think there's a need to remove anything.
… We try to guide users into types of support and act as if it is actually entailed.
<doerthe> fake=syntactic sugar?
thomas: In the original RDF*, triples were always stated.
<Souri> Niklas, could you write your question about my example, just so I can be sure I understand it?
ora: I also have multiple things I'm trying to keep track of.
… It was interesting to hear enrico say that good modeling does not use reifiection.
… I often discuss this with our customers. They want to use LPG because they think to annotate edges.
… I try to discuss how to do this in RDF using intermediates such as an "Event" entity.
… In 2010 there was an RDF Next Steps workshop.
… In the case of Nokia, everything in the graph was a six-tuple with SPO along with source, owner and timestamp.
<ora> https://
ora: These other terms don't have anything to do with the data model but are needed for other reasons.
… We used ideas from Aspect-oriented programming to not pollute the domain models.
<niklasl> With RDF-star and *OWL*, there is no "cul-de-sac"; you can actually go from a qualification reifier to a properly modeled entity: w3c/
<gb> Issue 27 Integrating different ontology designs through entailment upon triple terms (by niklasl) [use case]
ora: If reification ends up being part of RDF how does one use that for defining an ontology or schema?
… When I did work on this I realized we don't have the vocabulary to do this.
… This speaks to the idea the reification isn't good modeling.
… This leads me to the many-to-many proposition that seems like an attempt to sneak some kind of conjunctive assertions into RDF.
… Right now, I can talk about statements independently; RDF doesn't say that two statements have anything to do with each other.
… RDF started out without triples and came from the frame-based knowledge representation, we move to triples but maybe lost something.
… Maybe the reification thing has gotten out of hand.
<niklasl> Well, up until triple terms, triples were definitely independent. With triple terms, a triple can now relate to another triple.
thomas: The graph vision of RDF isn't about collections of triples that are related to each other.
… Statements about statements qualify those statements.
… Only relying on relational tables is too much of an RDMS vision and gives away the whole graph.
… An LPG is an annotated graph.
<fsasaki> just for the minutes, not to start a discussion on the chat: use cases mentioned in today's discussion for rdf:states are quite heterogenous: provenance, vagueness, access control etc. This heterogeneity may be better covered on the application level.
doerthe: If I recount what Souri and thomas proposed, they idea was to have two different predicates (assertion and reification). Souri doesn't want to add extra semantics but thomas would like to do something that says a triple term is also stated.
… In Souri's case, if we don't restrict at all, it allows different kinds of predicates.
… I wonder if we always have those two different use cases.
Souri: I'm really interested in just rdf:asserts. rdf:reifies is a "nice to have". We want to associate an ID with a triple.
… What it's relationship to that triple term is we don't want to say.
… RDF was simple, it gets complicated when the use case doesn't match the simplicity.
… LPG took advantage of their capability to do things.
… Once we get an ID into the graph we can use that for any number of different things.
… I thought that reifies was nice as other systems can't do that.
… I want binary relationships and not events.
<doerthe> But aren't we then just discussing naming here?
<AndyS> We have the syntax `:s :p :o ~:id`.
Souri: In my use case, most of the time, things are actually binary. If it's not, I'll use relational data.
… My sweet-spot is binary relationships without properties.
doerthe: Whey do we need two predicates? We can say I use it one way and you use it another.
<thomas> doerthe: what about shared meaning
<TallTed> `rdf:mumbles`
Souri: "reifies" is a scary term, and I just want to say "asserts"
<doerthe> thomas: I would therefore rather use predicates I define in some ontology
<niklasl> We *could* call it rdf:concretizes (https://
<thomas> doerthe: i'd like to have those terms in the rdf vocabulary
Souri: I don't need SPARQL to do anything special, If I as for rdf:asserts it will give me that.
<doerthe> thomas: that part I actually understood, now I only wonder what I want :). I am not sure (yet?) that we have such clear use of exactly two predicates
niklasl: I posted a link for a use case that might be interesting. It's about modeling things in OWL with reification.
… In LPGs you do qualify statements a lot, so it makes sense to not think about as some kind of second-class behavior, although I understand the perspective.
… I get a sense that the subject of an asserting triple is in the graph.
… It sounds a bit like a sub-graph and not a reifier, which I believe is independent of the asserted triple
… Asserted triples are triples which are members of the graph.
<thomas> we have discussed 3 types of use cases over the last 5 years: 1) annotating something that is asserted 2) annotating something that is not asserted 3) annotating something that is recorded in syntactic fidelity (referential opacity) - so the number of predicates needed is not infinite. covering these three cases explicitly makes sure that they
<thomas> don't overlap (like merely reified, or also asserted in the baseline proposal). so it's three predicates, two of which are rarely needed. that IMO is much more usable than the baseline proposal
niklasl: With reification, we can address relationships.
Souri: rdf:asserts should be used along with rdf:reifies, if necessary.
… In many-to-many I may assert many things with a reifier.
<TallTed> "engraves"
niklasl: I might say "the resource denoted by an identifier". We could use "concretize" instead of "reifies".
… I think that reifies is fairly common (at least in RDF circles).
… In LPG and RDMS worlds, there is no notion of reification.
<doerthe> thomas: maybe have some fixed terms in RDF and allow others? Then we would get rid again of the restriction that the triple term can only be used after rdf:reifies and rdf:asserts (which I dislike anyway) and then let users define there very particular predicates they might need
<TallTed> "rdf:suggests"!
niklasl: I assume that graphs assert what they assert. If I don't trust published data, I don't put it in the datastore.
… Named graphs are one way to deal with untrusted statements.
<thomas> doerthe: im all for letting people define other properties more specialized or different from rdf:reifies and whatever else we might define. but we should cover the basic needs. rdf:reifies does that in some way, but a rdfs:stated is what most use cases need
niklasl: Trust is way beyond simple, and graphs are simple.
… A marriage can be an entity, and describe multiple relationships.
<Souri> If you include two properties, I'd like to be very explicit about their difference coming through with the choice of the property names: so, rdf:asserts vs. rdf:reifies. If we go with a single property, why not rdf:states?
<doerthe> niklas, now I feel challenged to make you talk again ;)
enrico: To summarize Souri, I think he's advocating a change of name only.
… storing time and user is meta-modeling, but that is something RDF can do.
… When I say reification is only good for provenance I want to also include LPG representation.
… If you want to represent things with reification, you can do that, but it may be bad modeling.
… Additional properties of relationships can only be literal values in LPGs.
… I remember the period of the semantic networks, and we seem to be there again.
thomas: I'm not advocating modeling everything with annotated statements.
… I think annotated statements is useful for describing short-cut relationships.
… Use cases can be modeled in many ways, with our without reification.
<Souri> What is the format of the /msg command to send message?
thomas: Maybe LPG style modeling would ruin RDF, but we should enable it if we can.
… We can change the names of these predicates before publishing; I suggested "mentions".
… I understand that Souri doesn't care about reification; the annotation syntax captures that and SPARQL doesn't.
AndyS: thomas's example was neutral to the provenance case.
… Example statements are neutral about the statements being asserted or not.
<niklasl> I don't understand the "doesn't roundtrip" argument, as I wrote in https://
AndyS: We could through out annotation, but then you wouldn't have some of the useful Turtle features.
thomas: I think we should define rdfs:states rather than rdf:states.
AndyS: I'm concerned that you're imposing your view on everyone else.
<niklasl> No, at least I do not use annotations to imply that the reifier "wants it asserted in this graph", as I've shown in examples.
enrico: I think we have enough discussion and people understand the different positions.
… At this point, we need to propose a vote to settle the direction.
… Do we want rdf:states or rdf:reifies; the options are clear.
… IMO, states should be in RDFS predicate.
… If you have SPARQL with RDFS entailment you get much of what you want.
<Souri> My position is to not involve RDFS or any such entailment within RDF semantics.
Souri: I'm a +0.5 to have two properties.
… I'd like to have a property _not_ mean rdf:reifies. I don't want any RDFS or higher entailment semantics involved.
… RDF is the core.
doerthe: If I understand thomas, the main point is that you would like to have the information that someone asserts a triple by incorporating that in the predicate.
… I don't see the need for this. If I change my mind and want to remove the assertion, then I would need to change the predicate. I don't really see the point.
<AndyS> rdf:forTriple
thomas: I would say, in that case, that you change to use rdf:reifies instead of rdf:states.
… In the baseline, it takes two statements to give the meaning.
<AndyS> :r rdf:forTriple <<( :s :p :o )>> . is about as neutral as I can think of.
thomas: If the triple is removed, the meaning of the graph with a reified triple changes.
… It's not an accident that we have asserted examples.
… There are statements on a stated term or on a reified term and these mean different things.
niklasl: Im trying to understand the problem of conflating states and reifies.
… If you are the publisher of the graph you're not making neutral statements. What is the reifier?
… You say that the resource denoted by an ID states the triple.
… If you have :id rdf:states <<(spo)>>, :id (an IRI) denotes a resource.
… What is that resource?
thomas: A reference to the triple.
niklasl: No, the triple term is a reference to the triple.
… In RDF a triple states that a relationship holds between two resources.
thomas: The difference between states and reifies is on what we mean by the relationship, whether the triple is in the graph or not.
niklasl: The identify denotes a triple in the domain of discource.
… that should be clear.
TallTed: When we say "that's the way it is" it's inevitable that people will have different ideas about what this means.
<enrico> PROPOSAL: ask the WG to have a vote on whether or not to have an additional rdfs:states property (with special semantics) as proposed by few people recently, and formalised at https://
enrico: In thomas's examples you state your assumptions about what is reified or stated.
<gkellogg> +1
<enrico> +1
<Souri> For the single-property case, as long it is neutral (does not say asserts and does not say reifies) it is fine with me. I thought rdf:states is good enough, but you are a native English speaker, you can figure out a better name than I can. :-)
<TallTed> "rdf:splunges"
<Souri> sorry, that was a message meant for Andy.
<TallTed> +0.5
<doerthe> +1
<AndyS> +0 -- need to read the details.
<Souri> +0.5
<niklasl> +0 (I would prefer to define the need first)
<enrico> details: https://
AndyS: I think their's more than one rdf:states floating around.
… I don't have a problem with additional vocabulary when it's defined in a way that works with RDF.
<thomas> https://
<thomas> https://
<Souri> +1 (did not read the proposal text earlier)
enrico: Either it's what's described in the Wiki, or there are no semantics defined.
<thomas> two mails that give a good idea of what i think rdfs:states should be
<Souri> we need a more concrete proposal
<niklasl> Something like rdf:value but for claims/relationships (that resource which is denoted by a triple term).
<niklasl> (Which I found rdf:reifies adequate for...)
Souri: I like rdf:states as a neutral term.
… I'd like to have two different predicates, but I can live with one.
<niklasl> "states" implies that the subject states the claim.
Souri: But, keep it neutral, and rdf:reifies has too much baggage.
<enrico> BETTER PROPOSAL: ask the WG to have a vote on whether or not to have an additional rdfs:states property as proposed by few people recently; one semantics is formalised formalised in the wiki, other semantics are possible, or no semantics are also possible.
thomas: What I'm calling rdf:states does have more meanings.
<TallTed> "rdf:reifies has too much baggage", hence my various facetiously suggested predicates above. Less baggage associated with the English words being used.
Souri: I don't want a hint of entailment coming in.
<TallTed> (same applies to "rdf:states" and "rdf:asserts" as to "rdf:reifies")
thomas: But what you want _is_ entailment.
TallTed: It's impossible to separate english words from their meanings.
<AndyS> As that doc say, seems OK - but there are other things being bundled e.g. annotation syntax that. e.g :source is not about necessarily asserted triples.
<enrico> BETTER PROPOSAL: ask the WG to have a vote on whether or not to have an additional rdfs:states property (with special semantics) as proposed by few people recently; one semantics is formalised formalised in the wiki, other semantics, or no semantics are also possible.
<enrico> ORIGINAL PROPOSAL: ask the WG to have a vote on whether or not to have an additional rdfs:states property (with special semantics) as proposed by few people recently, and formalised in the wiki.
enrico: There are either semantics or you can make up something which is devoid of semantics.
<AndyS> CONSTRUCTWHERE {?X rdf:states ?T } is what?
<TallTed> better original PROPOSAL: ask the WG to have a vote on whether or not to have an additional rdfs:states property (with special semantics) as proposed by few people recently, and formalised at https://
<enrico> +1
<gkellogg> +1
<AndyS> +1 if not connected to annotation syntax
<Souri> +1 to rdf:asserts, not rdfs:states
enrico: This would _add_ rdf:states in addition to rdf:reifies.
<TallTed> +0.5
<niklasl> +0 (I'm too uncomfortable with the needs)
<thomas> +1
<TallTed> it's tempting to vote +i, i.e., +(sqrt(-1))
<niklasl> << </me> :votes +1 >> .
<doerthe> +1 (but I got lost in votes, so I am afraid of voting for the wrong thing)
TallTed: If you name graphs to keep them separate.
<AndyS> Also +1 to one property which is also workable.
<doerthe> bye
<niklasl> Yes +1 for one, I think it is what is needed.