Talk:Research papers

From cbwiki.net

Discussion: Research Papers Application Guide

San Cannon-FRB 17:20, 29 November 2006 (AST) I've started to flesh out the arguments and issues for research specification in RSS feeds. Please feel free to contribute as you see fit. I'll add a full sample feed for the two listed examples tomorrow (I hope!)

Dan Chall-FRBNY 18:06, 29 November 2006 (AST)I have added some flesh to San's version, and have added some proposed fields of my own. One question that applies to all these tags is whether we need a language attribute for each of them (identifying the language used in the elements themselves).

San Cannon-FRB 10:15, 30 November 2006 (AST)Okay, now I get to question some of Dan's suggestions! I'll play Timo for a minute and ask at what point we are posing a burden on those who might use the extended tags. Are we going to specific things as 'required', 'recommended' and 'optional'? I'd argue that we should or else it appears that all fields are required and some less technically savvy, or less interested, central banks might decide to opt for no additional tags rather than implement all things like <cb:educationLevel>.

Dan Chall-FRBNY 12:42, 30 November 2006 (AST)(I have no problem in making them optional. For now, the only mandatory tags should be the ones that make Timo's job manageable.)

Dan Chall-FRBNY 16:14, 26 December 2006 (AST)(about the <abstract> field:) There might also be shorter less formal or unpublished summaries too, distinct from the published abstract. One of the remaining questions is whether these should use a different DC field. A formal abstract may be far longer than a reader might want to wade through to decide whether the topic is of interest, yet some readers might want to have access to the formal abstract.

I'm also interested in gathering opinions as to how much metadata is too much to include for a feed. There should be a distinction between metadata that is useful for cataloging and storage in an institution and metatdata that is useful for identification and discovery in a feed. Dan Chall-FRBNY 12:42, 30 November 2006 (AST)(I've written a couple of pages on that subject for discussion next week.)

While I understand the logic behind having such things as <dc:audience>, I don't know that it is really useful for dissemination purposes. Are even the most diligent of custom aggregator creators going to do anything with it?

Dan Chall-FRBNY 12:42, 30 November 2006 (AST)(As I edited into the document, FRBNY does try to target audiences, and it does highlight some papers for classroom use. These two fields might bring this kind of marketing into the RSS world.)

I'm going to edit the guide to indicate which fields I think are TMI.

Timo Laurmaa-BIS 11:36, 30 November 2006 (AST) Great work, some quick comments and questions:

• <item><title> Why no date in front of the title? In most central banks, research papers are published at most monthly, and eg Firefox live bookmark users cannot see what is recent.

Dan Chall-FRBNY 12:42, 30 November 2006 (AST)(I think all RSS items are presumed to be recent. Are not Firefox live bookmarks listed in the order provided by the feed? The concern is that real estate in the title field is especially scarce, and the date would steal space from the title of the article.)

• <item><description>I find the current proposal cryptic. Since this item has no severe lenght restrictions and is, apart from the title, maybe the only item that a human reader can see before clicking, I'd like to see maximum information, such as "Bank of Spain Working Papers no 0315 by Alicia García Herrero and Pedro del Río. This paper builds upon the existing empirical ETC ETC WITH COMPLETE ABSTRACT"

Dan Chall-FRBNY 12:42, 30 November 2006 (AST)(If there is no length restriction in practice, anything beyond the bibliographical citation could be optional.)

• <item><link> The current proposal sounds fine, as long as one link is provided. For the purposes of our Central Bank Research Hub, I greatly appreciate the availability of separate HTML abstract and PDF full paper links, maybe even different language versions. However, should these be located under some less conventional tag such as <item><cb:links> in order not to clutter the link tag?

Dan Chall-FRBNY 12:42, 30 November 2006 (AST)(I have no objection to using a separate link tag. If alternatively the link element could have text and additional links, might that serve the same purpose? Maybe it doesn't matter.)

• <item><dc:creator> I see some merit in providing redundant information, first "as printed" (Alicia García Herrero and Pedro del Río) and then in subtags one by one (last="García Herrero" first="Alicia", last="del Río" first="Pedro")

Dan Chall-FRBNY 12:42, 30 November 2006 (AST)(Seems reasonable to me.)

• <item><dc:date> The full PDF would typically say October 2006 even if the paper actually comes out on, say, 7 November. This date would therefore be October 2006, but I would like the item title to start with "07Nov/...". Modification dates are definitely required even though not in use at the BIS.

Dan Chall-FRBNY 12:42, 30 November 2006 (AST)(Two issues here: which dates do we document, and how do we document them. Calling attention to working papers that were revised a year later might be of value. We could document the dates with specific elements for the original and for the revision. The decision to put the date into the title tag would serve only the native Firefox users who have no access to other fields. The cost is lost bytes of title. A CB aggregator could obtain all the necessary fields from DC tags. How the CB aggregator provides its information is yet another on. (If the CB aggegator creates a secondary RSS feed, hiding the channel title information obtained from the original source, it thereby may need to compress that information into the title element, losing significant bytes of title. If the CB aggregator built a web-based HTML user interface, then all the information could be shared in creative ways. If the end-users could obtain the RSS feeds from primary sources, then they would have access to the channel title information. ))

Dan Chall-FRBNY 18:17, 15 December 2006 (AST)Somebody, please help with the "attached presentation." I tried to use the "Image:" tag as an upload, but there seemed to be confusion: when it linked to the html upload page, it was looking for PDF. So I turned it into a URL link to where the uploaded file is stored.

Dan Chall-FRBNY 01:33, 20 April 2007 (ADT)dc:language: moved question here: [QUESTION] Might we want to have an additional element indicating links to translations in other languages? These translations might have their own primary feeds or items, but it might be useful to link to translations.

-- Steven Bagshaw-BIS 04:33, 26 April 2007 (ADT): No, it wasn't inadvertent... I would prefer to have cb:occurrenceDate for all applications, so I would definitely like to leave it as recommended for research papers. There should be no ambiguity between it and dc:date - if there is, we haven't explained it well enough yet. Basically, the dc:date is when the item is added to the feed. The cb:occurrenceDate is the date of publication, speech, event etc... depending on the application. For a research paper, perhaps having a specific date and time is overkill, but we should still have it. The aggregator may wish to use it for some other reason, such as displaying papers in order of publication - but the dc:date only refers to its appearance in the feed. So I'm going to undo the change if that's OK...

--Dan Chall-FRBNY 11:47, 4 May 2007 (ADT)The date of a publication is somewhat different conceptually from the date of a speech. The latter is a real date that can be expressed in a uniform standard format. The former is a time-based identifier for a particular issue, and it varies by publisher and series. Non-standard examples are "spring 2006" and "July-August 2006." The actual date of publication is of secondary interest (if any) unless it matters to the particular application (say, a press release). FRBNY Staff Reports, for example, are assigned month and year. That's the date that appears on the title page.

--Steven Bagshaw-BIS 15:33, 8 May 2007 (BST): It's still of interest to aggregators as we can then list them in some kind of meaningful order, remembering that dc:date is the time at which the item appears in the aggregator's feed. So, it would still be good to have it in there. If, as a feed provider, you don't see a valid, separate value, perhaps just use the same as dc:date. Or a date that is otherwise useful... e.g. July - August 2006 - 2007-07-01... Spring 2006 - 2007-03-22 (or whatever depending on local practice and hemisphere). There is cb:publicationDate for this non-standard date, of course...