 |
 |
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