Ray,

Although I agree that the distinction between an identifier and a location
is useful to draw and can see very good arguments for what you propose, I
see it as too significant a change to slip in at the eleventh hour. If you
want MODS 3.0 to come out soon, I would prefer to see this issue deferred
until the next version.

Quite apart from the issue of redundancy, and what you propose will
certainly be perceived as redundant at first glance, I see potential
ramifications in a couple of important areas:

  mapping to simple Dublin Core for OAI (or other) purposes

  effect on existing applications

Moving the element that provides access to the content itself seems
inherently more likely to provide nasty surprises to developers or those
who have descriptive guidelines in use than most of the other changes from
2.0.

   Just my two cents. Have a good weekend.

   Caroline Arms [log in to unmask]
   Office of Strategic Initiatives
   Library of Congress


On Thu, 11 Sep 2003, Ray Denenberg, Library of Congress wrote:

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