W3C home > Mailing lists > Public > semantic-web@w3.org > March 2011

Re: {Disarmed} Re: blank nodes (once again)

From: Michael Brunnbauer <brunni@netestate.de>
Date: Sat, 26 Mar 2011 16:38:07 +0100
To: Pat Hayes <phayes@ihmc.us>
Cc: Dieter Fensel <dieter.fensel@sti2.at>, semantic-web@w3.org
Message-ID: <20110326153807.GA25941@netestate.de>

re

On Fri, Mar 25, 2011 at 04:13:43PM +0100, Michael Brunnbauer wrote:
> Some applications store a list of URIs for a given thing so that all the
> reasoning does not have to be done over and over. These applications
> will have to handle much bigger lists with bnode URIs and will have to start
> their reasoning "from scratch" from time to time in order to prevent those
> lists from growing and growing.

Hmm. There is the option of treating the bnode URIs like old style bnodes
in order to avoid this problem. And application writers who do not care that
the bnode URIs may be invalid after the next reload of the RDF document they
came from can use them like real URIs.

> I do have not much experience with general purpose reasoners but if a thing
> has 100 URIs and a general purpose reasoner discovers this, will it not store
> all triples for that thing 100 times with all 100 different URIs ?

This applies to old style bnodes also so both my arguments are not really
persuasive.

I still feel uneasy about declaring all old documents with bnodes invalid
and making it harder to produce RDF.

And I plead the RDF specs should discourage the use of bnodes (skolemized or
not) in favor of real URIs.

Regards,

Michael Brunnbauer

-- 
++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail brunni@netestate.de
++  http://www.netestate.de/
++
++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
++  USt-IdNr. DE221033342
++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Received on Saturday, 26 March 2011 15:38:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:24 UTC