Date:         Mon, 15 Sep 2003 09:38:27 -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

The MARC to MODS and MODS to MARC mappings are the sources to find
equivalent MARC fields. We have some of this under documentation in the
schema, but these are not intended to be comprehensive. Often we included
them under documentation when it wasn't entirely clear what the element
represented in relation to MARC. We plan to clean up the documentation
areas of the schema so that we rely more on the mappings, although some is
helpful. So it is just an omission. Perhaps since we mention $3 we should
also include $u (or don't include any of them).

See the mapping and it will be clear that 856$u maps to identifier:
http://www.loc.gov/standards/mods/mods-mapping.html#identier

On Sun, 14 Sep 2003, Karen Coyle wrote:

> Was there a particular reason why the 856 $u (Uniform Resource
> Identifier) was not included in MODS 2.0? The 856 $3 (Materials
> specified) is there as an identifierType, and without the 856 $u it
> isn't clear what the $3 would be identifying. The only other 856
> subfield listed is the $q, which also seems to me to be a qualifier to
> the $u.
>
> *
> $q - Electronic format type (NR)
> An identification of the electronic format type, which is the data
> representation of the resource, such as text/HTML, ASCII, Postscript
> file, executable application, or JPEG image. Electronic format type may
> be taken from enumerated lists such as registered Internet Media Types
> (MIME types).
> *
>
> So it seems especially odd to have these two subfields and no place for
> the URL itself. I can't see how we can do without an electronic
> location.
>
> That said, I agree with Ray that we want to use the URL as a location,
> not as an identifier. This doesn't change the fact that there are times
> when the only way to identify an item unambiguously is to state its
> location. For example, there are online "preprint" archives that have no
> numbering system for their items, so the only data elements are
> author(s), title and URL. This creates a bit of a dilemma for functions
> like the OpenURL which would like to find at item no matter where it is
> physically located, but in some cases just the author and title may be
> inadequate to identify the item.

So, in these situations where the URL is essentially the only reliable
identifier, would you suggest putting the data in both <identifier> and
<location>? Or just figure that an application would use location if there
is no other identifier?

Rebecca

> Later we can discuss whether a "date last accessed" is needed, but I
> think that's a different discussion, and for a particular class of
> materials.
>
> kc
>
> On Thu, 2003-09-11 at 14:44, 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
>