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

I'm not sure where to post this because there are some subthreads and it's
hard to judge, if somebody would prefer that let me know, but it seems
relevant to bnodes so posting it here.

In one subthread ("Datatypes") Pat says:

I just wish we had allowed datatypes which used more than one character
> string, so that (for just one example that caused way too much hassle)
> language-tagged strings, but also things like latitude+longitude or number+
> unit (5 inches, 27 cm, 3.5 kg) could have been handled naturally. Right now
> it is not easy to say in RDF that the Thames is 215 miles long, and also
> that 215 miles is the very same thing as 346 km. But this kind of thing is
> ubiquitous.
>

So maybe, rather than a literal or a bnode, RDF could just incorporate some
JSON? Can put it all on one line like a literal or bnode, and can use
nesting too.

Example triples (I've removed string quotations etc. because this is just
rough pseudocode):

    france name {type: LanguageTaggedString, value: France, language:
English}
    place1 geoCoordinates {type: GeoCoordinates, latitude: 0.0, longitude:
0.0}
    thames length {type: QuantitativeValue, value: 346000, unitCode: MTR}
    uiElement shape {type: Circle, x: 0, y: 0, radius: 10}
    uiElement shape {type: Circle, center: {type: Point, x: 0, y: 0},
radius: 10}
    uiElement shape {type: Circle, center: {@id: point1}, radius: 10}
    event1 date {type: Date, year: 2020, month: 1, day: 1}

For multiple types you can just use type: [Type1, Type2] like in JSON-LD.

Regards
Anthony

On Thu, Jul 9, 2020 at 9:28 AM <phayes@ihmc.us> wrote:

>
>
> On Jul 9, 2020, at 5: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 ?
>
>
> Well, one motivation might be that in order to see
> https://allnumbers.org/17 as being a number, you have to get inside the
> URI syntax itself, whereas the literal actually tells you what kind of
> thing it is. Another might be that there isn’t any such URI as
> https://allnumbers.org/.
>
>
> That's probably in the RDF spec... let me check if I can find it.
>
>
> You won’t find much in the spec about motivation :-)
>
>
> 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.
>
>
> If you were inclined to do such unpacking in the first place, yes.
>
>
> So, "some" bnodes may have an "environment/subgraph" that makes them
> more interesting to skolemize than others when we want to refer to
> values ?
>
>
> Sure, if you are using a bnode that you know informally is actually
> referring to something unique and that might be of general interest, then
> coining a URI to name that thing seems like a useful thing to do. People
> have recommended that ALL bnodes be skolemized, in fact, eliminating bnodes
> altogether.
>
>
> 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 ?
>
>
> Asssuming that the unpacked version was properly formed, yes. Of course
> you have to know what conventions were being used for the unpacking: RDF
> doesn't specify that.
>
>
> 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 ?
>
>
> No, the definitions of datatypes are found by reading the various specs.
> You can’t /define/ the meaning of a datatype (or of a datayped literal, in
> fact) in RDF.
>
>
> 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.
>
>
> That's the end of it as far as literals are concerned.
>
> So any value in RDF has to be a literal
>
>
> No, of course not. Well, actually, I am not sure what you mean by a
> ‘value’. RDF names (URIs and literals) denote things. Is that what you mean
> by ‘value’? If not, then I am not following you. If so, then not all values
> are literals, or even literal values.
>
> and if one
> wants an immutable composite value
>
>
> Now I REALLY have no idea what you are talking about.
>
> , 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.
>
>
> I hope I never said that.
>
>
> 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)” ?
>
>
> As I understand TomP’s distinction, it is between bnodes that express a
> genuine existential claim (Harry has a wife) vs. bnodes that are really
> only a kind of structural link between triples (the ones used to be the
> intermediate tails of a long list.) That distinction does make sense, but
> AFAIK it has nothing to do with the OWA.
>
>
> 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 !
>
>
> Maybe I should not have said that. If you took it as meaning anything
> significant, then please let me withdraw the comment. RDF graphs themselves
> are ‘complex composite’ things, was the intended analogy.  But that is what
> they /are/, not what they /describe/.
>
> 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.
>
>
> The OWA doesn't allow anything to /change/ your coordinates, or indeed to
> say anything more about whatever your blank node means (because some other
> graph can't use your blank node, unless of course you skolemize it into a
> URI).
>
> 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.
>
>
> I think this analogy is flawed. The OWA is the assumption that more
> information can always be consistently added. That says nothing about
> structures being /changed/.
>
> 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 ?
>
>
> I have no idea what ‘mutable' means in the RDF context. There are no
> operations on lists (or on anything else) in RDF. The best that RDF can do
> with lists is describe them, the same way it describes anything else. That
> is all it can do.
>
> Sorry to repeat myself, but RDF is not a programmng language. It is not
> even remotely similar, in any way, to a programming language. It does not
> specify anything about any processes or actions. It has no interpreter or
> virtual machine. Ideas from the world of programming are alien to RDF and
> attemps to apply them to RDF are only likely to cause confusion.
>
> Was it a design goal of RDF not to
> include immutable data structures / composite values ? If so, would
> anybody here remember why ?
>
>
> To the best of my recollection, the topic never came up.
>
> Pat
>
>
> --
> Nicolas Chauvat
>
> logilab.fr - services en informatique scientifique et gestion de
> connaissances
>
>
>