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
|