RSS-CB 1.2 User Guide

From cbwiki.net
Jump to: navigation, search

Contents

Introduction

The user guide examines in greater depth some of the information set out in the RSS-CB specification. It also discusses the intended uses of RSS-CB, and recommends best practices for the implementation of RSS-CB.

Intended uses of RSS-CB

End-user RSS feeds

Most producers of RSS-CB content intend to create news feeds for consumption by human users via RSS reader software. The best practices aim to ensure optimal display of such feeds.

Aggregation

The RSS format is well-suited to automated harvesting by machine processes (aggregation). The RSS-CB project began in response to a request by the Federal Reserve Bank of New York for a reliable source of Bank for International Settlements news items. The BIS, which compiles news items from various central banks, also saw RSS-CB as an opportunity to enhance its own information gathering process.

Other institutions may be interested in developing such automated processes, as a way of reliably aggregating information from numerous central banks at once. RSS-CB namespaces become especially significant for this. Specifically, Dublin Core metadata can enhance the utility of aggregated content.

Statistical data

Users of central bank information are often interested in small pieces of statistical data, such as a foreign exchange rate, or an overnight lending rate. The RSS-CB project recommends consistent and efficient means through which RSS-CB can deliver such data to users and aggregators.

Authors/Contributors

Paul Asman, Federal Reserve Bank of New York
Christine Sommo, Federal Reserve Bank of New York
Dan Chall, Federal Reserve Bank of New York
Elena Atayeva, Federal Reserve Bank of New York
Mike Eltsufin, Federal Reserve Bank of New York
Allen Galiza, Federal Reserve Bank of New York
San Cannon, Federal Reserve Board of Governors
Butch Easton, Federal Reserve Board of Governors
Julie Jackson, Federal Reserve Board of Governors
Noé Palmerin, Banco de México
Timo Laurmaa, Bank for International Settlements
Brent Eades, Bank of Canada
Suzanne LeBlanc, Bank of Canada
Marcello Di Pietro, European Central Bank

Version

Latest Version: http://www.cbwiki.net/wiki/index.php/RSS-CB_1.2_User_Guide: this version

RSS-CB syntax and best practices

XML declaration

<?xml version="1.0"?>

Why: According to the RSS 1.0 specification, it is not mandatory to begin an RSS file with this declaration. However, doing so will ensure more reliable reading of the file by parsers, user agents, and other software. It also allows the specification of different character encodings through the use of the encoding attribute.

Requirement: Required

<rdf:RDF>

The RDF element contains namespaces as instances of the xmlns attribute. Four are required, as indicated below. Custom namespaces, either for an individual institution or a group of institutions (such as RSS-CB), are optional. Before adding an element to a custom namespace, care should be taken to ensure that the concept is not already covered in one of the required namespaces.

The RDF element requires one and only one instance of the channel child element, and one or more instances of the item child element. The RDF element permits one and only one instance of the image child element; it is optional. RSS-CB permits no instance of the textinput child element; it is prohibited. RSS-CB prescribes an order for the child elements of the RDF element to facilitate validation.

Namespaces

An RSS-CB file must contain the four following namespace declarations, for which the attribute values should be the URIs of the latest official specifications.

The RDF namespace, with the recommended prefix rdf:
Requirement: Required

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

The RSS 1.0 namespace, the recommended default namespace, with no prefix:
Requirement: Required

xmlns="http://purl.org/rss/1.0/"

The Dublin Core namespace, with the recommended prefix dc:
Requirement: Required

xmlns:dc="http://dublincore.org/documents/dcmi-terms//"

An RSS-CB file can also optionally declare custom namespace(s) for extensions used by individual institutions or groups of institutions:
Requirement: Optional

xmlns:cb="http://www.cbwiki.net/wiki/index.php/RSS-CB_1.2_Specification"
xmlns:onecb="http://www.particularcentralbank.gov/rss/">

<channel>

The channel element in RSS 1.0 has seven child elements, each of which can have at most one instance, and one required attribute, rdf:about. Four of the child elements are required, each having one and only one instance: title, link, description, and items. The other two child elements, image and textinput, are optional in RSS 1.0. Image remains optional in RSS-CB, but textinput is prohibited. RSS-CB also recommends one Dublin Core element, dc:license. RSS-CB prescribes an order for the child elements of the channel element to facilitate validation.

rdf:about

The RSS 1.0 specification does not explicitly prescribe the source of the value of the channel's rdf:about attribute. RSS-CB 1.0, however, stipulates that its value must be the URL of the current RSS feed. Thus, an RSS feed whose URL is http://yoursite/press.rss would have this value of rdf:about:

<channel rdf:about="http://yoursite/press.rss">

Why: One of the roles of RSS-CB 1.0 is to allow automated aggregators to collect feeds from multiple institutions, to be stored, for example, in a database. In such scenarios it may be important to know the original URL for a given RSS file.

<title>

Maximum length: 40 characters recommended.

Why: The RSS specification gives 40 characters as a suggested maximum. Because RSS user agents may display no more than this number of characters, RSS-CB upgrades this to a recommendation.

Best practice: Not all RSS readers display the channel title. For those that do, creators of RSS-CB 1.0 feeds should observe the following conventions:
  • Use the name of the institution as the first element in <title>, followed by a colon and a space. Example: New York Fed: events
  • The name used for the institution could be an acronym or a full name. It is included in the 40-character maximum.
  • Avoid superfluous words where possible. Example: Use New York Fed: announcements instead of New York Fed: announcement feeds.
  • If the institution's name does not indicate its country (perhaps implicitly), insert an ISO 3166 Country Code.

<link>

Best practice: The <link> should be to the landing page of the RSS feed - the page that lists and/or describes the RSS feeds available for a given site or site section.

If the feed has a page devoted to it (as on the web site of the New York Fed, for example), the URL is of that page. Otherwise, if the feed is from an institution’s home page, the URL is of that page, and if the feed is from a departmental page, the URL is of that page.

Why: Using <link> this way will allow users to return to the pertinent sections of the site to learn if new RSS feeds are available, or to discover other site content related to the subject matter of the feed.

<description>

Best practice: This element must not be empty, and should present a concise, unambiguous description of a channel's content, to a maximum of 500 characters.

Why: While not all RSS readers display the channel description, it should be meaningful for those that do.

<image>

If there is an <image> as a child of <channel>, there must also be an <image> main element. Discussion of image is deferred to that section.

<items>

See Specification document for the syntax of this element.

<dc:license>

Best practice: The <dc:license> should be to the landing page of the feed usage license. To conform with the Dublin Core Metadata Initiative specification, the value must be web-addressable.

Why: Using <dc:license> this way will allow users to return to the pertinent section of the site to learn if the license has been updated.

<image>

The <image> element is used to display a graphic for a channel. Typically this image will be an organization's logo or wordmark. Not all RSS software will display an <image>.

The RSS 1.0 specification recommends, following convention and version 0.9, that the dimensions of the image be 88 pixels wide by 31 pixels high. Observing this recommendation will help ensure correct rendering of images in reader software, and RSS-CB endorses it. RSS 0.91 did permit image sizes from 1 to 400 pixels wide and 1 to 144 pixels high; RSS-CB discourages this.

This element is required if there is an <image> child of <channel>. RSS-CB prescribes an order for the child elements of the image element in accord with its practices with the RDF and channel elements, where the order facilitates validation.

rdf:about

There are two requirements for the value of this attribute: that it match the value of rdf:resource of the image child of channel; and that it be unique in respect to any other rdf:about attributes in the document.

RSS-CB recommends that the value be the URL of the image.

Why: This will help ensure that it is unique within the document.

<title>

This free text value corresponds to the contents of the alt attribute in HTML, intended for user agents that cannot display images.

<url>

The value of this element corresponds to the value of the src attribute in the HTML, to specify the location of the image resource. It should also match the value of the rdf:about attribute of the parent image.

<link>

This has the same value as the link child element of channel. Guidelines are found here.

<item> element

There must be at least one item. The RSS 1.0 specification has no upper limit, but recommends no more than 15 items for compatibility with RSS 0.9 and 0.91. RSS-CB finds this recommendation obsolete, and does not endorse it. RSS-CB prescribes an order for the child elements of the item element in accord with its practices with the RDF and channel elements, where the order facilitates validation.

Below we list all RSS-CB fields that appear in the specification. Some are common to all application types, but many are used only in specific applications of RSS-CB. Developers should refer to the various Application Guides for information on relevant fields and more specific notes on how to use common fields within each application.

Child elements

rdf:about

There are two requirements for the value of this attribute:

  • that it match a value of rdf:resource in the list of items
  • that it be unique in respect to any other rdf:about attributes in the document.

The RSS 1.0 specification also recommends that the value of this attribute match the value of the link child of this element. (The wording is "should ... if possible.") RSS-CB endorses this recommendation. Given the uniqueness requirement for the value of this attribute, following this recommendation limits RSS-CB feeds to one RSS item per URL (which may include an anchor tag).

Why: The value of link must be a URL, while the value of rdf:about must be a URI. A URL picks out a web page, while a URI identifies an artifact that may or may not be a web page. Matching the value of rdf:about to that of link has the effect of requiring that the URI pick out a web page, which makes it useful to consumers of RSS-CB feeds.

<title>

The content of the item title is at the discretion of the institution providing the RSS feed. This is the title that will be displayed by the reader for human consumption.

Maximum length: 100 characters.

The RSS 1.0 specification suggests 100 characters as a maximum. Because many RSS user agents will display no more than (and possibly not even) this number of characters, RSS-CB strongly recommends adherence to this maximum.

Usage: required

<link>

Proposal: The link points to the landing page for this particular item as chosen by the institution. It could be a dedicated landing page, an abstract page for a paper, or any other valid URL. This URL should point to whatever the institution considers the main landing page for the content.

Usage: required

Discussion: If the recommendation given for the rdf:about attribute of the item is followed, this URL matches the value of that attribute. This entails that the values of this element be unique within the document. Uniqueness may be accomplished by appending anchor tags to the end of the URL. If the tags do not exist within the document they will have no effect on document navigation but would make the attribute value unique with respect to string comparison.

<description>

Proposal: RSS-CB recommends including the entire substantive contents of the item in the description, if possible. Otherwise, an abstract should be used here.

Usage: required

Discussion: The RSS 1.0 specification recommends a maximum length of 500 characters, which RSS-CB endorses.

The amount of information given in description depends on the intentions for the RSS feed. An institution that uses RSS feeds to drive traffic to its web site may wish to keep descriptions brief. An institution that wishes to offer complete information in different formats may wish to be more prolix.

<dc:date>

Proposal: Corresponds to date RSS feed updated. For date formatting information see W3C specification

Usage: required

Discussion: This field should follow the Dublin Core scheme which provides for date and time precision. Failure to include the time component will result in the display as midnight in some readers.

<dc:language>

Proposal: Indicates language of the content described by the item. Use the standard found in RFC4646.

Usage: recommended, especially for some application types such as research papers.

Discussion: The item links to one specific resource, so there should be one specific language indicated by the feed. In an international context such as that for central banks, and with the possibility of aggregated feeds, this field could be useful for any content.

The language of the feeds is a separate issue, and could be determined by a language attribute for various elements. The language of the content should instead by determined by a language element.

<dc:creator>

Proposal: This contains the abbreviation that signifies the identity of the institution. It contains no blanks. If the value is web-addressable, dc:creator can be used as well or as an alternative.

Usage: recommended

<dc:issued>

Proposal: This contains the date of formal issuance of the resource, e.g. a publication.

Usage: recommended for research publications

<dc:publisher>

Proposal: This identifies the entity responsible for making the resource available.

Usage: recommended

<georss:point>

Proposal: This field contains a string giving the physical location of an event expressed as a single longitude-latitude pair, separated by a whitespace. See GeoRSS Simple

Usage: Optional for event and speech applications.

<cb:event> | <cb:news> | <cb:paper> | <cb:speech> | <cb:statistics>

Proposal: Denotes that the item belongs to one of the specified RSS-CB applications. An <item> element can contain one of <cb:event>, <cb:news>, <cb:paper>, <cb:speech> or <cb:statistics>.

Usage: required when the item does belong to one of the applications.

Discussion: This field is used by aggregators to differentiate what kind of items are contained in the feed, and to enable validation using the various schemas. It is specified at the <item> level, as feeds may contain a mix of items from different applications, depending on how the institution wishes to structure their feeds for the public.

Elements used within RSS-CB applications

The following elements appear within the tags mentioned above - that is, <cb:event>, <cb:news>, <cb:paper>, <cb:speech> or <cb:statistics>.

Details on which child elements can or must belong in the specific application elements can be found in the RSS-CB 1.2 Specification and in the Application guides.

<cb:simpleTitle>

Proposal: A version of the title without any additional adornments such as date, institution and so on. Aggregators or re-purposers of the feed can then adapt this title.

Usage: required for certain application types

Discussion: For example, ECB might publish an item with the title "15/12/2006 Euro notes dissolve in beer". The cb:simpleTitle would be "Euro notes dissolve in beer", which an aggregator could then choose to publish as "15 Dec ECB: Euro notes dissolve in beer"

<cb:occurrenceDate>

Proposal: Corresponds to the actual date the speech took place, the event started, the item was published, and so on. This value should remain constant when repurposed, while aggregators may modify the dc:date value if necessary to control the order in which items appear. For date formatting information see W3 specification.

For example, a press release may be dated for official release as 2007-31-01. The dc:date value could then be 2007-31-01T19:20+01:00 on the website of the original source for the item. An aggregator may then use a different dc:date value - perhaps the time when the item came into its own system, which could be several days later - but should still be able to refer to the original <cb:occurrenceDate> to publish information on the actual release date.

In some cases, publishers will want to represent the <cb:occurrenceDate> as the date and time the item occurred without a full UTC date specification, to avoid unnecessary date/time calculations. In the cases where the occurrenceDate is listed without reference to UTC and an offset, the occurrenceDate time should be considered to be the representation of the local time. For example, if a speech is occurring at 1 p.m. EST and the feed is being published at 1 p.m. EST, the <dc:date> should show 2007-31-01T18:00-5:00. If the speech is actually occurring at a location in the Pacific Standard time zone then it is occurring at 10:00 AM local time and the publisher can choose to represent the <cb:occurrenceDate> as 2007-31-01T10:00.

Usage: required for certain application types

Discussion: This field should follow the Dublin Core scheme which provides for date and time precision. Failure to include the time component will result in the display as midnight in some readers.

<cb:institutionAbbrev>

Proposal: This contains the abbreviation that signifies the identity of the institution responsible for the feed item. It contains no blanks. In statistical applications, it is usually identical to a part of the title. The recommended model for this abbreviation is XYY where YY is the ISO 3166-1 country code.

Usage: Required for some statistical applications, optional for other applications.

<cb:audience>

Proposal: The group of people that represents the targeted audience for the item.

Usage: Recommended for some application types, particularly speeches and events, optional for others.

Discussion: This is not the location or venue of the item.

Example values for a speech could include "Conference of the Association of Banks," "Monetary Policy and the Markets Conference," and "Annual Meeting of the Danish Bankers Association." The audience could also be specified for an event or publication to indicate who could be best benefit from it. For example, "financial supervisory body managers". In the latter case, the use of dc:audience, which takes an agent class as its value, may be more appropriate.

<cb:keyword>

Proposal: Descriptive keywords and phrases of the item's contents. These are determined by individual institutions . There is no common taxonomy proposed for RSS-CB keywords.

Usage: recommended for publications, optional otherwise

Discussion: This field cannot contain more than one keyword/phrase. List each keyword as an individual item.

<cb:resource>

Proposal: Used to identify media items such as audio/video of speech, PDF, etc.

Elements: Each resource has a cb:title, cb:link and cb:description.

Usage: optional

Discussion:This field cannot contain more than one resource. List each resource as an individual item.

Suggestion: The cb:title should be read as an expansion upon the title of the main item being described (i.e. <item><title>), rather than reiterating all of the details. The description can be taken as a fuller explanation of the resource.

Example:

<cb:resource parseType="Resource">
  <rdf:type rdf:resource="http://www.cbwiki.net/wiki/index.php/RSS-CB_1.2_RDF_Schema#Resource"/>
  <cb:title>Powerpoint presentation</cb:title>
  <cb:link>http://www.bankofmolvania.yy/speeches/20061219a.ppt</cb:link>
  <cb:description>Powerpoint presentation accompanying the speech by 
    Georgios Hamb, Governor of the Bank of Molvania, on international 
    pension issues at the Hilton Hotel in 
    New York, 18 December 2006.</cb:description>
</cb:resource>
<cb:resource parseType="Resource">
  <rdf:type rdf:resource="http://www.cbwiki.net/wiki/index.php/RSS-CB_1.2_RDF_Schema#Resource"/>
  <cb:title>RealPlayer audio feed</cb:title>
  <cb:link>http://www.bankofmolvania.yy/speeches/20061219a.rm</cb:link>
  <cb:description>Audio feed in RealPlayer format of the speech by 
    Georgios Hamb, Governor of the Bank of Molvania, on international 
    pension issues at the Hilton Hotel in 
    New York, 18 December 2006.</cb:description>
</cb:resource>
<cb:resource parseType="Resource">
  <rdf:type rdf:resource="http://www.cbwiki.net/wiki/index.php/RSS-CB_1.2_RDF_Schema#Resource"/>
  <cb:title>Monetary Policy in a Forward-Looking Input-Output Economy</cb:title>
  <cb:link>http://www.federalreserve.gov/pubs/feds/2008/200833/200833pap.pdf</cb:link>
  <cb:description>PDF version</cb:description>
</cb:resource> 
<cb:person>

Proposal: Use to describe an individual (or institution) that is associated with the item.

Elements: cb:givenName, cb:surname, cb:personalTitle, cb:nameAsWritten, cb:role.

cb:nameAsWritten is required. The others are recommended when the values are those for an actual person rather than an institution, in which case cb:surname is required.

cb:role is itself recommended. If present, it has the optional child element of cb:jobTitle and/or the optional attribute cb:affiliation. Within speeches however, the cb:role is required, as is cb:affiliation, while cb:jobTitle is recommended.

Usage: As determined by the specific application. See above and then refer to the specific application guide.

Discussion: Where an institution performs the role a person might otherwise do (e.g. it is identified as the author of a document), use only the cb:nameAsWritten element.

Multiple roles are acceptable, but a single instance of cb:givenName and cb:surname is recommended.

Example:

<cb:person parseType="Resource">
  <rdf:type rdf:resource="http://www.cbwiki.net/wiki/index.php/RSS-CB_1.2_RDF_Schema#Person"/>
  <cb:givenName>Hng Kiang</cb:givenName>
  <cb:surname>Lim</cb:surname>
  <cb:personalTitle>Mr</cb:personalTitle>
  <cb:nameAsWritten>Lim Hng Kiang</cb:nameAsWritten>
  <cb:role parseType="Resource">
  <rdf:type rdf:resource="http://www.cbwiki.net/wiki/index.php/RSS-CB_1.2_RDF_Schema#Role"/>
    <cb:jobTitle>Deputy Chairman</cb:jobTitle>
    <cb:affiliation>Monetary Authority of Singapore</cb:affiliation>
  </cb:role>
  <cb:role parseType="Resource">
  <rdf:type rdf:resource="http://www.cbwiki.net/wiki/index.php/RSS-CB_1.2_RDF_Schema#Role"/>
    <cb:jobTitle>Minister for Trade and Industry</cb:jobTitle>
    <cb:affiliation>Government of Singapore</cb:affiliation>
  </cb:role>
</cb:person>
<cb:venue>

Proposal: The building or institution at which the described item took place.

Usage: Recommended for some application types, optional for others.

Discussion: For a speech, this would be the physical location of the speaker, but not including city/country details. For example, "Hilton Hotel", "Economic and Monetary Affairs Committee of the European Parliament", "Qing Hua University".

<cb:locationAsWritten>

Proposal: Where an item can be described as having taken place in a specific geographical location, this element contains human-readable text of the city, state and country to which a particular item relates.

Usage: Recommended for some application types, optional for others.

Discussion: Some examples, "Lugano, Switzerland", "Jackson Hole, WY, USA", "Beijing, China". Abbreviations can be used or avoided as preferred by the publishing institution. This element is designed to be read by humans, whereas <cb:locationCountry>, <cb:locationState> and <cb:locationCity> can be processed by machines.

<cb:locationCountry>

Proposal: Where an item can be described as having taken place in a specific geographical location, this element discretely specifies the country. Values conform to the ISO 3166 alpha-2 standard.

Usage: Recommended for some application types, optional for others.

<cb:locationState>

Proposal: The state, province, region etc of the <cb:locationCountry> in which the <cb:locationCity> is located. Use standard abbreviations where possible.

Usage: Optional.

Discussion: Where a state is required to uniquely identify the location, it should be used. The state should also be used where it is common practice for the relevant country (e.g. US).

<cb:locationCity>

Proposal: Where an item can be described as having taken place in a specific geographical location, this element discretely specifies the city.

Usage: Recommended for some application types, optional for others.

Discussion: Examples: "Lugano", "Jackson Hole", "Beijing".

<cb:eventDateEnd>

Proposal: Corresponds to the date that the event ends and should include day, month, and year. If the event starts and ends on the same day, this element can be omitted.

Usage: optional and currently used only for the Events application.

<cb:byline>

Proposal: The full byline for the paper or publication as it appears in the published version

Usage: Recommended for some applications (e.g. research papers).

Discussion: In addition to supporting each author's name in cb:person, it is worthwhile to have a dedicated element for the complete byline, with all the author names in proper order and with all the necessary punctuation and diacriticals. This approach makes it unnecessary for a client application to reconstruct the bylines for display.

<cb:publicationDate>

Proposal: A string representing the stated date for the publication, not necessarily the date of the actual creation of the document. For some papers, this will be some month-year representation; for others it may be a quarterly or seasonal indicator. For example "Spring, 2006", "1st Quarter, 2008", "2004-5"

Usage: Recommended for some applications (e.g. research papers).

Discussion: This date is not meant to be represented in a formal date format. It may indicate when a particular paper was made available, but can be a date label chosen for institutional reasons.

<cb:publication>

Proposal: Text field containing the name of the journal or working paper series, if one exists.

Usage: Recommended for some applications, such as research papers.

Discussion: Use a fully identifiable series title. e.g. "Central Bank of Argentina Working Papers" not just "Working Papers."

<cb:issue>

Proposal: Text field containing an alpha-numeric ordinal indicator.

Usage: Recommended for some applications, such as research papers.

Discussion: Issues may have numbers, months, quarters, two month names, two quarter or season names, volume numbers, and/or issue numbers.

<cb:JELCode>

Proposal: Codes from a controlled vocabulary list corresponding to the official subject listing used by the Journal of Economic Literature. There may be multiple instances of this element, one for each code. Codes can be one digit or more, and should not spell out the name of the category.

Usage: Recommended for some applications, such as research papers.

<cb:country>

Proposal: This contains the ISO 3166-1 country code of the country reporting a statistic. In the schema for exchange rates, the value will be limited to the enumerated values in a code list. The value is identical to the first field of the title for statistics.

Usage: Required for some specific statistical applications.

<cb:observation>

Proposal: This contains four elements that together represent an observation. Two elements, value and unit, are required. Two, decimals and unit_mult, have defaults and are optional.

Usage: Required for statistical applications.

Discussion: value will be identical to one of the fields in the title; see the relevant Application Guides for more information. unit can be a text string or a value from a code list. decimals, for which the default value is 0, may be limited to the values in a code list. unit_mult contains an exponent of 10. The default is 0, for stating the value in terms of 1 unit.

<cb:baseCurrency>

Proposal: This contains the ISO 4217 currency code that signifies the base currency. In the schema for exchange rates, the value will be limited to the enumerated values in a code list. The value is identical to the fifth field of the title for an exchange rate.

While some central banks may always report exchange rates in their own currency, this is not always the case. The New York Fed, for example, reports most exchange rates in United States dollars, but it reports the Australian dollar, the Euro, the New Zealand dollar, and the British pound in terms of those currencies. The Bank of Canada reports USD-CAD rates in both directions:

CA: 1.1165 CAD = 1 USD 2006-08-14 BOC closing

CA: 0.8957 USD = 1 CAD 1006-08-14 BOC closing

Since consumers of RSS exchange rate feeds may be taking rates from several different institutions, the inclusion of a base currency is important even for institutions that always use their own currency as the base currency.

Usage: Required for exchange rates.

<cb:targetCurrency>

Proposal: This contains the ISO 4217 currency code that signifies the target (or price, or counter) currency. In the schema for exchange rates, the value will be limited to the enumerated values in a code list. The value is identical to the third field of the title for an exchange rate.

Usage: Required for exchange rates.

<cb:rateName>

Proposal: This contains the higher-level local name for a rate. For the New York Fed, Fed Funds denotes a set of observations that include the daily effective rate, the high and low points in the range for the observation period, and more. This field indicates only the higher-level name. The value is usually identical to a part of the title.

Usage: Required for exchange rates and interest rates.

<cb:rateType>

Proposal: This contains a free text value describing the rate type as identified by the reporting institution. The value is usually identical to one of the fields in the title.

Usage: Required for exchange rates and interest rates.

<cb:transactionName>

Proposal: This contains the higher-level local name for the transaction. For the New York Fed, CouponPurchase represents one of three types of permanent open market operations conducted. The value is usually identical to a part of the title.

Usage: Required for some statistical applications.

<cb:transactionType>

Proposal: This contains a free text value describing the transaction type as identified by the reporting institution. It is a refinement of the transaction name. The value is usually identifical to a part of the title.

Usage: Required for transactions.

<cb:transactionTerm>

Proposal: This contains the term of the transaction. At the New York Fed, 1day is the transaction term and repo is the is the transaction name. The value is usually identical to a term concatenated to a part of the title.

Usage: Recommended for transactions.

<cb:topic>

Proposal: This contains a string representing the economic area to which the data belong. These can be institution specific. Abbreviations are acceptable as long as they can be easily interpreted from information provided in other fields or draw from established code lists.

Usage: Required for other statistics.

Discussion: This string usually indicates the broad category to which the datum belongs such as "Commercial Paper" or "Industrial Production".

<cb:coverage>

Proposal: This contains a string representing another dimension of the economic area to which the data belong such as industry or geographic region. These can be institution specific. Abbreviations are acceptable as long as they can be easily interpreted from information provided in other fields or draw from established code lists.

Usage: Required for other statistics.

Discussion: If there are further refinements to the topic, they should be expressed here. For example, "manufacturing" indicates industry coverage or "Alsace" for regional coverage.

<cb:dataType>

Proposal: This contains a string giving additional information about the data. Indications of measure, seasonal adjustment, change calculations, etc. should be indicated here.

Usage: Recommended for other statistics.

Discussion: This field contains a string that represents an attribute rather than a dimension of the data. Examples could be "seasonally adjusted", "Index: 1997=100", "Annual rate".

<cb:observationPeriod>

Proposal: This element contains two required child elements, one a string (period) with a date representation that corresponds to the observation period to which the value applies, the other (frequency) representing the frequency of observations.

Usage: Required for all statistical applications.

Discussion: <period> can be a date as written that users of the data would recognize from the original source. For instance, a quarterly date might be represented as "March 2007" or "2008Q2" when the primary source represents the date in such a way. For certain high frequencies such as daily and weekly, the period can be formatted as standard W3C three-part date. The values of frequency should be taken from a code list; one possible source for many frequencies is Core Collection Description Frequency Vocabulary, but additional frequencies may also be needed.

Usage: Required for all statistical applications.