W3C home > Mailing lists > Public > uri@w3.org > January 2002

Re: Some recent Internet Drafts relating to URIs

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 17 Jan 2002 09:38:47 +0200
To: Michael Mealling <michael@neonym.net>
Message-ID: <B86C4C27.BBAE%patrick.stickler@nokia.com>
On 2002-01-16 16:31, "ext Michael Mealling" <michael@neonym.net> wrote:

> On Wed, Jan 16, 2002 at 02:41:06PM +0200, Patrick Stickler wrote:
>> The following internet drafts have been submitted to the IETF
>> for consideration:
> Hi Patrick,
> 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.

>> "An Extended Class Taxonomy for Uniform Resource Identifier Schemes"
>> 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.

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
> 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.

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

> 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.

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.

> 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....

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

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.

> Beyond that the analysis is good from that point of view. The problem is
> 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 'hrn:' URI Scheme for Hierarchical Resource Names"
>> 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.

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.

>> "The 'uri:' URI Scheme for URI Reification"
>> 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....

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.

>> "The 'tdl:' URI Scheme for Typed Data Literals"
>> http://www-nrc.nokia.com/sw/draft-pstickler-tdl-00.html
> 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.

>> "The 'voc:' URI Scheme for Vocabulary Terms and Codes"
>> 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"....

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

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.

>> "The 'qname:' URI Scheme for XML Namespace Qualified Names"
>> 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.

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
> 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?

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.

>> "The 'xmlns:' URI Scheme for XML Namespace Declarations"
>> http://www-nrc.nokia.com/sw/draft-pstickler-xmlns-00.html
> 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).
>> "The 'auth:' URI Scheme for Hierarchical Authority Identifiers"
>> http://www-nrc.nokia.com/sw/draft-pstickler-auth-00.html
> 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.

>> Any and all comments are most welcome.
> 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
> 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...

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.



Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Thursday, 17 January 2002 02:37:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:03 UTC