User guide 1.1

From cbwiki.net
Jump to: navigation, search

Contents

Introduction

The user guide examines in greater depth 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). In fact, the RSS-CB project ensued from 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 these 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 will examine and recommend 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/Specification_1.1 1.1.0: this version

Status

Draft

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://purl.org/dc/elements/1.1/"

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

xmlns:dcterms="http://purl.org/dc/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.centralbanks.org/rss/"
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, items, and dc:license. 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 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 many RSS user agents will 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, 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.

<dcterms:license>

Best practice: The <dcterms:license> should be to the landing page of the feed usage license. To conform with the dcmi specification, the value must be web-addressable.

Why: Using <dcterms: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 the HTML specification. As that specification states, "For user agents that cannot display images, forms, or applets, this attribute specifies alternate text." See the HTML specification for further guidelines.

<url>

The value of this element corresponds to the value of the src attribute in the HTML specification. As that specification states, it "specifies 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

Discussion:

<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: Recommended is to have 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 RFC 4646

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, dcterms:creator can be used as well or as an alternative.

Usage: recommended

<dcterms:issued>

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

Usage: recommended for research publications

<dcterms: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 of 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 Specification 1.1 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 starts, the item was published and so on. This value should remain constant when repurposed, however aggregators may modify the dc:date value if necessary in order to control the order in which items appear. For date formatting information see W3 specs.

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 GMT 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", "Annual Meeting of the Danish Bankers Association" etc. The audience could also be specified for an events or publication to indicate who could be best benefit from it. For example, "Financial supervisory body managers". In the latter case, the use of dcterms: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>
  <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>
  <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>
  <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. The role of the individual in relation to the item is described using the type attribute.

Attributes: type (valid values - "author", "contact", "editor", "speaker").

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 type="speaker">
  <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>
    <cb:jobTitle>Deputy Chairman</cb:jobTitle>
    <cb:affiliation>Monetary Authority of Singapore</cb:affiliation>
  </cb:role>
  <cb: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.

Discussion: This is used to describe the .

<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 in order 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. USA)

<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: Some examples, "Lugano", "Jackson Hole", "Beijing".

<cb:eventDateEnd>

Proposal: Corresponds to the date that the event ends and should include day, month, 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

Discussion:

<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 to the users' screens.

<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 date format, per se. It may indicate when a particular paper was made available, but is a formal date label that can be 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 paper.

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 alpha-numeric ordinal indicator.

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

Discussion: This is where this information can be provided, using appropriate fields: issues may have numbers, months, quarters, two month names, two quarter or season names, volume numbers and issue numbers.

<cb:JELCode>

Proposal: Codes from a controlled vocabulary list corresponding to the official subject listing used by the Journal of Economic Literature. Multiple instances, 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 paper.

<cb:country>

Proposal: This contains the ISO 3166-1 country code of the country reporting the 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.

Usage: Required for some specific statistical applications.

<cb:value>

Proposal: This contains the value of the observation. The value will be identical to one of the fields in the title. See the relevant Application Guides for more information.

Usage: Required for statistical applications.


decimals attribute

Proposal: This contains the number of decimal places used to express the value. The value maybe limited to the enumerated values in a code list - please see the relevant application guides.

unit_mult attribute

Proposal: This contains an exponent of 10. The default is 0, for stating the value in terms of 1 unit.

units attribute

Proposal: This string contains a description of the units of the datum. It can be a text string with blanks or a value from the enumerated values in a code list. It is recommended for statistical data that are not clearly in rates. Please see relevant application guide.

<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.

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 some specific statistical applications.

unit_mult attribute

Proposal: This optional attribute contains the value of the unit multiplier, an exponent of 10. A unit_mult of 2, for example, indicates that the baseCurrency is stated in terms of 100 units. The default value for this attribute is 0, for stating the baseCurrency in terms of 1 unit.

<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.

Usage: Required for some specific statistical applications.

<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 some statistical applications.

<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 some statistical applications.

<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 some statistical applications.

<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 some statistical applications.

<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: Recommended for some statistical applications.

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: Recommended for some statistical applications.

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 some statistical applications.

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 a string with a date representation that corresponds to the observation period to which the value applies.

Usage: Required for all statistical applications.

Discussion: It 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" if that's how the primary source represents the date index. For certain high frequencies such as daily and weekly, it can be formatted as standard W3C three-part date, but it's still free text. The Application Guides list suggested formats for date representations.

frequency attribute

Proposal: This contains the value of the frequency. The value maybe limited to the enumerated values in a code list - please see the relevant application guides. The frequency attribute gives meaning to the period representation.

Usage: Required for all statistical applications.

Discussion: The values of frequency should be taken from a code list; one possible source for many frequencies is <a href="http://dublincore.org/groups/collections/frequency/">Dublin Core Collection Description Frequency Vocabulary</a>, but additional frequencies may also be needed.