Date:         Mon, 15 Sep 2003 15:01:27 -0700
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         Karen Coyle <[log in to unmask]>
Subject:      Re: location, location, location
Comments: To: Metadata Object Description Schema List <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:49 PM 9/15/2003 -0400, you wrote:

>LC has been putting identifiers into 856$u-- only they are both locations
>and identifiers. They consist of a handle attached to a proxy server
>location. We have essentially been treating these as both; we didn't have
>a way to put them into 0XX. Don't forget we once had a $g in 856 for the
>URN, which is an identifier and not a location. And LC put persistent
>names in the 856 $f and $g for a time (together they form the persistent
>ID), even though this was really a "location" field. So I wouldn't say
>that 856 has been purely locations only.

I think we can say that the 856 $u has been used in the library world for
locations. If some of the URLs in the 856 $u are also identifiers, that's
kind of a philosophical rather than a metadata question because they are in
a location field and their "identifier-ness" was never part of the
metadata. The 856 is named  ELECTRONIC LOCATION AND ACCESS. Handles,
persistent URLs, etc. are considered by some to be identifiers, but when
they are in the 856 $u they are in there to locate the item, either
directly or through a resolution of some kind.


>But that identifier you mention also does take you to a location-

I intended to use as an example one that isn't also a location, so I
mis-understood Ray's note, but many schema identifiers do NOT also take you
to a location. This is why I hate that we have put http:// in front of
identifiers because it muddies the difference between identifiers and
locations. If something is both, then it is a location when it is in the
location area of the metadata and it is an identifier when it is in the
identifier area, but it can't be both and only be in one area of the
metadata. People can handle that, but programs can't.

>If we think about existing MODS records we would have to decide whether
>anything with identifier type="uri" should become location should we
>decide to make this change, or should they remain as identifiers.

MODS records have versions, don't they? So the version 2.0 uri's would
remain uri's, and you won't know if they are locations or identifiers, but
version 3.0 would allow both uri's and locations. People using MODS need to
determine if they want to upgrade to version 3.0 to take advantage of the
two data elements, and they can make the decision for their own data if
they decide to convert. I assume that LC would start moving 856 $u to the
location area. Since there isn't an explicit uri:identifier field in MARC,
I don't know if it would be possible to create uri's for those items that
are both identifiers and locations.

kc
----------------------------------------------
Karen Coyle                    [log in to unmask]
       http://www.kcoyle.net

----------------------------------------------