While you're talking about minor changes to MODS, I have one other
change I'd like to request.  It's really just and extension to the
current set of physicalDescription/form elements. You've combined
'Regular Print Reproduction' and 'Large Print' ( ) into just
'print'.  While I'm not a cataloger and thus can't intuit the reasons
behind the merge, I can tell you that, at least in our public
libraries, it would be a huge boon to us to be able to tell large
print records for regular reproductions without having to go back to
the MARC to check.

I realize that we could do this with a local change to the stylesheet,
but I imagine that it would benefit others, so I thought I'd bring it

Thanks for all your work on MODS!

On 2/17/06, Rebecca S. Guenther <[log in to unmask]> wrote:
> We would like to make some minor changes to MODS for a version 3.2. This
> will be considered an incremental version in that it will not invalidate
> existing records. We plan to work on more extensive changes in a version
> 4.0 in the near future.
> Proposed changes for MODS v. 3.2
> 1. Add an attribute linkInfo to <location><url> to allow for notes
> associated with the link (MARC 856$z). (For DLF Registry of Digital
> Masters)
> We first considered adding an element like <urlNote>, but decided on an
> attribute because this note is associated with the URL. You could have a
> <physicalLocation> (for the repository that is responsible for the
> resource) and <url> (for the URL of the resource) that are bound together
> in a <location> container. So just adding a note under <location> wouldn't
> tell you whether it belongs with <physicalLocation> or <url>. It is
> associated with the link given in <url>, so an attribute seemed
> appropriate.
> 2. Add enumerated values under digitalOrigin to accommodate more of those
> in MARC ER 007/11 (Antecendent/source)
> (also for DLF Registry of Digital Masters)
> Now the MODS values are:
> born digital
> reformatted digital (which means reformatted to digital from the original)
> We want to add:
> digitized microfilm (MARC code b)
> digitized other analog (MARC code d)
> In the next full version of MODS (4.0) we could change "reformatted
> digital" to something more precise (to bring out that it means digitized
> from analog). Since this version should not invalidate existing instances,
> we would not want to make that change now.
> 3. Add ID attribute to part element.   This will allow the element to be
> referred by an IDREF attribute from within the same document. When MODS is
> used in METS documents, we need to be able to reference MODS relatedItem
> and part elements using the METS div DMDID attribute (which is an IDREF
> type). This makes it possible to associate particular entities represented
> by divs in the structMap with particular descriptive information.
> 4. Restore ID attribute to relatedItem element. (It disappeared
> inadvertently from Version 3.1-- was in 3.0).
> 5. Allow part element to be optionally empty (for when the ID and type
> attribute values contain all the information needed about the part).
> Example:
> <mods:relatedItem ID="DMD_article01" type="constituent">
>   <mods:titleInfo>
>     <mods:title>Wien, 10. mai.</mods:title>
>   </mods:titleInfo>
>   <mods:genre>article</mods:genre>
>   <mods:part ID="DMD_article01_para01" type="paragraph"/>
>   <mods:part ID="DMD_article01_para02" type="paragraph"/>
> </mods:relatedItem>
> The idea is that it is possible to use the part element plus type
> attribute to note the existence of paragraphs (as suggested in the
> MODS Outline of Elements and Attributes). Given that the above construct
> expresses all I needed to express (i.e. the existence of a sequence of
> paragraphs in document order) it renders the text subelement
> superfluous. Currently the text child element (or one of the other child
> elements- detail, extent, or date- are required.
> <mods:relatedItem ID="DMD_article01" type="constituent">
>   <mods:titleInfo>
>     <mods:title>Wien, 10. mai.</mods:title>
>   </mods:titleInfo>
>   <mods:genre>article</mods:genre>
>   <mods:part ID="DMD_article01_para01" type="paragraph">
>     <mods:text/>
>   </mods:part>
>   <mods:part ID="DMD_article01_para02" type="paragraph">
>     <mods:text/>
>   </mods:part>
> </mods:relatedItem>
> 6. Make a few elements global that are referenced in the DCMI Library
> Application Profile (these are subelements under other elements):
> dateCaptured (under <originInfo)
> edition (under <originInfo>
> physicalLocation (under <location>)
> 7. Addition of collection description elements
> Most of the elements in the DCMI Collection Description Profile map
> already to MODS. We are thinking we should provide for them all, since in
> many cases people will be exposing their metadata in OAI as MODS, but
> there may be collection description information they want along with their
> items that are exposed as MODS. So the following are the elements that
> would need to be added:
> Accrual periodicity: defined as "The frequency with which items are
> added to a collection" MODS has frequency under <originInfo>, although
> this is uncontrolled text and is under <originInfo> (and used for MARC 310
> information). That is used for the frequency of a publication as opposed
> to the frequency of adding something to a collection. But then if what you
> are describing is a collection you probably could use this frequency and
> add an authority for a controlled list of values.
> Accrual method: in MARC holdings this is Method of acquisition (008/07)
> Accrual policy: in MARC holdings similar to Receipt or acquisition status
> (008/06).
> If this will require a lot of discussion I'd rather wait until the next
> full version of MODS, since we want to get 3.2 out. If people think we
> should pursue it now because they think it's important to have it right
> away, I'll suggest some elements.
> Comments welcome. We'd like to be able to put out a new schema in a few
> weeks.
> Rebecca
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^  Rebecca S. Guenther                                   ^^
> ^^  Senior Networking and Standards Specialist            ^^
> ^^  Network Development and MARC Standards Office         ^^
> ^^  1st and Independence Ave. SE                          ^^
> ^^  Library of Congress                                   ^^
> ^^  Washington, DC 20540-4402                             ^^
> ^^  (202) 707-5092 (voice)    (202) 707-0115 (FAX)        ^^
> ^^  [log in to unmask]                                          ^^
> ^^                                                        ^^
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Mike Rylander
[log in to unmask]
GPLS -- PINES Development
Database Developer