Meeting minutes
Discuss if a single id can reify more than one triple
ora: discussing if a single reifier can reify more than one triple.
… I've stayed back from conversations up until now, but I need to take the chair hat off and speak as a member:
… I have a few points that trouble me about allowing a single reifier reify more than one triple.
… It's been 27 years since I started working on PICS-NG, which became RDF. In that 27 years, it's been an uphill battle to explain it to people.
… Some people get it right away, but for a lot it is difficult to explain how it works and what it does.
… This topic could make it a lot harder to explain.
… Regardless of how useful it might be to have multiple triples reified, it remains confusing for people, which worries me.
… Another thing is the distinction between named graphs and sets of triples reified.
… I find it difficult to explain the distinction between named graphs and multiple reifiers.
… On this list, I think we're mixing domain modeling and the fundamental RDF mechanisms.
… We haven't discussed what it would man say for SPARQL, or how to implement things.
TallTed: To say you can have only one object for a given predicate breaks other assumptions in RDF.
… RDF allows you to say anything about anything, I would expect it to be okay to have multiple, otherwise you'd have to say that the last utterance wins, and given that there is no order, it breaks query.
… I don't think the restriction is viable. How to handle without it may require something else.
<pchampin> If this is meant to be a strong restriction (as in "forbidden in the abstract syntax"), I'm strong +1 with TallTed
TallTed: It may turn into a reification of a set of triples, which is close to a graph,
<niklasl> +1 to what Ted said
<pchampin> but the restriction could be softer, just like rdf:first is "meant" to be functional, but this is not enforced by the abstract syntax
tl: You said Named Graphs should be out of the picture, but they come back when you talk about sets of triples. If named graphs are in the picture, I'd go back to my nested named graphs proposal.
… How do you explain that to people?
… You'll get questions because named graphs are optimized for multiple triples, and reification is not.
… Two different but similar mechanisms will be difficult to explain.
… Doerte explained how some cases require multiple triples to be reified.
… We should talk about meaning, not about how it's encoded.
<niklasl> +1 to Thomas too. (We need to talk about what it *means*.)
tl: It's going to be complicated to explain, Once you get further into RDF it becomes complicated.
gtw: I think that once we switch to using the "reifies" description it changes the assumptions.
… We're getting away from our charter which talks about statements on statements, which was about single triples.
… It feels like an entirely different thing than what I thought the WG was aiming for.
ora: The reason I brought up Named Graphs is because they're part of RDF.
… These two things look the same, but they're not.
niklasl: I think the discussion started by Thomas is pertinent. I've had confusing discussions about RDF-star too.
… We need to dig into the use cases; the original use case with quoted triples it was unclear if it was used as a subject, which was shown to not work out.
… Thomas talked about using named graphs.
… I wonder if we need to talk about one quoted triple, what was wrong with existing reification?
… The assumptions were that it wasn't good enough, as it's just one kind of reification (at statement).
… Because we have S/P/O, the old style is only one triple, but I think it's been shown that a reification isn't necessarily tied to just one abstract triple.
… As with anything, the identifier denotes something, and a reifier that donotes multiple triples denotes something.
… What is being reified depends on the domain of discourse.
… It could be an observation or an event. When it's an event, it's almost guaranteed that it reifies more than one triple.
… Both :a :marries :b and :b :marries :a are reified by the event of marriage.
… I think that it can work.
<Souri> if a domain says=> :Single owl:disjointWith :Married, then this is NOT valid=> GRAPH :g { :s rdf:type :Married, :Single } . BUT this is valid=> :e rdf:reifies <<( :s rdf:type :Married )>>, <<( :s rdf:type :Single )>> .
Souri: If you have a named graph, you cannot create a valid dataset with contradictory statements, but with reification, you can.
<pchampin> Souri: the graph between curly brackets is inconsistent (with the ontology), but the dataset it self is neither consistent nor inconsistent -- it does not have a standard formal semantics
Souri: Each statement is independent, but the same reifier reifies two different triples (separately, not as a set).
… This allows us more expressivity.
… Our goal is to be able to support edges in all generality, including some things supported by LPGs and others that aren't.
… It allows me to talk about how two edges are related.
… We need to focus on these things to provide more power in RDF 1.2.
… If we should allow the same reifier to reify more than one triple is up for debate.
… But, we need to provide some edge support with full generality, so that people can describe the relationship between edges as well as normal edge properties.
ora: We're not really discussion OWL, but your example could be taken as an argument for or against the multiple-reifier case.
… I don't understand what your example supports.
Souri: In that example (there's another too), there are two options. If you're using a single reifier to reify two inconsistent triples, it could be confusing if you don't come at it from RDF.
… If we said :e1 reifies s:Married, and :e2 refies s:Single, it might be simpler to use a multi-reifier.
… I think it would be easier for the user if it is single.
… One triple pattern per refier is simpler for users to understand.
<niklasl> ex:Fact a owl:Class ; rdfs:subClassOf [ a owl:Restriction; owl:onProperty rdf:reifies ; owl:cardinality 1 ] .
niklasl: Just to reiterate, I think the reifier type could ...
… For a given type, a reifier may reify only a single triple, in other cases, it may reify multiple.
… To test this, we need to look at use cases.
… Maybe we realize rdf:Statement was good enough all along, but I doubt it.
tl: Perhaps it makes sense for events, but what about other things?
… Why do you think its easier with only a single triple?
… It's frustrating to both have named graphs but not use them for something they're suited for.
ora: To be clear, I went through an exercise of explaining it to people, to identify reification vs a set of triples becomes confusing.
… We have to have a super clear description of what this does. This could go off the rails if we make it even more complicated.
… I understand that we need expressive power and clean formalizations, but none of this matters if its too confusing.
<TallTed> *named graphs* are sets of *asserted* triples.
<TallTed> *reified* *triple_terms* are not asserted.
<TallTed> *reification statements* are asserted.
enrico: People have made most of the arguments already, but ora said that a multi-reifier is confused with graph.
… I don't see why it's that confusing, it's not naming a triple, but a triple term.
… It may be hard to use, but I don't see how restricting its usage makes things easier.
… There's not connection between a set of triples and a graph.
… When I have something connected to multiple other things does not say it's connected to the set of those things.
… A graph is more than just a set of triples.
<pchampin> I agree with Enrico that "being related to N elements" is different from "being related to a set of N elements"
enrico: A graph has the same bnode scope as the graph, but not between graphs.
ora: I'm not saying its different, but it's going to be confused.
<pchampin> but I strongly disagree that an RDF graph is more than a set of triples; this is exactly how the spec defines an RDF graph
enrico: the other argument is that if we want a unique restriction, you now need to be able to verify that it is unique.
… You would need to assume that the different triples are really the same.
… This means that SPARQL with simple entailments should take that into account.
… You should always allow for arbitrary graphs, which is always possible under RDF semantics.
<niklasl> From last SemTF meeting: "All graphs are sets of triples, but not all sets of triples are graphs."
enrico: If I have a standard RDF graph where some nodes are triple terms I don't see the problem?
… It's a problem if we need to restrict to just be a single reifier.
… A refier could be anything, and the meaning of it could come from different perspectives.
tl: The seminal use case for RDF-star has been a prominent use case, and you can't know if it's an annotation of a single triple or multiple you can't really know.
… Things can get more complicated. One proposal was to rely on named graphs.
… Everything that needs semantics could be moved to the new space of triple and set-of-triple annotations.
… That would be a move away from named graphs for things that needs semantics.
kurt: If you have a many relationship you're opening up the possibility that RDF is a hyper graph.
… I don't see a problem with that, but I think people suffer with the 1-1 relationship because they're trying to move into a set relationship. It's not just about reifications.
TallTed: The major difference between reification and named graphs is that triples in named graphs are asserted.
… Triple terms inside of reification statements (one or multiple) are unasserted and basically literals.
… Until you want to ask who said something, in which case they need to be broken out, but not in the merged graph space of many stores.
… Every triple term needs to be treated as its own singleton graph. If we have a single identifier for multiple triple_terms, then those triple_terms with the same identifier should be treated as one graph, solving the concerns of blank nodes, among other things.
… A collection of triple terms must be treated as outside of the default graph space unless explicitly queried (by whatever mechanism we haven't quite defined).
… Implementing these things may be challenging, but not implausible.
tl: It depends on your implementation if triples in named graphs are asserted.
<Souri> Aren't the concepts of Named Graph and Atomic Reification orthogonal? GRAPH :g { :e rdf:reifies <<( :s rdf:type :Married, :Single )>> } . Many-to-many rdf:reifies=> A (single) reifier for a set of (atomic) reifications VS. NamedGraph=>An identifier (graph name) for a set of asserted triples and reifications.
Souri: We said we can't use named graphs for edge properties.
… Are the concepts of named graphs and atomic reification ...
… I could construct a named graph containing reified triples and say that it is a triple inside the graph.
… The two concepts complement each other.
… I should be able to put a reification within a named graph.
ora: Good discussion.
… My mind is less made up than it was before.
… We need to continue the discussion.
<pfps> I'm on the side of Ted in this discussion.
ora: I presume there is no semantics call tomorrow due to hollidays.
… I suggest we continue the discussion on the mailing list.
ktk: It's time to vote on RDF Dataset Canonicalization for those who can, by April 23.
introductions
Kurt: My name is Kurt Cagle, and have been following RDF for some time. Work on LinkedIn and elsewhere talks extensively about RDF.
… I'm following the discussions with much interest. Whether or not it can be confused, I need to struggle with it.
… I have an audience of about 10,000 people I need to describe this to.