 |
 |
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] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%