Print

Print


We'll look into this; it is not the intention to drop the 856 $z data in the note attribute in location/url. 

Rebecca

Rebecca S. Guenther                                                       
Senior Networking and Standards Specialist                  
Network Development and MARC Standards Office     
Library of Congress   
101 Independence Ave. SE                                                                                      
Washington, DC 20540-4402                                          
(202) 707-5092 (voice)    
(202) 707-0115 (FAX)           
 [log in to unmask]

>>> Dan Scott <[log in to unmask]> 1/22/2010 4:13 PM >>>
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