Difference between revisions of "Talk:Statistical data 1.1"

From cbwiki.net
Jump to: navigation, search
(title for other statisics)
(Thanks, San!)
Line 6: Line 6:
That said, I'm happy to open a dialog about how things should be done if there's someone else who cares now... ;-)
That said, I'm happy to open a dialog about how things should be done if there's someone else who cares now... ;-)
[[User:Christine Sommo-FRBNY|Christine Sommo-FRBNY]] 13:37, 11 July 2008 (BST) Aha!  I knew you could explain it.  Thanks!  How strict do you think the title structure for this  section should be then?  I'm perfectly happy with what you've done so far for the feed I'm writing now, but is this something that once more people create "other" feeds will become difficult to apply?  Should we even worry about that now?  Anyway, I'll probably pester you offline with some additional questions as I am not an economist and am not sure I'm using the atomic elements correctly.
==topic or coverage?==
==topic or coverage?==

Revision as of 13:37, 11 July 2008


title for other statisics

Christine Sommo-FRBNY 19:37, 10 July 2008 (BST) Question: Why does title for other statistics place the abbreviation of the datum being reported before the value? This is different from the statistical applications. I ask because I'm currently creating my first feed in this category. Thanks!

San 03:20, 11 July 2008 (BST) Well mostly because I've been the only one who cared about the "other" data and it made sense to me! The biggest issue for this category is that "Other" covers a lot of ground and I thought it was important to let folks know right up front what the area being covered was. Interest and exchange rates and even transactions don't need to specify the type of data covered as it's clearly stated as part of the metadata structure. This is more of a catch-all category so we need to make sure folks know right away what kind of info they are getting.

That said, I'm happy to open a dialog about how things should be done if there's someone else who cares now... ;-)

Christine Sommo-FRBNY 13:37, 11 July 2008 (BST) Aha! I knew you could explain it. Thanks! How strict do you think the title structure for this section should be then? I'm perfectly happy with what you've done so far for the feed I'm writing now, but is this something that once more people create "other" feeds will become difficult to apply? Should we even worry about that now? Anyway, I'll probably pester you offline with some additional questions as I am not an economist and am not sure I'm using the atomic elements correctly.

topic or coverage?

Steven Bagshaw-BIS 15:00, 25 January 2008 (UTC) I just noticed that there are some discrepancies in an element within <cb:otherStatistic>. I'm not sure in which direction to fix them, so I hereby ask the RSS-CB stats fellows...

In the user guide, we refer to cb:topic

In the statistics 1.1 application guide, we refer to cb:coverage

In the specification, it's an odd mix of both cb:topic and cb:coverage

I'm not sure which is the preferred element.

Paul Asman-FRBNY 15:39, 25 January 2008 (UTC) It's a bit worse than Steve indicated. The spec also includes an element, dateType, which didn't make it to the user guide.

Steven Bagshaw-BIS 15:26, 11 February 2008 (UTC) Does anyone know? It would be good to fix up this discrepancy if we can. I'm not so familiar with the statistics application, so I'd just be guessing if I chose one of the two options.

San 16:44, 11 February 2008 (UTC) Dan and I are in the process of working out who is going to clean up what. If anyone has a preference for terminology, let me know. The issue applies only to otherStatistics where it is necessary to indicate what on earth the number represents since it doesn't get it's own cb tag. cb:topic should be used for indicating to what economic phenomenon the number applies. A tag called cb:coverage would be used for distinguishing between industries, for example, or if we are going to start publishing sub-national data. So both would be used but I think only cb:topic would be required. Let me know if I'm missing something....

Getting this guide in order

Christine Sommo-FRBNY 20:51, 11 November 2007 (UTC) I updated the exchange rate, interest rate and transaction sections. I think they follow the spec now. Review is welcome!

One issue is that I don't think the headings (the style, that is) accurately reflect the parent child relationships of certain elements, but I'm not sure they did in the previous version. Should they?

I didn't do any work on the other statistics section as I'm not as familiar with it. I'm happy to do this if someone with more experience volunteers assistance.

Mike Eltsufin-FRBNY 17:21, 14 November 2007 (UTC) I've gone through all of the feed examples on this page and modified them to make sure that they validate against the current schemas.


Christine Sommo-FRBNY 16:42, 9 November 2007 (UTC) An ISO country code for the euro area does not exist. U2 is used in some systems (as per Xavier), but this warrants further discussion before being added to the schema.

Christine Sommo-FRBNY 21:02, 11 November 2007 (UTC) Note that I updated this page and left cb:country required for now and based the placement of fields in title on the assumption that ISO country code followed by a colon will be the first item in a statistics feed title. If this group comes to some other agreement, I will change it.

Xavier Sosnowska-ECB 10:45, 16 November 2007 (UTC) We would like to propose to make the country element optional instead of mandatory. Although this information is indeed useful in many cases (including when displaying it in the title for data such as exchange rates), the mandatory status of the element nevertheless creates us two problems in our euro foreign exchange reference rates feeds:

1. Our titles do not include the country code as the euro area is not a country. We could put the institution code instead (i.e.: ECB), but that would break the recommended elements order. This problem does not break the RSS-CB standard but we nevertheless do not currently follow the best practices for the title element. 2. More importantly, there is no code for grouping of countries (such as the euro area) in the ISO 3166-1 standard, which we have to use for the country element. So, at this moment, our feeds are not compliant with the RSS-CB standard (they would not pass the validation test). Adding a code for the euro area would mean that we would need to a) agree on the code to be used, b) extend the current code list, which means that it would not be the ISO standard anymore.

Both these issues could be solved, in our opinion, by simply making the element optional instead of mandatory.

If, however, the case of the euro area exchange rates is seen as a too limited case and too small a reason to make the country element optional, we could possibly suggest the code «U2» (for the "euro area"), however, in this case, we would wish, first, to conduct additional internal discussions and also with the SDMX Secretariat. Then, if the feedback is positive, we could also probably start make this code more visible (e.g. an article in wikipedia).

Paul Asman-FRBNY 21:00, 16 November 2007 (UTC) We put the country code prefix in, as I recall, so that people looking at the same rate from more than one institution could see its origin at a glance. (We figured that, from a customer point of view, the source is the United States, not a particular Federal Reserve Bank within the United States.) The ECB doesn't represent a country, though, so this doesn't work. Okay. So which of the two solutions Xavier proposes should we use? (I don't see a third.)

I think that this is up to the aggregaters. In my active bookmarks, I see our rates in a folder (channel) clearly identified as ours. I don't need to see 'US' also; I know the source from the folder title. But an aggregater might be putting together rates from several sources and posting them within one channel. What does the aggregater need to have to serve its customers? I'd like them to weigh in on this.

Christine Sommo-FRBNY 13:51, 19 November 2007 (UTC) Changes made to exchange rates should also apply to all other statistics feeds, agreed?

Steven Bagshaw-BIS 14:47, 19 November 2007 (UTC) I guess I represent the aggregator Paul mentioned...

Not that we are planning to aggregate this data, but if we were, I would want the field to be mandatory. I think it would be useful for other parties if it were mandatory too.

Is part of this debate whether to have it in the title? I would say it should certainly be optional in the title. Anything otherwise essential can be optional in the title, so long as it has its own discrete element. It may be a bit more programming for the aggregator, but so be it.

I notice that the ISO says to use EU for the European Union in ISO 3166, even though it's not a country. So, I think we could certainly say that for RSS-CB, U2 equals the euro area. Sharing usage with SDMX would be good.

So, I'd vote for keeping cb:country mandatory, with the special value of U2.

Steven Bagshaw-BIS 14:49, 19 November 2007 (UTC) Sorry, my reference for saying ISO bends its rules a little (and therefore, so can we) is here. (See 3rd FAQ)

Paul Asman-FRBNY 19:41, 19 November 2007 (UTC) We were talking about titles, mostly. I think that we have enough to settle that part. As Steve points out, should aggregators wish to construct a title from a title without a country at the beginning, they can do so from an atomic element. Furthermore, the spec for the title simply states that it must be free text; it's only in the application guides that we give particular formats. It would seem to meet the needs of the ECB and the BIS (in its role as aggregator) to make the initial element an optional recommendation in the application guide. If there is concurrence on this, I can change the guide.

This solution depends, as Steve says, on having the atomic element. Given that we must accommodate entities that are not countries, I think that we need to change the spec such that the codes come from ISO-3166 in the case that the entity is a country and from an extension (that I think we should build) if they are not. This would require the ECB to settle on a code, and I think that they should - this strikes me as an internal decision for the organization being named. If we need to change the element name from country to countryOrEquivalent, we can do that as well, although I don't think that necessary.

Christine Sommo-FRBNY 20:05, 19 November 2007 (UTC) one vote of concurrence (proper usage of that word? I don't know.) for making the country element in the title optional.

I'm also voting for changing the spec as Paul and Steve suggest (keeping cb:country required, but allowing for extensions of ISO 3166) and for the ECB providing a code for the atomic element. I don't care whether we call it cb:country or cb:countryOrEquivalent.

Mike Eltsufin-FRBNY 14:36, 21 November 2007 (UTC) As of Revision 21, Steve and I have modified the schemas extending ISO 3166 country codes list with 'U2' for 'Euro area' and 'EU' for the 'European Union'.

Christine Sommo-FRBNY 14:53, 21 November 2007 (UTC) I think we're moving too fast on the country codes here. Don't we need to wait for the ECB to conduct discussions internally and with the SDMX secretariat before making these changes?

Steven Bagshaw-BIS 14:57, 21 November 2007 (UTC) I think this is called "optimism". Seriously though, we can remove it if the ECB prefers for now, but it doesn't make much difference in the schemas - it's just a valid value if/when present in the data. If the selected value ends up not being 'U2', then we can change the schema. It's just one line. Xavier?

Christine Sommo-FRBNY 15:31, 21 November 2007 (UTC) Duly noted. This is the second time in a week that my optimism in the face of seemingly insurmountable obstacles has been pointed out to me.  :)

Exchange Rates

Christine Sommo-FRBNY 20:08, 8 November 2007 (UTC) I'm copying a long discussion that has occurred over the last two days in e-mail.

Xavier Sosnowska: 1. The specification requires that the country code comes from ISO3166. However, there is no code for the European Union or the euro area (http://www.niso.org/standards/resources/3166.html#euro). Should we not add something in the specs?

2. In the Statistical data guide, I do not see any element <cb:exchangeRate>, as you have in your feeds http://www.newyorkfed.org/rss/feeds/fxrates12_EUR.xml. Could you please let us know what is the correct (best?) way to display data for exchange rates?

Paul Asman: 1. We should add something about EU, I agree. We're treating EU as a country as a back-formation from the ISO 4217 currency codes. I don't think that there are any other currency codes for which would work - you can't get from XPF to XP, for example.

2. As far as I can tell - and I discovered this earlier today, when I first saw Marcello's file - the application guide was not updated to reflect the changes to the spec, even though it is called 1.1. I tried to offload the work to bring it up to spec onto Steve Bagshaw, but I haven't heard yet if he's willing. If not, we'll do it, I fear.

Xavier Sosnowska: Why is the country element required for exchange rates? Would the type of rates, the base currency, the target currency, the institution, the date and the value elements not be sufficient (along with attributes such as frequency, decimals and unit_mult of course)? Could it not be made optional rather than required?

And out of curiosity, why is the dollar sometimes used as base currency for your exchange rates (e.g.: CAD, CHF, CNY) and sometimes not (e.g.: AUD, GBP, EUR)? Is this based on preferences expressed by your main users?

Christine Sommo: Q1: The country code is required to allow aggregators (human and otherwise) of our feeds to quickly

see which institution reported the rate. For example, we might claim the dollar has more value

against the euro than the ECB on a given day. Unlikely I suppose, but possible.

Q2: It's one of those legacy things. That is simply how it has always been done. I can't remember

if anyone was able to give the reasons (Paul, feel free to chime in here.) for why those decisions

were made years ago, but since that is what we've been doing for ages, that is what we will continue

to do. Until of course, we stop publishing these rates next year. But no one wants to get me

started on THAT again...

Xavier Sosnowska: Maybe I totally miss the point (in which case I apologize in advance ;-), but is it not what the

institution abbreviation is for (which is also provided)? In the exchange rates examples, that would

be "ECB" and "NYFed" for example, and not "Euro area" or "US".

Paul Asman: The country prefix at the beginning of the title of the exchange rate that we report for the Indian

Rupee against the US dollar indicates that this rate is an official rate of the United States. I

might also want to have India's rate up there, and the prefix would tell me which is which if I

aggregated them into one folder. That it's the NYFed that reports the rate was thought to be less

important, and so that information is farther down in the title - in the part that's not visible,

given the real estate I'm willing to devote to my bookmarks. (I have the rupee up because I'm

travelling there later this month. I get to watch the US dollar buy fewer rupees each day until I


I don't know if this makes sense, but it was, I think, the reasoning: to put, right at the start of

the title, the country that's reporting the rate, in the context that the institution is not the

same thing as the country.

Xavier Sosnowska: Many thanks for the information. Actually, I was just wondering whether this element really is

"required" or whether you think it could be made "optional" (those who need it use it, those who

don't need it, just leave it out. Our data structure definition for exchange rates does not include

the country information for instance). If the element becomes optional, then our feed title could be

something like: 1.4722 USD = 1 EUR 2007-11-07 ECB Spot...

Marcello Di Pietro: I agree with Xavier. And our feed is already like this. Therefore I propose to change the country element in the title from "required" to "optional"

Christine Sommo: One of our intentions in making the country code required in the title of data feeds was to allow

parsing of the title in addition to the atomic elements. Changing this element to optional makes

that impossible (or at the very least, quite difficult). And that kind of change needs to be

discussed and agreed upon (or not) by the entire group. Therefore, we must get Xavier and Marcello wiki accounts and move this discussion there so all can

contribute in one long string to be saved for generations to come.

I volunteer to see that the discussion to this point is captured in some semi-coherent form in the


Xavier, In another e-mail you mentioned keeping your feed as is since this is the only non-valid item in

there. I agree with this approach for now.

Paul Asman: Whenever I see scare quotes - one of the terms used here for quotation marks that aren't used to

quote - I get scared. There's actually nothing in the specification that requires anything of the

title other than text. The application guide for statistical data uses the word 'required' in one

sentence that would apply to title: "As published on most central bank websites, exchange rates

contain certain pieces of information that are required to make them unique and unambiguous," and

one of these is country reporting the rate. You'd be in compliance with the spec whatever you had in

the title.

That said, the application guide does create, I think, legitimate expectations that it will be

followed. We put the country code at the start because we thought it would help those aggregating

feeds for exchange rates from different sources but between the same two countries. I continue to

believe this, even with the presence of country code as an atomic element.

Xavier, you now have access to the forum. I hope that Marcello does as well. (And we'll expand the

administration base so that we don't have this problem again.) I think that we should move this

discussion there, to the discussion page for statistical data. Perhaps you could suggest the

language you think should be in the application guide.


Somehow this is needed for the TOC to appear. Something to do with the text above.