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