- From: Ray Denenberg <rden@loc.gov>
- Date: Mon, 01 May 2000 10:46:24 -0400
- 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 UTC