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 for an example to see

        <name type="personal">
            <namePart type="given">Neil</namePart>
            <namePart type="family">Brenner</namePart>

                <roleTerm type="text">author</roleTerm>

Now, not all MODS records will nicely split out given vs family names.  
For example, the following LOC record  

 <name type="personal">
   <namePart>Crow, Martin Michael</namePart>

   <namePart type="date">1901-</namePart>
     <roleTerm authority="marcrelator" type="text">creator</roleTerm>
     <roleTerm type="text">ed.</roleTerm>


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  (accessed 
today at around 6pm Pacific), I see

<item rdf:about="">
<title>Can the Internet save us from epidemics?</title>
<description>SirKathleen Morrison, in News &amp; Views (&#8220;Failure 
and how to avoid it&#8221; Nature440, 752&#8211;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:source>Nature 441,  574 (2006)



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.


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
> It is also experimenting an SRU wrapper service into its search indexes
> again exposing result records in DC and PRISM, see
> 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]
> [2]
> "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)           413-541-5683  (fax)