W3C home > Mailing lists > Public > uri@w3.org > May 2000

Re: [Fwd: Re: Approval of initial Dublin Core InteroperabiityQualifiers]

From: Ray Denenberg <rden@loc.gov>
Date: Mon, 01 May 2000 10:46:24 -0400
Message-ID: <390D98BD.35BCA89B@rs8.loc.gov>
To: W3C URI List <uri@w3.org>
"Martin J. Duerst" wrote:

> Could somebody from the DC community explain what an
> 'encoding scheme' is in DC? Or give a pointer?

I'll be happy to be enlightened by someone more DC-mainstream;  pending that,
here's my explanation (in the context of the current discussion):  Say that a DC
metadata element needs to identify a resource, for example, say it's the
'relation' element, where you indicate both a relationship (e.g. 'replaces') and
what resource the resource-under-description bears this relationship to. You have
to identify the resource, so you need a resource identifier. Quote from DC:

(begin quote)
-------------------------------
Qualifiers for 'Relation':

   Element Refinements:
        Is Version Of
      Has Version
      Is Replaced By
      Replaces
      Is Required By
      Requires
      Is Part Of
      Has Part
      Is Referenced By
      References
      Is Format Of
      Has Format

   Encoding Scheme:
      URI
------------------------------
(end quote)

So for example say you want to identify the resource by "isbn", this presumes that
there will be a URI scheme for 'isbn'.  So DC uses the term "encoding scheme" in
this context to mean simply that the resource identifier will be sufficiently
self-identifying that you can tell what kind of identifer it is. And we presume
that the URI encoding scheme is sufficient for this purpose.


> The W3C has spent some time a while ago on preparing something like
> an URI activity; however, we have received signals from some of our
> Members that were very tired of discussions about these topics.

I'm not sure I should  respond to this assertion, on this (public) list,
so I'll save it for the AC meeting.


> >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).
>
> This is is not true, at least not for me. Persistence (or not) is
> an important distinction, ....

Sorry, I wasnt' clear. I'm not suggesting that anyone at all thinks that
persistent (vs. not persistent) is not an important distinction.  I'm suggesting
that some people don't think that this distinction is embodied in the URL vs.URN
distinction.



> but:
> - There are many other important distinctions, and picking up one
>    and splitting the realm of identifiers into two only based on
>    this distinction seems not so useful.
> - Persistence, as many other things, is more a social than a
>    technical problem. It is possible to create and maintain very
>    persistent things based on http:, on the other hand, it is
>    possible to create completely unstable URNs. Trying to use
>    naming differences or implementation differences may
>    give a dangerous impression of guaranteed persistence.

This certainly reflects my view.


> >What's
> >needed is a coherent document (preferably, normative), that ties all of the
> >relevant information together, perhaps pointing to the appropriate RFCs.
>
> What should such a document say? Should it be updated every time
> a new URI scheme is defined? Isn't it dangerous to try and say
> everything in one single place?

I would be happy (or at least happier) if there were a document that listed the
relevant RFCs (and permitted the reader to determine by inference that a given RFC
is  irrelevant, out-of-date, still experimental, etc.) and told you which RFC to
look at to solve a given problem.  But it should be an *authoritative* document
(not just someone's private web page, or some *informal* W3C page).

And no, it should not be updated for new URI schemes, and yes, it is not good to
try to say "everything" in a single document.



>
> > -- we'll never even begin to
> >discover what URI schemes are going to be necessary, useful, and/or
> >popular;
>
> Well, this is a feature, not a problem. If we knew exactly which
> URI schemes would be needed/popular in a few years, we would
> already have invented them.

Our views differ here.  Your's seems to be: determine which shemes are going to be
the winners, then register them;  the reason for the intertia is that we haven't
quite figured out which. Our  view is: there are many potential schemes; we won't
know which are going to be winners without some shakedown process, including
registering some that ultimately won't survive, so let's get started registering
schemes, see which are deployed, which become popular, and which ones vendors
support -- the reason for the intertia is the confusion over how to register the
schemes.


> Not, it's very clear. There is an RFC on it, RFC 2717.
>

Ok, I'll look at it again.


>
> .>....registration of "isbn:"  hasn't
> >even been explored, apparently because it is assumed that it simply cannot be
> >registered, for legal reasons.
>
> What would these reasons be? I would be interested to know.

I'm sure you know as much as I do about this. The IETF can't simply write an RFC
registering ISBN as a URI scheme because of the proprietary aspects of ISBN, even
though there is an RFC that describes this hypothetical scheme. It is up to the
ISBN Agency to decide that they want ISBN registered, and (according to Leslie
dagle, in response to my original posting to the DC list) they're exploring it.
Problem is, they seem to have been "exploring" it for a very long time.  I don't
know what the legal/business consideration are.

Thanks for your comments on this, Martin.     --Ray


--
Ray Denenberg
Library of Congress
202-707-5795
rden@loc.gov
Received on Monday, 1 May 2000 10:48:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:27 GMT