I'd like to consider the deeper implications of Roy's message.
Roy Tennant wrote:
> Say what?!? Did I miss a pronouncement from W3C that URI finally has some
> kind of meaning? Since when is "URI" an encoding scheme?
These are two separate questions, what URI means, and whether URI is an
encoding scheme.
I think the first is the relevant question: the meaning of "URI" is clearly
the subject of pervasive confusion. (As to the second question, yes, URI is
an encoding scheme, it just hasn't been nailed down yet as such, and it won't
be, until we know the meaning of "URI".)
There is a rather profound implication, I think, to the fact that the sole
encoding scheme prescribed by DC for a resource identifier is URI. Though I
don't take issue with this approach I think it is necessary to consider the
implication: the assumption that there will be a URI scheme developed for
any type of identifier to be used in Dublin Core.
There's a long way to go before this a reality, and it all begins with
agreement on what URI means (or, conversely, there won't be any progress
until this is resolved).
The reason I'm addressing this issue is that we (LC) have been
trying to convince the W3C to initiate an activity on URIs; several of the
people active in DC have ties to the W3C, and I think that this issue is a
good illustration of the importance of this to the DC community.
On the issue "what is a URI?", I see two differing views:
(a) URI schemes fall into two (or more) broad classes, URL and URN. Each URI
scheme is cast into one or the other class; thus for example "HTTP:" is a
URL scheme and "hdl:" a URN scheme. (Of course, there are RFCs that still
hypothesize about an additional class, URC.)
(b) The distinction between URL and URN is artificial, and therefore this
"level" in the URI hierarchy un-necessary. Thus "HTTP:" and "hdl:" are
simply URI schemes. By this view, the concept of "URL" and "URN" would go
away, and be replaced by "URI". (Which does not mean that any of the
proposed URN schemes would go away; they would just become URI schemes, as
would HTTP.)
Most RFCs pertaining to URIs support view (a), however there seems to be
growing sentiment for view (b). I don't personally see it as an important
issue, worthy of bringing progress on uri schemes to a complete impasse; it
is an issue that needs quick resolution (either way, as far as I'm
concerned), and it needs IETF/W3C collaboration.
The argument for view (a) is the conceptual and practical distinction
between a URL and URN. The conceptual distinction is expressed in terms of
persistence (which those who support view (b) think is an artifical
distinction). The practical basis for the distinction is probably the
difference in how URLs and URNs will be resolved, the theory being that URN
schemes will share certain resolution traits, as will URL schemes, and the
URN resolution traits will differ from those of URL schemes. Thus all of
the URN commonality could be absorbed into a single "common-scheme" (or
"common protocol") simplifying the "individual-schemes" (or "individual
protocols"); furthermore (as the theory goes), much of the common resolution
process corresponding to URNs would be supported by the DNS. (There are RFCs
that describe, in fairly specific detail, how the DNS will be used for
resolution of URNs.) The counter argument is that web browsers don't
understand URNs nor do they seem to offer any prospects for URN support;
moreover, there doesn't appear to be any prospects of seeing this special
DNS facility developed either.
As a more general observation, consider that there are dozens of
URI/URN-related RFCs; it is difficult to even identify them all, much less
determine which are relevant and which aren't, which are current and which
are out-of-date, and understand their relationships to one another. What's
needed is a coherent document (preferably, normative), that ties all of the
relevant information together, perhaps pointing to the appropriate RFCs. We
simply feel that confusion over URIs is so pervasive that without a
proactive initiative, progress is unlikely -- we'll never even begin to
discover what URI schemes are going to be necessary, useful, and/or popular;
which will be supported; and which schemes vendors will need to support. The
only way that this discovery process can even begin is if we begin to
register URI schemes (some will ultimately be winners, others won't), and it
isn't even clear how to do that. (There are certain potential URI schemes
that we're fairly sure are going to be necessary, and for which registration
hasn't been attempted yet, because of confusion over registration
procedures. "isbn:" may or may not be a popular scheme; we won't begin to
find out until it is at least registered. Its definition as a URN scheme has
been described hypothetically in an RFC, but registration of "isbn:" hasn't
even been explored, apparently because it is assumed that it simply cannot be
registered, for legal reasons. This is, at least, our understanding, and if
our understanding is wrong, then perhaps that's the point: pervasive
confusion.)
Consider Leslie Dagle's response to the original posting:
Leslie Daigle wrote:
> I think they think it means this:
>
> RFC2396
> http://www.ietf.org/rfc/rfc2396.txt
>
Note that Leslie (who is the expert on these matters) didn't say "I think it
means..." (which in itself would indicate confusion) but rather "I think they
think it means..." which, to me, is a disturbingly cryptic response (with
which Stu Weibel concurred). The DC community should be clear about what is
meant by "URI", if it plans to type an object as URI. I suggest that DC may
want to consider supporting the suggestion that W3C initiate a URI activity.
--Ray
--
Ray Denenberg
Library of Congress
202-707-5795
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
