I strongly agree with each of Erik Jul's comments on proposal 97-9.
I believe it is premature to define a place for the URN in the MARC record,
but if we need to do something now, we should certainly not put it in the $u
of the 856. As Erik points out, the 856 is by definition an electronic
location, while the URN is location-independent, and its relation to any
particular location is not at all clear. In theory, one of the greatest
values of the URN is that a single URN may refer to different instantiations
or even versions of an object, and a good URN resolution service can return
multiple URLs and even some metadata to distinguish them.
Last week I heard a report from a member of the IETF group working on URNs,
and it is clear that the IETF is going to worry only about the architecture
required for resolution and not about the syntax of any particular
identifier. However, they are proposing the existence of a global NID
registry, which will need to know enough about any particular URN scheme to
pass resolution to the appropriate agency for that particular namespace. In
this scennario true URNs (not the identifiers themselves but the overall
scheme and naming authority) would have to be registered with the NID. To
my knowledge we have no schemes that are so registered, in which case there
are no true URNs to include in MARC records anyway. Though the handle
system is in use in a number of prototype applications, to my knowledge
these are all "closed" applications in which the identifier directly
addresses the resolving agency.
Priscilla Caplan
University of Chicago Library
>Dear Readers: Here are some comments that I shared with Rebecca, which she
>suggested I post to the list.
>
>--Erik
>
>Erik Jul
>[log in to unmask]
>
>I've been thinking about MARBI proposal 97-9 and I have these
>questions/concerns.
>
>First, I wonder if changing $u to accommodate URNs doesn't violate the
>scope of the 856 field. As defined, 856 encodes electronic location and
>access
>information. By definition, URNs are location-independent. It seems a bit
>like mixing oil and water to mix location-independent data in a field
>called "electronic location."
>
>Also, how are software applications to determine whether the content of 856
>$u is a URN or URL? By definition now it is a URL. If more than one
>object type can be stored in $u, then applications that handle that data
>must be
>able to distinguish. The prefix "urn:" is not yet accepted or standard,
>nor is "hdl:" Parsing the content of $u seems problematic.
>
>I realize that LC and CNRI have a Handles experiment going, but Handles are
>not widely adopted and actually diverge from the proposed URN syntax
>(although modification would be trivial, it seems). I have some concern
>about modifying a national standard to accommodate a local implementation.
>
>Finally, it still seems premature to formalize URNs. Unlike URLs, URNs
>will require development of significant infrastructure that is not yet in
>place,
>including naming authorities and resolution services.
>
>What do you think about these issues?
>
>
|