Kingsley Idehen wrote:
> Every URL is a LINK to an Information Resource, so it is always an
> Information (data in context) link. Basically, a file hosted at the
> Address conveyed by the URL.
>
>
Being careful, a Resource can be a "file", in the sense of a fixed
passive information set that is more-or-less blindly returned by the
HTTP server. A URL can also locate a service, which is a also a
Resource, and what Information is accessible thru that service may
depend on what request you make of it. (01)
> A generic HTTP URI isn't the same thing as a URL. It possesses a
> powerful Identity / Address (Access) duality that comes into play when
> you seek to Refer-to something (Identity) or Access its Description
> (Access via Address) in a representation of your choosing (typically via
> HTTP's content negotiation).
>
And here we have the jumping off point for an endless debate. Trying to
put Identity and Location in the same bucket creates many more problems
than it solves. IETF RFC 2396 (URI) specifies that a URI is an
Identifier, not a Locator, but some subtypes of URI may be Locators or
have some known standard transformation to Locators. Unfortunately, we
have reached a state of the practice in which even a URI beginning
"http:" is not necessarily a Locator. There are two common reasons for
this:
- effective role: its value as a commonly used Identifier becomes
more important than its continuing validity as a Locator (organizational
names and registrations change, but the Resource in question and the
need for a standard identifier is preserved).
- ignorance/lazinees: the websmiths didn't know that URIs beginning
"http:" are always expected to be Locators, or didn't go to the effort
of acquiring another category of URI, or didn't know there were any, or
didn't know how. (And enough occurrences on the Internet justifies this
as de facto practice, RFC 2616 (HTTP) notwithstanding.) (02)
The great vision that has not yet come to pass is that super DNS-like
servers will field arbitrary URIs and know how to convert them to valid
URLs. 30 years after inception, the state of the practice is that DNS
are just barely able to keep up with the explosion of valid URLs.
Success brings its own headaches. (03)
-Ed (04)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (05)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (06)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (07)
|