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

RE : URI: Name or Network Location?

From: Neil McNaughton <info@oilit.com>
Date: Mon, 26 Jan 2004 12:52:05 +0100
To: <www-rdf-interest@w3.org>
Message-ID: <002301c3e402$d1f49340$0300a8c0@dell>

I know that this is 'the original dumb question' but could someone take a
step back from this tantalizing thread and explain what is at issue here -
without using the normal terminology which has so far obscured my
comprehension of the issues. Also what does 'dereference' mean, 

Neil McNaughton
Editor - Oil IT Journal

> -----Original Message-----
> From: www-rdf-interest-request@w3.org [mailto:www-rdf-interest-
> request@w3.org] On Behalf Of Hammond, Tony (ELSLON)
> Sent: Monday, January 26, 2004 12:33 PM
> To: 'Patrick Stickler'
> Cc: www-rdf-interest@w3.org
> Subject: RE: URI: Name or Network Location?
> > I simply can't fathom any real benefit to having a URI
> > which, by definition, cannot be used to access such knowledge.
> The reason is to keep the barrier to entry as low as possible. By
> explicitly
> excluding dereference we have devised a very simple, focussed registration
> mechanism which requires almost zero maintenance and is consistent across
> the whole INFO namespace with a predictable behaviour (i.e. disclosure of
> identity). This is a baseline service - think of it as something like the
> Model T.
> I agree that it would be useful to have resource representations sitting
> out
> there on some network endpoint - but that is just way too expensive for
> the
> namespaces we are interested in fostering. There are no (human) resources
> available to maintain such an undertaking. The conclusion is that we
> either
> go this zero-resolution route or we accept that many of these namespaces
> will continue not to be represented on the Web. Which means that we will
> continue to be frustrated by not being able to 'talk' about well-known
> public information assets in Web description technologies.
> Tony
Received on Monday, 26 January 2004 07:11:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:49 UTC