Paul Asman-FRBNY 13:33, 18 November 2008 (UTC) According to the DCMI specification, the value of this element must be web-addressable. I have therefore removed the option that the text of the license can be included in lieu of a URL.
Paul Asman-FRBNY 12:57, 18 November 2008 (UTC) dcterms:audience has a range of AgentClass, such as a class defined to include high school students. It does not permit literals, such as "Economic Club of New York." Since our intention was to capture not an agent class but a group for whom an event is scheduled or to whom a speech is given, identified by a literal, I have removed the dcterms element from the specification, and added a cb element under events and speeches. Creators of RSS-CB feeds can continue to use dcterms:audience if they wish to specify an agent class, as they can use any dcterms element; all dcterms elements are optional.
New location elements
Please help out by having a look around to spot errors, or clearer ways of describing the new elements.
Christine Sommo-FRBNY 19:41, 11 November 2007 (UTC) The spec reads: The <cb:statistics> element has two required child elements, the second of which is a choice among statistics application subtypes. The child elements must appear in the order shown below, and any additional elements, including custom elements, must follow them.
Shouldn't it read: The <cb:statistics> element has three required child elements, the third of which is a choice among statistics application subtypes. The child elements must appear in the order shown below, and any additional elements, including custom elements, must follow them.
Christine Sommo-FRBNY 20:12, 8 November 2007 (UTC) I am copying discussion begun in e-mail regarding frequency.
Xavier Sosnowska: In the framework of SDMX, to the best of my knowledge, there seems to be an agreement on the code list for frequency. And, again to the best of my knowledge, the following list is already used by institutions such as the ECB, the BIS, Eurostat, the OECD, etc. Should we not maybe promote the use of this list then (if not already done but I could not find it in the documentation)? A Annual, B Business, D Daily, H Half-yearly, M Monthly, N Minutely (this is under discussion), Q Quarterly, W Weekly
San Cannon: The current list isn't quite adequate (I've raised this with the SDMX folks on more than one occasion!) as there are frequencies that aren't listed. Noe has three times a year data and we often deal with more unusual frequencies such as twice monthly (I can never remember if that's semi-monthly or bimonthly!) as well as data released every two weeks and of course my favorite: 10 day auto sales which are (usually) published 3 times a month - except in February of course.....
Dan, Noe and I have decided to use the Dublin Core frequency list as our starting point (http://dublincore.org/groups/collections/frequency/) since it covers all the odd cases of which we are aware. We were in the process of putting together "suggested" date representations for the DC list for the group to discuss but we got sidetracked. We can certainly make suggestions as to codes for the frequencies on this list that aren't on the list Xavier suggests if no one else feels like tackling it.
As always, I'm happy to discuss (debate?) this topic with all and sundry. Paul, please note that I have recovered from my issues with varying days for weekly frequency and am happy to accept "Weekly" in general (until I can think of better arguments!)
Christos Androvitsaneas: Indeed, as San points out, the previous discussion (in the context of an SDMX group/meeting in Basel) was not actually finalised. Also, currently, the on-going discussions on some "common" code lists (in the sense that they could have the potential to be used by several institutions) in the SDMX Secretariat are expected to end up to "proposals" that will be subject to further public review. With the frequency, there may also be some misunderstandings. Of course, series and observations could be observed at very peculiar regular or peculiar irregular frequencies. That is OK. However, for reasons of simplicity and in order not to overload users (in particular, end-users) with codes from a very long frequency code list, we have found (at least in ECB, Eurostat, BIS) that in all cases (so far), for a dimension "frequency", participating with other dimensions in the identification of time series, it would be enough to have the code list shown above by Xavier. This allows producers and end-users to simply remember (and it is easy) what A, B, D, H, M, N, Q, W mean, and this is easy (the "period" or time-stamp which anyway indexes/identifies anyway any observation completes its "timing" identification). For example if a series may happen to have two observations per year and these to occur on a particular date, we would code it as daily (implicitly assuming that for all other dates we have empty cells/holes or missing values). We are pretty confident that with this technique we can cover/identify all cases, including difficult ones (of course, happy to further discuss difficult cases).
San 21:13, 9 November 2007 (UTC) Christos, I'm trying to follow your example but it reads to me as though you are suggesting that half-yearly (semi-annual?) series be marked as "Daily" with a three part date (m-d-y or some variation) indicating the two times a year that the data are published. I hope that's not what you are suggesting because I couldn't disagree more strongly! I suspect I missed something because there is an "H" in Xavier's list so that gives me some hope...
Let me explain the position of folks here at the Board: a datum which is meant to capture some economic phenomenon over a period of time longer than 24 hours should NOT have an index which ties it to a particular date. Period. End of story. This was my big quibble with SDMX - an observation for the first quarter of 2007 is meant to capture some condition from January 1, 2007 until March 31, 2007 so assigning it a date index with a month, day and year is wrong. It doesn't matter if you pick the first day of the period or the last day of the period; there should be no particular date.
While I agree that keeping things simple is best, I still feel strongly that W3C-style three part dates are not adequate for anything with a lower frequency than weekly. Others may think I'm being pedantic but this is an issue that very senior people here are adamant about. I'm happy to try to reach a consensus but unfortunately it will appear that I am being a truculant child because if any other decision is made, we won't abide by it. It really doesn't matter if *I* think one way is right or wrong, it is that I don't think I'll be allowed to publish data that are dated contrary to our officer's beliefs. Therefore, we'll either do it "our" way or we won't publish it in RSS.
I have been through this all before with implementing our Data Download Program on the public website and this issue almost completely derailed the application launch because in order to follow the SDMX spec, we *had* to assign a W3C date to quarterly observations. The only way we got approval for that was to ensure that it only appeared in the XML and to promise that we would change it to the "proper" date representation when it was incorporated into the spec.
Slumping down off my soapbox now....
Christos Androvitsaneas: I think we actually share the same views. Indeed, having always two observations per year (one corresponding to each semester) has to be represented with H (half yearly). "Daily" would need to be used only if the pattern of appearance is unknown and if it is also possible that more than one observation might appear in one semester (and, especially, if more than one observation might appear within a month, as this would also exclude the possibility to assume/consider the "monthly" frequency). All these considerations, nevertheless, concern data and databases (so, for RSS, the considerations may be, indeed, different). Generally speaking, an approach that SDMX may need to follow is the acceptance of a "core code list" (e.g. for frequency: A, B, D, H, M, N, Q, W) and to also acknowledge that various institutions may also have additional needs that would need to be served through additional codes (extensions). For example, in Europe, besides the ISO country codes, we need several additional codes (extensions) for country grouppings (e.g. EU15, EU27, euro area, EU27 without euro area countries, etc).
Job title required in cb:role?
San 17:41, 31 October 2007 (UTC) Just curious but.... why are we requiring the Job title component of cb:role? We'd like to use it for our research papers but don't want to worry about correctly specifying job titles for authors (which are irrelevant for papers) especially for co-authors that are not at the Board. We want to use cb:body to indicate where the authors are since so many of them are at universities somewhere but I don't want to have to worry whether or not someone is an assistant or associate professor....
I understand why it's important for speeches but if we are going to allow it as a component of cb:paper, then we shouldn't require irrelevant information.
Noe Palmerin-Banco de Mexico 18:13, 31 October 2007 (UTC) Certainly we do not put the "Job title" in our research papers, and I do not believe we will do it. I just checked and BIS neither. We should put this as optional at least.
Paul Asman-FRBNY 18:47, 31 October 2007 (UTC) I think that you want to bar a role element with no child elements, which you can get if both are optional. That said, how should the following use cases be represented:
- Principal Analyst, Forrester
- Independent Scholar
- New York University
- First Vice President and Chief Operating Officer, Federal Reserve Bank of New York
- Professor of Economics, New York University and Columbia University
- Columbia University and New York University
- Advisor, Federal Reserve Bank of Minneapolis and Professor, University of Chicago
And I'm sure that there are others; please add them.
San 23:23, 31 October 2007 (UTC) I don't get it - Paul, are you arguing for having Job Title be optional or against? I can certainly outline how I would propose tagging the examples above but I'm afraid I'm missing the point. For working papers, do we actually want to indicate that someone is an associate professor versus an assistant professor? Does it matter? I see where it would for speeches and I think it's important to indicate the institutional affiliation for each author but I don't see what specifying the title gets us.
If <cb:role> is optional, then why would anyone include it if they intend to leave out the child elements? I would argue that if one of the fields should be required, it should be body and not job Title. In practice, that's what we'll include. I'm not interested in the work involved in tracking down the titles for all the authors of the 75+ working papers we put out each year.
Playing the Timo card, is there any value to this information to an aggregator?
Paul Asman-FRBNY 13:38, 1 November 2007 (UTC) I'm not arguing for or against Job Title being optional. I have no particular expertise in this area, and it doesn't much matter to me.
It does matter to me, though, that the schema guard against someone putting in cb:role without any text children of the child elements. Perhaps no one will intend to, but no one will intend to put an alpha character in a numeric field, either. I think that the schema needs to guard against unintentional errors as well as against misunderstandings. To answer your question directly ("why would anyone include it if they intend to leave out the child elements?"), I suggest negligence as an answer.
I put up the use cases to find out what actually needs to be in cb:role, so that those writing the schema can know what to include.
San 15:11, 1 November 2007 (UTC) Here's how I would tag these - assuming that where title is indicated, it should be included but otherwise not. Feel free to suggest alternatives. I know that multiple roles per person is okay but I don't know if multiple body or jobTitle tags per role would work.
<cb:role> <cb:jobTitle>Principal Analyst</cb:jobTitle> <cb:body>Forrester</cb:body> </cb:role>
<cb:role> <cb:body>Independent Scholar</cb:body> </cb:role>
<cb:role> <cb:body>New York University</cb:body> </cb:role>
<cb:role> <cb:jobTitle>First Vice President</cb:jobTitle> <cb:body>Federal Reserve Bank of New York</cb:body> </cb:role> <cb:role> <cb:jobTitle>Chief Operating Officer</cb:jobTitle> <cb:body>Federal Reserve Bank of New York</cb:body> </cb:role>
<cb:role> <cb:jobTitle>Professor of Economics</cb:jobTitle> <cb:body>New York University</cb:body> </cb:role> <cb:role> <cb:jobTitle>Professor of Economics</cb:jobTitle> <cb:body>Columbia University</cb:body> </cb:role>
<cb:role> <cb:body>Columbia University</cb:body> </cb:role> <cb:role> <cb:body>New York University</cb:body> </cb:role>
<cb:role> <cb:jobTitle>Advisor</cb:jobTitle> <cb:body>Federal Reserve Bank of Minneapolis</cb:body> </cb:role> <cb:role> <cb:jobTitle>Professor</cb:jobTitle> <cb:body>University of Chicago</cb:body> </cb:role>
Dan 15:43, 1 November 2007 (UTC) San, I think what you wrote does address Paul's concern that <role> not be used if there is nothing inside. Maybe what's left to consider is that "New York University" doesn't by itself sound like what a human being would expect to be a "role". This kind if entity is normally called an "affiliation", and affiliations often appear without titles. If we ignore the human connotation of the terms, then your suggestion captures the necessary information and should work perfectly. I'm wondering though about two different "role" elements for the two-school guy. If we expect people to search by school, it's fine, but if it's just there to allow for flexibility of formatting, then maybe the two schools could go into the same <body> tag.
Paul Asman-FRBNY 15:58, 1 November 2007 (UTC) 'affiliation' in place of 'body' also makes sense of 'Independent Scholar', which is the use case I threw in that seemed to have a jobTitle but not a body. Since a role is only in a context, affiliation should always make sense, in a way that body (in English) does not. I support that change.
The text children of affiliation (or body) would be free text, so the schema would prohibit neither two instances of role with single universities named in each, or one instance of role with a conjunction of universities. We could of course make recommendations in the guide. But the only restriction the schema can make is to limit the number of instances, and while that could work for someone with the same position at two institutions it wouldn't work for someone with different positions at two institutions, at least not easily. So here I support multiple instances, and leave it to others to establish best practices to be recommended in the application guide.
San 20:30, 1 November 2007 (UTC) So we appear to be in agreement: cb:role will have two children, jobTitle is optional and affiliation is required.... yes?
Mike Eltsufin-FRBNY 19:14, 8 November 2007 (UTC) I've modified the spec and the user guide to make use of cb:affiliation instead of cb:body and made both cb:jobTitle and cb:affiliation optional. I'll upload the updated schemas in a few minutes. If anyone objects, please post here.
Steven Bagshaw-BIS 11:11, 13 November 2007 (UTC) I just noticed this now.
Actually, we would like to put job title into our feeds, but we don't have the data to do it at the moment.
Someone asked about the usefulness to aggregators... it would be very useful for us (in the medium-term) if RSS-CB feeds did have these values. It would mean we could generate automatically the text we currently we do by hand to fully describe a speech. If some feeds have the data and some don't, it would be mostly useless.
Most useful for the BIS would be if cb:jobTitle and cb:affiliation were required for speeches. That is to say, the BIS would require them to be aggregated in our feed, as we only take speeches from staff at the level of Deputy Governor and above.
So firstly, I think optional is too weak for these fields. I would suggest recommended at least.
Secondly, could we make one or both required for speeches? Will anyone publish a speech that would fall under any of the odd scenarios listed by Paul?
At the moment, we say in the User Guide that some applications such as speeches may have different guidelines on optional/recommended etc. But the speech app guide itself is silent on this.
San 13:45, 13 November 2007 (UTC) I certainly have no objection to title being required for some applications and not for others if that makes logical sense to all and is technologically feasible. My concern was having it be required for research papers where it doesn't make sense. Speeches is a different kettle of fish, as they say, and for those it makes sense to have them required or at least recommended.
Steven Bagshaw-BIS 09:47, 15 November 2007 (UTC) Mike, perhaps you can confirm, but it looks as if we couldn't make role and its child elements required for one application and not for others? If that is correct, I'll change the spec to say it is (strongly!) recommended for speeches, and optional for other applications.
Mike Eltsufin-FRBNY 15:54, 15 November 2007 (UTC) Steven, it is actually possible to make role and its child elements required for one application and not for others because cb:person is a child element of the specific application element and we can use different type definitions for cb:person in different applications. However, this might be a little confusing for the users of the feeds if they assume a uniform structure for elements with the same name regardless of the context in which they appear. Another option might be for speeches to use a new element instead of cb:person and call it cb:speaker.
Steven Bagshaw-BIS 16:08, 15 November 2007 (UTC) I wouldn't want to make a new element, because it is basically the same thing and I imagine people might want to drive an "entity" or "person" database from all of the cb:person elements in the various applications.
I think users of the feeds would more likely use the user and application guides, rather than the schemas, to understand the structure. So long as that is clear, if the schemas had to be a bit more complicated, I'd be fine with it. So long as it's always called cb:person in all apps.
If it's possible, I'd like to do that. But was there any disagreement in the end for making role required for speeches? And affiliation required, and jobTitle recommended?
Steven Bagshaw-BIS 16:00, 20 November 2007 (UTC) OK, I made the changes along these lines.
Mike, as I'm not sure how to reflect the fact that person, role and affiliation are required for speeches (only), would you be able to adjust the schemas? I'll try to have a look at how it was done afterwards. No hurry!
Mike Eltsufin-FRBNY 22:42, 20 November 2007 (UTC) I've updated the schemas to make person, role and affiliation required for speeches only. I also took the liberty of extending the country codes list to include 'U2' for European Union, even though I didn't see a definite consensus on that.
Steven, can you add a link to 'Technical Tools' on the left panel under 'RSS-CB quick access'.
Steven Bagshaw-BIS 08:30, 21 November 2007 (UTC) Thanks Mike!
Actually, U2 is Euro area, which is not equal to the European Union. I am going to modify that and I thought I may as well add EU for the European Union itself. Presumably someone will want to use that some day - and it is an ISO-approved extension.
I've added technical tools to the side navigation.
XML Schemas Updated (rev 15)
Mike Eltsufin-FRBNY 21:49, 24 October 2007 (BST) I've updated the RSS-CB schemas to reflect the current state of the spec (see: Technical tools). The major update is that the rss-cb namespace has changed to "http://www.cbwiki.net/wiki/index.php/Specification_1.1". Following San's suggestion below, cb:observationPeriod has been implemented. I've also modified the Sample RSS-CB 1.1 file to validate against the current schemas.
San 15:35, 9 October 2007 (BST) I have changed the required element for other statistics from date to observationPeriod to allow it to remain free text without offending anyone's sensibilities. Are there any other changes that need to be made? Also, it appears that our rates and transaction data types don't actually have a specification for observationDate - will there ever be a case that the dc:date won't be the observation date?
Christine Sommo-FRBNY 21:28, 11 November 2007 (UTC) While it would truly be a terrible thing to have the publication date be anything other than the observation date with the statistics feeds, I suppose it could happen. (Although with exchange and interest rate I think the observation would also then be obsolete.) But if it were put to a vote, I would hang my chad in favor of adding observationDate.
San 12:03, 12 November 2007 (UTC) The issue here is that for statistics that aren't at a daily frequency, the publication date will not equal the observation period. You are right that for exchange rates and interest rates, which have been our real focus up to now, the distinction is a small one and observationDate (a three part W3C date) makes sense. But for quarterly flow of funds data, the publication date will be 12-06-2007 (or 06-12-2007) but the observationPeriod will be 2007Q3. A three part date is not appropriate here. (See my foaming-at-the-mouth rant about this under Frequency on the talk page for the spec.
Christine Sommo-FRBNY 14:33, 12 November 2007 (UTC) So, this is the recommendation? Daily statistics would have a dc:date and observationDate (both using a three-part W3C date)and others would have a dc:date and observationPeriod (free-flow text)?
San 14:57, 12 November 2007 (UTC) I don't think that specific text has appeared anywhere but the idea is the same. Question: do we need observationDate as a distinct entity? I see where it would be useful but are we convoluting things too much by having the date field be named differently for different types of statistics?
Christine Sommo-FRBNY 13:01, 13 November 2007 (UTC) I don't think it's too convoluted. Where possible a W3C date is better than free text. And using one element to capture either a formatted date or free text doesn't seem right either.
So, how long do you think you and I can keep this echo chamber going before others chime in? :-)
San 14:30, 13 November 2007 (UTC) I don't know - we're following the rules... I'd send out an email alerting folks to the discussion but I'd probably get yelled at... ;-)
Steven Bagshaw-BIS 14:35, 13 November 2007 (UTC) We are not actively working on any statistics feeds at the moment (maybe in the middle of next year), thus I don't feel I can contribute anything useful. :-)
Christine Sommo-FRBNY 18:06, 13 November 2007 (UTC) San - you and I could simply come to an agreement and put it in the spec.
Steve - thanks for acknowledging us!
San 19:04, 13 November 2007 (UTC) Agreed! Can we say that either observationDate *or* observationPeriod is required depending on the frequency? How does that affect the schema? Can I send Mike an email asking him to address this before we make spec changes?
Christine Sommo-FRBNY 19:09, 13 November 2007 (UTC) Yes! Let's ask Mike and then just do it.
Mike Eltsufin-FRBNY 23:26, 13 November 2007 (UTC) I assume we are talking about the cb:otherStatistic element because it's the only element that has cb:observationPeriod as a child. This rule that either observationDate *or* observationPeriod is required depending on the frequency attribute cannot be expressed in XML Schema given the current structure of the feeds. This semantic rule can be expressed if we change the structure to where frequency would actually be an element rather than an attribute, and the cb:observationPeriod/cb:observationDate would be a child element of the frequency element, but it would seem awkward and confusing, and I don't recommend doing that.
Instead, I would suggest making cb:observationPeriod more structured by adding two child elements strictly formatted as dates: periodStartDate and periodEndDate. Would that work for the different scenarios you are thinking of?
Christine Sommo-FRBNY 12:38, 14 November 2007 (UTC) We're also talking about adding it to the other statistics feeds which are more likely to have a daily frequency, so periodStartDate and periodEndDate would be overkill.
San 13:38, 14 November 2007 (UTC) And just to throw a monkey wrench into the works, it's possible (though not likely) that this issue will apply to data besides otherStatistics. I'm not sure we'd *want* to post monthly exchange rates (or interest rates) as an RSS feed but we have them and if it was useful, we could certainly create feeds for them.
Is having just observationPeriod even for daily data really that bad?
Steven Bagshaw-BIS 13:43, 14 November 2007 (UTC) No comment here on the basic issue, but the BIS will mostly likely have a monthly feed of (effective) exchange rates.
San 14:16, 14 November 2007 (UTC) Thanks for letting us know Steve. If nothing else, it shows that this is not just an issue for the otherStatistics data type. Once we get things ironed out, we'll need to add the solution to the other data feed types as well.
Mike Eltsufin-FRBNY 16:06, 14 November 2007 (UTC) For feeds to be meaningful to machines, I think it's very important to have a well structured format for the dates specified in observationDate/observationPeriod. We can allow a choice between observationDate and obvservationPeriod, where observationPeriod would have a startDate and endDate. However this would have to be independent of the frequency. This will only work if you can put dates on things such as "Fall 2007".
Dan 16:49, 14 November 2007 (UTC)I think we have decided not to support automated processes chosen primarily to serve database loaders. We will build the format to serve automated process designed to support aggregated RSS feeds to be viewed by humans. As such, start-date and end-date for a week, month, or quarter would not be the best choice. We use "name as written" for names, and the concept (if not the element name) may work for period labels. One approach is to label periods according to the way the data provider labels them. We may not need anything else. Users are accustomed to seeing quarters like Q1, months like "January", and probably weeks like 3-part dates. I think oddball periods would be used in circumstances where the original data provider uses a specific period label in press releases, say. I am assuming that end-users of RSS feeds are familiar with the data items being served, and care more about standard usage for those products rather than some kind of format conformity between products. I also think it's fine to use, as additional elements, DC frequency names and publication dates, mostly for feed operational support. but humans should have access to the period labels used by the primary data provider.
San 19:29, 14 November 2007 (UTC) Hang on to your hats - Dan and I agree!!! ;-)
I like Dan's example of the nameAsWritten - that's really how we've been viewing this field. While there is no reason that someone can't use the feeds to populate a database, that isn't their purpose and it's not something I think we should design the spec specifically to accommodate. I know I've used this example in discussions elsewhere but I think of these feeds as being used by, say, a big commercial bank that wants to repackage our data for representation on an internal website. The machine is reading the feed and picking off the pieces that they want to use for their page but the ultimate consumer of the repurposed information is a human - similar to the repackaging that Timo and company do for central bank speeches. We aren't providing the tags for those simply for automated processes to use except as input for displaying to humans. I have no problem with daily data using a 3-part W3C date in the observationPeriod field as free text if that's what the central bank wants. Alternatively, they could use <observationPeriod>January 28, 2007</observationPeriod> if it makes them happy. They wouldn't do that in the title because the 40 character constraint would make it impractical and we probably wouldn't recommend that they do it that way but being a text field, we can't do much about that. That said, I am in favor of beefing up the application guide to indicate what we do recommend - which is what is promised in the application guide. Dan is going to take some initial suggestions for formats for the Dublin Core frequency list and float them for general comment as we mentioned in the frequency discussion(right Dan?).
Christine Sommo-FRBNY 13:48, 15 November 2007 (UTC) So, what this sounds like is ONE new required free text element called observationPeriod that could also include three part W3C dates. Am I correct? And if I am, can I think about for it a bit before I commit?
By the way, I feel a little uneasy about the fact that San and Dan agree.
San 14:37, 15 November 2007 (UTC) You should be nervous... it's obviously a vast research conspiracy! ;-)
Your summation is correct and please feel free to contemplate before chiming in. I'd really like to hear other people's opinions as well.
Dan 14:50, 15 November 2007 (UTC) I'm nervous about it myself. I'll just clarify my understanding by saying that the free text element might be structured to look just like a three-part W3C date, but I don't expect any automated system or validity checker to treat it as one. When it looks like one, it's only for the benefit of human eyes.
San 15:30, 15 November 2007 (UTC) Dan, good point. That said, however, if we indicate that we recommend a W3C date where appropriate (do we recommend that? I think so...) then programmers will know what format the text string will have for that frequency and can program the approprate action for the "then" part of the if freq = "daily" type statement - if they are really interested in using the date as a date object.
Dan 15:40, 15 November 2007 (UTC) That wouldn't bother me, San. I think it would be "un-XML-like" to build an application around it, I think, but if the text field has a known data format it would be easy to parse if necessary.
Noe Palmerin-Banco de Mexico 16:42, 15 November 2007 (UTC) Ok, I must say that I concur with San and Dan (there is three votes now), nevertheless I don't like the idea about the recommendation for daily and non-daily information, it really sounds "un-XML-like" as Dan says. Maybe we could just put some examples about this and not being so explicit. Just a thought.
Mike Eltsufin-FRBNY 16:53, 15 November 2007 (UTC) As a conclusion, are we agreeing to leave observationPeriod as free-text but use the guides to explain how it should be properly used? Also, currently, observationPeriod is only part of the cb:otherStatistic. Should it be added to other cb:statistics sub-elements: cb:exchangeRate, cb:interestRate, and cb:transaction.
Christine Sommo-FRBNY 16:57, 15 November 2007 (UTC) Well, if Noe says it's O.K., then I'm in! :-)
Yes, we need to add it to the other statistics in the application guide.
San 19:21, 15 November 2007 (UTC) Yeah! A consensus! If Mike will take care of the schemas, I'll add the element to the spec and the other guides. I'll leave some text about formatting recommendations being forthcoming until we've had a chance to hash out what we want to formally recommend - and what we want to show by example.
Paul Asman-FRBNY 19:19, 28 June 2007 (BST) As the New York Fed began to convert to 1.1, we found this field useful in all application types. It had been in the spec only for statistics, where it is required. I put it in the spec after occurrenceDate for the other application types. I did not change the application guides or user guide.
Steven Bagshaw-BIS 08:41, 3 July 2007 (BST): Well, no one objected so I have updated the user guide, app guides and schemas to conform to this change.
Christine Sommo-FRBNY 18:18, 26 June 2007 (BST) What happened to the unit_mult attribute for statistics? Was it intentionally omitted and why?
Paul Asman-FRBNY 14:46, 28 June 2007 (BST) In foreign exchange, it's with base currency. This reflects the usage of Bank Negara Malaysia, which is the only instance of which I'm aware where the base currency is not always expressed in units of one. BNM, for example, reports the value of the ringgit against 100 Vietnamese dong - today, 100 dong buy 0.0215 ringgit. While an easy conversion could be done to express how many ringgit one dong buys (0.000215), that's not how BNM reports it. The way they report it, the value (0.0215) has a unit multiplier of one, and the base currency has a unit multiplier of 100 (expressed as the exponent of 10, 2). Should another reporter wish to do differently, we'll adjust the spec to include unit_mult with other fields.
Christine Sommo-FRBNY 23:22, 22 June 2007 (BST) cb:transactionTerm cannot be required for ALL transactions. Obviously,I can't speak for all central banks, but for the NY Fed the term is relevant and absolutely necessary for temporary open market operations because they are repurchase agreements. However, permanent open market operations are exactly that - permanent. Therefore, there is no agreement to repurchase and hence, no term. Creating two unique transactions with different required elements doesn't seem to me to be the solution. I'd really appreciate comments from the collaborators on the new spec.
Mike Eltsufin-FRBNY 15:05, 25 June 2007 (BST) I agree, <cb:transactionTerm> should be optional. Anyone else care to cast a vote?
Christine Sommo-FRBNY 15:31, 26 June 2007 (BST) anyone? anyone? Bueller?
Dublin Core and/or custom namespace elements
Steven Bagshaw-BIS 09:48, 19 June 2007 (BST): I updated this part today to 1.1. To conform with all of the many examples on the wiki, I put the dc elements before the cb:* (event, speech, papers etc) element.
Open question is where cb:custom goes... within cb:* or after it, as a sibling. The example has the former for now. I don't mind either way.
Paul Asman-FRBNY 14:56, 19 June 2007 (BST) To the open question. cb:custom is a catch-all for all additional elements. Some of them might be relevant only to particular applications, but others might be relevant at the item level. For that reason, I think that cb:custom is a sibling of the application. Another way to think of it, leading to the same conclusion: the application element says "here's a bunch of stuff about the application," while the custom element says, "here's a bunch of stuff that we don't characterize or categorize."
Mike Eltsufin-FRBNY 15:09, 19 June 2007 (BST) I agree with Paul about the location of cb:custom. As far as the optional and required dc elements are concerned, I had to switch the order of dc:date (required) and dc:language (optional) to allow any dc elements before the cb elements. The reason for this is that enforcing an order for a selection of optional dc elements right before allowing any dc elements without an order creates a parsing ambiguity and breaks the schema.
Steven Bagshaw-BIS 15:21, 19 June 2007 (BST): Makes sense Paul. I changed that bit.
Mike Eltsufin-FRBNY 17:57, 14 June 2007 (BST) Currently, the definition of <cb:value> varies depending on the type of statistic reported. For example, when it appears under <cb:exchangeRate> the "decimals" and "frequency" attributes are required, but when it appears under <cb:otherStatistic> the "decimals", "frequency", "unit_mult", and "units" attributes are required. I'm afraid this may confuse the users as they might expect a consistent definition of <cb:value> regardless of the context. I think the only inherent attributes of <cb:value> are "unit_mult" and "decimals". I would move other attributes such as "frequency" and "units" to the parent element if they are required. This is already the case for <cb:exchangeRate> because the "units" attribute of the <cb:value> is represented by <cb:baseCurrency>/<cb:targetCurrency>.
Paul Asman-FRBNY 18:52, 7 June 2007 (BST) I'm creating 1.1 by copying 1.0, moving around stuff, and making changes. On the main RSS-CB page, I've warned people off editing it until I complete the initial work. I'll make progress reports under this topic as I go.
Christine Sommo-FRBNY 19:50, 7 June 2007 (BST) I think you lost me in the discussion from the Spec 1.0 page, but I'll wait to see what you create. I hope it's good. I've got my my eye on you.
Paul Asman-FRBNY 14:35, 8 June 2007 (BST) Okay, the first cut is ready. Every reference to the user guide should be wrong, unless one is right by chance. (I didn't look at any of them.)
Steven Bagshaw-BIS 15:11, 8 June 2007 (BST): Some random comments based on a quick look... looking good so far!
1) What about optional elements that are acceptable? For example, at the moment the news application guide says that keyword, person and resource can optionally appear here, but they're not in the spec. (But these would not be allowed in, say, statistics). You have listed resource as optional for events though, not in news, so I'm not sure what the rule is. I guess this is where the big ugly list was OK - it meant you really had to look at the respective application guides to make real sense of things.
Without explicitly mentioning which cb: elements are optional for an application, it would be hard to work out the correct validation.
2) Is the plan for the spec to replace the application guides? For example, now cb:occurrenceDate is listed three times, each with the same data. But if you look at the application guide for events, there is a specific guidance note (saying it is the starting date of the event), but that doesn't apply in the other applications. If we list the element in the spec distinctly for each application, would people look to this definition for all the info on implementation, thus making the app guides obsolete? However, if the app guides become obsolete, the spec itself will become much longer.
3) Note for myself (or someone else): later we need to clean up the cb:person type attribute values. In places we say "Speaker" and in others "speaker".
Overall, I think it's looking better than 1.0 - IMHO.
Paul Asman-FRBNY 15:41, 8 June 2007 (BST) Responses to Steve's comments 1 and 2:
To 1: To make the 1.0 spec work, we needed to call any element that applied to any application optional for all. In most cases, I took elements that in 1.0 were optional but recommended for certain applications as inapplicable outside the mentioned applications. No doubt this is often wrong. In the specific example you cite, I can see keyword may apply, but probably not person. It would be good if someone with more knowledge about news would put in the appropriate optional elements; that person isn't me. In short, the optional elements should be listed, but someone else will need to list them.
To 2: It isn't my plan for the spec to replace the application guides; it was only my plan to write the spec first, and work from there. I repeated the elements in the spec rather than referring to a single instance because I thought it made the spec easier to follow. In a number of cases, the spec differs with different application types and subtypes (most notably, the element 'value' in all the statistics subtypes).
Steven Bagshaw-BIS 14:54, 11 June 2007 (BST): On #1: The work behind this has already been done. It would be better, I think, just to migrate the sense of what is in the 1.0 application guides, rather than try to second-guess them. For example, for news cb:person could be a contact person in the press department, which is what the application guide says at the moment. Moving people to 1.1 will take a lot longer if we have to rehash all this I think.
But if we list all the elements from each of the application guides in the spec multiple times, it'll be huge. So, I'm happy to help with moving these optional elements in, but I'm a bit worried that the end result will be a hard to maintain and very large page.
San 20:38, 11 June 2007 (BST) Can I just chime in and mention that this is part of what I was worried about for "ease" of adoption? I'm not saying we shouldn't do it (I already said that) but I just want to point out that if we are making the spec hard to maintain and navigate due to length, we should feel obliged to ensure that the documentation provides sufficient guidance to allow (encourage?) adoption.
Paul Asman-FRBNY 20:55, 11 June 2007 (BST) I'm not getting the "huge" part. I just went in and added all the fields in the application guides into the spec - all nine of them. For the record, this required adding keyword and person to event, keyword, resource, and person to news, occurrenceDate to paper, keyword to speech, and publicationDate and dataType to otherStatistic. I also moved country up a level in statistics; it was only in the exchangeRate, but it was in the user guide for all four subtypes, and at the same requirement level for each. The spec is a bit longer, but "huge" is a term of art. Harry Potter books are long; so is Ulysses. Harry Potter books are easy to read, Ulysses isn't. I don't see that size matters.
I left out one field that was in the user guide for paper, dcterms:extent. The way I'm doing things now, it would either go with item (as 2.5.8), and be optional for all even when inapplicable, or as the first item in paper, where it would come after cb:paper. Since paper is not my space, I thought that I'd leave this to others. If no choice is made, it becomes simply another dcterms element, which according to the spec would need to be placed after all the specified elements. I'm not sure how that would be handled in the application guide.
Dan 21:50, 14 June 2007 (BST)(Is RSS-CB1.1 "Harry Potter?" The spec is not Ulysses, but it might seem like using the Merriam-Webster Collegiate Dictionary when you care about tracking changes to verbs. But might there be something useful to highlight changes to the spec to help existing users keep up? I'm not sure the talk item above suffices...)
Steven Bagshaw-BIS 08:14, 12 June 2007 (BST): OK. So, what next? User guide 1.1 - app guides 1.1? I'm ready to start on the application guides. I'll start this afternoon with the same naming convention as for the spec??? "<oldpagename> 1.1"
Steven Bagshaw-BIS 12:17, 12 June 2007 (BST): OK, app guides are done, except for stats. That's a little hairy in there, so I'll leave it for now to the stats experts. I've also made a stab at the user guide and the sample file. Comments please.
If someone's happy that we have now officially moved to 1.1, please modify the RSS-CB home page to move the 1.0 links down into the obsolete section I made.
Admin 08:31, 14 June 2007 (BST): OK, everything is 1.1 now (AFAIK), except the Stats application guide and the technical tools. I will work on the latter today.
determining optional, recommended, or required status
Paul Asman-FRBNY 18:52, 7 June 2007 (BST) I'm using the 1.0 status comments as a guide. If 1.0 says that an element is recommended for some applications, and would be required for others if more structure were added, then I'll make it recommended for the first set and required for those others. I'm also using some judgment, so people with a stake in this may want to check my work. If you see the sentence about more structure, I haven't gotten to it yet. (And as of now, I haven't gotten to any.)
Paul Asman-FRBNY 19:28, 7 June 2007 (BST) The 1.0 spec has subtypes (exchange rate, interest rate, transaction, other) for which some fields are required and other recommended. In other words, it has the same pattern as application types. So I'm deepening the hierarchy. Once I get it mostly done - it won't take that long - feel free to fight back.
Steven Bagshaw-BIS 07:27, 8 June 2007 (BST): Don't forget a "generic" application. You reminded me once that the spec says an RSS-CB
<item> does not necessarily have to belong to an application. So I assume we need an element like
<cb:event> for this. (He says not wanting to edit anything while smoke and flames belch from the wiki).
Paul Asman-FRBNY 12:59, 8 June 2007 (BST) I don't think so. If the item doesn't belong to a particular RSS-CB defined application, it stops with the RSS and DC elements. If it's an event in RSS-CB terms, it should use that element. If you don't want to use any of the RSS-CB apparatus, you might put some sort of indication that it's an event in the title or description. I haven't put in cardinality for the choices yet, but I envision the choice of events|news|speech|paper|statistics as 0 or 1.