Talk:Research papers 1.1

Jump to: navigation, search

Links to more than one version

Christine Sommo-FRBNY 19:49, 25 July 2008 (BST) Yes. <cb:resource> is what I think you should use. We use it often in our news feed for linking to PDFs (and other stuff as well). I'd be happy to work on this with you.

San 16:38, 25 July 2008 (BST) Our application guide doesn't give much guidance on how to handle a link to a PDF of a paper if you don't want that to be what the feed link is. For example, we do *not* want the feed link to go directly to the PDF; rather, we want folks to go to the abstract page from where there is a link to different versions of the paper (PDF, Screen reader, etc.)

But, this doesn't play nicely with our stated purpose of helping the aggregators: Timo still has to mine the abstract page to pull out the PDF info.

So we should address this. I suspect that this is where we'd use a <cb:resource> element but does anyone want to help me put together suggestions on how these should be structured?

Dan Chall-FRBNY 17:07, 25 July 2008 (BST) I do. You nailed the problem. I agree, for us, we do not want the feed (or search engines, or any general navigation) to send the user to the PDF. For our site, the only way to the PDF should be from the abstract page. So the first question might be: should the RSS-CB standard support the desire of the "anonymous CB aggegator" (Timo didn't want to be named, as I recall) to send users directly to the PDF? One might suggest that your site and mine might prefer if Timo didn't link to PDFs, to keep the visitors within our own navigation structure when they get here. Then again, I suppose it could always be voluntary, and some central banks might want to make it possible for users or aggregators to find either the abstract page or the PDF. In that case, I think you're right that cb:resource is the answer. See

On our site, we have some publications with two primary representations in addition to the abstract page: the PDF version of the Current Issues article, and the interactive HTML version. For instance, see: This would require two different cb:resouce tags. Each one would have a title, a link, and a description. Title might be the title of the article in each case (repeated from the feed entry's title), and Description might say "PDF version" or something like that.

San 18:47, 25 July 2008 (BST) Yeah Dan! We're on the same page again!

So it's the "something like that" that I'm interested in putting together guidance for. As a starting point, I've been toying with something as banal as the following:

  <cb:title>PDF version of "Monetary Policy in a Forward-Looking Input-Output Economy"</cb:title>
  <cb:description>Link to PDF file of FEDS 2008-33</cb:description>

I'm sure we could also do it for the screen reader version if we wanted to really have equal time but I don't know if other unnamed aggregators would be interested in the info.

Now we need to nail down the details - this is the fun part! Suggestions?

Dan Chall-FRBNY 19:07, 25 July 2008 (BST)Like Hannah Arendt on the banality of XML? Banal is good, here, I think. I'm not sure whether we need "PDF" identified in the title element, since that's conveyed in the description and "PDF" doesn't appear on the title page. And I'm not sure if we need "link to" in the description element, as the user interface should provide that information. I also think you might not want FEDS 2008-33 in the description, because you may be overloading it. That information should be stored elsewhere in the feed, and the key piece of info for this resource is "PDF," as I see it.

How about:

  <cb:title>Monetary Policy in a Forward-Looking Input-Output Economy</cb:title>
  <cb:description>PDF version</cb:description>

Additionally, in this context I think there might be interest in some new elements. On our site we always want to tell the filesize and the number of pages whenever there's a link to a PDF file. I don't see those two concepts identified as elements anywhere in the spec, at least in the context of cb:resource.