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

Yay, Ray!

Yes, this list needs to chew on this question.

First step is to set aside the question "Which is right, a) or b)" and
substitute the question:  

With regard to the question "compare and contrast: URI, URL, URN,"  what
are the points of general agreement and where are the distinctions which
generate more disagreement?

There are three U-words associated with URIs, in descending order of
agreement rating:

Uniform -- Use RFC xxxx syntax to avoid collisions
Universal -- Attempt to get "all" resources to share collision-free namespace
Unique -- Honor system, but pretty good results so far (lack of actual
spoofing attacks, etc.)

Next letter is R.  There is reasonable agreement that the URI discipline,
does little and intends to do little to define what a resource can be that
has a URI.  Note this works against the 'universal' goal above, because if
you don't know where to stop pushing for conformance, you never know how
well you are doing.

Third letter is I, for Identifier.

This is where the DC "encoding scheme" question hits.

What does Dublin Core need, operationally, in terms of 'identification' in
order to ensure effective operation?  It is possible that the incumbent
theory or class definition for "encoding scheme" is too strong or
restrictive, relative to what is actually required.

Cautionary Note: In terms of validating requirements for the performance of
identifiers, it is necessary to include the fallback to multi-trait
identification from single-trait identification in applications.

The Storage Resource Broker project at SDSC eventually abandoned the idea
of an identifier (i.e. a one-trait sufficient key) as persistent
identification for objects, and operates on the basis of a tuple or pattern
of traits as a sufficient-for-identification key.  This may be the general
answer in the large.  Identifiers are shortcuts and they usually work; to
be sure, refine the identification expression [a.k.a. query] until a unique
referent is returned.


Theory Note:  URIs form a namespace.  However, it is a namespace which is
intentionally weak in consistency of encoding.  A rather weak supertype
within the class of names.  This is why a declarative theory of names (what
propositions hold on what subspaces) is likely to be at least helpful if
not necessary in resolving this question.  [The declarative theory can, in
turn assert that the only reliable semantics are operational...]

Process Note:  Has there been any resolution to the alleged issue between
BICI and URI?

Al

At 11:19 AM 2000-04-28 -0400, Ray Denenberg wrote:
>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 Saturday, 29 April 2000 11:20:59 UTC