This is not actually a change to MODS, but to the list of controlled
values at: http://www.loc.gov/marc/sourcecode/form/formlist.html

That list is a subset of those from the values in 008/23 and 008/29 (maps
and visual materials. We can certainly add large print, especially since
it's on the MARC list. We will do that.

Rebecca

On Sat, 18 Feb 2006, Mike Rylander wrote:

> 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' (
> http://www.oclc.org/bibformats/en/fixedfield/form.shtm ) 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
> up.
>
> 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
> http://open-ils.org
>