Date:         Wed, 24 Sep 2003 14:50:44 -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

Although I agree that we don't want to make any rash decisions about this
change, I am coming around to believe that we need to allow for URLs as
locators in the <location> element. I did want to address your concerns.

1. Mapping to simple Dublin Core for OAI (or other) purposes

If we allow for URIs in both location and identifier in MODS, this will be
just another case where MODS provides distinctions where Dublin Core
doesn't, because the latter only has 15 elements. There are lots of
situations where more than one MODS element would map to one DC element,
as multiple MARC elements map to one DC element. So both <location> (with
type="electronic or whatever we use to make this distinction) and
<identifier) would map to dc:identifier.

2. effect on existing applications

We plan to provide a stylesheet to do a conversion from MODS 2.0 to MODS
3.0. We would expect that uses of identifier with type="uri" are most
likely all locations, so the conversion between MODS versions would put
them in location.

Also, in terms of the MARC mapping, 856$u is defined as "Electronic
location and access" and, although some data there are both identifiers
and locations, it would not be incorrect to map them all to <location>.
Probably the only ones that do not belong in location are those that are
"raw" handles or DOIs or something, where the identifier string is not
attached to a server name. And it's unlikely any of these have been
recorded there.

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

The fact that it provides access maybe says it IS a location. But what
other surprises could you foresee that you haven't mentioned above that we
might need to be prepared to deal with?

Rebecca

On Fri, 12 Sep 2003, Caroline Arms wrote:

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