Re: New question: distinguished status of http:?

On 2002-02-19 19:43, "ext Graham Klyne" <GK@NineByNine.org> wrote:

> I think I get a glimpse of what you're saying ... that in some cases you
> need to be able to take a given scheme of URI and know a method to resolve
> it.  In other cases, some indirection may be required or appropriate.

Right. I see there being three basic "flavors" of URIs: names,
locations, and primitives; with the latter divided further
into terms and values.

Names are just that -- names. They are independent of location or
representational veriability, and always consistently denote the
same resource. They may denote abstract, concrete, digital, and
web-accessible resources. They may or may not serve as a means of
indirection for retrieving/accessing a web-accessible resource. If
that resource is web-accessible and you wish to access a representation
of that named resource, you must determine its location(s). The urn: URI
scheme is a good example of a name URI scheme.

Locations are just that -- points of access. They may host a given
resource or provide access to some representation of a resource, but
they don't name the resource obtained by dereferncing them. They name a
location. The location itself is the resource. Any mnemonic relation between
the name of the location and the nature of the resource accessible there is
not manditory, simply useful for humans. The http: URI scheme is the epitome
of a location URI scheme.

Primitives are resources. They do not involve any indirection or
dereferencing. They are to be taken at face value. Primitive URIs
are WYSIWIG URIs.

Terms provide for globally unique vocabularies. Knowledge may be
defined for terms, describing their semantics, use, etc. but they
do not provide any indirection nor resolve to any other resource.
They are the resource. The voc: URI scheme is an example of a term
URI scheme (http://ietf.org/internet-drafts/draft-pstickler-voc-00.txt)

Values are static, URI encoded, lexical representations of a specific
resource. They don't name a resource. They don't state where a
resource is located. They fully embody the resource. The data: URI scheme
is an example of a value URI scheme.

Insofar as dereferencing is concerned, locations always should be
dereferencable, as that is their very purpose of existence. Primitives
never dereference, as they are self-contained and do not provide
any indirection. Names are the only class which (a) may or may not
denote a (potentially) web-accessible resource, and (b) may or may not
have any location associated

Thus, names are the only class of URI which require per-instance
metadata. For all other URI classes, it should be consistently
clear if the URI is dereferencable or not, or whether it constitutes
the actual self-contained resource.

For a URN, you must check (a) if it denotes a web-accessible resource
and (b) if that resource is actually retrievable.

Note that a 404 error will not differentiate between these two
questions. If you get a 404 error, you cannot know whether the
resource is not intended to be web-accessible or an actual access
error occured.

So the simple picture for an application is:
- If the URI is a primitive, use it as-is.
- If the URI is a location URI, dereference it.
- If the URI is a name, check if there are any locations
  associated with it, and if so, choose one and dereference it.

Now, an application cannot make such decisions about URIs if it
doesn't know which URI schemes are locations, names or primitives,
and in the case of names, without a mechanism for checking for
locations defined for a given name.

The first problem is addressed by a *formal* taxonomy of URI
classes with explicit semantics as defined above, such that
for any URI, it is clear whether it is a location, a name,
or a primitive; and in the latter case whether it is a term
or a value. 

The second problem is addressed by solutions such as DDDS (and
of course, DDDS may also provide a portion of the solution for
the first problem as well).

> The "contemporary view" doesn't prevent that.

Well, actually, I think it's general sentiment does. In the
discussions I've had over the past year or so, it has been
noted repeatedly that "there is no such thing as a URI class"
and "one cannot know anything about the use of the URI from
the URI scheme" etc.

What that basically says to me is that it is a principle of
the architecture, per the contemporary view, that one can only
rely on per-instance URI semantics, and that all a URI scheme
provides is syntax.

I appreciate that the contemporary/classical distinction is
really a continuum with folks taking personal viewpoints along
it, but every time I suggest some formal taxonomy of URI
classes and URI schemes where the interpretation semantics
is fixed per class or scheme, I'm told "that's wrong".

So, while technically the contemporary view doesn't forbid
it, it certainly doesn't encourage nor support it.

> But consider:  the proposed DDDS URN resolution mechanism *can* in
> principle be used to resolve any form of URI, including HTTP (and maybe get
> a different answer to just using HTTP directly).

I have great hopes for DDDS, and am just getting down into the
nuts-n-bolts of the specification.

I hope that it can be extended/evolved into something that will, in
addition to providing location mapping for URNs will also help achieve
some kind of global access solution for knowledge in general -- a
kind of distributed, global knowledge base allowing retrieval of
metadata associated with specific URIs (which will alleviate the need
for things like RDDL or http: URL namespaces).

Alot of work to do, still, though...  ;-)

Cheers,

Patrick


> --
> 
> At 06:34 PM 2/19/02 +0200, you wrote:
> 
>> Hmmm... I've understood the contemporary/classical distinction to
>> be whether a given URI scheme inherits any shared semantics from
>> any particular URI class (such as URL, URN, etc.) and whether such
>> information is formally defined.
>> 
>> I would expect that any URI scheme is free to assert name vs. location
>> semantics for interpretation of instances of that scheme.
>> 
>> What it all boils down to is scalability. The contemporary view seems
>> to want to assert all semantics on a per-URI instance basis, irrespective
>> of actual scheme, class, whatever.
>> 
>>> From a software engineering perspective, that's just plain stupid.
>> 
>> There *are* classes of URIs which require per-instance metadata,
>> such as URNs which, in order to resolve to anything must be associated
>> with a URL (or some metadata that has the same effect).
>> 
>> But even if the creators of the http: URL scheme were thinking about
>> being able to describe 'anything' I don't think they were at first
>> thinking of using http: URIs (I'm still reviewing the historical
>> material on that) and the use of http: for names of abstract things
>> is a recent occurrence, not as some would claim, intended from the
>> very beginning. And even if so (which I doubt) there is strong
>> resistence, and rightly so, against http: URLs which do not denote
>> web-accessible resources.
>> 
>> Applications need to know what they can do with URIs, whether they
>> denote directly retrievable resources (are a location) or
>> indirectly retrievable resource (are a name) or are self-contained
>> (are the resource) and the most efficient, economical way to
>> provide that information is by using URI schemes with that semantics
>> built-in, and in addition, defining classes of URI schemes that
>> capture that semantics.
>> 
>> Anyway, it's late and I'm probably just rambling incoherently,
>> so I'll shut up now...  ;-)
>> 
>> Cheers,
>> 
>> Patrick
>> 
>> 
>> On 2002-02-19 16:22, "ext Graham Klyne" <GK@NineByNine.org> wrote:
>> 
>>> Hi Patrick,
>>> 
>>> FWIW, I agree with the "contemporary view" -- whether a URI is a name or an
>>> address is IMO a function of how it is used, not the URI scheme name.  What
>>> I don't agree with is that that makes HTTP the right scheme name for just
>>> about everything.
>>> 
>>> #g
>>> --
>>> 
>>> At 03:18 PM 2/19/02 +0200, you wrote:
>>> 
>>>> (offlist)
>>>> 
>>>> Bravo, Graham!
>>>> 
>>>> Boy am I glad to see this issue put forward so precisely.
>>>> 
>>>> It will be interesting to see the responses...
>>>> 
>>>> PS: I've had for some time the vision of 'http:' URL cowboys
>>>> lamenting the end of the wild wild web and the arrival of
>>>> lawmen and order... with the "contemporary view" as one last
>>>> ditch effort to maintain their URI "freedom" and hold off
>>>> the inevitable organization of identity semantics into well
>>>> defined class taxonomies...  ;-)
>>>> 
>>>> Cheers,
>>>> 
>>>> Patrick
>>>> 
>>>> 
>>>> On 2002-02-19 13:17, "ext Graham Klyne" <GK@ninebynine.org> wrote:
>>>> 
>>>>> In reading TAG-team responses on namespace and content-type issues, I
>> note
>>>>> that a prefererence for HTTP: scheme URIs is expressed.  The rationale is
>>>>> clear enough -- that the URI should be dereferencable -- but it does
>> raise
>>>>> a question in my mind.
>>>>> 
>>>>> Does TAG consider that the HTTP: scheme has a distinguished status among
>>>>> URI schemes?  For example, a dereferencable URI might be FTP: or
>> LDAP: or a
>>>>> scheme indicating one of a number of other deployed protocols for
>>>>> retrieving information.
>>>>> 
>>>>> I submit that one architectural benefit of the IETF DDDS work [1] is that
>>>>> it allows separation of naming authority concerns from URI dereferencing
>>>>> concerns, thus avoiding the creation of a special /primus inter pares/
>>>>> status for the HTTP: URI scheme simply because the HTTP protocol
>> happens to
>>>>> be one of the most widely deployed at this time.
>>>>> 
>>>>> #g
>>>>> --
>>>>> 
>>>>> [1] http://search.ietf.org/internet-drafts/draft-ietf-urn-ddds-toc-01.txt
>>>>>    http://search.ietf.org/internet-drafts/draft-ietf-urn-ddds-05.txt
>>>>> 
>>>>> 
>>>> 
>> http://search.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-07.tx
>> >>
>> t
>>>>> 
>>>> http://search.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-05.txt
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ------------
>>>>> Graham Klyne
>>>>> GK@NineByNine.org
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> 
>>>> Patrick Stickler              Phone: +358 50 483 9453
>>>> Senior Research Scientist     Fax:   +358 7180 35409
>>>> Nokia Research Center         Email: patrick.stickler@nokia.com
>>> 
>>> ------------
>>> Graham Klyne
>>> (GK@ACM.ORG)
>>> 
>>> 
>> 
>> --
>> 
>> Patrick Stickler              Phone: +358 50 483 9453
>> Senior Research Scientist     Fax:   +358 7180 35409
>> Nokia Research Center         Email: patrick.stickler@nokia.com
> 
> ------------
> Graham Klyne
> (GK@ACM.ORG)
> 
> 

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Wednesday, 20 February 2002 04:33:55 UTC