Steven Bagshaw-BIS 08:21, 14 May 2007 (BST): The capitalisation of this is different to all of our other elements. I'd suggest renaming to cb:institutionAbbrev for consistency?
Christine Sommo-FRBNY 20:01, 14 May 2007 (BST) Yes. You're correct. I think I had just done the unit_mult attribute and had that in mind. I will update all pages.
Christine Sommo-FRBNY 23:27, 11 May 2007 (BST) Can dc:creator be used instead?
Steven Bagshaw-BIS 08:29, 14 May 2007 (BST): Right now for dc:creator we say "This contains the abbreviation that signifies the identity of the institution. It contains no blanks." Which seems to contradict cb:institution_abbrev...
One thing about cb:byline is that it contain multiple authors. dc:creator is meant to be used one element per individual (like our cb:person).
Christine Sommo-FRBNY 22:26, 14 May 2007 (BST) They do contradict each other right now. The text you cite describes how cb:institutionAbbrev should be used. I'm not sure how we should use dc:creator, if at all.
Steven Bagshaw-BIS 17:42, 15 May 2007 (BST): Sounds like we should get rid of it for now then?
San 18:26, 15 May 2007 (BST)I vote for dropping the byline and the use of dc: format.
Steven Bagshaw-BIS 18:40, 15 May 2007 (BST): I vote strongly against dropping the byline - we need it! (I was talking about dropping dc:creator just above). I'm happy either way with dc:format, so vote to drop it for simplicity's sake.
San 19:25, 15 May 2007 (BST)Okay so apparently I'm confused: why do we need byline? Is this to cover the representation of authors for working papers or is there some other use?
-Steven Bagshaw-BIS 20:54, 16 May 2007 (BST): Yes. It is the authors in the preferred order, with titles, notes, commas whatever. e.g. Prof. James R. Squiggle, Marie Boulainvilliers and D.J. Jazzo. The authors themselves would be listed individually as cb:person elements, but the byline makes it easier for aggregators to recreate the desired full authorship line.
Christine Sommo-FRBNY 13:04, 16 May 2007 (BST) Agreed we should abandon dc:format. If dc:creator only allows for one creator then I think we still need cb:byline.
Christine Sommo-FRBNY 21:19, 16 May 2007 (BST) Steve - What about non-aggreagtors, that is plain old readers like Google Reader? Do you know if there is an element (assuming by now that dc:creator is out of the running) that will list more than one author as the "creator" of an item?
-Steven Bagshaw-BIS 21:39, 16 May 2007 (BST): Ugh. Guess what? Looks like Google Reader and others use dc:creator to show an author for a feed item. But you still do one creator per author, not all in the one - so, not a replacement for byline.
I think this falls into the generic RSS stuff that we don't mention at all in the wiki. That is - it's Dublin Core and it's optional, therefore up to the organisation.
At any rate, I'm not sure if central banks/BIS would use it at all anyway - even for a research paper, it's not as if the authors of the paper are the authors of the feed item. I think dc:creator in this context only makes sense for blogs and opinion stuff, rather than abstracts or data like we're doing... ???
- Paul Asman-FRBNY 16:46, 17 May 2007 (BST) I checked out this reference, and found it confused. I can see where you think that it recommends using dc:creator for the creators of the item - the guide says that the element should be used for the person who wrote an item, and item is said to be something that represents content, rather than the content itself. But the reference does not in fact use 'item' this way. Here's the recommendation for category as an element of item: "An item's category element identifies a category or tag to which the item belongs." If item is taken as the item, then the category is RSS feed. But this is the example: <category>movies</category>. Whatever an RSS item is, it is not a movie. The general use of 'item' in the reference seems to be the content to which an <item> refers, not to the item itself.
Christine Sommo-FRBNY 02:55, 17 May 2007 (BST) Mmm...not sure I follow your reasoning. The New York Times uses dc:creator to represent the author of the content the item refers to, that is the author of a news article. Isn't this the same way central banks would use it for research papers? I do see your point about capturing the different ways an author might be referred (D.J. Jazzo, etc.). Are you saying that cb:byline is necessary for aggregators and what anyone chooses to do with the dc elements which then wouldn't be required is therefore up to them and outside the realm of this wiki? I'm not sure I'm making sense right now - kind of tired myself. I'll think about this more tomorrow.
Christine Sommo-FRBNY 16:12, 17 May 2007 (BST) Okay, I officially suggest we need both cb:byline which is useful for aggreagtors and dc:creator which is useful for standard readers (Google Reader).
Steven Bagshaw-BIS 17:02, 17 May 2007 (BST): OK by me, but dc:creator is optional and it's Dublin Core, which by our convention means it is not covered in the wiki. Because for us, our authors are properly described in cb:person elements. And the full author list (which could included "edited by", "with a foreword by" or whatever else) in cb:byline. That's my 2 euro cents...
Point taken on item authorship - we could most probably use dc:creator here too for research papers if it looks OK in the aggregators. (I am just used to seeing full blog rants with authors, not brief abstracts).
Perhaps there should be a page with notes on selected, optional DC elements such as this one, so that this question is clearly answered if/when it comes up again?
Christine Sommo-FRBNY 17:45, 17 May 2007 (BST) 2 euro cents must be worth more than 2 U.S. cents. Anyway, I think we are in agreement. The dc:creator stuff is optional, but useful. So, although our conventions don't demand that we cover it I think we should provide some guidance on why/how it may be useful given how it is used in practice. This is what I was unable to articulate last night.
So, the question is are we creating a new page for guidance on dc elements or making an exception in this one case?
Steve - as the "official" I leave that to you.
San 14:31, 11 May 2007 (BST)I don't see mention of dc:format anywhere in the user guide yet it appears in the sample feeds for data. Are we not mentioning it because it's a DC element or is it an oversight?
Steven Bagshaw-BIS 15:10, 11 May 2007 (BST): I think the rule is if it is not required and in the DC namespace, then we don't mention it unless it has some special usage within RSS-CB. That said, I see it in the stats page and that would I think mean it needs to be in the user guide too.
Do we need it though? I guess I could imagine using it as an aggregator to put nice icons next to links - to distinguish PDF from HTML etc.
Seems though we are adding lots of things lately (and not taking any away). Overkill? And not all are essentials... (playing devil's advocate....)
San 18:23, 11 May 2007 (BST)I had some notion that it was important for something. I'd rather leave it out entirely and keep the feed as short as possible. Even if it's listed as optional, what purpose would it serve - anything besides pretty icons?
Christine Sommo-FRBNY 22:21, 11 May 2007 (BST) Those are our (NY Fed) sample feeds with the dc:format. I honestly don't remember why we put that in. I'll have to check with Allen and Paul.
cb:role in cb:person
Steven Bagshaw-BIS 07:48, 5 March 2007 (AST): I noticed a gap in the spec, which caused validation errors when running our speeches feed through the schema on the technical tools page. We haven't listed if cb:role itself is required or recommended within cb:person.
What do people think? I'd like to require it, but perhaps people are having difficulties implementing it. (The BIS needs to make some code changes to put the role in actually).
FYI, at the moment the schema does require it, but the specs do not mention it either way. Please comment if you have a viewpoint and I'll fix itup.
Christine Sommo-FRBNY 13:44, 8 March 2007 (AST) What the hell. I haven't commented in a while. Are you asking about cb:role in terms of job title, body or both? I can see how the body might be a required element, but not so much the job title for jobs below very senior management.
Steven Bagshaw-BIS 04:32, 9 March 2007 (AST): Previously, title was required and body optional. That could always change I suppose.
But I was asking whether the role element itself should be required. Nobody had responded at first, so I've made it optional for now. This means you can add a cb:person element without the cb:role element at all (although it is recommended to have one). I guess it's still open whether this is OK.
Christine Sommo-FRBNY 15:17, 9 March 2007 (AST) Optional seems about right to me.
Dan Chall-FRBNY 19:46, 17 April 2007 (ADT) I found a question in the body of the page about the type attribute of cb:person: such questions belong in the talk page, do they not? Rather than creating a new section, I just moved it here. [Do we allow other values ad-hoc??]
cb:occurrenceDate and cb:simpleTitle
Paul Asman-FRBNY 10:23, 22 February 2007 (AST) The user guide had these as required, which would apply even when it adds nothing (as in the RSS feed for FX rates). The specification had them as recommended for certain applications. I changed the user guide to reflect the specificatin.
Steven Bagshaw-BIS 06:12, 22 December 2006 (AST): I recall some discussion in Basel in December about this, but missed the conclusion. Is it a recommended field for items such as speeches and so on? Could someone add a link to the proper set of (ISO??) codes for the languages that we would use. Thanks!
- Elena Atayeva-FRBNY 09:22, 22 December 2006 (AST) I don't remember if there was a different conclusion but there is some discussion of this here:
We recommend that xml:lang be used with any element with free text as a child, most notably title and description. Appropriate sections in the user guide will reflect this recommendation. We do not recommend it for any element that takes a formatted value (e.g. date) or a value from a controlled vocabulary. In those cases, there is no language choice. Unlike xml:lang, dc:language reports on the underlying resource. Ian Forrester uses it as an element of <item>, and we will require its use in the description of a monolingual resource. It is less useful describing a resource that uses more than one language, although the element can have more than one instance. For such resources, it is optional. It is also optional for channel and the items element of channel. If the underlying resources that a channel (or an items child of channel) collects are in one language, it can do no harm.
Brent had this at the end of the Introduction, which I've removed to here: [We should have some stuff about the different roles we see RSS-CB serving... as ordinary end-user RSS format; for consumption by aggregators and other machine processes; for daily statistics; etc...] Brent also agreed to have a go at this.
Brent also noted the lack of a reference to statistical data. I suggest that initially this should be covered in the introduction.
Brent Eades-Bank of Canada 11:07, 8 July 2006 (ADT): I've taken a first, quick pass at expanding the Introduction. Feel free to slice and dice it without mercy.
As an aside, you'll note I use the term 'aggregator' to describe a machine process that pulls in RSS feeds to some sort of database or whatever. However, I note that the term 'aggregator' also seems to be used, in some circles, to denote what we would simply call 'an RSS reader'. Any thoughts on terminology here?
Paul Asman-FRBNY 12:27, 10 July 2006 (ADT) I found the discussion of the link element (of channel) confusing. I couldn't figure out what was recommended in the case that an RSS feed was available directly from a home page or departmental page, but also available from a special RSS page (such as the New York Fed has). So I gave one solution priority, and made the other an 'otherwise'. The recommendation is now, I think, unambiguous, but it may be wrong - that is, I may have reversed priority and otherwise. Please take a look.
Paul Asman-FRBNY 11:43, 10 July 2006 (ADT) I want to challenge one of the best practices under the channel title, or at least raise an issue. The recommendation had this: "If the institution's name does not denote its country, insert an ISO 3166 Country Code." You'll note that the examples do not follow this practice. 'New York Fed' does not denote the U.S. But I think it sufficient, so I changed 'denote' to 'indicate'. New York indicates the U.S.
The WHY section
Paul Asman-FRBNY 10:49, 7 July 2006 (ADT) I sent an email questioning the including of the WHY section that was present for some of the elements.
Brent replied that he put it in. Here's the excerpt: I used the "WHY:" device. I borrowed the approach from a web style guide I created for the Bank of Canada a couple of years ago. The idea was to make it easier for readers to scan the document and quickly identify 'key' ideas and principles (on the entirely valid assumption that many people would not read every word.)
This proved a useful approach with the style guide, although when I thought to use it in the RSS-CB User Guide, I did have some hesitation -- I'm not sure that it's feasible to provide a "WHY:" for every element and attribute in the Guide.
So: I'm not, as they say, wedded to the idea. On the other hand, I would like to see the Guide formatted in such a way that users can scan for the important bits, without being obliged to read every word.
Then Timo weighed in: I vote for the use of "WHY:", no doubt about it. I think of our RSS effort as (among other things) an educational exercise for institutions that have not thought about RSS feeds yet. Learning how to set up RSS feeds, I think, is much easier if the rationale for all non-trivial steps is provided. Doing this with an explicit "WHY:" indicator structures the document nicely and also underlines the fact that our group has done its work thoroughly.
And then Butch: I agree. I also recall from our meeting in Ottawa that we made a point to include reasons for various choices we made in the minutes that I believe could be entered as appropriate in the WHY area.
My argument to the contrary is that I don't think that the why is one of the important (Brent's term) elements, in that it doesn't tell someone what to do. And in all caps, it looks more important than Best Practice. On the other hand, I can see that I'm in the minority here, so I won't change it. Should someone in the majority wish to change it to Why (from WHY), though, I wouldn't object.
Dan Chall-FRBNY 11:07, 7 July 2006 (EDT) It seems to me that identifying the WHY section is useful for the very reason of indicating that the text does NOT imply any actions. It might be useful to start the section on a new line to highlight the actionable part above. It could be indented to indicate a different significance from the main entry. I have no objection to "Why:" over "WHY:" if shown in bold.
Timo Laurmaa-BIS 13:55, 7 July 2006 (ADT) As a reaction to the above, all "WHY:"s now say "Why:"
Christine: I changed the title of the Speeches example from FRBNY Speech:XXXXX to FRBNY (author's name):XXXX. I think this is more useful.
Paul: I changed 'not recommended' to 'discouraged'. 'Not recommended' is compatible with neutrality; 'discouraged' is not.
San 15:46, 26 June 2006 (ADT): Looking through the user's guide (should we have the 's?), I noticed two things: a sporadic indication of whether an element is required and the use of the redundant sounding: Requirement: Required. In Suzanne's notes, she uses the phrase "Obligation" then the phrases, "Required", "Optional", etc. which I prefer.
This raises two questions (in addition to the apostrophe question):
Which phrase should we use?
Shouldn't we make certain that it is indicated for all elements?
Brent Eades-Bank of Canada 15:21, 27 June 2006 (ADT): 'Requirement' I took directly from the RSS 1.0 spec. Strictly speaking I find it a more precise word in the current context than 'obligation', but I don't have strong feelings either way.
As for sporadic appearances of Requirements/Obligations: all are welcome to edit apparent omissions and inconsistencies of this sort.
I would be inclined to leave "User guide" as is. "User's guide" is incorrect, as it literally asserts "this is the guide for some specific user". "Users' guide" is more accurate, but looks a little poncy IMO.
San 18:33, 27 June 2006 (UTC) Okay - I don't have any strong feelings on obligation/requirement either but I wanted to see if anyone did before I started adding more info to the various pieces (which is next on my "To do" list).
Prefacing your posts with four tildes ~~~~ will prepend both your name and the date.
If I remember correctly (I vividly remember arguing against this, so it must be right!), we decided to require a non-empty description element. I made the change to the user guide. Should this be reflected in the specification document, as well?
Elena Atayeva-FRBNY 15:43, 27 June 2006 (ADT)
Brent 10:56, 28 June 2006 (ADT): Yes, I think it should.
Brent 10:52, 28 June 2006 (ADT): I revised this section, and upon doing so realized that I perhaps did not entirely understand what our intentions are regarding the "landing page" approach. Feel free to edit mercilessly, if you think I'm missing the point.
Draft Type Categories for central banks
Suzanne LeBlanc-Bank of Canada 13:08, 4 July 2006 (ADT) Here is my draft list. Comments, suggestions, are welcome.
How it came about -
- I looked at various central bank sites and found RSS feeds at the Fed Atlanta, Richmond and Chicago (as well as Fed NY).
- If people would like, I can post a query on the Central Bank Librarians' listserv (60 central banks subscribed) to see who is using RSS. Please let me know. Paul Asman-FRBNY 16:00, 5 July 2006 (ADT) It can't hurt. Can you ask not only who is using but who plans to use, and following what standards? [[Suzanne LeBlanc-Bank of Canada 12:25, 6 July 2006 (ADT) Request posted to listserv July 6 2006. I will compile the responses
- It was also interesting to see how some of the central banks used type under advanced search, eg. Banque de France.
- I also looked at the DCMI Type Vocabulary (http://dublincore.org/documents/dcmi-type-vocabulary/) and the Government of Canada Type Scheme (http://www.tbs-sct.gc.ca/im-gi/mwg-gtm/typ-typ/docs/2003/schem/schem_e.asp).
- I wasn't sure whether the list was going to reside in the User guide or be placed in the actual specification. Paul Asman-FRBNY 16:00, 5 July 2006 (ADT) Presumably the list will be a controlled vocabulary for some Dublin Core element. Right now, in the specification, we don't list any particular Dublin Core elements as recommended; we simply say to use DC for extensions. If the list went into the specification, we'd have to change that, so that particular DC elements were recommended. We may want to do that; I'm not taking sides. Even if we did that, though, we might not want to mandate use of a particular controlled vocabulary. On this I am taking sides - it seems that the vocabulary is something we'd want to promote, but not to mandate, so I'd put it in the user guide. It strikes me as a way to use the spec, but not part of it.
- I wasn't sure if we wanted broad categories for the most part. Can the specific items under Rates stand on their own?
- I debated over some of the names for type, eg. Regulations. Suggestions?
Type Categories for Central Banks
- Careers : job posters, recruitment, employment opportunities
- Circular letters
- Economic indicators : CPI, etc.
- News : current news and headlines
- Press releases
- Rates : exchange rates, interest rates, etc.
- Regulations : regulations as well as changes to central bank legislation
- Research : publications and other research
- Statistics : note issues and coin mintings, etc.
Christine Sommo-FRBNY 12:26, 19 July 2006 (ADT) Would publications that are not research (ex. educational pubs) have a separate category? Would time series that are not rates (ex. open market operations) be part of the Statistics category?
San Cannon-FRB 10:31, 24 July 2006 (ADT) Isn't there an implication with the System for what Statistics means? We have a "Statistics" function liaison for Wedge so I think it has a particular definition - banking statistics and the like. I don't know what the meaning is for other institutions. So we have *lots* of data that are not rates and not statistics in the banking sense (Flow of Funds and Industrial Production to mention some high profile ones) - how do they fit in?
Is "rates" really the right "data" category for this? Rates are a subset of what we produce even if they are what central banks publish in common. Also, are we considering the information for which we are the primary source only or will we want to capture all the information that we publish on the public website? I know Banco de Mexico publishes their IP numbers on their site even though they are not the source.
Suzanne LeBlanc-Bank of Canada 14:06, 24 July 2006 (ADT)What about "Data and Statistics" or "Other Data and Statistics". Would this work for now until we see whether a separate category is needed for "Data"?
Paul Asman-FRBNY 16:40, 24 July 2006 (ADT) The most forward-looking aspect to our work is representing data through RSS. That's how we've talked about it. Why not, for now, have a category that is simply 'data'? This would cover rates and other statistics as such. (Announcements that the data are available, should one of us wish to summarize them with RSS, would be something else.) Then, when we tackle data later in the year, we can subdivide as seems useful.
Brent Eades-Bank of Canada 10:26, 25 July 2006 (ADT): We may also want to look at the SDMX Content-Oriented Guidelines, currently in draft stage as part of SDMX 2.0. These introduce the notion of the "statistical domain"; which encompasses:
"...a statistical activity that describes a certain sphere of societal phenomena and has common characteristics with respect to concepts and methodologies for data collection, manipulation and transformation. Examples of statistical domains are price statistics, national accounts, environment statistics and education statistics."
A much-elided version of the the list of proposed categories follows:
Domain 1: Demographic and social statistics (...) 1.5 Income and consumption Domain 2: Economic statistics 2.1 Macroeconomic statistics 2.2 Economic accounts 2.3 Business statistics 2.4 Sectoral statistics (...) 2.4.6 Banking, insurance, financial statistics 2.5 Government finance, fiscal and public sector statistics 2.6 International trade and balance of payments 2.7 Prices 2.8 Labour cost Domain 3: Environment and multi-domain statistics 3.1 Environment 3.2 Regional and small area statistics 3.3 Multi-domain statistics and indicators (...)
San Cannon-FRB 10:57, 26 July 2006 (ADT) This list is a good starting point but since it was developed to cover a much broader set of topics than those for which central banks are likely to produce data, I don't think that it really gets to where we need to be. If we are talking about the broader types of information for which we'll be using RSS, then I would think that "Statistics and Data" or something to that effect would be sufficient. If we want to further classify what types of statistics and data, we should look at refining the parts of this list that are applicable to central bank data: I suspect that most of us produce data under 2.4.6 but not 3.1.
I still have two questions:
1. Can someone please remind me precisely where this "type" information will be used?
2. Paul points out that announcements about data would go somewhere else - which is fine - but begs the question of "Where?" The first RSS feeds we'll be putting on the Board's site will be related to changes in data in our Data Download application. Suggesions on where these would go?
Brent Eades-Bank of Canada 08:48, 28 July 2006 (ADT): San: Yes, I agree that few of the SDMX "statistical domain categories" are pertinent to the kinds of data we publish on our sites. But as you say, it may (or may not) be useful as a starting point.
As for where this "type" information would go in an RSS-CB document -- I don't know if we ever discussed that in any detail. I had originally thought this would be part of a custom namespace specific to RSS-CB. However, I now think that the Dublin Core
subject element might do the job just as well. Its purpose is to identify:
... keywords, key phrases or classification codes that describe a topic of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.
Dublin Core also has the
type element, which identifies:
... terms describing general categories, functions, genres, or aggregation levels for content. Recommended best practice is to select a value from a controlled vocabulary (for example, the DCMI Type Vocabulary.)
Note that you can declare more than one
type, and they can be from both the DCMI Type Vocabulary and your own vocabularies. The Dublin Core site provides the following example:
dc:type = "Text" (DCMI Type Vocabulary)
dc:type = "Press Release" (custom vocabulary)
... which would seem a pretty good fit for our purposes. As an aside, I'm a little foggy as to how one declares that a given controlled vocabulary is being employed; I think the form is something like this:
Back to statistical data... as it happens, the DCMI Type Vocabulary has a
Dataset attribute, in addition to
Text as noted above. (It also has the perplexing
Event attribute that we discovered in the Ottawa meeting.)
So I suppose that could lead us to something like:
<dc:type>Dataset</dc:type> <dc:subject rdf:datatype="http://sdmx/category/vocabulary/">2.7 Prices</dc:subject>
(Stressing again that I'm unsure about that "rdf:datatype=" bit.)
Addendum: Or we could dispense with the SDMX categories and devise our own taxonomy. As we discussed in Ottawa, the types of statistical data that we are likely to publish in RSS-CB will be fairly few, presumably -- FX rates, interest rates, a few others. In that context, it wouldn't be too difficult to create a simple taxonomy that covered everything. And I suppose it would be more useful to describe a given piece of data as simply being an "exchange rate", rather than an instance of "2.4.6 Banking, insurance, financial statistics".
Dan Chall-FRBNY 14:46, 2 August 2006 (ADT)"Publications and other Research" are two categories, right? There can be other kinds of categorizations, such as by audience or type of publication (current analysis, academic research, bedtime reading, etc.) There are a variety of dimensions of categories: subject matter, information type, etc. In fact, I think "category" is a very unhelpful label, and "type" doesn't add very much. Regulations/news/press releases/statistics are categories of what? How do we identify the dimension they span? Then the SDMX categories are really subject matter categories or something like that. It's an entirely different dimension from the first set.
Paul Asman-FRBNY 15:35, 2 August 2006 (ADT) Some of the "other kinds of categorization" are handled by other Dublin Core elements, such as - to stick with Dan's example - audience. Type is also part of the Dublin Core. The main DC element for our categorizations, though, is subject. Subject can take its value from a controlled vocabulary, and there can be more than one instance of the subject element.
There's no requirement that we have a common controlled vocabulary to represent (an aspect of) subject, although I think it would be nice. Even if we did, we would not be required to limit ourselves to that vocabulary, even if it overlapped one of our own. To cut, paste, and edit from an earlier example, one of us could find it useful to have something like this:
<dc:subject rdf:datatype="http://sdmx/category/vocabulary/">2.7 Prices</dc:subject> <dc:subject rdf:datatype="http://custom/category/vocabulary/">Prices</dc:subject>
Dan Chall-FRBNY 12:48, 3 August 2006 (ADT)Subject would be a better term, then, than category. Category means different things to different people. Or have I misunderstood, and we're talking about "type" and "subject" and never about something explicity called "category"? I think "type" might benefit from some kind of qualifier too. "What type of content is this?" might not automatically lead someone to expect the type categories listed above, but perhaps some other label might be more helpful.
Suzanne LeBlanc-Bank of Canada 13:54, 4 August 2006 (ADT)When I think of type, I ask myself the question "What is it?" and I answer speech, press release, publication, statistic, etc. We are then going further with type by indicating what kind of information is included under a specific "type", eg. exchange rates might be included under "rates" or "statistics" depending on what is decided. When I think of subject, I ask myself what it is "about" so yes, there is a blur between subject and "specific type" in some cases (like foreign exchange rates), but not all (I wouldn't think to have a subject for "research publication", it is a type) As a future initiative, I certainly think it is an excellent idea to develop some kind of subject taxonomy for central banks (recommend a group initiative)and this might be something to bring up with the central bank community.
Attributes and Language and writing on the issues behind the guidelines
Dan 13:24, 7 July 2006 (EDT): I took language about the language attribute from Paul's "language" section and imported it to a new section on general guidelines. I also took the words about the dc language element and inserted it into the dc section. I have not changed Paul's "essay" but I think more of it could be incorporated into these two sections. Would part of the essay belong here on the discussion page?
Paul Asman-FRBNY 15:37, 7 July 2006 (ADT) Maybe it belongs here. Given Dan's changes, it no longer belongs in the document itself. So here it is:
In a BBC World Service article, Ian Forrester recommends using both the Dublin Core language element and the xml:lang[uage] attribute: "Consideration was given to using only an XML:lang attribute or only the dc:language element to indicate the language of content, but putting both, while redundant, allows the feeds to work well with more RSS readers." Forrester is correct that both should be used
However, they are not redundant, and the way in which they differ informs how they should be used. Even if they were redundant, though, Forrester would still be correct. As he implies, different readers have (and will have) different strengths and abilities, and RSS providers should provide them all the help they can. There is no practical expense to using both, while there is a cost in failing to provide what a reader can use.
The xml specification permits xml:lang as an attribute of any element. As an attribute of an element, it states the language of the text child of that element. For example, in <title xml:lang="en">the title</title>, xml:lang indicates that "the title" is English-language text. The attribute makes no claim about the language of the title of any underlying resource. The Bank of Canada, for example, may have a French language feed that includes links to research articles available only in English. In the RSS feed, the item could have a French title while the underlying resource does not.
In contrast, the dc:language element indicates "the language of the intellectual content of the resource". This is the underlying resource, the same object referred to by creator and the Dublin Core terms. Given the use of xml:lang and dc:element, then, this is plausible: <item rdf:about="..."> <title xml:lang="fr">le titre</title> <dc:language>en</dc:language> …
Both the XML and DC specifications call for values to be taken from ISO 3066. We accept this for our use of RSS.
We recommend that xml:lang be used with any element with free text as a child, most notably title and description. Appropriate sections in the user guide will reflect this recommendation. We do not recommend it for any element that takes a formatted value (e.g. date) or a value from a controlled vocabulary. In those cases, there is no language choice.
Unlike xml:lang, dc:language reports on the underlying resource. Ian Forrester uses it as an element of <item>, and we will require its use in the description of a monolingual resource. It is less useful describing a resource that uses more than one language, although the element can have more than one instance. For such resources, it is optional. It is also optional for channel and the items element of channel. If the underlying resources that a channel (or an items child of channel) collects are in one language, it can do no harm.
San 12:46, 17 July 2006 (ADT) Looking at the other (U.S.) government sites with RSS feeds, I can't find any lanugage AT ALL about licensing, wordmarking or anything else. It's not that these sites have something less complete than the BBC legal lingo, they have NOTHING about it. The Board cannot copyright anything so I wonder what limitations that might have on the licensing issue. So I wonder.... at what stage do we need the legal types to weigh in on this or can it be avoided since we are just making general suggestions?
Christine Sommo-FRBNY 10:13, 19 July 2006 (ADT) My thoughts are that we don't need legal types for this document, but we may want it for our actual feeds. We allow reproduction of anything on our website without "limitation as to number provided that it is not for the purpose of private gain." The private gain part may be an issue with some syndication. Oh, damn. I may have just changed my mind. A user guide might be a good place to offer guidance on legal issues! We do have a lawyer that we talk to regularly about confusion we have with website stuff, so he has a good understanding of the issues. If no one objects by Monday (Jul 24), I'll share this website with him and ask for his thoughts. Maybe we should also look at the source code of some for profit feeds?
Brent Eades-Bank of Canada 13:35, 24 July 2006 (ADT): I see the development of licensing terms as basic butt-covering, essentially. It doesn't necessarily imply the assertion of copyright -- in fact, I suppose one could argue that publishing content in RSS explictly disavows copyright, in that RSS is intended for the syndication of one's content. (You can't on the one hand say, "Here, take our news items and republish them", while on the other say, "But don't violate our copyright.")
So the licensing terms are meant only to protect us from the most egregious misuses of our content, e.g.: republishing it without giving attribution to our institutions; republishing it in contexts that might prove embarassing to us; and so on. Having licensing terms gives us something to fall back on when we see our content being used in ways we don't like.
Otherwise, those who misuse our stuff could quite rightly say, "So? Show me where it says I can't do that with your feed??"
Elena Atayeva-FRBNY 16:08, 27 December 2006 (AST) Are the granular cb:person fields such as givenName and surname required or recommended? I lean towards making them recommended, so that if granular information is not available, the feed creators can fall back on nameAsWritten.
Steven Bagshaw-BIS 03:34, 28 December 2006 (AST): Makes sense to me. In fact, I think I noted somewhere that you could use nameAsWritten to have an institution name (which would leave those other two fields as not relevant). The fact that there may be institutional (or departmental?) authors was mentioned in Basel in December. It would be nice for aggregators to get the granular names, but I can imagine that would prove challenging to provide for some parties.
I've modified the User guide to correspond to this. If anyone would like to change these guidelines, please update the User Guide.
Elena Atayeva-FRBNY 12:43, 6 April 2007 (ADT) From user guide:
"This field cannot contain more than one keyword/phrase. List each keyword as an individual item".
From the specification:
"<cb:keyword>financial stability, conferences</cb:keyword>"
Normally, I would think that the specification has the ultimate authority, but in this case, the user guide seems to be right.
Does anybody remember what we agreed on?
Paul Asman-FRBNY 14:38, 6 April 2007 (ADT) I changed the spec to have only the phrase financial stability.
Steven Bagshaw-BIS 04:14, 10 April 2007 (ADT): I seem to remember it being agreed that there would be one keyword per element. I think I probably updated the user guide to reflect that, but not the example in the spec. So I think it's all in order now.