Date:Thu, 8 Jun 2006 09:37:47 -0400
Reply-To:Metadata Object Description Schema List <[log in to unmask]>
Sender:Metadata Object Description Schema List <[log in to unmask]>
From:"Rebecca S. Guenther" <[log in to unmask]>
Subject:Re: Crosstown Traffic
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
I meant to respond to this one earlier.
There are many areas in MODS where you'd get richer metadata, so exposing
in MODS would be useful. In addition, it seems that the initial message
discussed using it with journal articles, which is something MODS handles
quite well (especially since we added the <part> element some time ago),
allowing for flexibility with citations.
Here's an example of a MODS record for an article (citing the information
about the journal issue in relatedItem):
http://www.loc.gov/standards/mods/v3/modsjournal.xml
Tony might also want to send his original note out to the SRU list for
further discussion.
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] ^^
^^ ^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Thu, 1 Jun 2006, Raymond Yee wrote:
> Hi Tony,
>
> Just to look at one angle of this problem. Let's say that I want to get
> a record that will be easily formatted for a scholarly bibliography. To
> that end, I want to distinguish between the given and family names of
> authors. The MODS specification provides for that distinction. See
> http://www.loc.gov/standards/mods/v3/modsjournal.xml for an example to see
>
> <name type="personal">
> <namePart type="given">Neil</namePart>
> <namePart type="family">Brenner</namePart>
>
> <role>
> <roleTerm type="text">author</roleTerm>
> </role>
> </name>
>
>
> Now, not all MODS records will nicely split out given vs family names.
> For example, the following LOC record
> http://z3950.loc.gov:7090/voyager?operation=searchRetrieve&version=1.1&query=title=%22Chaucer%20Life-%20Records%22&maximumRecords=10&recordSchema=mods3
> shows:
>
> <name type="personal">
> <namePart>Crow, Martin Michael</namePart>
>
> <namePart type="date">1901-</namePart>
> <role>
> <roleTerm authority="marcrelator" type="text">creator</roleTerm>
> </role>
> <role>
> <roleTerm type="text">ed.</roleTerm>
> </role>
>
> </name>
>
> Now, the fact that the name is written as "Crow, Martin Michael" does
> help over writing it simply as Martin Michael Crow.
>
> When I look at
> http://www.nature.com/nature/current_issue/rss/index.html (accessed
> today at around 6pm Pacific), I see
>
> <item rdf:about="http://dx.doi.org/10.1038/441574c">
> <title>Can the Internet save us from epidemics?</title>
> <link>http://dx.doi.org/10.1038/441574c</link>
> <description>SirKathleen Morrison, in News & Views (“Failure
> and how to avoid it” Nature440, 752–754; 2006), notes that
> societies have often prevented collapse by adopting new technological
> strategies. In today's world, where one of the most-talked about
> prospects for </description>
> <dc:title>Can the Internet save us from epidemics?</dc:title>
> <dc:creator>David M. Eagleman</dc:creator>
>
> <dc:identifier>doi:10.1038/441574c</dc:identifier>
> <dc:source>Nature 441, 574 (2006)
> </dc:source>
> <dc:date>2006-05-31</dc:date>
> <prism:publicationName>Nature</prism:publicationName>
> <prism:publicationDate>2006-05-31</prism:publicationDate>
> <prism:volume>441</prism:volume>
> <prism:number>7093</prism:number>
> <prism:section>Correspondence</prism:section>
> <prism:startingPage>574</prism:startingPage>
>
> <prism:endingPage>574</prism:endingPage>
>
>
> </item>
>
> My question: if you were to present this record in MODS, would you be
> parsing out David M. Eagleman to be family name = Eagleman and given
> name to be "David M.". That is, are we going to get metadata of finer
> granularity through MODS or ONIX than what you are currently putting
> out? If so, then I'd definitely be interested. If not, I would
> probably have code to parse out whatever you have (Since there is no
> universal agreement on the metadata specs and since I have had to deal
> with enough systems, whether you show me DC, or PRISM or MODS doesn't
> really matter -- unless you get metadata of finer granularity in one
> other the others.)
>
> There are other issues to consider -- but let me just throw in this one
> observation for now.
>
> -Raymond
>
> Tony Hammond wrote:
> > Hi All:
> >
> > In common with many other scholarly publishers Nature Publishing Group makes
> > citation level metadata available through its RSS feeds using the DC [1] and
> > PRISM [2] vocabularies, see
> >
> > http://www.nature.com/rss
> >
> > It is also experimenting an SRU wrapper service into its search indexes
> > again exposing result records in DC and PRISM, see
> >
> > http://nurture.nature.com/search
> >
> > Question: Would it be useful (or even helpful) to also expose this metadata
> > in MODS? As a complement to DC/PRISM? (And what about ONIX?) What is the
> > sweet spot for libraries/publishers? (We can't really do this without some
> > feedback from you guys. We may not have that level of imagination. Believe.
> > :~)
> >
> > What do libraries want? What do end-users want? What can publishers do to
> > improve the overall situation? To make our metadata feeds more widely
> > useful?
> >
> > Our general perception is that an open disclosure of our metadata records
> > will facilitate a third party service ecology which can only be of benefit
> > to all.
> >
> > Looking for answers. Pretty, please.
> >
> > Cheers,
> >
> > Tony
> >
> > --
> > Tony Hammond
> >
> > New Technology, Nature Publishing Group
> > 4 Crinan St., London N1 9XW, UK
> >
> > tel:+44-20-7843-4659
> > mailto:[log in to unmask]
> > --
> >
> > [1] http://dublincore.org/
> >
> > [2] http://prismstandard.org/
> >
> > "The Publishing Requirements for Industry Standard Metadata (PRISM)
> > specification defines an XML metadata vocabulary for syndicating,
> > aggregating, post-processing and multi-purposing magazine, news, catalog,
> > book, and mainstream journal content. PRISM provides a framework for the
> > interchange and preservation of content and metadata, a collection of
> > elements to describe that content, and a set of controlled vocabularies
> > listing the values for those elements."
> >
> > ********************************************************************************
> > DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
> > not the original intended recipient. If you have received this e-mail in error
> > please inform the sender and delete it from your mailbox or any other storage
> > mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
> > liability for any statements made which are clearly the sender's own and not
> > expressly made on behalf of Macmillan Publishers Limited or one of its agents.
> > Please note that neither Macmillan Publishers Limited nor any of its agents
> > accept any responsibility for viruses that may be contained in this e-mail or
> > its attachments and it is your responsibility to scan the e-mail and
> > attachments (if any). No contracts may be concluded on behalf of Macmillan
> > Publishers Limited or its agents by means of e-mail communication. Macmillan
> > Publishers Limited Registered in England and Wales with registered number 785998
> > Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
> > ********************************************************************************
> >
> >
>
>
> --
> --
> Raymond Yee 2195 Hearst (250-22)
> Technology Architect UC Berkeley
> Interactive University Project Berkeley, CA 94720-3810
> [log in to unmask] 510-642-0476 (work)
> http://iu.berkeley.edu/rdhyee 413-541-5683 (fax)
>
