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

I support everything Nicolas is saying here, and the connection to lists
occurred to me too but I feared it would be another rabbit hole. I honestly
don't have the RDF chops to continue the discussion, but the inability to
describe composite values without using literal syntax feels like a hole.
That could just be my limited understanding of RDF though, and I don't know
if that's the case so I'll probably just leave it there for now. Nicolas
describes it much better anyway.

Anthony

On Thu, Jul 9, 2020 at 3:35 AM Nicolas Chauvat <nicolas.chauvat@logilab.fr>
wrote:

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