 |
 |
At the time that mods:location was added to DC-LAP, we were in MODS version 2.1 and there were no subelements under <location>. In version 3.0 we decided to make the distinction in MODS between an identifier and a URL (electronic location), so we redefined location with 2 subelements: <url> and <physicalLocation>. The latter is equivalent to the previous version's <location>, i.e. it is for a repository that holds the resource. The location is DC-LAP is intended for the repository, so we had intended to make <physicalLocation> a global element. Developers of DC-LAP wanted to specify the institution that held the resource. There was no plan to use it for a URL. When the Usage Board first considered the DC-LAP, the decision was made to include MODS elements because of the general guidelines that DCMI was following about reuse of metadata elements that already existed. Initially this discussion about XML elements vs. RDF properties didn't come up. So DC-LAP has included the MODS elements for quite some time. When the Collection Description proposal for IsAvailableAt came up, this is when the Usage Board started discussing the issue of using MODS elements, since it was clear that the proposed isAvailableAt had essentially the same semantics as mods:location. And it has been discussed a few times since then. On a historical note, edition/version was almost included in the initial DC element set in 1995, but was thrown out because it was considered by some not to be "cross-domain, resource discovery" and too library centric. Since those criteria seem to be no longer the requirements to define a DC element, who knows if edition/version may creep in. Rebecca On Fri, 11 Feb 2005, Ann Apps wrote: > Hi All, > > Apologies for not explaining what I meant by MODS terms not > being consistent with DC practice. But I think others have > explained it for me :) > > Another (more simplistic) point about using the MODS terms, in > particular mods:location. > > Looking at the MODS XML schema, mods:location has 2 sub- > elements, according to the hierarchical XML model: > physicalLocation and url. They are both optional and can occur > many times (though physicalLocations must precede urls). Thus if > the sub-elements were promoted to 'first class' elements (ie could > be used without the surrounding <mods:location> tags) (and > assuming it were possible to sort out the definition in RDF terms) > you would end up with 2 location properties rather than a single > one. > > I understood that mods:location was included in the DC-Lib AP so > that either a physical location or a digital location (or both) could be > captured within the same property, not to have separate properties. > > The situation at the moment is that you need to write: > <mods:location> > <mods:physicalLocation>My Library</mods:physicalLocation> > </mods:location> > for a physical location and: > <mods:location> > <mods:url>http://example.com/mylibrary.</mods:url> > </mosd:location> > for a digital location > [<mods:location>My Library</mods:location> is wrong according > to the schema.] > > Whereas if there were a DCMI property for location, like all DC > properties, it's value could be represented by either a URL or a text > string. > > It also seems to me that a location property must bear some > similarity to that needed but not yet decided by the Collection > Description AP (isAvailableAt, isLocatedAt?). > > As for 'edition', this sounds akin to my long-lamented 'version' > property :). But, joking aside, I do think there is a general need for > a DCMI edition/version property (I seem to remember a question on > askDCMI not long ago). > > Ann > > > > > > -------------------------------------------------------------------------- > Ann Apps. IT Specialist (Research & Development), MIMAS, > The University of Manchester, Oxford Road, Manchester, M13 9PL, UK > Tel: +44 (0) 161 275 6039 Fax: +44 (0) 0161 275 6040 > Email: [log in to unmask] WWW: http://epub.mimas.ac.uk/ann.html > -------------------------------------------------------------------------- >