Talk:Portal

data flow through biodiversity portals/providers
 * non-exclusive-eur data: DataProvider -> OBIS -> GBIF -> EurOBIS (filtered on eur-data)
 * exclusive-eur-data: DataProvider -> EurOBIS -> OBIS -> GBIF

frequency of caching:
 * EurOBIS every few months
 * OBIS every first wednesday of a month

Comment von Uwe Schindler zu ScientificCommon

Scientific Commons hat die Eigenschaft, dass es EPIC (und auch PANGAEA) harvestet via OAI-PMH, um erstmal die Dublin Core Metadaten zu bekommen. Das reicht ihm jedoch nicht und deshalb treibt es das ganze weiter: Es besucht die Zielseite (wie auch Google) und versucht dann herauszufinden, wo der Volltext zu finden ist (Analyse der HTML-Webseite). Da es bei dem SEPAN Paper weder eine PDF dazu gibt noch ein Abstract im Dublin Core geliefert wurde, macht er hier einen entscheidenden Fehler. Er sucht auf der Zielseite nach einem Link zu einer PDF.... Und da gibt’s nur einen, ganz rechts die Publication List. Und die versucht er wie Scholar zu analysieren. Und irgendwie verwexelt er die mit einem Paper... Als Folge findet man den Link zum „vermeintlichen“ Volltext findet man links im Scientific Commons Output. Das passiert bei allen Datensätzen in EPIC ohne PDF oder Abstract. Auch bei PANGAEA Datensätzen passiert das: Da wir grundsätzlich nie ne PDF haben (sind ja Daten) passiert hier immer, dass das zugehörige Paper aus der Referenz analysiert wird (wenn die URI direkt auf die PDF und nicht Splash-Seite zeigt). Da kann man leider nicht viel machen, so was passiert immer, wenn Entwickler wie bei Scientific Commons zuviel „Intelligenz“ in die Software checken (die „Intelligenz“ ist hier: „Es muss eine PDF auf dem Link hinter dem Dublin Core Datensatz geben. Wenn er nicht selbst direkt auf eine PDF zeigt, suche danach“). Dabei gibt es dann immer Ausreißer. Leider ist EPIC und PANGAEA davon sehr betroffen. Und man kann nichts tun (man könnte sich vielleicht beschweren, aber es würde nix helfen, weil die ja keine Datenbank haben, die man editieren könnte, alles ist ein großer Automatismus).

Comment von Uwe zu Google (2008-09-09)

Frage: bekommt google die abstracts zum lesen ?

Google macht nix anderes, nachdem er alle möglichen URLs unter http://doi.pangaea.de mitgeteilt zu bekommen hat (via http://doi.pangaea.de/sitemap.xml), als die Seiten zu indexen (also HTML runterläd und speichert). Was im HTML steht weiss er. Zu den Datendownloads selber geht er dann nicht mehr, obwohl er alle Links verfolgt, weil im Link zum TAB-File drinsteht: rel="nofollow" -- aber in den Daten steht nix für Google wichtiges und belastet nur den Server, daher ausgeklammert.

Datensätze die nicht published sind, enthalten im HTML-Header das Tag 

Auch ohne Sitemap kommt Google im Prinzip zu allen Datensätzen: Er geht auf www.pangaea.de/projects/, "klickt" auf den Datenlink hinter jedem Projekt und bekommt via PangaVista Results viel zum Harvesten :) - nur umständlicher für ihn.

Der Teil für das Datenportal ist:

http://dataportals.pangaea.de/epoca/

Dies verwendet das Stylesheet der EPOCA-Webseite mit ein paar Zusätzen für PangaVista. Die Ränder und alles wurde schon so optimiert, so dass es embeddbar in andere Webseiten via ist, das wäre so:

 [Your user agent does not support frames or is currently configured not to display frames]

Die PHP-Seite und das Style könnt ihr hier editieren (auf pansrv1): /pangaea/htdocs/dataportals.pangaea.de/epoca/

Das Rolf-Weller-IQ-Abfragetool ist genauso in Typo3 auf www.awi.de von Ana integriert worden:
 * http://www.awi.de/en/infrastructure/stations/neumayer_station/observatories/air_chemistry_observatory/data_download/