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

In this specific case it could be rdf:type time:DateTimeDescription from OWL-Time.
See https://www.w3.org/TR/owl-time/#time-position


From: Patrick J Hayes <phayes@ihmc.us>
Sent: Wednesday, 8 July, 2020 09:20
To: Anthony Moretti <anthony.moretti@gmail.com>
Cc: thomas lörtsch <tl@rat.io>; Dieter Fensel <dieter.fensel@sti2.at>; Hugh Glaser <hugh@glasers.org>; Semantic Web <semantic-web@w3.org>; MindLab <mindlab@lists.sti2.at>
Subject: Re: Blank nodes must DIE! [ was Re: Blank nodes semantics - existential variables?]




On Jul 7, 2020, at 5:54 PM, Anthony Moretti <anthony.moretti@gmail.com<mailto:anthony.moretti@gmail.com>> wrote:

Hmm, not to me they don’t. Blank nodes are basically anonymous variables. LIterals are names with a /fixed/ denotation, a meaning fixed by external constraints, like a proper name.

And what about just for the subset of blank nodes whose type is an rdfs:Datatype, such as the example?

Well, I would be inclined to just always use literals as literals, rather than as codes for a subgraph with a bnode. But if that were in the graph then I would say, treat the bnode like any other bnode. Nothing will break if you do.


Why put a blank node in there?

Yeah I agree, there's absolutely no need for an identifier, its properties are sufficient, and any processing should ignore the ID. I put it in for completeness though because it's the only way I know to say something like flight123 hasArrivalTime _:dateTime1 without using the dateTime literal.

I must be missing something in this conversation. Why not use the literal? That is what literals are for, after all.

Pat



Anthony


On Tue, Jul 7, 2020 at 2:47 PM Patrick J Hayes <phayes@ihmc.us<mailto:phayes@ihmc.us>> wrote:



On Jul 7, 2020, at 1:47 PM, Anthony Moretti <anthony.moretti@gmail.com<mailto:anthony.moretti@gmail.com>> wrote:

Very interesting reading, Pat. Pushing my knowledge a bit here, but should literals also become a subset of the graffiti of S, and not just blank nodes? (Slide 21<https://image.slidesharecdn.com/iswc2009pathayes-091028162812-phpapp01/95/blogic-iswc-2009-invited-talk-21-728.jpg?cb=1256747359>)

Literals seem like syntactic sugar for blank nodes,

Hmm, not to me they don’t. Blank nodes are basically anonymous variables. LIterals are names with a /fixed/ denotation, a meaning fixed by external constraints, like a proper name.


so whatever applies to blank nodes seems like it should apply to literals too, for example:

    "2020-01-01T00:00:00"^^xsd:dateTime

The literal seems to only exist as a convenient way of writing:

    _:dateTime1
    type: xsd:dateTime
    year: 2020
    month: 01
    day: 01
    hour: 00
    minute: 00
    second: 00

Why put a blank node in there? This is like saying “Something which is midnight on 1 january 2020” instead of “midnight on 1 january 2020”. I mean, you CAN always do this, but the longer form doesn’t gain you anything and since the description uniquely specifies what you are talking about, it doesn’t add anything new.

Pat



In Swift, you write code the normal way using Int and Float etc., but behind the scenes and hidden from users they're actually implemented as structures. So one could alternatively argue that literals must die (joking).

Regards
Anthony


On Tue, Jul 7, 2020 at 2:41 AM thomas lörtsch <tl@rat.io<mailto:tl@rat.io>> wrote:


> On 7. Jul 2020, at 05:22, Patrick J Hayes <phayes@ihmc.us<mailto:phayes@ihmc.us>> wrote:
>
>
>
>> On Jul 6, 2020, at 3:44 PM, Dieter Fensel <dieter.fensel@sti2.at<mailto:dieter.fensel@sti2.at>> wrote:
>>
>> Hi Hugh,
>>
>> yes I agree and thanks for the pointer which we will check carefully. Actually we could enfore some strong recommendations for future information items in the distributed sources but why should you waste your time when you can hid the issue behind same-as. Full agreement! My point was more:
>>
>> - we started to define a framework for finding "nice" URIs for touristic information coming from heterogeneous sources (events, accommodations, trails, PoI, restaurants, etc.). Close to the end of our exercise we realized that what we are actually doing is just a special case of duplication detection, entity resolution, etc., etc., etc., etc. We even started to wonder whether we really need these "nice" URIs or better just describe entities by their properties and use a strange blank note as an "identifier". The first time after more than 20 years (also through the help of Andreas who was eating my ears on this issue) I started to understand why some nurts are so dedicated about them.
>
> Nurts? Did you mean nurds, or is this a new word? I hope so, because it is a wonderful word, with echoes of nut, nurd, hurt and snort. Congratulations.
>
>> In the end what is better, a random number as identifier or the magic of an existential variable.
>
> Or Q<number> which Denny likes to use in Wikidata.
>
>>
>> - Especially the comment of Dan on global scale skolems made me a bit worrying, too. We seem to try very hard to turn the duplication detection, entity resolution, etc., etc., etc. problem to its full potential and we somehow would seem to try to give names to formulae and sets of entities. Now I know that for FOL even Aidans' super power approach would not work (or say semi-work). For a simple logic as RDF it may; but still? [1]
>>
>> So summarizing blank notes in a nutshell: I hope very much that they are not just another rdf:typo. What I mean: Would it not be nice to have RDF as a simple data model and RDFS etc. as a first simple logical languages on top of them? Maybe much too late and also wrong, however, can we ignore the rumour on the street that steadily (!) pops up quite visible on this slightly magic stuff.
>
> Let me recommend (re?) reading my ISWC 2009 invited talk. If we provide (1) a clear way to indicate bnode scopes and (2) negation to RDF, it is already FOL. We can do both with one single, simple extension to the syntax (and a small modification ot the semantics, routine stuff). Then we don't need all these new languages in 100 different syntaxes all “on top” of RDF. This leapfrogs OWL expressivity, and one could always provide OWL-Manchester-like macros, or some other “intuitive” notation (maybe defined using SHACL?) to keep the poor users from being burnt to death (or is turned into salt?) by the sight of actual logic.
>
> Best
>
> Pat
>
> https://www.slideshare.net/PatHayes/blogic-iswc-2009-invited-talk. especially starting at slide 15

Also available on videolectures.net<http://videolectures.net/>:
http://videolectures.net/iswc09_hayes_blogic/

7013 views already!

>>
>> Greetings,
>>
>> Dieter
>>
>> [1] Btw, I would not mind if I get harshly corrected as I talk alongside the boundaries of my knowledge.
>>
>> On 05.07.2020 23:16, Hugh Glaser wrote:
>>> Hi Dieter.
>>>
>>> That sounds very like the sort of thing that we use sameAs services for.
>>> In particular, if you don't bring the data into one store, you can't do "normalisation" without writing stuff back into multiple sources stores.
>>> I guess you are bringing the data into one store, so you can use normative URIs.
>>>
>>> If not, a while ago we spent a while building an Open Source sameAs Lite service (including a lot of benchmarks to optimise the table structure.)
>>> It's at https://github.com/seme4/sameas-lite

>>> The Github structure seems to have degraded a little since then but I'm sure would be serviceable if you found it useful - we'd be happy to help.
>>>
>>> Even if you are managing URIs, you might find this way of managing them has benefits.
>>>
>>> Best
>>> Hugh
>>>
>>>> On 5 Jul 2020, at 15:37, Dieter Fensel <dieter.fensel@sti2.at<mailto:dieter.fensel@sti2.at>> wrote:
>>>>
>>>> Thanks for the pointer. We may use this work in a project where we try to normalize URIs for a German Tourstic Knowledge Graph. There may be different URIs from different sources and we normalise these and give them a normative URl from established data sources on the web if possible (sorry in German [1]). Otherwise we some randomly generated IDs. Your work also may have relations to ID generation like studies in the OCCAM project or general in the IoT field (as Dan indirectly points out).
>>>>
>>>> [1]
>>>>
>>> ...
>>>> --
>>>> Dieter Fensel
>>>> Chair STI Innsbruck
>>>> University of Innsbruck, Austria
>>>> www.sti-innsbruck.at/<http://www.sti-innsbruck.at/>
>>>> tel +43-664 3964684
>>>>
>>>>
>> --
>> Dieter Fensel
>> Chair STI Innsbruck
>> University of Innsbruck, Austria
>> www.sti-innsbruck.at/<http://www.sti-innsbruck.at/>
>> tel +43-664 3964684