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

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

Maybe this is a good place to end it too, I'm fine without going deeper 😂

But yeah that's a good way of putting it, an 'unpacked' representation of a
datatype. We could steal some fine-dining lingo and perhaps call it a
"deconstructed literal" as well 😂

Thanks for the discussion, it's been great.

Anthony


On Wed, Jul 8, 2020 at 10:29 PM Patrick J Hayes <phayes@ihmc.us> wrote:

>
>
> 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> wrote:
>
>>
>>
>> > On Jul 8, 2020, at 1:30 PM, Nicolas Chauvat <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> 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. 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 - services en informatique scientifique et gestion de
>> connaissances
>> >
>>
>>
>>
>