[Fwd: Re: Approval of initial Dublin Core Interoperabiity Qualifiers]

It's been recomended that I forward this message, originally posted to
the DC list, as this list is probably the appropriate place for this
discussion.

 Though the context may not be completely clear, the message is fairly
self-explanatory.


-------- Original Message --------
Received: from mailout2.mailbase.ac.uk (mailout2.mailbase.ac.uk
[128.240.226.12])by rs8.loc.gov (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id
LAA75754;Thu, 27 Apr 2000 11:06:01 -0400
Received: from naga.mailbase.ac.uk (naga.mailbase.ac.uk
[128.240.226.3])by mailout2.mailbase.ac.uk (8.9.1a/8.9.1) with ESMTP id
QAA00991;Thu, 27 Apr 2000 16:05:54 +0100 (BST)
Received: (from daemon@localhost) by naga.mailbase.ac.uk
(8.8.x/Mailbase) id QAA13848;Thu, 27 Apr 2000 16:03:04 +0100 (BST)
Received: from rs8.loc.gov (rs8.loc.gov [140.147.248.8]) by
naga.mailbase.ac.uk (8.8.x/Mailbase) with ESMTP id QAA13797;Thu, 27 Apr
2000 16:02:54 +0100 (BST)
Received: from rs8.loc.gov (rden.loc.gov [140.147.23.4])by rs8.loc.gov
(AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id LAA25456;Thu, 27 Apr 2000
11:02:45 -0400
Message-ID: <39085674.3F18CBA9@rs8.loc.gov>
Date: Thu, 27 Apr 2000 11:02:15 -0400
Organization: Library of Congress
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References:
<Pine.OSF.4.10.10004250920180.32674-100000@library.berkeley.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Approval of initial Dublin Core Interoperabiity Qualifiers
From: Ray Denenberg <rden@loc.gov>
To: DC General <dc-general@mailbase.ac.uk>
Cc: Roy Tennant <rtennant@library.berkeley.edu>
X-List: dc-general@mailbase.ac.uk
X-Unsub: To leave, send text 'leave dc-general' to
mailbase@mailbase.ac.uk
X-List-Unsubscribe:
<mailto:mailbase@mailbase.ac.uk?body=leave%20dc-general>
Reply-To: Ray Denenberg <rden@loc.gov>
Sender: dc-general-request@mailbase.ac.uk
Errors-To: dc-general-request@mailbase.ac.uk
Precedence: list
Content-Transfer-Encoding: 7bit
Status: 
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 35ec60470000397d

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
rden@loc.gov

Received on Friday, 28 April 2000 11:21:02 UTC