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

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

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