Talk:Statistical data (FX, Interest Rates, Other)
From cbwiki.net
cb:publicationDate
Christine Sommo-FRBNY 19:23, 17 May 2007 (BST) Do we want to provide requirements (or guidance) on how to publish these dates?
San 14:11, 18 May 2007 (BST) Do we have any guidance? I think for numeric dates, we should recommend the most specific date possible (e.g. ccyy-mm-dd, or ccyy-mm, or ccyy). Quarterly dates are a headache: is ccyyQq a good suggestion or should it be ccyyQ0q? What about publications that are dated "Fall" or 1006/2007?
Christine Sommo-FRBNY 17:39, 18 May 2007 (BST) You got me. :-) The question is asked out of absolute ignorance of whether such standards exist elsewhere that we could adopt - say in research pubs.
Paul Asman-FRBNY 21:15, 18 May 2007 (BST) XML recognizes ISO 8601for date and time formats. I think that we want to encourage use of the 8601 formats in the cases for which they are adequate, which are many.
cb:country
Christine Sommo-FRBNY 09:53, 25 April 2007 (ADT) If it's not clear from the recent edits I've made to this page, I'm suggesting that ALL statistical feed titles begin with the ISO country code followed by a colon.
Other section
Paul Asman-FRBNY 10:27, 16 April 2007 (ADT) I changed a couple of minor things here, but more work needs to be done. The section has cb fields in the example that are not present in the specification.
Different channel name for every feed?
Brent Eades-Bank of Canada 13:55, 20 December 2006 (AST) - Pursuant to my previous e-mail: I would be interested in thoughts on whether each feed should also have its own unique channel name.
Steven Bagshaw-BIS 05:03, 21 December 2006 (AST): Seems to me, from your example, that they would need to, regardless. The poor old aggregators would just have to deal with it. Maybe there could be a feed set up containing all currency details from BOC though - perhaps just for machines? But I can't see this kind of feed being mandatory to conform to RSS-CB. (Disclaimer: I am only just starting to think myself about the mechanics of the RSS-CB aggregation. Maybe Timo has a different view.)
Brent Eades-Bank of Canada 08:48, 21 December 2006 (AST) - First, here's the screen capture illustrating the issue again, for reference.
As for aggregators: well, in my example I still have a consistent string in every channel title ("BoC FX Rates:"), and from a coding perspective I don't suppose that's much different from a consistent string reading "Bank of Canada FX Rates" in its entirety. Either way, the aggregator will simply be looking for a given string in order to identify the source of the feed...
general guidelines for other types of data
Paul Asman-FRBNY 09:13, 1 December 2006 (AST) The discussion of 'unit' in attributes seems to conflate the labelling of the unit (percent, USD, ...) with "an indication of how that observation is measured," which strikes me as more of a methodology issue that a unit.
San Cannon-FRB 09:41, 1 December 2006 (AST)So is conflation a bad thing? (I had to look that up BTW. Great word!) I tried to fix it but I hate using the word unit in the explanation of the attribute unit. Editorial suggestions (such as you have already been kind enought to make) are again welcome.
San Cannon-FRB 17:05, 23 January 2007 (AST)I'm working to beef up the "general data" information and example since we are trying to actually publish such data. If anyone notices a general element I've missed or wants to comment on the changes I've made, please feel free.
interest rate categories and types
Paul Asman-FRBNY 17:04, 12 October 2006 (ADT) I'm beginning to work on interest rate representation, and started with the sample file. I put in FedFunds as the rateName, and 'daily effective' as the rateType. (I had rateType and rateSubtype, respectively; Mike Eltsufin changed them). I considered putting a third element under item, rateCategory, for which the value here would be 'overnight interbank' or some such. This would be a code list maintained at the RSS-CB level, useful to those who wished to get rates of a certain type, whatever we called them. I think that this is worth considering.
I also omitted maturity, which may need to come back. If it doesn't matter much, it could be an attribute of the value. If it matters, it might need to be in the title.
San Cannon-FRB 09:33, 13 October 2006 (ADT) I think it might be worth considering at the outset. If we see this representation being used for more than just a handful of easily distinguishable rates, there may not be a problem. If, however, we envision or wish to allow for the possibility of dozens of statistical data feeds covering lots of fairly similar rates, there could be problems. We publish 11 different "Nominal Treasury constant maturity" rates for maturities ranging from 1-month to 30 years. If we want to allow for the possibility that we may have feeds for several, or all, of them, then we need to be able to identify that property from the outset. Of course, this makes it a nightmare staying inside the 40 character limit....
<dc:creator>
Paul Asman-FRBNY 16:49, 10 October 2006 (ADT) Having failed to hear objection (or response) to my proposal for separating out the rate elements, I have begun to do so. I have used <dc:creator> to reproduce the identify of the institution. This may not be desirable, however. If we had instead an rss-cb element <rss-cb:institution>, we could enforce use of a code list through the schema and create a subelement for a full institutional name. On the other hand, the presence of a code list does not enforce uniqueness (two different institutions could use the same value) and it seems good to use DC elements where possible. The full name of the institution is in the <description> element of <channel> in the example. It could also be a separate element there.
Brent Eades-Bank of Canada 09:28, 12 October 2006 (ADT): Hi Paul, guess I missed your initital proposals below. In any case: I'm fine with spaces as a separator. I'm not quite clear on what you see as the functional differences between <dc:publisher>Federal Reserve Bank of New York</dc:publisher> in the <channel>, and <dc:creator>FRBNY</dc:creator> in the <item> iself. Is this a form of disambiguation, advising the user that 'FRBNY' is indeed an abbreviation of 'Federal Reserve Bank of New York'? Or does (or an 'rss-cb:' equivalent) serve some other purpose?
Paul Asman-FRBNY 11:19, 12 October 2006 (ADT) I wanted to have all the fields that the title comprises separated out within the item element, with the same text in the subelement of item that appears in the title. My aim is easier parsing for those who want the fields separately. I used the formal name under publisher in the channel, thinking of that as the publisher of the underlying content to which the RSS links. I used creator in the item to indicate who created the item.
San Cannon-FRB 09:40, 13 October 2006 (ADT) Would there ever be an instance where <creator>, <publisher> and <rss-cb: institution> would convey different information? Not different representations of the same institution but will there be a case (or do we want to allow for the case) that the creator or publisher is a group within the institution? For central banks, this might not matter but I was thinking of the various U.S. statistical agencies which have "bureaus" within "departments"; in those cases, specifying the "Statistics of Income" division as the <publisher> as separate from the "Internal Revenue Service" which is the <institution> might be useful.
Of course, I'm just playing devil's advocate here; this may not be an issue at all....
Christine Sommo-FRBNY 11:50, 26 April 2007 (ADT) We (the NY Fed) are going to use the dc:creator as Paul has suggested in our feeds. Allen Galiza will update the spec to reflect this. Since it's a wiki (imagine Elena saying it), feel free to revert the spec back to not having dc:creator, but please let us know if you do.
Christine Sommo-FRBNY 19:31, 17 May 2007 (BST) See the discussion in the Talk:User_guide for the most up to date decision on dc:creator.
Separating out the rate elements
Paul Asman-FRBNY 16:03, 4 October 2006 (ADT) I propose that we separate out the the items of the exchange rate information and include them as separate elements that we define within RSS-CB. This is not a substitute for their presence within the RSS element description; it is in addition. In particular, I propose the creation of these elements under the RSS-CB namespace: baseCurrency, exchangeCurrency, value (with attributes for frequency and decimals), and rateType. The other two items in the description, institution and date, are handled by the dc elements creator and date.
Acceptance of this proposal will have a number of consequences for the specification, but I will wait to gain consensus on the proposal before making them. I did change the sample, however, to show what it would look like. (I also took the commas out of the description in the sample, as that space-saving measure would be one of the consequences. If an application can parse the description, it can grab and parse the newly defined elements.)
Branding abbreviations
San Cannon-FRB 09:52, 22 August 2006 (ADT) Okay - so far I like the statistical data discussion. I think the format makes sense and the information is clear and concise... but (and you knew there had to be one!) there are two pieces that I think need careful deliberation: (Paul Asman-FRBNY 15:43, 4 October 2006 (ADT) I moved this introduction here, so I could get the table of contents on top and put a new topic first. It applies to both the branding entry and the controlled vocabulary entry.)
San Cannon-FRB 09:52, 22 August 2006 (ADT)I know we discussed this briefly in Ottawa but do we have any guidelines/suggestions/notions on how to handle this? What if the Bank of Cambodia wants to be BOC? Does Brent win just cuz he got there first? Or is this a "free market" situation where conflicts will be resolved between affected parties? Does the BIS have any institutionalized way of dealing with such things?
Brent Eades-Bank of Canada 10:10, 22 August 2006 (ADT): Hmm. We may have to consider a controlled vocabulary here as well. 'BOG' gets especially thorny; could correspond to:
- Bank of Ghana
- Bank of Greece
- Bank of Guatemala (they've recently redone their site, by the way -- very attractive. Go see.)
- Bank of Guyana
Strictly speaking I'm off the hook with Cambodia, (a) because their full name is National Bank of Cambodia, and (b) because they haven't a website (!) So they're probably not going to be worrying about RSS anytime soon.
Timo Laurmaa-BIS 10:55, 22 August 2006 (ADT) What about requiring the use of ISO country codes in front: US-FRBNY, CA-BOC, GR-BOG, GH-BOG etc?
Paul Asman-FRBNY 09:14, 23 August 2006 (ADT) Timo's suggestion seems reasonable to me, although the eight characters of US-FRBNY might prove to be cumbersome in practice. But rather than try to decide that now, why not wait and see how it plays out once there's some real content?
Noe Palmerin-Banco de Mexico 12:01, 23 August 2006 (ADT) Maybe just waiting could lead us to future changes and solving some issues that could be solved now. I vote for Timo's suggestion.
Suzanne LeBlanc-Bank of Canada 11:06, 24 August 2006 (ADT)I vote for Timo's suggestion as well. Having the country in front will be useful if the Bank abbreviation is in the native language and not English.
Controlled vocabulary/thesaurus for rate type
Paul Asman-FRBNY 09:52, 11 October 2006 (ADT) In my latest updates, I've treated rateType as defined by the rss-cb namespace. Since we seem to agree (for now) that it would be unwieldy to maintain a central code list even for exchange rate types, it's a free text field. To work from an individual code list would, I think, require an additional custom field for the institution wishing to do so.
San Cannon-FRB 09:52, 22 August 2006 (ADT)For exchange rates, there may not be too many types (noon, closing, "official",???) but interest rates could get really hairy. Are we going to delve into defining some sort of "code list" or controlled vocab for the different types? This would allow us to include (enforce?) parity between equivalent concepts with different names (Fed Funds vs. overnight, for example) but would require some sort of maintenance agency-type oversight. (Ohhh.... SDMX terms all over the place...)
Brent Eades-Bank of Canada 10:21, 22 August 2006 (ADT): My initial thought is to say no: no codelists or maintenance agencies or the rest. Even exhange rates could get messy pretty quickly, I suspect.
For example, the Bank of Canada publishes eight different forms of the $US rate (noon nominal, closing nominal, intraday high, intrday low, noon/90-day forward average, closing/90-day forward average, monthly noon average, annual noon average, probably others I'm forgetting.) So even just establishing parity between us and the Fed could get pretty involved. Never mind the 160-odd other central banks with websites.
I'm more inclined to have individual banks use the <description> field for such metadata as may be required to disambiguate a given rate... as in my sample:
<description> These are official New York Fed FX rates. Type: noon buying; [more info could be added here] Frequency: daily; Decimals: 4. </description>
Paul Asman-FRBNY 09:20, 23 August 2006 (ADT) What about code lists on a local level? I agree with Brent that common code lists would be too difficult, but don't see that we're left only with prose in a desciption field. We could each publish our own code lists and use them. We could also, as individual central banks, make equivalency claims under our own authority and not that of the group. I believe that SDMX version 2 has a mechanism for stating equivalencies between codelists; we could use that.
Noe Palmerin-Banco de Mexico 11:54, 23 August 2006 (ADT) I agree about local codes but I think we can try a few common characteristics. I'm sure that Frequency is a good example to start. About the rates, we could try just "rate" and be more specific in the local list. What do you think?
Brent Eades-Bank of Canada 10:15, 24 August 2006 (ADT): Hm. How does a user actually retreive/view such codelists? Are they published as separate web documents, and then their labels plugged into the <description>?
Paul Asman-FRBNY 16:23, 24 August 2006 (ADT) I did have a separately published set of codelists in mind, much like we had from the start with SDMX (and then neglected to maintain, but that's another matter).
Dan Chall-FRBNY 09:46, 5 September 2006 (EDT) It seems that we may be thinking about two different audiences: the casual "inexperienced" user who comes across a feed, for whom we want the feed to be entirely self-contained, and the central banks and other knowledgeable users who might benefit from structured documentation. The latter approach would allow us to change formats and conventions over time.
Ordering of fields
Paul Asman-FRBNY 09:48, 16 January 2007 (AST) I'm making another change in the order of fields for title. Since we now have the country identifier up front, it strikes me that the target currency is more important than the base currency. That is, if I'm looking at something in my bookmarks, "US: 0.7826 USD = 1 AUD ..." is more useful than "US: 1 USD = 2144.60 VEB ...," given that the latter part might get cut off. With the base currency up front, too much of the visible bookmark is taken up by "1 XXX."
Paul Asman-FRBNY 10:21, 23 August 2006 (ADT) Brent had ordered the fields in this way: institution, base currency, exchange currency, rate type, date, value. He justified this as presenting the most significant information first for the benefit of human users. I agree with the justification but not the order. This human would want to see the rate itself as far up front as plausible. I'm not minimizing the importance of date, but I'd want only the most recent. Nor am I minimizing the importance of rate type. But I'd want to see the number before both of those values.
Brent Eades-Bank of Canada 10:23, 24 August 2006 (ADT): I'm not really sure why I had the rate so close to the end. I'm fine with Paul's changes.
Dan Chall-FRBNY 9:36, 5 September 2006 (EDT) In any event, shouldn't there be documentation in the field? It seems ironic to devote all this energy to an XML representation of numerical data to wind up with the numbers being represented solely in a text field, but one would think somewhere there might be a terse indicator of the format.
Commas to separate fields
Brent Eades-Bank of Canada 10:19, 24 August 2006 (ADT): No, I don't suppose it would require a superhuman feat of coding to parse that. Better still would be to use this form -- USD->CAD -- because it is human language-neutral.
Suzanne LeBlanc-Bank of Canada 11:00, 24 August 2006 (ADT)I have to go with Brent on this one because with the "to" we would need the other language equivalents.
Paul Asman-FRBNY 16:22, 24 August 2006 (ADT) The arrow is fine. I hope there is no language in which it symbolizes an obscenity.
Brent Eades-Bank of Canada 10:01, 25 August 2006 (ADT): Thanks for my morning laugh, Paul. Hadn't considered that possibility. Another concern occurs to me, though -- I wonder if there's any remote chance of some parsers having trouble with the > character (since it also denotes the closing of an element name.) I suppose to be ultra-safe we could encode it -- > -- though I doubt that should be necessary.
Dan Chall-FRBNY 09:41, 5 September 2006 (EDT) (Might some parsers not be ready to decode those expressions?) I'm sorry for bringing up ancient history, If we are talking about machines parsing the fields rather than just using them for RSS readers, and we're using XML, is there an option to represent separately the numbers in elements that would be accessible to customized clients, that could be ignored by browsers and RSS readers?
