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

And while we're at it, let's add optional time and space, and maybe ID,
positions to every statement, like what's done in YAGO (
https://www.mpi-inf.mpg.de/departments/databases-and-information-systems/research/yago-naga/yago
).

Then you can say other ubiquitously said things like:

    id:1 donaldTrump spouse ivanaTrump startTime:1977 endTime:1992
    id:2 cars driveOn right location:unitedStates

Regards
Anthony

On Sun, Jul 12, 2020 at 8:28 AM Anthony Moretti <anthony.moretti@gmail.com>
wrote:

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