PANGAEA Wiki - User contributions [en]

Supplementary Data links for Publishers

2011-01-20T12:25:11Z

Uwe Schindler: use new URLs

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 <img/> 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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/doi:10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/doi:10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/doi:10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/doi:10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/doi:10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/doi:10.1016/somefakedoi" style="border:none" /></a></html>" (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: {{doi|10.1016/0377-8398(94)00015-F}} - 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.

Supplementary Data links for Publishers

2010-11-05T13:28:55Z

Uwe Schindler: /* Google-Maps-based javascript / iframe approach (to be discussed / not yet operable) */ change link to better example

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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: {{doi|10.1016/0377-8398(94)00015-F}} - 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.

Supplementary Data links for Publishers

2010-11-05T13:23:51Z

Uwe Schindler: /* Separate "tab" on publisher's web page (to be discussed / not yet operable) */ remove SD

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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: {{doi|10.1016/S0098-3004(01)00112-1}} - 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.

Supplementary Data links for Publishers

2010-11-05T13:22:46Z

Uwe Schindler: /* Google-Maps-based javascript / iframe approach (to be discussed / not yet operable) */

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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 (this is more similar to the approach used at ScienceDirect's PANGAEA map): 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: {{doi|10.1016/S0098-3004(01)00112-1}} - 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.

Supplementary Data links for Publishers

2010-11-05T13:22:11Z

Uwe Schindler: /* Google-Maps-based javascript / iframe approach (to be discussed / not yet operable) */ add link

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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 (this is more similar to the approach used at ScienceDirect's PANGAEA map): 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 then described above, because it can be used also to embed other content.

An example can be seen here: {{doi|10.1016/S0098-3004(01)00112-1}} - 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.

Supplementary Data links for Publishers

2010-11-05T13:20:30Z

Uwe Schindler: /* Google-Maps-based javascript / iframe approach (to be discussed / not yet operable) */

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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 (this is more similar to the approach used at ScienceDirect's PANGAEA map): 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. Elsevier uses an own framework called "EMBED" that is used for this. The approach is much more complicated then described above, because it can be used also to embed other content.

An example can be seen here: {{doi|10.1016/S0098-3004(01)00112-1}} - 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.

Supplementary Data links for Publishers

2010-11-05T13:19:44Z

Uwe Schindler: /* Google-Maps-based javascript / iframe approach (to be discussed / not yet operable) */

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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 (this is more similar to the approach used at ScienceDirect's PANGAEA map): 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. Elsevier uses an own framework called "EMBED" that is used for this. The approach is much more complicated then described above, because it can be used also to embed other content.

An example can be seen here: {{doi|10.1016/S0098-3004(01)00112-1}} - This page has the banner based approach next to the "View Record in Scopus" link somewhere on the bootom-right side and the EMBED top-right.

Supplementary Data links for Publishers

2010-11-05T13:18:53Z

Uwe Schindler: /* Google-Maps-based javascript / iframe approach (to be discussed / not yet operable) */

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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 (this is more similar to the approach used at ScienceDirect's PANGAEA map): 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. Elsevier uses an own framework called "EMBED" that is used for this. The approach is much more complicated then described above, because it can be used also to embed other content.

An example can be seen here: {{doi|10.1016/S0098-3004(01)00112-1}} - This page has the banner based approach next to the "View in scopus button" somewhere on the bootom-right side and the EMBED top-right.

Supplementary Data links for Publishers

2010-11-05T13:11:31Z

Uwe Schindler: /* Google-Maps-based javascript / iframe approach (to be discussed / not yet operable) */

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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 (this is more similar to the approach used at ScienceDirect's PANGAEA map): 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.

Supplementary Data links for Publishers

2010-11-05T13:08:29Z

Uwe Schindler: /* Google-Maps-based javascript / iframe approach (to be discussed / not yet operable) */

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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 (this is more similar to the approach used at ScienceDirect's PANGAEA map): 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 webpage 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.

Supplementary Data links for Publishers

2010-11-05T13:07:48Z

Uwe Schindler:

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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 (this is more similar to the approach used at ScienceDirect's PANGAEA map): 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 webpage 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.

Supplementary Data links for Publishers

2010-11-05T13:01:32Z

Uwe Schindler: /* Google-Maps-based javascript / iframe approach (to be discussed / not yet operable) */

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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 (this is more similar to the approach used at ScienceDirect's PANGAEA map): 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:

Supplementary Data links for Publishers

2010-11-05T12:58:43Z

Uwe Schindler: add new approach

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/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/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

=== The second REST service is a resolver/redirector: ===

http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/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 <a href=”…”> 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):

<pre>
<a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/example-publisher/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/example-publisher/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (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.

== Google-Maps-based '''javascript / iframe''' approach (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 (this is more similar to the approach used at ScienceDirect's PANGAEA map): 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.

All these approaches would result in a separate page behind the new tab/buttn/image on publisher's side (like the tabs for references etc.), but simply contains (as described above) a 100% iframe that displays all information generated by PANGAEA's servers.
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.

Publisher-Supplementary-Data

2010-11-05T11:49:13Z

Uwe Schindler: moved Publisher-Supplementary-Data to Supplementary Data links for Publishers

#REDIRECT [[Supplementary Data links for Publishers]]

Supplementary Data links for Publishers

2010-11-05T11:49:13Z

Uwe Schindler: moved Publisher-Supplementary-Data to Supplementary Data links for Publishers

Supplementary Data links for Publishers

2010-11-05T11:34:17Z

Uwe Schindler: /* Simple REST service for banner-based linking */

Supplementary Data links for Publishers

2010-11-05T11:32:31Z

Uwe Schindler: remove elsevier completely

Supplementary Data links for Publishers

2010-11-05T11:18:33Z

Uwe Schindler: /* Simple REST service for banner-based linking */

Supplementary Data links for Publishers

2010-11-05T11:16:59Z

Uwe Schindler:

Supplementary Data links for Publishers

2010-11-05T11:15:54Z

Uwe Schindler: remove sciencedirect

Supplementary Data links for Publishers

2010-11-05T10:56:08Z

Uwe Schindler: initial version

== REST service (first version) ==

The REST service for linking [[PANGAEA]] with Elsevier's [http://www.sciencedirect.com ScienceDirect] provides two functions:

== Linking Banner ==
One generates a GIF image with a [[PANGAEA]] Logo and some text, if a data set is available. The encoding of the DOI 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 normal Science-Direct-DOIs consisting of only ASCII chars, no encoding is needed most times (but I am not sure):

http://linkinghub.pangaea.de/elsevier/supplementBanner/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/elsevier/supplementBanner/10.1016/somefakedoi

This image can be included as SRC-Attribute for a HTML <img/> tag.

== The second REST service is a resolver/redirector: ==

http://linkinghub.pangaea.de/elsevier/redirectToSupplement/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 your Science Direct DOI name. You may put this URL in a <a href=”…”> 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 Science Direct webpage (replacing the DOI name to the encoded current article’s DOI name):

<pre>
<a href="http://linkinghub.pangaea.de/elsevier/redirectToSupplement/10.1016/j.margeo.2006.07.006">
<img src="http://linkinghub.pangaea.de/elsevier/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" />
</a>
</pre>

In real life the link looks like this:
"<html><a href="http://linkinghub.pangaea.de/elsevier/redirectToSupplement/10.1016/j.margeo.2006.07.006"><img src="http://linkinghub.pangaea.de/elsevier/supplementBanner/10.1016/j.margeo.2006.07.006" style="border:none" /></a></html>", if no supplement available: "<html><a href="http://linkinghub.pangaea.de/elsevier/redirectToSupplement/10.1016/somefakedoi"><img src="http://linkinghub.pangaea.de/elsevier/supplementBanner/10.1016/somefakedoi" style="border:none" /></a></html>" (you should see nothing)

It may be possible, to only generate the above HTML fragment for ScienceDirect journals from the geoscientific world. If not too much effort is needed, we would like to avoid to get too many hits on our webserver from journal pages, that will never get datasets (like computer science papers,…). Maybe Elsevier has a property in your database that identifies the scientific area of article and journal.

MediaWiki:Loginreqpagetext

2009-12-01T16:19:11Z

Uwe Schindler: finalize the error message

You need to $1 for displaying or editing pages in the '''Talk''' namespaces. Additional '''curator rights''' are needed for pages from the '''Techdoc''' namespace (see [[Login]])!

MediaWiki:Loginreqpagetext

2009-12-01T16:08:40Z

Uwe Schindler:

You need to $1 with a '''curator account''' to display or edit pages from the '''Techdoc''' or '''Talk''' namespace!

MediaWiki:Loginreqpagetext

2009-12-01T16:08:12Z

Uwe Schindler:

You need to $1 with a '''curator account''' to display or edit pages from the '''Techdoc''' or Talk '''Namespace'''!

MediaWiki:Loginreqpagetext

2009-12-01T16:06:51Z

Uwe Schindler: Created page with 'You need to $1 with a curator account to display or edit pages from the "Techdoc" or "Talk" Namespace!'

You need to $1 with a curator account to display or edit pages from the "Techdoc" or "Talk" Namespace!

Main Page

2009-09-06T14:49:55Z

Uwe Schindler:

Welcome to '''PangaWiki'''! This wiki is a dynamic manual and reference for the data library

<h3><font face="Times">'''[[PANGAEA]]® - Publishing Network for Geoscientific and Environmental Data'''</font></h3>
PangaWiki is operated to support data providers, curators and end-users in archiving, publishing and retrieving data from earth system research in the data library Pangaea. It is the reference system for any questions and information around the system and its operation. The Pangaea [[login]] is required to add or modify pages.
----
The most important PangaWiki chapters are listed in the '''table of [[content]]s'''.
----
If you need information on how to '''provide data for archiving and publication''' please go to [[Data submission]].
----
'''New users''' may start reading the following pages:
* [[Pangaea]]
* [[Data model]]
** [[Project]]
** [[Campaign]]
** [[Event]]
** [[Data series]], [[Data set]], [[Parent set]]
* [[Parameter]]
* [[Basic rules]], [[Curator]] and [[Staff]]
----
'''see also:'''
* [[Articles|Articles and projects related to data management]].
* A list of publications, presentations, posters and talks about Pangaea is maintained in [[ePIC]].
* [[Project data management|Recommendations, aphorisms and draft web pages]].
* The [[STD-DOI]] project
----
----

== Why using a Wiki for PANGAEA? ==
''Operation of a complex system like Pangaea, fulfilling the data management requirements of nearly all sciences in earth system research, is a challenge and must be supported by some documentation. In a first step, documentation was distributed through various pdf-files, web pages, and a (draft) manual ({{doi|10.1594/PANGAEA.319947}}). Also the [http://bscw.pangaea.de BSCW system] was used to exchange documentation and common files between various projects and curators.''

''A major problem of documentation is the very fast development and changes with any technology related to data systems and the Internet. Also new scientific requirements, sometimes just invented from scratch in running projects, need to be taken into account. A significant amount of resources are required to keep track on all documents and to keep them up-to-date and thus the distribution of a static (and most of the time outdated) manual is useless.''

''A comprehensive system was needed to support users in providing and accessing data and curators while working with Pangaea in an efficient way, ensuring overall technical quality of its content. The introduction of the wiki principle made a dynamic documentation easier. With the open source software '''MediaWiki''', developed and used by the Internet Encyclopedia [http://en.wikipedia.org/wiki/Main_Page Wikipedia], a free software tool is provided for fast and easy editing of content which is accessible and editable to anyone on the Internet. '''PangaWiki''' was installed in 2005-11-01 by ''Wikimaster'' Uwe Schindler and has become a constantly growing archive for any information around Pangaea.''

PANGAEA XML schema

2009-03-31T08:36:55Z

Uwe Schindler:

Field names as given in the '''PANGAEA XML schema''' can be used for specific queries using the PANGAEA search engine [http://www.pangaea.de/]. Queries are not case sensitive and can be combined by boolean operators. A blank is equivalent to ''AND'', use the ''minus sign (-)'' to exclude specifications. See also the ''Help'' function of PangaVista.

Search examples:
* data sets with a specific parameter [http://www.pangaea.de/search?q=parameter:obsidian ''parameter:obsidian'']
* data sets with a specific geocode [http://www.pangaea.de/search?q=geocode:depth-ice/snow ''geocode:depth-ice/snow'']
* data sets of a certain author in the citation [http://www.pangaea.de/search?q=citation:author:sieger ''citation:author:sieger'']
* data sets following two queries combined by boolean operators
**keyword ''radiocarbon'' in the reference AND published via Pangaea in the year 2000 [http://www.pangaea.de/search?q=reference:radiocarbon+citation:year:2000 ''reference:radiocarbon citation:year:2000'']
**keyword ''radiocarbon'' in the reference OR published via Pangaea in the year 2000 [http://www.pangaea.de/search?q=reference:radiocarbon+or+citation:year:2000 ''reference:radiocarbon or citation:year:2000'']
**keyword ''radiocarbon'' in the reference and NOT published via Pangaea in the year 2000 [http://www.pangaea.de/search?q=reference:radiocarbon+-citation:year:2000 ''reference:radiocarbon -citation:year:2000'']

== Schema ==

http://ws.pangaea.de/schemas/pangaea/MetaData.png

[http://ws.pangaea.de/schemas/pangaea/MetaData.xsd XML variant for writing transformations]

PANGAEA XML schema

2009-03-31T08:35:28Z

Uwe Schindler:

Field names as given in the '''PANGAEA XML schema''' can be used for specific queries using the PANGAEA search engine [http://www.pangaea.de/]. Queries are not case sensitive and can be combined by boolean operators. A blank is equivalent to ''AND'', use the ''minus sign (-)'' to exclude specifications. See also the ''Help'' function of PangaVista.

Search examples:
* data sets with a specific parameter [http://www.pangaea.de/search?q=parameter:Obsidian ''parameter:obsidian'']
* data sets with a specific geocode [http://www.pangaea.de/search?q=geocode:depth-ice/snow ''geocode:"depth-ice/snow"'']
* data sets of a certain author in the citation [http://www.pangaea.de/search?q=citation:author:sieger ''citation:author:sieger'']
* data sets following two queries combined by boolean operators
**keyword ''radiocarbon'' in the reference AND published via Pangaea in the year 2000 [http://www.pangaea.de/search?q=reference:radiocarbon+citation:year:2000 ''reference:radiocarbon citation:year:2000'']
**keyword ''radiocarbon'' in the reference OR published via Pangaea in the year 2000 [http://www.pangaea.de/search?q=reference:radiocarbon+or+citation:year:2000 ''reference:radiocarbon or citation:year:2000'']
**keyword ''radiocarbon'' in the reference and NOT published via Pangaea in the year 2000 [http://www.pangaea.de/search?q=reference:radiocarbon+-citation:year:2000 ''reference:radiocarbon -citation:year:2000'']

== Schema ==

http://ws.pangaea.de/schemas/pangaea/MetaData.png

[http://ws.pangaea.de/schemas/pangaea/MetaData.xsd XML variant for writing transformations]