W3C home > Mailing lists > Public > www-tag@w3.org > October 2004

RE: referendum on httpRange-14 (was RE: "information resource")

From: <Patrick.Stickler@nokia.com>
Date: Wed, 27 Oct 2004 17:17:42 +0300
Message-ID: <1E4A0AC134884349A21955574A90A7A50ADD68@trebe051.ntc.nokia.com>
To: <len.bullard@intergraph.com>
Cc: <www-tag@w3.org>

> -----Original Message-----
> From: ext Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
> Sent: 27 October, 2004 16:49
> To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: www-tag@w3.org
> Subject: RE: referendum on httpRange-14 (was RE: "information 
> resource")
> I'm not sure it's useful either.  It's just that when one 
> factors the definitions, URIs are the only solid bits.  
> Everything else is 'turtles all the way up'. 
> That means the web isn't an information space.  
> It's a name space of opaque identities.
> len

I don't think the web is 'turtles all the way up'. 

The hypertext web itself is very concrete. You have a URI, you
dereference that URI, and either you get a representation, comprised
of an explicit stream of bits, or you don't.

Thus, both the URIs and the representations they resolve to are
both comprised of "solid bits". 

The hypertext web is a finite set of interlinked representations, which,
at some abstract level, reflect a set of interrelated resources
which we presume to reflect the conceptual focus of those representations;
though the web machinery cannot actually tell you what the conceptual focus of
any given representation actually is.

To date, that conceptual focus is conveyed by social conventions, and
need not even be clear or known in order to benefit from consistent
representation. Whether anyone knows what some URI actually identifies,
they can still use, share, and benefit from links employing that URI;
because the information they obtain via that URI is consistent and
useful. To know what the URI actually identifies, and what that nature
of that identified resource is, they have to ask the owner/creator of
that URI (or someone else who might know and whom they trust).

In time, the semantic web will be used to facilitate more precise
communication about the conceptual focus of each particular URI,
but even then, the web itself will hum along indifferently, dealing only
with the concrete bits of URIs and representations and providing
access to representations via URIs.

Thus, insofar as the identity and nature of resources are concerned,
it may indeed seem like its turtles all the way up, but fortunately,
for the concrete bits of URIs and representations, and getting from
URI to representation, it's not turtles all the way down.

(just one turtle, or maybe a few turtles worth of redirections ;-)

At least, that's how I see it...   



> From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com]
> It's an odd thing to do, but I don't see why you can't have e.g.
>    <http://example.com/blargh> owl:sameAs
> "http://example.com/foo"^^xsd:anyURI .
> Thus, <http://example.com/blargh> identifies the specific
> URI "http://example.com.foo". Note that the above statement is not
> the same as
>    <http://example.com/blargh> owl:sameAs <http://example.com/foo> .
> I.e. in the first case, <http://example.com/blargh> is identifying the
> URI, the string conforming to the lexical constraints for URIs, and
> is not (necessarily) identifying what the URI "http://example.com/foo"
> itself identifies.
> --
> How having one URI identify another URI would be useful is 
> unclear to me.
> But in principle, a URI is a thing, and if a URI can identify 
> anything,
> then one URI can certainly identify another URI.
> And having an RDF description of <http://example.com/blargh> available
> allows one to clarify that it identifies a URI, which is quite clear
> from the first RDF statement above.
> Patrick
> > From: ext Bullard, Claude L (Len) 
> Sent: 26 October, 2004 22:49 
> A mad thought:  if URIs identify resources (not representations), 
> and resources are abstract, do URIs only (put verb here) 
> other URIs?
Received on Wednesday, 27 October 2004 14:18:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:06 UTC