Date:Thu, 7 Apr 2005 18:46:17 -0400
Reply-To:Metadata Object Description Schema List <[log in to unmask]>
Sender:Metadata Object Description Schema List <[log in to unmask]>
From:"Sally H. McCallum" <[log in to unmask]>
Subject:Re: MODS version 3.1
Comments:To: Metadata Object Description Schema List <[log in to unmask]>
In-Reply-To:<[log in to unmask]>
Content-Type:text/plain; charset="us-ascii"
Rebecca, I do not remember agreeing that nameTitle should be defined? Sally
At 04:50 PM 4/7/2005 -0400, you wrote:
>We are preparing for MODS version 3.1. The primary need is to incorporate
>the changes in mods-for-mads.xsd so that MADS may reference MODS elements
>instead of repeating them. There are several other changes that have been
>discussed on this list or are small additions that we would like to
>incorporate at this time.
>
>These changes are generally additions or corrections and do not invalidate
>existing MODS instances. Thus, an incremental version number.
>
>We also have a list of more substantive changes that will affect existing
>instances or require broader discussion. I will circulate these separately
>as candidates for MODS 4.0.
>
>Following are the changes with links to the MODS archives where there has
>been previous discussion (I've included the messages with summaries of the
>issues). Please review the previous messages if necessary, since we
>probably don't want to have the same discussions again.
>
>1. Implement the reorganization in mods-for-mads.xsd
>see: http://www.loc.gov/mads/mods-for-mads.xsd
>Rationale: necessary for implementation of MADS, since it uses MODS
>structures.
>
>2. Change <coordinates> to not be required under <geographic>.
>Rationale: This was an oversight/error.
>
>3. Define <part> under <mods>, not just <relatedItem>. Take out
>documentation (in MODS guidelines) restricting <relatedItem> to
>type="host".
>Discussion:
>http://listserv.loc.gov/cgi-bin/wa?A2=ind0501&L=mods&T=0&F=&S=&X=6B08E338A3
DB0F5B48&P=7151
>and
>http://listserv.loc.gov/cgi-bin/wa?A2=ind0501&L=mods&T=0&F=&S=&X=7C0B4C4855
0B393709&P=8609
>
>4. Define <nameTitle> with subelements <name> and <title> as a top level
>element. This would give the option to explicitly indicate a compound work
>identifier, i.e. a uniform title entered under author to correspond with
>1XX/240 or 700$a$t rather than a relatedItem subrecord.
>Discussion:
>http://listserv.loc.gov/cgi-bin/wa?A2=ind0502&L=mods&T=0&F=&S=&X=7C0B4C4855
0B393709&P=7848
>(Rebecca Guenther, Feb. 28, 2005)
>and
>http://listserv.loc.gov/cgi-bin/wa?A2=ind0503&L=mods&T=0&F=&S=&X=7C0B4C4855
0B393709&P=1064
>(Stephen Hearn, Mar. 2, 2005)
>
>By including as a top level element of course <nameTitle> could also be
>under <relatedItem> (which includes everything under <mods>). We see it
>used at the top level when it is the compound identifier for the work
>being described itself and under relatedItem when it's contained in the
>larger work.
>
>5. Addition of attribute "objectPart" to <language> to indicate language
>of what part of the resource described (to be distinguished from the lang
>and xml:lang attributes, which refer to language of the value in the tag).
>e.g. <language objectPart="summary" authority="iso639-2b">spa</language>
>indicates that only the summary is in Spanish.
>Rationale: there is no way to indicate that the language specified is for
>something other than the entire text.
>
>6. Add attribute "type" to dateOther to specify other kinds of dates. (Not
>enumerated list).
>Rationale: Everyone has their favorite date type associated with specific
>materials. MODS enumerates the most important ones as specified by users,
>but could allow for extensibility for other types of dates by including
>this.
>
>7. Changes for the emerging content standard Cataloging Cultural Objects:
>http://www.vraweb.org/CCOweb/
>
>7.1. add attribute "type" to <genre>
>Rationale: to distinguish different aspects of genre: in CCO this includes
>class, work type, style.
>
>7.2. add attribute "type" to <form> under <physicalDescription>
>Rationale: to be able to specify whether the form concerns materials or
>techniques.e.g. type="material": oil paint; type="technique": painting
>
>7.3. add attribute "type" to <physicalLocation> under <location>
>Rationale: to indicate different kinds of locations, e.g. current,
>discovery, former, creation
>
>8. Allow for empty elements for xlinked elements.
>Rationale: xlink is an attribute, so the element with which it's
>associated may be empty if only a link and no text is needed.
>
>9. Add displayLabel attribute in <classification>.
>Rationale: corresponds to MARC 050$3 (materials specified).
>This is needed for instance for mapping to LC's American Memory
>records.
>
>We are working on incorporating these changes into the schema.
>
>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] ^^
>^^ ^^
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
********************************************************
Sally H. McCallum, Chief, Network Development and
MARC Standards Office, Library of Congress
Washington, DC 20540 USA
smcc@loc.gov (Fax: 1-202-707 0115) (Voice: 1-202-707 5119)
[log in to unmask] (Fax: 1-202-707 0115) (Voice: 1-202-707 5119)
********************************************************
