Re: Blank nodes must DIE! [ was Re: Blank nodes semantics - existential variables?]

> On Jul 8, 2020, at 4:15 PM, Thomas Passin <tpassin@tompassin.net> wrote:
> 
> On 7/8/2020 2:30 PM, Nicolas Chauvat wrote:
>> On Wed, Jul 08, 2020 at 11:54:16AM -0400, Thomas Passin wrote:
>>> Here's what I am thinking of, and I'll talk about points, since that was the
>>> ...
>>> Or put another way, just because the same literal value is assigned to two
>>> nodes does not make them the same.  Is that literal value itself the "same"
>>> for both?  In some software it might be - if it's been memoized, for example
>>> - but that's normally an implementation detail, not something fundamental.
>> When I say that (1,2) is a true value, aka an immutable struct, your
>> answer is that two (1,2) values are not the same because, taking into
>> account the open world assumption, they could have a third dimension
>> (or some other attribute).
>> You write "the same literal value is assigned to two nodes, does not
>> make them the same".  Is it correct to rephrase that as follows ?
>>   p1 has_coords (1,2)
>>   p2 has_coords (1,2)
>> In that case I agree that nothing proves p1 and p2 are the same.
>> But what I am pointing at when I talk about an immutable struct is not
>> the above.
>> A better comparison would be "2002-05-30T09:00:00"^xsd:datetime, that
>> could be deserialized to (year: 2002, month: 5, day: 30, hour: 9,
>> minutes: 0, seconds: 0).
>> Would you say that the two literals
>> "1;2"^<http://mydomain.com/mytypes/tuple-of-two-integers> and
>> "1;2"^<http://mydomain.com/mytypes/tuple-of-two-integers> are
>> different things ?
>> Does it follow from the open world assumption that
>> "2002-05-30"^xsd:date and "2002-05-30"^xsd:date are different values
>> because one could append the time information and write
>> "2002-05-30T09:00:00"^xsd:datetime ?
>> I would think that the open world assumption applies to nodes, not to
>> values/literals. Am I missing something ?
> 
> Not exactly, but I'm saying it's not usually of much importance to say that the two literals are "the same" or not.  They aren't identifying anything

They most certainly are. They are the only things in RDF which have a unique, fixed meaning. “17”^^xsd:integer /always/ refers to – identifies, denotes, names, has as value – the number seventeen. 

> , and very few literals except for URIs used as unique identifiers can do so.  It's really in the same league as whether the integer "2" in a given programming language is implemented as a singleton object or not (I understand that it is in Python).  It's much like an implementation detail.

There isn’t anything like ‘being implemented’ in RDF. The RDF literal does not get ‘implemented’ as some binary construct in memory. It is simply a /name/ for the /number/ (or string, or date, or whatever the datatye says it refers to). There isn’t any underlying implementation for RDF to compile into, no virtual machine for it to run on. So…

> Where the question could have some interest is if a particular literal could have a canonical and a non-canonical form

…that question is meaningless. Literals wear their form on their sleeve, so to speak. They are what they seem to be, no need for canonicalization. 

> ;  Now the question of whether they are "identical" might have some significance.  That might come up in encryption, for example.  But in these cases we're talking about two literal forms that are not, on their face, identical, but that might resolve to the same canonical value.

What does ‘resolve’ mean in this RDF context? I know about several kinds of useful operations on RDF graphs, but I haven't come across this one. 

Pat

> 
> TomP