- From: Ross Horne <ross.horne@gmail.com>
- Date: Sun, 5 Jul 2020 16:06:05 +0200
- To: Jiří Procházka <ojirio@gmail.com>
- Cc: Semantic Web <semantic-web@w3.org>
Hi Benjamin and Jiří, I think Pat and yourselves understood well the idea of nominals in RDF from the short sketch. Please let me try to clarify a little further. Benjamin says: > > We are talking about different kinds of mappings. I was talking about > > variable assignments from syntax to semantics, i.e., the thing the RDF > > semantics calls "interpretation" assigning some things in a semantic > > space to blank nodes (and IRIs and literals). > > > > If I understand you correctly, interpretations would still be able to > > assign the same semantic thing to two different blank nodes. > > > > (But then {:Bob :has _:b1 :Bob :has _:b2} would still be semantically > > equivalent to {:Bob :has _:b3} and all of them are semantically entailed > > by {:Bob :has :something}, because each interpretation of :something is > > also a viable interpretation for _:b1, _:b2 and _:b3.) Indeed I was talking about comparing two graphs (i.e., logical equivalence of two formulas denoting the graphs). Semantic interpretation are trickier to describe, typically a semantics for nominal quantifiers assume we have an infinite set of atomic names which we can pick from, and that meaning is invariant under permutations of these names (i.e., names have no structure or discernable differences). [These semantic interpretations are not usually helpful, so it can be good to skip the model theory and look at the inference rules.] These kinds of interpretations are a little different from what you're describing, thus { :Bob :has _:b1 :Bob :has _:b2 } would not be equivalent to {:Bob :has _:b3}. Above, you pick up on a key distinction between nominals and existentials. Consider data: :Bob :has :something The above data would not be satisfied by the following query if nominals were used. ASK { :Bob :has _:b3 } However, that isn't as problematic as you might expect, since you would probably write the following query which is satisfied on the above data, where a variable interpreted existentially is used if you wanted the intended effect. ASK { :Bob :has ?x } Also, please see the example I shared with Pat to see how we might allow some co-reference (via owl:sameAs) without collapsing :Bob :has _:b1 :Bob :has _:b2 and :Bob :has _:b1. Question from Ross: > >> E.g., how many SPARQL 1.1 implementations answer no to the following > >> query on the following data: > >> Query: ASK { :Bob :has _:b2 :Bob :likes _:b3 } > >> Data: :Bob :has _:b1 :Bob :likes _:b1 > >> I'd be interested to know (but am out of time). Answer from Benjamin: > > I'm not really knowledgeable in SPARQL implementations, but according to > > the specification https://www.w3.org/TR/sparql11-query/#BGPsparql blank > > nodes in patterns can be mapped by instance mappings according to the > > semantics specification: https://www.w3.org/TR/rdf-mt/#definst > > > > And these can map (possibly non-injectively, many-to-one) blank nodes to > > blank nodes, IRIs and literals. > > > > Hence, implementations should answer yes to the query (because of the > > mapping _:b2 |-> _:b1 _:b3 |-> _:b1). I should perhaps have stated my question more clearly. I completely agree that is what the W3C standards say a SPARQL query implementation should do in this setting, hence e.g. Query A and Query B below are equivalent. Query A: ASK { :Bob :has _:b2 :Bob :likes _:b3 } Query B: ASK { :Bob :has :x :Bob :likes :y } The question I was getting at was more to do with the various real implementations of SPARQL. Are there implementations of SPARQL that are sensitive to these differences and say "no" to Query A on the data :Bob :has _:b1 :Bob :likes _:b1? In other words, is there an implementation of SPARQL where Query A and Query B are not equivalent? From Benjamin: > > Of course, we could create a new Nominal-SPARQL, where blank nodes can > > only be mapped one-to-one to blank nodes in the data. It's a purely > > syntactical decision to map less than the semantics would allow. This is what I had in mind and seems to fit Eric's view of SPARQL. From Jiří: > It seems nominal variables in RDF would complicate things even more than > they are now, but it might be useful for some things and got me a bit > curious. > For it to be useful as blank node replacement it would need to fulfill > the conditions Aidan brought up, or more precisely not break things if > locality is kept and existentiality is replaced by nominality, which I'm > not convinced of. Aidan explained it well: > > > (B) We could think about keeping locality and removing existentiality, > > but let's say we take two RDF graphs G1 and G2 parsed from the same > > Turtle document: > > > > ":abc :has ( a b c ) ." > > > > by two different parsers that generate different blank nodes to > > represent the list. If blank nodes are not existential, which is to say > > that if blank nodes denote a resource in a similar manner to IRIs, then > > we lose the formal relation between G1 and G2, even though they > > represent the same data; more specifically, we would consider that G1 > > associates :abc with one list, and that G2 associates :abc with a > > *potentially* different list. To me, this behaviour is undesirable. > > > > Under existential semantics, I can say that G1 and G2 are formally > > equivalent. If I union/merge G1 and G2, the existential semantics tells > > me that in the resulting graph, there exists one list, not that :abc > > potentially has two lists, allowing me to "lean" the graph and keep just > > one list (if I want). Under a nominal semantics G1 and G2 would also be formally equivalent. Under the W3C standard for RDF, if you merge the two graphs the blank nodes would be "standardized appart". The same would happen for nominals. Aidan's point looks more like an argument for not Skolemizing blank nodes and instead embracing them. From Jiří: > Consider that I parse a RDF file twice, producing two graphs... This scenario has been covered elsewhere in these threads. I believe the advice should be: please don't parse a graph twice, merge the instances and expect the resulting graph to be meaningful --- this applies equally to blank nodes whether they are treated nominally or existentially. You could however, parse the graph today, then parse the graph tomorrow and then compare the two graphs for equivalence or entailment to learn something about how the knowledge graph has evolved. Kind regards, Ross
Received on Sunday, 5 July 2020 14:06:30 UTC