Date:         Thu, 11 Sep 2003 17:44:24 -0400
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         "Ray Denenberg, Library of Congress" <[log in to unmask]>
Subject:      location, location, location
Comments: To: [log in to unmask]
Content-Type: text/plain; charset="utf-8"

I'd like to propose for consideration a MODS change, to be applied in 3.0.
(I think this is an important change, and that the impact on the schema is
fairly small.)

I suppose I had though that if you have a URL to access an item and you want
to include it in a MODS record for that item, you could put it  in the
<location> element. Well,  you can't.  <location> is essentially
physical.It's defined as sourceType with an authority attribute for an
organization code. The authority can be omitted in which case it's just a
string,  but there isn't any way to indicate it's a URL. It appears that the
prescribed way to code a URL is as an identifier (the <identifier> element)
of type URI. Recent discussion of 'date accessed' has brought this to my
attention. (I think Bruce brought it up. But I should have realized this
long ago.)

Coding a URL as an identifier, when the intent is to provide a URL for
access, is a big mistake.  I'm willing to elaborate profusely on this point
if anyone needs to be convinced.

To be clear: if the intent of supplying a URI is to provide an identifier --
even when that string also happens to to be a URL that can be used to access
the resource -- by all means, put it in the <identifier> element and call it
an identifier. But if the intent is also to provide location information, we
need somewhere in addition to put it (if that means putting an identical
string in two places, so be it), and the logical place would be <location> I
think.

My suggestion is to add an attribute to <location> to indicate if it's a
physical or electronic source (values 'physical' and 'electronic' or please
suggest alternative values); in the latter case a URL would be assumed.

This will take a little fiddling with the definition and references to
sourceType, but not much.

Please comment soon on this proposal, as we want to get 3.0 out.

--Ray