W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2002

Re: what RDF is not (was ...)

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Fri, 04 Jan 2002 11:34:57 -0500
To: distobj@acm.org
Cc: msabin@interx.com, www-rdf-interest@w3.org
Message-Id: <20020104113457Y.pfps@research.bell-labs.com>
From: Mark Baker <distobj@acm.org>
Subject: Re: what RDF is not (was ...)
Date: Fri, 4 Jan 2002 11:07:44 -0500 (EST)


> Hmm, I can tell below that are you making an invalid assumption.  You
> are assuming that we're restricted to identifying reals with a URI
> structure such as;
>   http://math.org/number/[put some expansion of number here]
> That's not the case at all.

I'm not making this assumption at all.  I'll allow you any effective way of
determining the denotation of a URI.  

> [snip]
> > This real number is different from all the real numbers represented by
> > URIs.
> Ok, so I'll identify it as;
> http://example.org/numbers/real/peters-example-real
> MB

Actually http://example.org/numbers/real/peters-example-real doesn't refer
to a number.  

But let's fix that by adding a new URI scheme, say foo.  The meaning of
foo:<string> is go to the web page identified by <string> and determine the
real number refered to there, if possible.

Now suppose that we allow the determination above to include things like
the scheme that I described in my message.  So
should refer to real number.

What number is this?  In particular what is the nth element of its decimal
expansion, where n is the ordinal of
in the ordering of URIs?

If this element is 1 then it has to be 2, so it can't be 1.
But if it is not 1, then it has to be 1, so it has to be 1.
Either we have just created an inconsistent system, or we have to admit
does not refer to a real number.

The moral of this story is that finite systems can only do so much.
Efforts to make them do more cause them to collapse.


PS:  This sort of argument has played out in several other arenas.
Received on Friday, 4 January 2002 11:35:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:33 UTC