Re: Announcement: The "info" URI Scheme

On 2003-10-02 19:53, "ext Garret Wilson" <garret@globalmentor.com> wrote:

> Patrick Stickler wrote:
>> It seems to me that if the effort is taken to define the http: URI
>> equivalences, that it's then *less* work to just *use* the http: URIs
>> and simply not have to muck about with mappings.
>> 
>> So while the mapping approach is an interesting idea, it seems
>> to highlight IMO the needlessness of yet another specialized URI
>> scheme.
> 
> Let me apply this logic:
>
> 1. "If the effort is takent to define IP address URL equivalences (using
> a domain-name system), then it's *less* work to just *use* IP addresses
> and simply not have to muck about with mappings."
> 
> Moral: The HTTP URL system is distinct from a resource's physical
> location on a hard drive.

This is true, of course. Although it seems to me that the phrase
"less work" is subjective, and your assertion above doesn't seem
to take into account the work that will be involved in updating
references to IP URLs as servers move physically around subnetworks,
which certainly does make such use more burdensome in many ways
than when employing the indirection provided by DNS.

Indirection is a good thing, *if* it is provided for as needed.

Note that there really is no such thing as a non-resolvable URI.
Only a presently-non-resolvable URI. Or not resolvable by a
standardized, globally ubiquitous means.

Any URI can be deemed meaningful to a resolution protocol and
used to obtain representations/descriptions of the the thing
denoted. And no definition of a particular URI scheme can preclude
such usage (even if it tries).

Whether or not indirection is used is not the question here, but
rather, what is the cost of deploying a global solution for
resolving that indirection, and does there already exist a solution
that would do the job?

Why re-invent DNS if DNS does the job?
Why create a new URI scheme if http: does the job?

IMO, presuming that those minting info: URIs or using info: URIs
are never going to care about resolving those URIs to representations
and/or descriptions of the resources denoted by them is an error.

> 2. "If the effort is taken to define HTML CSS or XSL equivalences, then
> it's *less* work to just *use* <xhtml:i> for italics and <xhtml:b> for
> bold and simply not have to muck about with mappings."
> 
> Moral: The style of a document is distinct from its semantics.

Hmmm... Sorry. I don't see the relevance of this particular example.
Unless you're trying to suggest that some URIs would bear more specific
semantics than some other URI (which is false), as some markup bears
richer semantics than other markup (which is true).

???

> 3. "If the effort is taken to define a nation-wide ID system in the
> United States that matches SSN with date of birth, hair color, and
> physical address, that it's *less* work to just *use* date of birth,
> hair color, and physical address when filling out tax returns and simply
> not have to muck about with mappings."
> 
> Moral: The identity of a person is distinct from his or characteristics.
> 
> As #3 indicates, this is not just about having a unique URI,


I never thought this was about having a unique URI. I.e. a 1:1 mapping
from URIs to resources. The SW will have to deal with an N:1 mapping
from URIs to resources, and of course, OWL has specific machinery
to do so.

> as date of 
> birth, hair color, and physical address surely uniquely identifies
> 99.99% percent of the population. To my mind, saying "the blond person
> born in 1 January 1900 living at 1 Main Street" is different than
> saying, "the person with SSN 123-45-6789. What happens when that person
> moves? What happens when Main Street is torn down? I make the same
> distinction between "the language identified by the URI uri:lang:en_US"
> and "the language described by the resource at
> http://example.org/languages/en_us".

Sure, but I fail to see how this has anything to do with the
creation of a new URI scheme. Different folks can use different
URIs to denote the same resource (insofar as they all percieve
a common resource) without those different URIs having to be
of different schemes. Sure, they *could* be based on different
schemes, but wouldn't it be alot better to be able to do

MGET http://example.org/fred/dog HTTP/1.1
MGET http://example.org/mary/dog HTTP/1.1
MGET http://example.org/jane/dog HTTP/1.1

(sorry for not having more creative differing URIs)

to compare what Fred, Mary, and Jane agree or disagree about
presumably the same resource?

If Jane used info:.../dog or tag:.../dog then we'd remain in
the dark about what Jane has to say about that thing -- or we'd
have to use yet another bit of technology *just* for Jane's
knowledge.

IMO, using an http: URI to denote a resource does not mean that
that URI will or should resolve to a representation and/or
description, but that it might, and decisions about whether,
when, and what to say about a given resource are orthogonal
to decisions about what to call it.

Cheers,

Patrick

Received on Friday, 3 October 2003 06:05:16 UTC