|
Hi Raymond:
Many thanks for your feedback. Fully understand where you're coming from.
Was just looking to see how we can establish a better cross-fertilization of
two different termsets (PRISM in the library world, and MODS in the
publisher world). Maybe one day. (The granularity thing of course is
interesting - but that may be a separate question.)
Cheers,
Tony
On 1/6/06 02:02, "Raymond Yee" <[log in to unmask]> wrote:1/6/06 02:02
> 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=t
> itle=%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
>> *****************************************************************************
>> ***
>>
>
|
