Subject: Some recent Internet Drafts relating to URIs

From: Patrick Stickler <[email-masked]>
Date: Wed, 16 Jan 2002 14:41:06 +0200

The following internet drafts have been submitted to the IETF
for consideration:

"An Extended Class Taxonomy for Uniform Resource Identifier Schemes"
http://www-nrc.nokia.com/sw/draft-pstickler-uri-taxonomy-00.html

"The 'hrn:' URI Scheme for Hierarchical Resource Names"
http://www-nrc.nokia.com/sw/draft-pstickler-hrn-00.html

"The 'uri:' URI Scheme for URI Reification"
http://www-nrc.nokia.com/sw/draft-pstickler-uri-00.html

"The 'tdl:' URI Scheme for Typed Data Literals"
http://www-nrc.nokia.com/sw/draft-pstickler-tdl-00.html

"The 'voc:' URI Scheme for Vocabulary Terms and Codes"
http://www-nrc.nokia.com/sw/draft-pstickler-voc-00.html

"The 'qname:' URI Scheme for XML Namespace Qualified Names"
http://www-nrc.nokia.com/sw/draft-pstickler-qname-00.html

"The 'xmlns:' URI Scheme for XML Namespace Declarations"
http://www-nrc.nokia.com/sw/draft-pstickler-xmlns-00.html

"The 'auth:' URI Scheme for Hierarchical Authority Identifiers"
http://www-nrc.nokia.com/sw/draft-pstickler-auth-00.html

Note that the URLs above are to unofficial copies of these
drafts on the Nokia site, as they are not yet available
(nor garunteed to be posted) on the IETF site.

Any and all comments are most welcome.

Regards,

Patrick

--

Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: [email-masked]

---

From: Michael Mealling <[email-masked]>
Date: Wed, 16 Jan 2002 09:31:26 -0500

> The following internet drafts have been submitted to the IETF

Hi Patrick,
  I assume you knew you were stiring up a hornets nest, right? ;-)

> http://www-nrc.nokia.com/sw/draft-pstickler-uri-taxonomy-00.html

Being one of the people in the URI-IG that discussed the classical vs
contemporay view (and an adherent of the contemporary view) I have to say
that this way lies madness. Most of the people on the URI-IG were involved
in the original discussions about URIs when we had such animals as
URA, URMs, URCs, URAv2, etc. The thing that has become clear is that
a given URI's characteristics have more to do with how it is used than
what its scheme says. For example, Dan uses the http scheme for
pretty much everything. For him the http scheme makes a pretty valid
urn-like thing. Others don't use it that way so it doesn't have those
semantics for them and thus isn't one.

The one thing I do have a problem with is the inclusion of 'hrn:'
along side 'urn:'. IMHO, since your 'hrn' proposal includes a domain-name
it cannot be a URN because it is not persistent. The UUID version might
but the domain-name based one isn't....

Beyond that the analysis is good from that point of view. The problem is
getting agreement on it...

> http://www-nrc.nokia.com/sw/draft-pstickler-hrn-00.html

As mentioned above, I think that this statement is erroneous:
"This URI scheme is also a type of URN, as defined by RFC 2396, but is not a
namespace of the 'urn:' URI scheme [5], because the 'urn:' scheme does
not provide for hierarchical characteristics which are central to the
semantics of this URI scheme. "

The fact that there is a domain-name in there means that it violates
the persistence requirement in RFC 2396.

> http://www-nrc.nokia.com/sw/draft-pstickler-uri-00.html

This is an interesting one but I think you should pick another scheme name.
The one you picked will end up causing you to much argument over the name
and none over the merits of the idea. The one question I have is: is
reification so globally well understood that it means the same thing to
everyone? I've been out of the RDF discussions but I seem to remember
this being an issue at one point....

> http://www-nrc.nokia.com/sw/draft-pstickler-tdl-00.html

What is the merit of this over the 'data:' scheme?

> http://www-nrc.nokia.com/sw/draft-pstickler-voc-00.html

I can't figure out what this scheme has that doesn't already exist in
current schemes. It seems that this one definitely falls into the "a URI's
semantics have more to do with how you use it than what the scheme has
in it"....

> http://www-nrc.nokia.com/sw/draft-pstickler-qname-00.html

Hmm.... I don't think a URI scheme can disclaim the URI Reference so the
hash mark statement is false. hmm... This one also really strikes me
as shortcutting RDF statements by putting them into the URI scheme
itself. I.e. all of the examples are previously stated URI examples from
other documents with an XML element name in front of it. Is it wise to be
creating new URI schemes when a statement in RDF could do the same thing?

> http://www-nrc.nokia.com/sw/draft-pstickler-xmlns-00.html

I thought we'd fixed that whole XML namespace thing?

> http://www-nrc.nokia.com/sw/draft-pstickler-auth-00.html

What's the difference between this and an 'http:' scheme?

> Any and all comments are most welcome.

Sorry if it sounds like I was picking it apart.  Its just that some of these
ideas were discussed in other fora which is how we got to the "its how
you use it, not the scheme name that's important" idea...

-MM

--
--------------------------------------------------------------------------------
Michael Mealling        |      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: Patrick Stickler <[email-masked]>
Date: Thu, 17 Jan 2002 09:38:47 +0200

> I assume you knew you were stiring up a hornets nest, right? ;-)

I'm quite aware that the issues that are addressed in my IDs
are areas of strong debate, yes.

> that this way lies madness.

Perhaps you missed the part that said that it is compatible with either
the classical or contemporary view?

Let me stress it again, draft-pstickler-uri-taxonomy-00 is compatible
with either the classical or contemporary view.

If you read it without this understanding, I would encourage you to
read it again.

> Most of the people on the URI-IG were
> involved
> what its scheme says.

Use and abuse are two different things. I assert that any use of a URI
scheme contrary to the specified intended use is contrary to the very
purpose of standards, and while research and advancement often need
to bend the rules and try unconventional things, eventually, advancements
and improvements need to be addressed in a standardized manner such
that industry can build upon that knowledge in a consistent and reliable
manner.

> For example, Dan uses the http scheme for

IMO, a URI scheme defines, in addition to the syntax, a common semantics
and basis for interpretation of instances of that scheme so that an
application has at least half a clue what to do with such instances.

Otherwise, let's all just use uuid: URIs and define the semantics in RDF.

> but the domain-name based one isn't....

You missed the essential point about my extended taxonomy and the
definition of a URN -- that while a URN may embody within its representation
the identity of the minting agent, it does not embody the identity of
the resolution agent. URLs do both -- and in fact, the minting and
resolution agents are the same.

I suggest you re-read draft-pstickler-uri-taxonomy-00, particularly
section 3.

An 'hrn:' may include the web authority of the minting agent, and that
is persistent, as that will never change. Unlike a URL, however, that
is *not* the resolution authority -- which like all URNs -- remains
undefined in the URI itself.

The 'hrn:' scheme provides a consistent, open, non-centralized
URN scheme that does not need a dedicated centralized authority
for granting namespaces, but uses web authority as that namespace
and thus is far better suited for the Web, not having the bottleneck
of namespace registration preventing global and mass minting of
URNs.

Furthermore, the 'hrn:' URN scheme is a hierarchical URI scheme, which
is highly desireable for many applications.

By those two criteria, I consider the 'hrn:' URN scheme to be superior
to the 'urn:' URN scheme -- though both are fully valid URN schemes
in that neither refer to any resolution agency explicitly in their
representation and are hence persistent in that regard.

> getting agreement on it...

Absolutely. Agreement about URI classes (or lack thereof) and URI semantics
will be a long road, I think.

But even though I'm coming late to this party, I think I've brought
along some rather good music, and maybe we can all get into the
same groove ;-)

> the persistence requirement in RFC 2396.

But this persistence requirement has the rather narrow view that
a web authority (domain name) only indicates a resolution agency,
and that the URL-centric perspective perhaps precludes the broader
role of a domain name representing only the minting agency, which
even if that domain ceases to exist, remains historically valid
and thus persistent -- within the scope of URN schemes which
only attribute significance with regards to minting and not
to resolution.

> this being an issue at one point....

This URI scheme is specifically intended for use within RDF applications.

And as for the name, it seems quite consistent with the URN/urn:
convention ;-)

After all, not all URNs are urn:'s. Likewise, not all URIs are uri:'s.
But all urn:'s are URNs and all uri:'s are URIs.

> What is the merit of this over the 'data:' scheme?

Specific, constrained semantics.

Furthermore, the 'data:' URI scheme requires that all datatypes
be registered/defined as MIME types, which is an unnecessary
overhead IMO for the kinds of datatypes in question.

The 'tdl:' approach is that each datatype is denoted by a URI,
and the pairing of datatype URI and lexical form uniquely
identifies a member of the value space of the datatype. This
is based on one proposal under consideration by the RDF Core
Working Group for datatyping of literals in RDF.

C.f. http://www-nrc.nokia.com/sw/TDL.html

While the 'data:' URI scheme *could* be made to work for this
application, it would be cumbersome.

> semantics have more to do with how you use it than what the scheme has

Again, perhaps its significance is not seen because the
distinction between URI classes as defined in
draft-pstickler-uri-taxonomy-00 section 3 is not fully understood.

The key point is that a 'voc:' URI does not resolve to
"something else". It is a URP.

Yes, you could define a similar URI using 'http:' but it would
never be clear whether it should or should not resolve to anything,
and if so, to what.

This is the basis for the classical view that I openly admit to
subscribing to. The URI scheme lets an application know what it
should or should do with a given URI.

Using 'http:' URLs for everything just leaves the application
guessing.

The syntactic similarities between 'voc:' and 'http:' are due
to both of them being hierarchical URI schemes and utilizing
web authorities -- but their semantics are *very* different.

> hash mark statement is false.

Under the currently defined URI Class taxonomy, consisting only of URLs
and URNs, no -- but under my extended URI taxonomy, with URPs, it can.

And actually, since the definition of a URI Reference is based on
the *returned* media type from dereferencing a URI, and if a given URI
scheme is never intended to be dereferenced, then it is IMO valid and
reasonable to state that in such cases a URI Reference is simply
undefined (cannot exist, or is vacuous).

> hmm... This one also really strikes me

This URI scheme has nothing to do with RDF/XML serialization.

The utility of this URI scheme is to achieve intersection of knowledge
in a 'tidy' RDF graph.

"Constellations" of property/value pairs do not constitute equality
in the eyes of RDF insofar as graph merging is concerned.

A URI representation results in there being one and only one node
in an RDF graph for each qualified name and allows one to make
statements about that qualified name resource which are global to
the knowledge base.

> I thought we'd fixed that whole XML namespace thing?

1. XML Namespaces still remain problemmatic in several areas, but
   that is a totally disjunct discussion that I won't introduce
   here to this forum, especially since it is not relevant to
   the 'xmlns:' URI scheme itself.

2. The 'xmlns:' URI Scheme does not replace XML NS declarations
   in XML instances. As with 'qname:' it provides a consistent
   representation for NS declarations in an RDF knowledge base
   (or anywhere else such a representation is useful).

> What's the difference between this and an 'http:' scheme?

1. It's a URV
2. It can be temporally qualified.
3. Its semantics are explicitly constrained to the representation
   of authoritative agents.

> Sorry if it sounds like I was picking it apart.

No need for apologies, I wan't folks to pick them apart. That's
how (a) they get better, and (b) how we achieve agreement.

> Its just that some of
> these

As I said, I know I'm coming late into these discussions (or have
missed them entirely ;-) but I sincerely feel that the contemporary
view is missing something very important and essential -- perhaps
not so essential for the Web, but definitly essential for the
Semantic Web.

Regards,

Patrick

--

---

From: Patrick Stickler <[email-masked]>
Date: Thu, 17 Jan 2002 10:26:20 +0200

>> What is the merit of this over the 'data:' scheme?

It's actually interesting (IMO) to note that a 'data:' URI
is in fact a URV (and hence URP) as it is never dereferenced,
but provides a complete, self-contained representation of
a resource. It is a WYSIWIG URI.

Thus the URV classification of 'data:' is far more accurate
regarding its semantics and application than the current URL
classification.

Cheers,

Patrick

--

---

From: Patrick Stickler <[email-masked]>
Date: Thu, 17 Jan 2002 10:47:24 +0200

On 2002-01-16 16:31, "ext Michael Mealling" <[email-masked]> wrote:

> ... The thing that has become clear is that

I hardly consider that something that is "clear" or true.

Take the simple example of the identity of a thing versus
the identity of the representation of a thing, where that
thing itself is not a digital resource, e.g. a car.

The "use 'http:' URLs for everything' approach suggests
that a given URL can be used both to denote the thing
(the car) as well as be dereferenced to retrieve a
representation of that thing (e.g. a photo, or technical
specs, etc.)

Yet, a SW application which is trying to "understand"
a given statement such as

   <rdf:Description rdf:about="http://foo.com/freds_car/">
      <dc:creator>Fred</dc:creator>
   </rdf:Description>

cannot tell whether Fred is the creator of the car itself
or of the digital resource retrievable from the URL.

Likewise, if the URL is intended only to be a URT -- i.e.
to be a non-dereferencible identifier of a non-digital
resource (just the car), an application has no way of
knowing if a 404 error is a true error (i.e. it *should*
resolve to "something") or just a side effect of the use
of a URL as a URT.

This degree of chaos in the interpretation of URIs is
IMO completely unacceptable and will greatly hinder the
advancement and deployment of useful SW applications.

Far better would be

   <rdf:Description rdf:about="http://foo.com/freds_car.jpg">
      <dc:creator>Fred</dc:creator>
      <rdfs:description>Picture of Fred's Car</rdfs:description>
   </rdf:Description>

   <rdf:Description rdf:about="voc://foo.com/freds_car">
      <dc:creator>Toyota</dc:creator>
      <rdfs:description>Fred's Car</rdfs:description>
      <rdfs:seeAlso rdf:resource="http://foo.com/freds_car.jpg"/>
   </rdf:Description>

and an application knows, based on the defined semantics of
'http:' URLs that it should get "something" when it dereferences
the URL and knows, based on the defined semantics of 'voc:'
URTs that it should not dereference one but use it simply as a
global identifier.

Cheers,

Patrick

--

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 17 Jan 2002 03:47:01 -0500

Note that these are _not_ I-D's unless and until they _do_
appear in the IETF Internet-Draft repository.

> Any and all comments are most welcome.

Leslie.

--

-------------------------------------------------------------------
"An essential element of a successful journey
    is recognizing when you have arrived."
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Mark Baker <[email-masked]>
Date: Thu, 17 Jan 2002 12:28:11 -0500

Patrick,

> representation of that thing (e.g. a photo, or technical

Right.

> or of the digital resource retrievable from the URL.

That's not true.  We've had this discussion before, and I've pointed
out that your assertion above is about the *resource*, i.e. the car.
If a particular representation of the car was created by somebody else,
then that should be reflected in a different URI, and the relationship
between http://foo.com/freds_car/ and this other URI should be
authoritatively established with HTTP's Content-Location header.

e.g.

GET http://foo.com/freds_car/ HTTP/1.1
Host: foo.com
Accept: image/gif

response headers;

HTTP/1.1 200 OK
Content-Type: image/jpg
Content-Location: http://foo.com/freds_car/image?format=jpg

Then you could make assertions about that particular representation;

 <rdf:Description rdf:about="http://foo.com/freds_car/image?format=jpg">
   <dc:creator>Jane</dc:creator>
 </rdf:Description>

MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

---

From: Seth Russell <[email-masked]>
Date: Thu, 17 Jan 2002 10:40:37 -0800

From: "Patrick Stickler" <[email-masked]>

I think you've done a great service to the SW in defining these new URI
schema.  They clearly define our names such that finally our RDF
applications will know of what we speak:)

Do you know of any nasty side effects of starting to use them immediately -
i.e. will they break any known RDF parsers ?

Seth Russell

language: Semenglish
URI
    seeAlso
        "http://www-nrc.nokia.com/sw/draft-pstickler-uri-taxonomy-00.html" ,

"http://lists.w3.org/Archives/Public/www-rdf-interest/2002Jan/0127.html" .

---

From: Patrick Stickler <[email-masked]>
Date: Fri, 18 Jan 2002 08:16:33 +0200

> applications will know of what we speak:)

Blush...  ;-)

> i.e. will they break any known RDF parsers ?

I don't know of any URI schemes that will break any RDF parser, since
URIs are expected to be fully opaque in the RDF graph.

As to RDF applications that attempt to grok URIs for various
purposes, I can't say. If they are "stupid" and presume that
every URI is an 'http:' URI and barf when they fail to resolve,
then of course, any of the URP schemes will choke such apps.

But I think folks should be able to start using them immediately
with few, if any, concerns of that sort.

We are...   ;-)

Cheers,

Patrick

--

---

From: Patrick Stickler <[email-masked]>
Date: Fri, 18 Jan 2002 08:31:57 +0200

On 2002-01-17 19:28, "ext Mark Baker" <[email-masked]> wrote:

> then that should be reflected in a different URI,

I agree that if separate URIs are used to denote the non-digital
resource and digital representations/expressions of that resource
that what you say is true (though the argument that I was contesting
about "multipurposed" URIs seems to be a common one).

However, using a URL to denote a non-digital resource is IMO just
plain bad practice. The point of the 'http:' URI scheme (and forgive
me for telling all you other folks what that is, even those of
you involved in writing the RFCs ;-) is to provide a URI that is
meaningful to HTTP resolution, and HTTP resolution is intended
to provide access to digital resources.

The problem is that folks needing to talk about non-digital resources
have been so 'http:' URL saturated that they started using them
out of habit, or (fairly enough) not having much else to use, and
then IMO folks started trying to re-define what URLs are for in
order to justify this (mis)use.

The distinction between URIs denoting accessible digital resources
and URIs denoting either abstract concepts or non-digital resources
is IMO crucial for the future of the SW. Again, it may not be
crucial for the Web, but it is for the SW.

> and the relationship

A content header is not a digital-resource, it is part of the
interchange protocol which describes to the recieving application
what the content is -- how can you describe empty content?

And this approach presumes that all that can be known about
such a resource can be expressed in the content header. And it
requires the explicit definition of "non-dereferencable" status
for *every* such URI rather than globally for all instances of
a particular URI scheme, or ideally for a URI class such as URP.

Far better to be able to know that one has a URP and thereby
know that the URI is non-dereferencable than have to define for
*every* URP in existence an explicit header response. Yikes!
What a massive overhead!

This content header approach feels to me like a hack. Sorry.

Regards,

Patrick

--

---

From: Patrick Stickler <[email-masked]>
Date: Fri, 18 Jan 2002 09:59:24 +0200

On 2002-01-18 8:52, "ext Mark Baker" <[email-masked]> wrote:

> whereas I would
> prefer that *all* of these relationships were made explicit with the
> mechanisms provided by the Semantic Web, and that the identifiers
> themselves remain entirely opaque.

Well, we could do that by simply using only UUIDs.

But as I pointed out, having to define all of the common, shared
semantics explicitly for every single identifier is IMO the
way of madness.

The whole point IMO of URI schemes is to be able to capture
the common semantics and intended application of sets of
identifiers in a consistent and efficient manner.

Capturing common semantics in a formal taxonomy of URI schemes
allows for all SW applications/layers to benefit, not just
HTTP or applications built on HTTP protocols, but any SW
application, standard, or methodology that is URI aware.

HTTP is not the foundation/heart/soul of the SW. URIs are.

The maximal point of intersection between SW applications
should be URIs and the common semantics defined for URI
schemes and the URI classes to which those schemes belong,
and the taxonomy of schemes and classes should, IMO, be
formal -- i.e. the classical view.

Regards,

Patrick

--

---

From: Mark Baker <[email-masked]>
Date: Fri, 18 Jan 2002 01:52:50 -0500

> order to justify this (mis)use.

Well I'm not going into that again, but at least we've boiled
down your argument. 8-)

> what the content is -- how can you describe empty content?

It's an assertion, like any other on the Semantic Web, except in RFC 822
format rather than RDF.

Anyhow, my general attitude towards your drafts are that it's a good
idea to be able to know things about resources and the relationships
between them.  You appear to want to put at least some of this
information into the URI scheme (e.g. HRNs, where the existence of one
resource implies the existence of other resources), whereas I would
prefer that *all* of these relationships were made explicit with the
mechanisms provided by the Semantic Web, and that the identifiers
themselves remain entirely opaque.

MB

---

From: Mark Baker <[email-masked]>
Date: Fri, 18 Jan 2002 09:04:44 -0500

> identifiers in a consistent and efficient manner.

That's true, but it doesn't mean that the only way to communicate that
sort of information is with a new URI scheme.  The most general model
would be to assume an opaque URI scheme, and then build up from there,
no?

What should one do when they need to make these same kinds of assertions
about an existing URI scheme that doesn't already support them (perhaps
because it's opaque)?  For example, what if the owner of example.org
wants to assert that http://example.org/foo/bar implies the existence of
http://example.org/foo and http://example.org/?

MB

---

From: Patrick Stickler <[email-masked]>
Date: Fri, 18 Jan 2002 16:59:26 +0200

> http://example.org/foo and http://example.org/?

But it does. Although it is rather implicit IMO in the definition
of hierarchical URIs, the individual path components are distinct
and hence can be referenced individually.

Note that that does *not* mean that subpaths correlate to URIs,
and this is the case also with 'hrn:' and 'voc:', only that one
can deduce that such subpaths might be valid URIs and in the case
of 'hrn:' and 'voc:' *if* they correlate to resources, there is
a defined superordinate/subordinate relation.

Obviously, though, it is difficult to rebake a cake, and if you
put the wrong ingredients into it...  cest la vie...  ;-)

Cheers,

Patrick

--

---

From: Mark Baker <[email-masked]>
Date: Fri, 18 Jan 2002 11:16:38 -0500

> and hence can be referenced individually.

They can be referenced, but so can any local path.  That's not the same
as asserting that they actually identify a resource.

Hierarchical naming does not in general imply the existence of resources
elsewhere in that same hierarchy.  If you think you've found some text
to the contrary, I'd appreciate a pointer though, as I've been looking
into the opacity qualities of RFC 2396 recently.

The point here being that this assertion should be able to be made about
any URI, not just ones using a particular URI scheme.  So the most
general model for this would be entirely opaque URIs, and explicit
assertions made about them.

> a defined superordinate/subordinate relation.

Sorry, I don't follow.

> put the wrong ingredients into it...  cest la vie...  ;-)

That sounds like it would be funny, if I understood the context.
8-)

MB

---

From: Patrick Stickler <[email-masked]>
Date: Fri, 18 Jan 2002 18:47:34 +0200

> into the opacity qualities of RFC 2396 recently.

I agree. And never stated that such was the case.

>> a defined superordinate/subordinate relation.

Meaning exactly your argument above, that just because a hierarchical
URI can be parsed into discrete subpaths doesn't mean that any of
the subpaths denote a resource -- but if they do, there is additional
semantics that can be inferred for an 'hrn:' and 'voc:' subpath that
cannot be inferred for an 'http:' subpath (or any other hierarchical
scheme I am aware of).

Thus, there is functionality defined for 'hrn:'s and 'voc:'s that
is not present in 'http:'s, all else being equal (which it isn't ;-)

> That sounds like it would be funny, if I understood the context.

Meaning that if needed semantics are not defined for a given
URI scheme from the get go, you can't (at least not easily)
go back and add it. That's why alot of thought went into the
recipes for 'hrn:' and 'voc:' ;-)

(though they may still end up tasting bad to some folks ;-)

Cheers,

Patrick

--

---

From: Justin Couch <[email-masked]>
Date: Sat, 19 Jan 2002 11:37:25 +1100

> with few, if any, concerns of that sort.

For those using Java-based parsers, I'd be interested to know if my
generalised URI resolver library handles these without modification. If
not, what additions should I make to help that process out:

http://www.vlc.com.au/urilib/

Latest updates are not in pre-compiled form, will need CVS for that.

--
Justin Couch                         http://www.vlc.com.au/~justin/
Freelance Java Consultant                  http://www.yumetech.com/
Author, Java 3D FAQ Maintainer                  http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
                                               - Greg Bear, Slant
-------------------------------------------------------------------

---

From: Patrick Stickler <[email-masked]>
Date: Sat, 19 Jan 2002 12:58:07 +0200

> Latest updates are not in pre-compiled form, will need CVS for that.

I had a brief look, and my initial impression is that insofar
as the 'hrn:' URN scheme is concerned, if you are treating URNs
as fully opaque keys in a (possibly global) associative array
(dictionary) then there should be no difference whatsoever from
the treatment of 'urn:' URNs. I suspect that you are at least
examining the URI scheme prefix to determine which class of
URI they belong to (URL, URN, etc.)

As for the other URP (URT/URV) schemes, the resolver is
irrelevant, as URPs do not resolve to anything.

If this sounds like I haven't fully understood the function of
the urilib, please let me know and I'll have a closer look.

Regards,

Patrick

--