Date:Mon, 15 Sep 2003 16:49:55 -0400
Reply-To:Metadata Object Description Schema List <[log in to unmask]>
Sender:Metadata Object Description Schema List <[log in to unmask]>
From:"Rebecca S. Guenther" <[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
On Mon, 15 Sep 2003, Karen Coyle wrote:
> I can go for this if we have BOTH (as you suggested earlier), and if our
> intention is to translate the 856 $u (and its related $3 and $q) to the
> location area of MODS. Since there are no identifiers in MARC (today) that
> begin http:// then in fact there will not be identifiers that are URLs when
> MARC is translated to MODS. (That's right, isn't it? Is anyone putting
> URL-formatted URI's in the 0XX area?) For those creating MODS records that
> aren't from a MARC crosswalk, they can have both identifiers and locations
> that are formatted as URLs.
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.
> If we agree on this, then we have to answer the question: if I have a URL
> that is both an identifier and a location, do I have to put it in both
> places in MODS? My answer would be yes -- if you only put it in one of
> those areas in MODS, there is no way to know that the URL can be used for
> both.
>
> Now we get down to the actual URL that stirred this up: a URL in a citation
> for a web resource, as required by various citation rules. My reading of
> the citation rules is that those URLs are locations, even though the
> location can sometimes help define the item. If someone wishes to also call
> it an identifier, then I have no problem with that, but if the URL is not
> placed in the location area then you have not indicated that this should be
> a "clickable link". It then has the same status as the identifier
> <http://www.loc.gov/mods/>http://www.loc.gov/mods/, which identifies but
> doesn't take you to the location of the item via http.
I don't think that citations are what stirred this up-- it was more
rethinking what we had done. But in the case of citations, they are
locations because they tell you how to access it. As with others, they may
also be identifiers.
But that identifier you mention also does take you to a location-- so the
string http://www.loc.gov/mods/ can be used both as a location and an
identifier but it doesn't really mean the same thing (in SRW it's used as
an identifier for the MODS schema; as a locator it's the MODS home page).
> So I guess I'm arguing that the 856 $q $u $3 should be locations, not
> identifiers, in MODS. And the way I read the identifier area, there is no
> reason why you cannot input an arbitrary URI, so that's already covered.
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. I would
argue that they are probably locations, but they may also be
identifiers. The only way to know is to look at each one (and then you may
not always know). But we can probably safely assume that they are at least
locations. And, yes, the same would go for 856. (We do plan to provide a
stylesheet to convert from MODS 2 to MODS 3, and this is something we
would need to deal with.)
Rebecca
>
> kc
>
> ----------------------------------------------
> Karen Coyle [log in to unmask]
> http://www.kcoyle.net
>
> ----------------------------------------------
>
