2010/1/22 Tracy Neckar Meehleib <[log in to unmask]>:
> Hi All,
>
> We have revised the transformation from MARCXML to MODS 3.3, and it is available here:
> http://www.loc.gov/standards/mods/v3/MARC21slim2MODS3-3.xsl
>
> Changes in the transformation reflect changes made in the MARC to MODS 3.3 mapping located here:
> http://www.loc.gov/standards/mods/v3/mods-mapping-3-3.html
Is it intentional, or an oversight in MODS33, that a MARC record with
a single 856 (ind2=0) pointing to a URL beginning with "http" results
in an <identifier> that contains only the URL, throwing away the
public description, etc that helps describe the resource?
Previous versions of MODS would generate a rather useful <location
note="_note_contents_"><url>... structure, but MODS33 did away with
this and effectively removed our interest in adopting MODS33 in
Evergreen as an intermediate format for generating indices.
Compare:
* Original MARCXML:
http://laurentian.concat.ca/opac/extras/unapi?id=tag:opac:biblio-record_entry/2109490/CONIFER&format=marcxml
* MODS32 version:
http://laurentian.concat.ca/opac/extras/unapi?id=tag:opac:biblio-record_entry/2109490/CONIFER&format=mods32
* MODS33 version:
http://laurentian.concat.ca/opac/extras/unapi?id=tag:opac:biblio-record_entry/2109490/CONIFER&format=mods33
The MODS32 version has both the identifier and the location elements,
with the richer metadata for the public note (okay, there are times we
have richer notes than "To view this resource, click here" but you get
the idea).
In the MODS33 version, the public note is gone for where subfield u
starts with anything other than "urn" or "urn:hdl". Was http:
overlooked?
In addition to being identified as a primary identifier, I would still
expect and desire 856[ind2=0] to generate a <location><url> structure
parallel to the ind2=1 and ind2=2 structures. This would enable a
smoother transition from previous versions of MODS to MODS 3.3
--
Dan Scott
Laurentian University
|