Supplementary Data links for Publishers

PANGAEA provides several REST-based services to link supplementary data at publisher's abstract pages:

Simple REST service for banner-based linking
The REST service for banner-based linking provides two functions.

All example URLs are suited only for an "example publisher". Other publishers will get their custom banner using their own one design requirements. Also for tracking purposes, the URLs below may never be used unmodified for other publishers! Other publishers will get the "/example-publisher/" part of the URL replaced by their name.

Linking Banner
REST service generates a GIF image with a banner image, if a data set is available. The encoding of the paper DOI name must be in the same format like dx.doi.org needs it. Any special characters should be urlencoded using the UTF-8 Character Set. For most DOIs consisting of only ASCII chars, no encoding is needed most times:

http://linkinghub.pangaea.de/example-publisher/supplementBanner/doi:10.1016/j.margeo.2006.07.006

If no data is available, the service returns a transparent one-pixel-gif image:

http://linkinghub.pangaea.de/example-publisher/supplementBanner/doi:10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML tag.

The second REST service is a resolver/redirector:
http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/doi:10.1016/j.margeo.2006.07.006

Encoding is the same, only the action is different. This link redirects the user to the supplementary dataset behind the paper DOI name. You may put this URL in a  around the image. If the image is empty (1 pixel, the user is normally not able to click on it, if he does, he will be directed to an information page on www.pangaea.de, describing that there is no supplement available). If it works you get a 301 redirect (because the linking hub url is not generally available and should not be indexed by search engines, search engines should use the DOI-link of PANGAEA, this is why it is a permanent redirect).

General Usage
In complete you can insert the following HTML into your artcle abstract webpage (replacing the DOI name to the encoded current article’s DOI name):

  

In real life the link looks like this: "  ", if no supplement available: "  " (you should see nothing)

Harvesting approach (to be discussed)
A straightforward approach could be offered through harvesting our metadata on a regular base (once a day or so via OAI-PMH or more simple through a REST based service delivering the list of available supplementary data sets for specific publisher). This would let the publisher know in advance which articles do have supplementary data. This approach would also satisfy any general interest in PANGAEA's metadata, in particular with respect to articles related to data sets.

Separate "tab" on publisher's web page (to be discussed / not yet operable)
A naive approach would be to add some server-executed code to publisher's backend page generator that prints out the abstract page (JSP/Servlet, PHP, ASP,...). This code on publisher's side calls a REST-based webservice on PANGAEA's side that requests the availability of data. Input parameter would be the DOI of the publication. Based on that, an additional tab/button/link whatever is printed out. When the user clicks on the tab/button/link, our content could be embedded on a newly generated page(e.g. based on a 100% iframe inside the publisher's website).

The main problem with this approach is the very close linkage between PANGAEA's and publisher's services, as the code runs on publisher's server and depends on the request to PANGAEA's webservice. In case of failures, network problems etc. page generation on your side would be halted or delayed. Although PANGAEA has a high availability (>99.9%) this would cause problems on your side. This is not acceptable. The main problem is simply the dynamic display of the tab.

A further solution is client-based: The idea is to always add the tab/buttin/link to publisher's page output. There is no need to call any services on the server-side page generation, so publisher won't depend on PANGAEA's servers. The trick is: The tab/button/link is initially hidden by CSS. The Javascript part of the publisher's web page does the request to the REST-based service. Because of same-origin browser limitations, the trick goes back to the same simple initial approach as the banner linking above: The page contains a "banner image", which is 1 pixel, if we have no data, and has some size if supplementary data are available. This banner is also the fallback, if the client's computer has no javascript enabled. So it should be placed as a fallback at any place where it fits (e.g. behind the article abstract). The banner appears exactly as described above. It's an image - simply the fallback, the link behind goes to a redirect service at PANGAEA that links to the data set (users without javascript simply see this banner-like link). If the image has only 1 pixel of size it is not visible nor easily clickable by users. The URL to this image/redirect service contains the DOI of the publication. The trick for the TAB is to use the image itself as indicator of availability. Javascript on the publisher's page would simply register for onload-event of the image and on successful load check the image size. If its > 1px, it shows the hidden tab/button/link using JavaScript/CSS. As this all runs on the client's computer, there will be no delays generating the web pages.

The separate page behind the new tab/button/image on publisher's site The URL of the iframe would contain our service parameterized by the publication DOI. The URL to the TAB is always available (in case a robot would follow the hidden link behind the TAB). The iframe would only contain an error message from our servers. For your servers there is no difference between availability of supplementary data or not. The new page could contain the Google Map as described below:

Google-Maps-based javascript / iframe approach (to be discussed / not yet operable)
With / or without a separate page on the publisher's website, the same approach like above can be used to display an iframe with a Google Maps generated by PANGAEA's servers. Also here, the iframe would be generated by JavaScript, as soon as the banner-based image is larger than 1px.

An idea how this could look like can be seen on a (proprietary) implementation of Elsevier's ScienceDirect pages (see Elsevier-Partnership). Elsevier uses an own framework called "EMBED" that is used for this. The approach is much more complicated than described above, because it can be used also to embed other content.

An example can be seen here: - This page has the banner based approach next to the "View Record in Scopus" link somewhere on the bottom-right side and the EMBED top-right.

The PANGAEA-internal idea is to do the following (similar to “Google Adwords banners”). The trick is to use a “asynchronous” element created by a small Javascript on your page, that works similar to the above banner approach: It loads dynamically generated Javascript from linkinghub.pangaea.de (the link will include the DOI of the paper like witrh the banner image) and inserts (if dataset is available) an similar to Elseviers Gadget into the HTML page loading the async script. If the paper has no data on our side, the dynamic javascript is just “empty” and does not modify your web page at all. The size and other things will get modifiable by Javascript before inserting the remote. The usage of asynchronous script is to ensure (just like with the IMG-element) to not prevent loading your page completely when our servers will be down.