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

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

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.

Anthony


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

>
>
> On Jul 7, 2020, at 1:47 PM, Anthony Moretti <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> wrote:
>
>>
>>
>> > On 7. Jul 2020, at 05:22, Patrick J Hayes <phayes@ihmc.us> wrote:
>> >
>> >
>> >
>> >> On Jul 6, 2020, at 3:44 PM, Dieter Fensel <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/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>
>> 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/
>> >>>> tel +43-664 3964684
>> >>>>
>> >>>>
>> >> --
>> >> Dieter Fensel
>> >> Chair STI Innsbruck
>> >> University of Innsbruck, Austria
>> >> www.sti-innsbruck.at/
>> >> tel +43-664 3964684
>>
>>
>>
>