Re: Blank nodes semantics - nominal variables?

It seems nominal variables in RDF would complicate things even more then
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). 

Consider that I parse a RDF file twice, producing two graphs:

G1 { :abc :has [] }
G2 { :abc :has [] }

If I would query the union/merge of the graphs with the variables using
nominal instead of existential semantics using query:

ASK { :abc :has _:n1 . :abc :has _:n2 }

Wouldn't the result be true, same as with existential semantics?
This is a result not what you'd expect with nominal variables.
To avoid that you would probably have to either do some complicated
things for union/merge of graphs (keeping track of origin of graphs to
know the variables are one and the same) or get rid of the locality of
the variables, which is not without consequences Aidan explained:

> (A) We could think about removing locality, and make blank node global,
> but now in the context of (1), a parser has to take care of generating a
> term that is globally unique, which will require something like a "base
> IRI" and some non-trivial conventions regarding what to do when parsing
> something from the same base URI multiple times (also considering that
> the document might have changed). This would greatly complicate simply
> parsing an RDF document. 

Does that sound right or am I missing something?

J.

On 7/2/20 10:44 PM, Benjamin Braatz wrote:
> Hi List, Hi Ross.
> 
> On 02/07/2020 17:19, Ross Horne wrote:
>> Are you still working with SnT?
> 
> No, I'm out of academia since 2014 (and not actively working with RDF
> anymore, but at least with some notion of graphs).
> 
>>> For nominal variables, the variable assignment has to be
>>> injective/one-to-one, while for existential variables, it can be
>>> non-injective, can map multiple variables to the same thing.
>> The existence of a bijective map renaming blank node (names) is indeed
>> one property preserved by nominal quantifiers, yes. [side note: That
>> would be summed up by the "equivariance" property: nominal x. nominal
>> y.P(x, y)  iff  nominal y. nominal x.P(x, y). ]
> 
> 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.)
> 
>>> Does that make sense for RDF?
>>> Especially, since the semantics explicitly allows two IRIs to denote the
>>> same thing?
>>> This would surely impact the notions of Skolemization (where blank nodes
>>> are replaced by minted IRIs) and instance (where blank nodes are
>>> replaced by IRIs, literals or blank nodes) in the RDF standards.
>> I don't see anything that would break, since you could also Skolmise
>> nominal variables (something similar is done inside several
>> verification frameworks that use nominal quantifiers to reason about
>> data containing names). Maybe you could give an example of something
>> that might break...
> 
> The misunderstanding was that I thought nominal blank nodes would also
> have to have distinct semantic interpretations (which is not the case
> for IRIs and especially Skolemized IRIs).
> 
> If the distinctness is not a semantics/interpretation thing, then there
> is probably no problem.
> 
>>> Diallowing two IRIs to denote the identical thing, would not fit at all
>>> with the open world assumption, in my opinion. So, we would probably
>>> lose Skolemization and instances if blank nodes were nominally
>>> quantified, since IRIs would then behave very differently from these
>>> nominal blank nodes.
>> Two blank nodes can still represent identical things, as you can
>> already achieve in RDF, that's not what my examples demonstrated.
>> E.g., you can still use owl:sameAs and build in a semantics for such
>> vocabularies. Two blank nodes are just not syntactically equal in the
>> same document, which is exactly what we want in RDF.
> 
> They are also not syntactically equal in the current RDF standards. The
> standards just express (through the notion of "lean graph"), when two
> blank nodes can be merged without changing something w.r.t. semantics,
> possible interpretations (and through the notion of "instance", one
> situation where a graph semantically entails another graph).
> 
>>> As an additional possibility, they could be useful, but explaining two
>>> different kinds of blank nodes/variables through the whole syntax and
>>> semantics could also be very cumbersome.
>> Why two approaches? Just have one (blank nodes are names). The mixing
>> I was illustrating previously was in the query languages, e.g., SPARQL
>> queries asking for a pattern containing a blank node in one place and
>> a variable (which must be existential) in another place. My feeling is
>> that this is really close to what SPARQL already does.
>>
>> 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).
> 
> 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).
> 
> In fact, they should even answer yes for:
> Data: :Bob :has :something  :Bob :likes :something
> (because of the mapping _:b2 |-> :something _:b3 |-> :something)
> 
> 
> 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.
> 
> Kind regards,
> Benjamin
>