Date:         Sun, 14 Sep 2003 16:43:52 -0700
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         Karen Coyle <[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

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.

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