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

> On Jul 8, 2020, at 9:01 PM, Anthony Moretti <anthony.moretti@gmail.com> wrote:
> 
> Hi Patrick
> 
> Thank you for the time granted in answering my questions. I'll try to keep it focused and work on the fire management with you 😂

:-)

> 
> there is nothing corresponding to the ‘reference’ case
> 
> If I were to merge two graphs, both containing URLs and bnodes, I'd retain the URLs, but I'd create new bnode IDs (to avoid potential problems if the graphs happened to use some bnode IDs that were the same). So maybe it's just my terminology, but the retaining of original identifiers, the URLs in this case, is the reference case.

OK, but I find this very strange. If I were to read several news articles which all use the name “Trump” and I were to write a summary using the same name in the same way, am I using reference semantics? Seems to me that I am just using language in the normal way, where names are understood to refer to things, and that this has nothing at all to do with any reference/value distinction, because we aren't talking about data structures. English simply doesn’t have the reference/value distinction. 

> How do you ever know when you have all the necessary properties? 
> 
> Yeah, that's the problem being discussed earlier in the thread about type-dependent comparison operations for value types, and David's discussion about keys.
> 
> you might want to assign a URI to a literal value ... it shouldn't be illegal
> 
> Agree, it shouldn't be illegal.
> 
> Blank nodes don't have types.
> 
> When I say blank nodes have a type I'm being sloppy, sorry. I mean the things they refer to, of course.
> 
> If this were RDF, what would this distinction (between class and datatype) /mean/?
> 
> Something being an instance of a datatype would be an instruction to not rely on the identifier to find equivalents, but to (somehow) look up prescribed comparison operations for that type. 

What do “equivalents” and “comparison operators” mean? Neither of these seem to have any meaning in RDF. 

> It'd also be an instruction that those instances are better off not being skolemized and should be passed along to the next consumer as is.

Not skolemized, so we are talking about bnodes... 

> It'd basically be an instruction to treat the individual like a literal when trying to reason about the graph.

…and it still seems slightly crazy to me to treat a bnode like a literal, or vice versa. 

But that, as I recall, is where we started this thread.

OK, let me ignore the whole reference/value thing and the (bad) analogy to Swift. What /does/ make sense in RDF is the idea of ‘unpacking’ a datatype into a collection of properties, then tying these together into a bundle of triples all fixing the properties of something (written typically as a bnode tying these triples together by acting as the common subject). Then anything we wanted to say using the literal can be done (at least in tha same graph) by using the bnode instead. In fact, it would make sense to skolemize this, if the data is important, because then other graphs can refer to the same value.

Yes this is kind of possible. But it would be a mistake to think that literals as currently defined in some sense /already are/ just syntactic sugar for this kind of ‘unpacked’ representation. 

BTW, for straighforward datatypes like the xml schema, which all relate a value to a string, it occurs to me that you could do this by using the datatype name as an RDF property. So instead of, say, 

ex:Pat ex:age “75”^^xsd:integer .

you might have

ex:Pat ex:age _:x .
_:x xsd:integer “75” .

where the “75” is now type xsd:string. This makes a kind of intuitive sense since datatypes are required to define a mapping from strings to values, and we have used the datatype name in exactly that way. (It would make even more sense if RDF allowed literals to be subjects, so we could write it the other way round.) 
And since it is all in one triple, the issue, about how we know when we have enough proprties, vanishes. 

(Note, this is NOT standard or an accepted RDF convention, so use it at your own risk!)

Hope this helps.

Pat

> 
> Regards
> Anthony
> 
> On Wed, Jul 8, 2020 at 6:46 PM Patrick J Hayes <phayes@ihmc.us <mailto:phayes@ihmc.us>> wrote:
> 
> 
> > On Jul 8, 2020, at 1:30 PM, Nicolas Chauvat <nicolas.chauvat@logilab.fr <mailto:nicolas.chauvat@logilab.fr>> 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”.
> 
> Um.. with one plausible interpretation, that is wrong. (RDF does not have the notions of ‘assignment’, and ’same’ is ambiguous, but ploughing ahead…) Lets use owl:sameAs to attach a literal value to a URI:
> 
> ex:this owl:sameAs “17”^^xsd:integer .
> ex:that owl:sameAs “17”^^xsd:integer .
> 
> and now ask, are this and that the same?:
> 
> ex:this owl:sameAs ex:that . ??
> 
> and the answer is always, Yes. This is entailed by the first two triples. Of course they are not the same URI, but they have the same denotation (value).
> 
> >  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.
> 
> True.
> > 
> > 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 <http://mydomain.com/mytypes/tuple-of-two-integers>> and
> > "1;2"^<http://mydomain.com/mytypes/tuple-of-two-integers <http://mydomain.com/mytypes/tuple-of-two-integers>> are
> > different things ?
> 
> Better not say that, as it would be flat wrong :-)
> > 
> > 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 ?
> 
> No. It has absolutely nothing to do with the OWA. Adding more information to an RDF graph cannot change the meaning of a literal, whether the world is open or closed. The meanings of literals are defined externally to the RDF spec, by the specs for the datatype of the literal. So whatever the RDF graph says about those literals, their value does not change.
> 
> Pat
> 
> > 
> > I would think that the open world assumption applies to nodes, not to
> > values/literals. Am I missing something ?
> > 
> > -- 
> > Nicolas Chauvat
> > 
> > logilab.fr <http://logilab.fr/> - services en informatique scientifique et gestion de connaissances  
> > 
> 
>