Recommendations on RSS Feeds for Scholarly Publishers

Version

Status

Contents

1. Introduction

The JISC funded ticTOCs project has developed a service to enable users to discover, subscribe to, and re-use Table of Contents (TOC) RSS feeds for thousands of journals from a wide range of publishers.

The initial phase of the project included analysis of publishers current practices with regard to the provision of RSS TOCs. The analysis revealed a range of issues which may impact on the ability of end users and feed aggregators to effectively utilize feeds.

Just because a particular publisher’s feed "looks good" in the major feed readers isn't enough to make said feed truly usable. RSS feeds are designed to be aggregated. When aggregated, even minor variations in feeds can be greatly distracting and make for an unpleasant user experience. For instance, there is currently wide variation amongst scholarly publishers in the use of the <channel><title>  element.  Examples encountered after having looked at only ten publishers during the early stages of the ticTOCs project included:

<title>Nature</title>

<title>BMJ Current Issue</title>

<title>British Journal of Visual Impairment current issue</title>

<title>Journal of Geophysics and Engineering latest papers</title>

<title>British Journal of Criminology – current issue</title>

<title>Journal of managerial psychology: table of contents</title>

<title>Science Direct Publication: Biochemical and Biophysical research communications</title>

<title>SpringerLink - Journal</title>

<title>Blackwell Synergy: International Journal of Cosmetic Science: Table of Contents</title>

<title>NATURE –LONDON-</title> 

Variations in practice amongst publisher feeds can be irritating for end-users, but they can be insurmountable for automated processes. RSS feeds are increasingly being consumed by knowledge discovery and data mining services. In these cases, variations in date formats,  the practice of lumping all authors together in one <dc:creator> element, or generating invalid XML can render the RSS feed useless to the service accessing it.

The draft recommendations below are a result of this initial analysis and are ultimately intended to facilitate good practice in the production and provision of TOC RSS Feeds. The guidelines include general recommendations for good practice, specific recommendations on the use of RSS Modules and an example RSS TOC feed. Ultimately, we expect that industry wide adoption of these best practices will help drive more traffic to publisher web sites. Note that most of these recommendation can also be applied to non-TOC RSS feeds such as thematic feeds, automated search result feeds, etc.

The Best Practice recommendation group included the following members:

• Geoffrey Bilder (CrossRef)
• Leigh Dodds (Talis)
• Tony Hammond (Nature Publishing Group)
• Richard O'Beirne (Oxford University Press)
• Lisa Rogers (ICBL, Heriot-Watt University)

The recommendations were based on early work developed by Malcolm Moffat (ICBL, Heriot-Watt University).

Your feedback and comments are much appreciated. Please email rss_best_practice@crossref.org

2. General Recommendations for Good Practice

• Use the RSS 1.0 specification because of its greater flexibility. RSS 1.0 extended with RSS 1.0 modules is ideally suited to the provision of RSS table of contents type materials. A number of publishers are already utilising this approach. Some publishers offer a choice of formats for their TOCs (e.g. RSS 1.0 and RSS 2.0).

• Use RSS 1.0 Modules (e.g. Dublin Core Module, CONTENT Module and PRISM Module) to extend TOC RSS feed functionality [see details and examples below].

• Validate TOC RSS feeds using an RSS validation tool.(e.g.W3C feed Validator or Redland RSS 1.0 validator).

• Do not include HTML markup in standard RSS Feed elements e.g. Avoid using HTML tags (such as <b> <p> <a href> etc) in the <item><description> element. The <item><description> should only include plain text as it is not possible to know how the feed will be presented and including markup can prevent your feed from being correctly displayed.

• Do not include empty elements if no data for that element is available.

• Expose article metadata in your feeds using Dublin Core and PRISM modules. Researchers are increasingly making use of online social citation and bibliographic management tools that can take advantage of embedded metadata in RSS feeds. These tools, in turn, allow researchers to consistently format and link citations back to publisher content. 

• Include abstracts/summaries in your feeds. There is increasing evidence that providing users with more information in a feed will drive more users to your site. Conversely, there is also evidence that users will choose not to subscribe to "partial-feeds" due to the inconvenience associated with reading them. The “full vs partial feed” is the subject of intense debate. At the very least you should familiarize yourself with the issue before making a decision about whether or not to include abstracts/summaries in your feeds.

• Use the RSS 1.0 Content Module to present HTML marked up content. For example the <content:encoded> element can be used to provide an alternative marked up version of the <item><description> [see details and examples below].

• Do not restrict access to TOC RSS feeds. RSS is an excellent and cost-effective way of driving traffic to, and increasing brand awareness of publisher's content. Restricting access to the feeds themselves (e.g. to subscribers only) negates many of the potential benefits that RSS can bring.

• Understand the purpose of each RSS TOC feed you provide. Provide multiple feeds, rather than diluting the message of one with information irrelevant to its audience. For example it may be appropriate to provide separate feeds for the current TOC issue only and a combined TOC for a number of recent issues.

• Ensure your web server is configured to serve RSS files using a media type of application/xml. Using the correct mime types allow client-side applications such as browsers and feed readers to more accurately identify and process content. See Section 9 "Notes on Media Types" for further discussion.

• Provide OPML files to enable aggregators or end users to utilise a number of your feeds. In some instances it may be appropriate to provide a range of OPML files (e.g. OPML files for each subject category) or to enable end users to create custom OPML files on the fly.

• Name your feeds correctly. The title of the RSS feed is encoded in a number of places:

   

  • the /opml/body/outline[@title] attribute of the outline element in an OPML file

  • the /rdf/channel/title element in the RSS feed

    
    

As discussed above, RSS feeds are designed to be read in aggregate. When RSS feeds from different sources are intermingled in one view, variations in the content and formatting of the title element can become distracting and/or confusing.  Most of these variations in title formatting amongst publishers occur because the publisher has chosen to "annotate" the title with a description of the feed (e.g. "current issue", "latest papers", "table of contents", etc.). These annotations can vary in their naming conventions, their formatting and their placement (e.g. prepended or appended). In addition to being confusing to the researcher, such variations in the title element make it difficult for automated processes to make sense of the title as they have no consistent way of distinguishing the actual content of the title element from the annotation.

The practice of annotating the title channel should generally be deprecated. Ideally, if explanatory text is needed to describe the feed, then this should be placed in the <description> element of the feed. 

However, some might object that RSS readers do not consistently make use of the feed description element and that title annotations are still necessary in order to allow users to distinguish between different feeds. In this case we recommend that such annotations be confined to non table of content feeds (e.g. saved searches, "most cited articles", etc.) and that the RSS feed for the <title> element for table of contents for the current issue should only contain the official name of the publication. 

Finally, in order to introduce some constancy where annotations are included, publishers should:

• Append (rather than prepend) annotations to the title. This helps to ensure that the actual title of the feed does not get truncated when display space is tight.  
• Delineate the annotation in square brackets so that automated processes can more easily distinguish the content of the title element from the annotation.

Thus, the title of the TOC feed for the current issue of the Journal of Psychoceramics would be encoded like this:

<title>Journal of Psychoceramics</title>

Where as the feed of most cited articles from the Journal of Psychoceramics would be encoded like this:

<title>Journal of Psychoceramics [most cited articles]</title>

• Normalize formatting quirks inherited from journal style guidelines. RSS feeds are designed to be read in aggregate. Feeds from many publishers and titles will often be mixed together in a feed reader. This means that stylistic formatting quirks that are transfered from the journal's metadata, such as all-cap titles, will appear distracting when viewed within a feed.

3. Recommendations for Use of RSS Modules

RSS 1.0 Modules are XML-namespace based compartmentalised extensions to RSS 1.0. This namespace based modularization allows RSS 1.0 to be extended without the need for rewrites of the core RSS 1.0 specification and without the need for consensus on each and every element. In a nutshell, RSS 1.0 Modules allow the basic RSS 1.0 format to be extended in standard ways by specifying which modules and namespaces are being used. A range of Standard and Proposed RSS 1.0 modules are available which enable RSS 1.0 to be extended in a multitude of ways (e.g. provision of information on feed status or frequency of feed updates, and extension for use with audio or wiki type content).

From the perspective of TOC feeds four RSS 1.0 modules are particularly relevant:

1. Admin Module

   mod_admin provides administrative properties that can be used to help improve the robustness and reliability of broad RSS usage between providers, aggregators, clients, and other users.

2. Content Module

   mod_content is a module to extend RSS to permit the inclusion of actual content rather than just metadata descriptions of content.

3. Dublin Core Module

   mod_dc is a module to extend RSS via the use of the Dublin Core element set

4. PRISM Module

   mod_prism is a module to extend RSS via the use of the PRISM element set.

Full details of these modules can be found from the links above. The remainder of this section attempts to provide brief outlines of these three modules along with examples of commonly used elements and short notes on their usage.

3.1 Admin Module

 The RSS 1.0 Admin Module 'mod_admin' provides two useful properties that can be added to an RSS feed in order to provide a means for consumers of a feed to provide feedback on errors encountered in the feed. This kind of mechanism is essential in a large syndication network in which feeds may be aggregated and re-syndicated before reaching the eventual consumer: there needs to be clear labelling within the feed itself as the client may not be consuming it from its original location.

The two additional elements that the admin module specifies are as follows:

• The first and most important piece of information is a means for submitting error reports. The admin:errorReportsTo element should contain a URI that can be used to report any problem with the RSS feed. In the most typical scenario this URI will be a mailto: URI that provides an email address of a person, an email alias that may forward messages to one or more people, or an automated bug tracking system that will capture the error report for later review. The preferred mechanism is up to the publisher, although a mail alias is the simplest and least brittle approach, allowing messages to be handled manually if necessary but without introducing a personal email address into the feed.

• The second element defined in the specification is the admin:generatorAgent element. This should be a unique URI that identifies the application that generated the RSS feed, i.e. a URI that identifies the software rather than the website of origin. Providing this additional information provides a means for identifying feeds that may all suffer from a common problem (because of a consistent bug in the software), or a feed that was generated by an older version of some software containing a problem that has subsequently been fixed. The latter scenario is relevant when one considers that RSS feeds may be aggregated and stored for some time.

The following example illustrates the usage of each element. Note that as the values of both elements are URIs, and are hence pointers to other web resources, then the "rdf:resource" attribute is used rather than element content.

<channel rdf:about="...">

<admin:generatorAgent rdf:resource="http://www.example.org/software/platform/1.0"/>

<admin:errorReportsTo rdf:resource="mailto:errors@example.org"/>

</channel>

3.2 Content Module 

The RSS 1.0 Content Module 'mod_content' was originally intended to allow RSS 1.0 to be extended to permit the inclusion actual content, rather than just metadata descriptions, within RSS 1.0. It has, however, become common practice to use this module to enable inclusion of HTML marked up versions of <item><descriptions> within feeds. This is accomplished by the use of the <content:encoded> element as illustrated below.

Using the RSS 1.0 Content module in this way allows both metadata descriptions and HTML marked up content to be simultaneously presented within a feed. Aggregators, feed readers, and other third parties can then choose which form to utilise.

3.3 Dublin Core Module 

The RSS 1.0 Dublin Core Module 'mod_dc' allows RSS 1.0 to be extended to utilise the Dublin Core Metadata Element Set.

Typically used elements include:

Usage Notes:

• <dc:creator> A 'creator' is an entity primarily responsible for making the content of the resource. Examples of a 'creator' include a person, an organization, or a service. According to the Dublin Core Usage Guide "Creators should be listed separately, preferably in the same order that they appear in the publication. Personal names should be listed surname or family name first, followed by forename or given name. When in doubt, give the name as it appears, and do not invert."

• <dc:date> The recommended best practice for encoding the date value is defined in a profile of

  ISO 8601 [W3CDTF] and follows the YYYY-MM-DD format.

• <dc:identifier> An 'identifier' is an unambiguous reference to the resource within a given context. The recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system such as the Digital Object Identifier (DOI).

• <dc:language> The recommended best practice for the values of the Language element is defined by RFC 1766 [RFC1766] which includes a two-letter Language Code (taken from the ISO 639 standard [ISO639]), followed optionally, by a two-letter Country Code (taken from the ISO 3166 standard [ISO3166]). For example, 'en' for English, 'fr' for French, or 'en-GB' for English used in the United Kingdom. Generally, this document recomends that Country Code not be used to qualify the Language Code as this will have the widest acceptance by downstream applications (i.e. 'en' for English should be preferred to 'en-GB' or 'en-US').

See the Dublin Core Usage Guide for further details on the usage of individual dublin core elements.

3.4 PRISM Module 

The RSS 1.0 PRISM Module 'mod_prism' allows RSS 1.0 to be extended to utilise the PRISM specification (Publisher Requirements for Industry Standard Metadata). Basically the PRISM element set comprises of a range of metadata elements specifically selected for use in electronic publishing contexts and is therefore highly appropriate for use within TOC related RSS feeds.

Typically used elements include:

* Elements require use of PRISM 2.0 namespace (or above), otherwise PRISM 1.2 namespace is sufficient.

Usage Notes: 

• <prism:doi> The DOI should be given in "bare" form, i.e. without the "doi:" prefix which is to be used in citation formats (and also used within the <dc:identifier> element).

• <prism:publicationDate> The Publication Date is defined as "Announced date and time when the resource is released to the public...The publication date for an issue is the date that it became available for sale." It is NOT the cover date, which is covered by the prism:coverDate and prism:coverDisplayDate elements. Recommended best practice is to use the ISO 8601 [W3CDTF] which follows the YYYY-MM-DD format.

• <prism:url> The URL should be URL for the article specified using the DOI with the DOI Proxy Server, e.g. "http://0-dx-doi-org.libus.csd.mu.edu/10.1093/bjc/azn067". It must not be the URL of the final article.

This document strongly recommends the use of PRISM 2.0 (or above) as this allows for the direct inclusion of DOI and associated URL into feeds.

See the PRISM specifications for further details on individual PRISM elements. 

4. Example RSS 1.0 TOC Feed

An example RSS 1.0 TOC feed utilising the the Admin, Content, Dublin Core and PRISM modules is available here. Both <channel> and <item> elements are shown below.

4.1 Example <channel> element

<channel rdf:about="http://0-www-nature-com.libus.csd.mu.edu/nature/current_issue/rss">

<title>Nature</title>

<description>Nature is a weekly international journal publishing the finest peer-reviewed research in all fields of science and technology on the basis of its originality, importance, interdisciplinary interest, timeliness, accessibility, elegance and surprising conclusions. Nature also provides rapid, authoritative, insightful and arresting news and interpretation of topical and coming trends affecting science, scientists and the wider public.</description>

<link>http://0-www-nature-com.libus.csd.mu.edu/nature/current_issue/</link>

<admin:generatorAgent rdf:resource="http://0-www-nature-com.libus.csd.mu.edu/"/>

<admin:errorReportsTo rdf:resource="mailto:feedback@nature.com"/>

<dc:publisher>Nature Publishing Group</dc:publisher>

<dc:language>en</dc:language>

<dc:rights>© 2009 Nature Publishing Group</dc:rights>

<prism:publicationName>Nature</prism:publicationName>

<prism:issn>0028-0836</prism:issn>

<prism:eIssn>1476-4679</prism:eIssn>

<prism:copyright>© 2009 Nature Publishing Group</prism:copyright>

<prism:rightsAgent>permissions@nature.com</prism:rightsAgent>

<image rdf:resource="http://0-www-nature-com.libus.csd.mu.edu/includes/rj_globnavimages/nature_logo.gif"/>

<items>

4.2 Example <item> element

<head>
<title>Journal of Tree Studies</title>

<link rel="alternate" title="Journal of Tree Studies" href="http://www.example.org/journals/trees.rss" type="application/rss+xml">
</head>

<opml version="2.0">
  <head>
    <title>RSS Feeds for Botany</title>
  </head>
  <body>
    <outline title="Journal of Flowers" type="rss"
             xmlUrl="http://www.example.org/journal/flowers/latest.rss"
             htmlUrl="http://www.example.org/journal/flowers/latest"/>
    <outline title="Journal of Trees" type="rss"
             xmlUrl="http://www.example.org/journal/trees/latest.rss"
             htmlUrl="http://www.example.org/journal/trees/latest"/>
  </body>
</opml>

6. Guidelines on Gathering Statistics on RSS Usage

6.1 Caveat about statistics

Gathering meaningful usage statistics on your RSS usage is probably even more fraught and difficult to do than gathering regular web statistics. This is due to a number of idiosyncrasies around RSS usage, including:

• Web based RSS aggregators (e.g. Bloglines, Google Reader) serve as proxies for many users.

• All feed readers (including browsers and email clients with RSS reading capabilities) will automatically download feeds multiple times a day

• There is an increase in specialized applications for filtering and re-syndicating RSS feeds. We expect to see more of these developed by librarians and researchers.

There are generally three major types of statistics that you may want to gather about your RSS usage:

• Subscribers

• Clickthroughs

• Impressions

Each is discussed in more detail below.

6.2 Subscribers from Aggregated Services 

There is evidence that the vast majority of RSS consumption occurs through one of the major feed aggregators, Google, iGoogle, MyYahoo, Bloglines, etc.

The good news is that web based feed readers are generally well-behaved and, when their bots retrieve your RSS feeds, they will typically use the UserAgent string to inform you of how many subscribers they have to the feed they are retrieving. So, for instance looking in your web server logs you might see an entry like this:

GET /journal_of_psychoceramics/toc_rss1.xml - x.x.x.x HTTP/1.1 Bloglines/3.1+(http://www.bloglines.com;+43+subscribers)

Which indicates that there are 43 Bloglines subscribers to the “Journal of Psychoceramics” RSS feed. Obviously, if you offer your RSS feed in multiple formats (RSS 1, RSS 2, ATOM), you would need to sum the subscribers of all the formats to get an overall count.

The bad news is that the term “subscribers” does not mean “active subscribers”. In other words, this statistic gives no evidence that said subscribers are actually reading your feeds (or that they even continue to use the BlogLines service). It is also possible that some “subscribers” have subscribed to your content in multiple systems. For example, a user moving from using BlogLines to Google Reader is unlikely to delete their old BlogLines subscriptions and therefor all of their subscriptions might be double-counted.

Still, the subscriber count not not entirely useless. At the very least the act of subscribing to somethig usually indicates interest and intent.

6.3 Click-Throughs 

Measuring “click-throughs” might  give one a better idea of how many people are actually actively engaged with your content, though one has to be careful to not sacrifice user experience for the sake of accurate statistics. As discussed above, creating a “partial feed” and forcing a user to click-through to your site in order to get an article abstract just so that you can boost your click-through statistics may ultimately be counter-productive. Again, at the very least you should familiarize yourself with the “full vs partial feed” debate before making a decision about how much you want to depend on click-throughs for measuring usage of your RSS feeds.

Gathering click-through statistics from RSS feeds is generally accomplished by making sure that links in the RSS feed are encoded in some way that lets the publisher look at the referrer and determine that the link was followed from an RSS feed. This is often done by appending parameters to the link url.

 If you generate your RSS feeds dynamically, you might even wish to customize the links based on the UserAgent of the application retrieving the feed:

We recommend that, where possible, Scholarly publishers use the DOI to link to their content. In order to measure click-throughs and still use the DOI for linking to your content, you will want to structure your links using DOI Parameter Passing. In practice, this would mean that a link to an article that might normally be recorded like this: 

 Would instead be encoded like this:

Note that for DOI parameter passing to work, the publisher must have implemented a service capable of using the nested parameters and have agreed to participate in DOI Parameter Passing.

6.4 Impressions 

Again, one of the problems with gathering statistics on RSS uptake is that the act of reading an RSS feed  entry does not normally trigger a page GET on your site. One way in which publishers have tried to get around this is to embed uniquely named, invisible graphic in the feed item. This way, any rendering of the RSS feed item would trigger a GET of the graphic from your site. In theory, this should mean that you should be able to detect when a particular item is being read, but in practice this technique is not very accurate because:

• Some feed readers render all RSS posts, regardless of whether a user is actually reading the post. For example, this occurs when scrolling through a list of entries in Google Reader.

•  Many feed readers will cache content for offline viewing

•  Some feed readers or bots consuming RSS feeds might strip posts of graphics.

7. Incorporating Licensing Information into RSS Feeds

As noted in the introduction to these recommendations, RSS feeds are increasingly used for purposes beyond simply syndicating information to users: feeds are also typically processed, aggregated and repurposed as part of a growing range of knowledge discovery and data mining services. The recommendations in this document aim to support and encourage these diverse users by ensuring that there is rich, well-expressed metadata included in each feed.

However to properly enable these forms, RSS feeds should ideally be clearly annotated with some form of rights statement. Publishers are encouraged to consider the license to reuse metadata embedded in their feeds, such reuses are likely to cover both commercial and non-commercial uses of the data.

The Creative Commons website defines a standard way to include licensing metadata in an RSS 1.0 feed. This approach allows a publisher to use any of the existing range of Creative Commons licensing options and to also provide pointers to additional licensing terms, e.g. to directly enable academic (non-commercial) usage, but require additional agreements for commercial usage.

8. Tools for Creating and Validating Your RSS Feeds

8.1 Creation

These are as many methods for creating RSS Feeds as there are for creating HTML web pages. Here is a brief summary of some of the methods.

• Manual Coding. This is not a desirable option as it is very time consuming – however for publishers of single journals it may be a viable option. 

• Online/Desktop Creation Tools. There are many generic tools for creating Feeds, however many of these tools do not support the use of modules. 

• Content Management Systems. Many content management system have the option to export metadata in RSS format. Open Journal Systems [http://pkp.sfu.ca/?q=ojs] is one example specifically for Journal tables of contents which has an RSS plugin to export feeds in a variety of formats, included RSS 1.0 with DC and PRISM modules. 

• Databases. RSS feeds can be generated from data stored in a database.

8.2 Validation

It is essential that Feeds and OPML files are valid. Here are some online validation tools.

• Feed Validator for Atom and RSS

  • http://feedvalidator.org/

     

• W3C Feed Validation Service, for Atom and RSS

  • http://validator.w3.org/feed/

     

• OPML Validator Beta

  • http://validator.opml.org

Note that the above-mentioned validation tools will only verify that Feeds or OPML files are valid, they will not confirm that they follow the best practices recommended here. CrossRef will develop and host a tool that can be used to confirm that your feeds are both valid and that they conform to these recommendations. We will update this document with a link to the tool when it is ready for use.

9. Notes on Media Types

This section provides some additional discussion on the correct use of media types for RSS feeds.

Media types are an important feature of the web architecture that enable browsers and other user agents (e.g. RSS feed readers) to correctly identify and process content that they retrieve from the web. In the context of RSS this is particularly important as without using the correct media type, a user may by shown XML markup rather than being offered the option to subscribe to an RSS feed using their configured feed reader.

Several mimetypes have been commonly used or recommended for use for delivering RSS feeds. This advice is often contradictory and does not always take into account all relevant use cases. These recommendations take a pragmatic approach that attempts to address the most common issues. The following table outlines some commonly used media types and the issues related to them:

To encourage the use of standardised media types, this document therefore recommends the use of application/xml as the default media type for delivering RSS feeds. It is also recommended that feeds are delivered with UTF-8 character encoding, requiring that the feed be delivered with a content type of: application/xml; encoding=UTF-8.

Note: this might seemingly introduce a slight discrepancy between the recommended media type for delivering an RSS feed, and the media type used to link to an RSS feed from an RSS Autodiscovery link. In the latter case, a media type of application/rss+xml. However it is important to recognise that in the case of linking to a feed, the media type is being used simply as a label, it does not define the processing behaviour of the feed reader.

A. Example Atom TOC Feed

An example Atom TOC feed based on the cut-down (and slightly modified) version of the example RSS feed given in Sect. 4 is shown here for illustrative purposes only. Both <feed> and <entry> elements are displayed.

A.1 Example <feed> element

A.2 Example <entry> element

<entry>

<id/>

<title>Structure-based activity prediction for an enzyme of unknown function</title>

<link rel="alternate" type="text/html" href="http://0-dx-doi-org.libus.csd.mu.edu/10.1038/nature05981"/>

<summary>With many genomes sequenced, a pressing challenge in biology is predicting the function of the proteins that the genes encode. When proteins are unrelated to others of known activity, bioinformatics inference for function becomes problematic. It would thus be useful to interrogate protein structures for </summary>

<updated/>

<author>

<name>...</name>

</author>

<content type="xhtml">

<div xmlns="http://www.w3.org/1999/xhtml">

<p><b>Structure-based activity prediction for an enzyme of unknown function</b></p>

<p>Nature 448, 775 (2007). <a href="http://0-dx-doi-org.libus.csd.mu.edu/10.1038/nature05981">doi:10.1038/nature05981</a>

</p><p>Authors: Johannes C. Hermann, Ricardo Marti-Arbona, Alexander A. Fedorov, Elena Fedorov, Steven C. Almo, Brian K. Shoichet & Frank M. Raushel</p><p>With many genomes sequenced, a pressing challenge in biology is predicting the function of the proteins that the genes encode. When proteins are unrelated to others of known activity, bioinformatics inference for function becomes problematic. It would thus be useful to interrogate protein structures for </p>

</div>

</content>

<dc:title>Structure-based activity prediction for an enzyme of unknown function</dc:title>

<dc:creator>Hermann, Johannes C.</dc:creator>

<dc:creator>Marti-Arbona, Ricardo</dc:creator>

<dc:creator>Fedorov, Alexander A. </dc:creator>

<dc:creator>Fedorov, Elena</dc:creator>

<dc:creator>Almo, Steven C. </dc:creator>

<dc:creator>Shoichet, Brian K.</dc:creator>

<dc:creator>Raushel, Frank M.</dc:creator>

<dc:identifier>doi:10.1038/nature05981</dc:identifier>

<dc:source>Nature 448, 775 (2007)</dc:source>

<dc:date>2007-07-01</dc:date>

<prism:publicationName>Nature</prism:publicationName>

<prism:publicationDate>2007-07-01</prism:publicationDate>

<prism:volume>448</prism:volume>

<prism:number>7155</prism:number>

<prism:section>Article</prism:section>

<prism:startingPage>775</prism:startingPage>

<prism:endingPage>779</prism:endingPage>

</entry>