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

Hi List,

I know this thread is coming to an end, please bear with me while I
try to be sure of what to conclude from it before I let it rest in
peace.

On Thu, Jul 09, 2020 at 12:29:29AM -0500, Patrick J Hayes wrote:

> 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.

What motivates using "17"^xsd:integer instead of https://allnumbers.org/17
or "Trump"^xsd:string instead of https://allstring.org/Trump ?

That's probably in the RDF spec... let me check if I can find it.

> 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.

I find this last sentence important. You are saying that for other
graphs to refer to the same "value", it would make sense to skolemize
the bnode that came out of the unpacking of a literal datatype.

So, "some" bnodes may have an "environment/subgraph" that makes them
more interesting to skolemize than others when we want to refer to
values ?

> 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.

But one could define a pair of functions such that the first one turns
the bnode/unpacked representation to the string/literal/packed one and
the second one turns the string/literal/packed representation to the
bnode/unpacked one, no ?

I understand that literals are not that kind of syntactic sugar as of
today, but the whole thread started from discussing evolutions to RDF
and whether bnodes should die or not and what they are good for...

> 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.

Does it mean that the second function of the pair I mention above is
the datatype definition ?

> > > 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 ?
> > 
> > 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.

I stand reassured :)

> 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.

To summarize, if I understand correctly, the RDF spec says that there
are literals and that these literals can have a datatype... and that's
the end of it. So any value in RDF has to be a literal and if one
wants an immutable composite value, one has to define a datatype and a
pair of packing/unpacking functions that applications will use to
access what is encoded in that literal.

But what if we had "open-world" blank nodes that are "anonymous URI
(apologies for the oxymoron)" and "closed-world" blank nodes that are
good candidates for skolemization and a perfect fit to "cram data
structures into RDF (as TomP said)" ?

In another email PatHayes said "think of RDF as JSON with semantics",
but in JSON, using a tree of dicts and lists, it is super easy to have
a complex composite value ! I fail to see how to do the same in RDF,
because assuming I use a blank node to group together the two
coordinates of my point, it entails from the OWA that this blank node
can be "extended" and that my pair of coordinates is not immutable.

Not all of you may like the programming language comparison, but in
Python, you could define a list [1,2] that can be extended an a tuple
(1,2) that is immutable (same goes for sets and frozensets, dicts and
frozendicts, etc). One could think of the former as an open-world
version and the latter a closed-world version. It follows that lists
can not be used as keys in mappings, but tuples can (the hashing
algorithm works for immutable tuples, but not for mutable lists).

There are lists in RDF, but there is no such thing as an immutable
list (or tuple) in RDF, right ? Was it a design goal of RDF not to
include immutable data structures / composite values ? If so, would
anybody here remember why ?

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances

Received on Thursday, 9 July 2020 10:35:31 UTC