Many thanks for this Rebecca. Most useful. Will take a closer look and see
what might be done - and also think about author granularity, what we have,



Re the SRU questions, I have been and am posting to the SRU list.

Fwiw - and in light of Karen C.'s comments about not having seen PRISM in
action before, I thought I could just dump the 51 elements in the PRISM
namespace here just to give a flavour of what the PRISM term set is
attempting to cover:

 "byteCount category complianceProfile copyright corporateEntity
  coverDate coverDisplayDate creationDate distributor edition
  eIssn embargoDate endingPage event expirationDate hasAlternative
  hasCorrection hasFormat hasPart hasPreviousVersion hasTranslation
  industry isCorrectionOf isFormatOf isPartOf isReferencedBy
  isRequiredBy issn issueIdentifier issueName isTranslationOf
  isVersionOf location modificationDate number objectTitle
  organization person publicationDate publicationName receptionDate
  references requires rightsAgent section startingPage subsection1
  subsection2 teaser volume wordCount"

Note that these would typically be used with the regular 15 DC elements.
(There are also 3 more specialist, narrower term sets for rights, controlled
vocabularies, and inline markup -  but generally we are just using DC and

Wonder sometimes if this is not unlike the Chunnel with PRISM at one end and
MODS at the other. (Maybe there's light at the end of the tunnel. :)

On 8/6/06 14:37, "Rebecca S. Guenther" <[log in to unmask]> wrote:8/6/06 14:37

> 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):
> 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
>> 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
>> 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 
>>  (accessed
>> today at around 6pm Pacific), I see
>> <item rdf:about="">
>> <title>Can the Internet save us from epidemics?</title>
>> <link></link>
>> <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: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
>>> 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)