<extension> practice

Hello MODS implementers,

The MODS/MADS Editorial Committee is in the final stages of planning for version 3.4 (very soon now,
really!) and one of the outstanding issues before us is whether or not to do more with the <extension>
element. We've heard a number of times along the way that it would be helpful to have <extension> not just at
the top level but also inside specific MODS elements. We'd like to hear from you about your current
practice and needs for <extension> to better plan for how and if this should be implemented.

1) What type of data are you currently putting in the top-level <extension> element?

2) Do you have specific cases in which it would be helpful to you to have <extension> inside a specific MODS
element rather than at the top level to convey additional semantics?

3) Have you made changes to the MODS schema locally to allow for additional elements not in the MODS schema?

Thank you,

Jenn Riley, on behalf of the MODS/MADS Editorial Committee

========================
Jenn Riley
Metadata Librarian
Digital Library Program
Indiana University - Bloomington
Wells Library W501
(812) 856-5759
www.dlib.indiana.edu

Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com

Re: <extension> practice

On 11-8-2009 21:26, Riley, Jenn wrote:
> Hello MODS implementers,
> 
> The MODS/MADS Editorial Committee is in the final stages of
> planning for version 3.4 (very soon now, really!) and one of the
> outstanding issues before us is whether or not to do more with the
> <extension> element. We've heard a number of times along the way
> that it would be helpful to have <extension> not just at the top
> level but also inside specific MODS elements. We'd like to hear
> from you about your current practice and needs for <extension> to
> better plan for how and if this should be implemented.
> 
> 1) What type of data are you currently putting in the top-level
> <extension> element?

The Dutch institutional repositories and the institutional 
repositories that co-operate in the European project NEEO 
(http://www.neeoproject.eu/) use digital author identifiers (dai) for 
their authors. These identifiers can't be used in the mods:name 
element. Instead we introduce these identifiers in the extension 
element. There is a schema for a daiList. The authors described in the 
name element are linked to the author identifiers in the list in the 
extension element by the ID attribute of the name element and the 
IDref attribute of the corresponding identifier element of the daiList 
in extension.
The two attributes must have the same value to match a name with an 
author identifier.

See for more information:
http://www.surffoundation.nl/wiki/display/standards/Use+of+MODS and

Re: <extension> practice

Jenn,

> 1) What type of data are you currently putting in the top-level <extension> element?

We use the <extension> element for local holdings info and for non-roman
data. If a MARC record contains 880 fields, then we create a second
<mods> element using the 880s and stick it in <extension>. You can
see an example here:

    http://copac.ac.uk/search?ti=Qian+gu+zhi+mi&rn=1&format=XML+-+MODS

> 2) Do you have specific cases in which it would be helpful to you to have <extension> inside a specific MODS
element rather than at the top level to convey additional semantics?

No.

> 3) Have you made changes to the MODS schema locally to allow for additional elements not in the MODS schema?

No.

Regards,

Ashley.
--

-- 
Ashley Sanders               a.sanders@...
Copac http://copac.ac.uk A Mimas service funded by JISC

MODS-MARC map: hierarchicalGeographic

In the MODS-MARC map, <subject><hierarchicalGeographic> maps to 752.  
However, in the MARC format, 752 is meant for an "added entry [NOTE: not 
subject heading] in which the entry element is a hierarchical form of 
place name that is related to a particular attribute of the described 
item, e.g., the place of publication for a rare book."

Shouldn't <subject><hierarchicalGeographic> map instead to 662, 
"Hierarchical form of a geographic name used as a subject added entry"?

We are using LC's conversion tools but would like our subjects to map to 
6xx, not 7xx.

It looks like 662 might be a relatively new addition to the MARC format 
and so I'm wondering if this is just an oversight?

Thanks for your help!

Jane Otto
E-Monographs and Multimedia Metadata Librarian
Rutgers University Libraries

jjotto@...
(732) 445-5904
(732) 445-5888 (fax)
Rutgers, the State University of New Jersey
Library Technical Services Building
47 Davidson Road
Piscataway, NJ 08854-5603

MODS-MARC map: note type=bibliography

In the MODS-MARC map, <note> with type=bibliography maps, like most 
other notes, to 500.  However, in the MARC format, a bibliography note 
is tagged 504. 

We are using LC's conversion tools and would like all our bibliography 
notes to map to 504, whether they're mapped in from MODS or input 
manually through our ILS.

Am I missing something, or is this something that could be  revised in 
the MODS-MARC map and  the conversion tool?

Thanks again!

Jane

On 8/12/2009 9:20 AM, Jane Otto wrote:
> In the MODS-MARC map, <subject><hierarchicalGeographic> maps to 752.  
> However, in the MARC format, 752 is meant for an "added entry [NOTE: 
> not subject heading] in which the entry element is a hierarchical form 
> of place name that is related to a particular attribute of the 
> described item, e.g., the place of publication for a rare book."
>
> Shouldn't <subject><hierarchicalGeographic> map instead to 662, 
> "Hierarchical form of a geographic name used as a subject added entry"?
>
> We are using LC's conversion tools but would like our subjects to map 
> to 6xx, not 7xx.
>
> It looks like 662 might be a relatively new addition to the MARC 
> format and so I'm wondering if this is just an oversight?

Re: MODS-MARC map: note type=bibliography

Hi Jane,

The existing MODS-MARC mapping and conversion is based on the MODS 3.0. We are currently in the process of
drafting the MODS-MARC mapping and conversion for MODS 3.3. 

I know that the 662/752 issue is addressed in the new mapping. And, at first glance, it looks like MODS notes
that are typed "bibliography", based on the current MODS notes list
<http://www.loc.gov/standards/mods/mods-notes.html>, will be converted to MARC 504 notes, once the
MODS-MARC mapping and conversion for MODS 3.3 are complete.

Tracy

Tracy Meehleib
Network Development & MARC Standards Office
Library of Congress, LA-308
101 Independence Ave., SE
Washington, DC 20540-4402
(202)707-0121
tmee@...

>>> Jane Otto <jjotto@...> 8/12/2009 9:28 AM >>>
In the MODS-MARC map, <note> with type=bibliography maps, like most 
other notes, to 500.  However, in the MARC format, a bibliography note 
is tagged 504. 

We are using LC's conversion tools and would like all our bibliography 
notes to map to 504, whether they're mapped in from MODS or input 
manually through our ILS.

Am I missing something, or is this something that could be  revised in 

Re: MODS-MARC map: note type=bibliography

Right-o!  It's all coming back to me now.  Thanks for jogging my memory, 
Tracy.  We'll keep our eyes peeled for the new conversion (which I'm 
sure will be announced to this list).

Thanks again,

Jane

On 8/12/2009 2:45 PM, Tracy Neckar Meehleib wrote:
> Hi Jane,
>
> The existing MODS-MARC mapping and conversion is based on the MODS 3.0. We are currently in the process of
drafting the MODS-MARC mapping and conversion for MODS 3.3. 
>
> I know that the 662/752 issue is addressed in the new mapping. And, at first glance, it looks like MODS notes
that are typed "bibliography", based on the current MODS notes list
<http://www.loc.gov/standards/mods/mods-notes.html>, will be converted to MARC 504 notes, once the
MODS-MARC mapping and conversion for MODS 3.3 are complete.
>
> Tracy
>
>
> Tracy Meehleib
> Network Development & MARC Standards Office
> Library of Congress, LA-308
> 101 Independence Ave., SE
> Washington, DC 20540-4402
> (202)707-0121
> tmee@...
>

The upcoming release of the EAC-CPF schema and Tag Library

Re: <extension> practice

Re: <extension> practice

Joe,

> Regarding the non-roman data in your MODS records, I wonder if 
> <extension> is merely a storage place for that data, or if it is used in 
> a functional way for indexing or display in your systems?

We are using <extension> as a storage place, but you can see how we
display the non-roman data contained in it here:

    http://copac.ac.uk/search?ti=Qian+gu+zhi+mi&rn=1

We use MODS as a way of holding the data for display and export
(into a variety of formats via XSL Transformations.) Indexing is
done separately.

> The MARC $6 
> feature permits a field-specific ability to toggle roman and non-roman 
> data in a user display -- would a similar feature in MODS be useful for 
> you (and other MODS implementors)?

I'm not sure we would use such a facility -- even though the MARC21
records we create the MODS record from have the $6 data.

Regards,

Ashley.

> Joe Altimus
> Metadata Librarian
> Arizona State University Libraries
> 
> On Wed, Aug 12, 2009 at 1:59 AM, Ashley Sanders 
> <a.sanders@...
<mailto:a.sanders@...>> wrote:
> 
>     Jenn,
> 
> 
>         1) What type of data are you currently putting in the top-level
>         <extension> element?
> 
> 
>     We use the <extension> element for local holdings info and for non-roman
>     data. If a MARC record contains 880 fields, then we create a second
>     <mods> element using the 880s and stick it in <extension>. You can
>     see an example here:
> 
>       http://copac.ac.uk/search?ti=Qian+gu+zhi+mi&rn=1&format=XML+-+MODS
>     <http://copac.ac.uk/search?ti=Qian+gu+zhi+mi&rn=1&format=XML+-+MODS>
> 
> 
>         2) Do you have specific cases in which it would be helpful to
>         you to have <extension> inside a specific MODS element rather
>         than at the top level to convey additional semantics?
> 
> 
>     No.
> 
> 
>         3) Have you made changes to the MODS schema locally to allow for
>         additional elements not in the MODS schema?
> 
> 
>     No.
> 
>     Regards,
> 
>     Ashley.
>     -- 
>     Ashley Sanders               a.sanders@...
>     <mailto:a.sanders@...>
>     Copac http://copac.ac.uk A Mimas service funded by JISC
> 
> 

--

-- 
Ashley Sanders               a.sanders@...
Copac http://copac.ac.uk A Mimas service funded by JISC