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/

Comment zur Anfrage der Nutzbarkeit von SCARMarBIN für das AWI (2009-04-22 data librarian)

Julian Gutt hat die Bedeutung von SCAR-MarBIN für die Biologie im Südpolarmeer ausreichend gewürdigt und auch ich bin der Ansicht, dass die Sichtbarkeit und Verfügbarkeit der vielfältigen Antarktischen Daten und Datenbanken unter einem gemeinsamen Portal für eine moderne Wissenschaft notwendig sind - unter den besonderen Bedingungen der Antarktis und SCAR einmal mehr. Das AWI sollte sich hier beteiligen, allerdings mit einigen Vorgaben.

Die Zahlung von Beiträgen an internationale Organisationen ohne Erfolgskontrolle wird leicht zu einer Geldsenke (wurde im letzten Jahr vom Bundesrechnungshof kritisiert). Und gerade Datensysteme haben die Eigenschaft sehr schnell ein User-fremdes Eigenleben zu entwickeln, dass ihre Akzeptanz minimiert. Unter der Voraussetzung, dass die SCAR-MarBIN Partner einen Beitrag zahlen, sollte das Portal daher regelmäßig durch unabhängige Gutachter und seine data provider begutachtet werden. Das Gutachten sollte Grundlage für weitere Zahlungen sein. Den Partnern sollte klar sein, dass die Begutachtung zusätzliche eigene Ressourcen benötigt. Gesagtes gilt im übrigen auch für JCADM, dass mit SCAR-MarBIN eng kooperieren sollte.

Ein finanzieller Beitrag sollte ehr gering ausfallen. Zu diesem Zeitpunkt sollte das Portal nicht ausgeweitet werden, sondern mit einem Aufwand betrieben werden, der sich auf das Kerngeschäft konzentriert (5 statt wie jetzt 50 Menuepunkte, schnell und einfach Daten der Provider verfügbar machen, Artenregister). Bei Betrachtung des Aufwandes sollte klar sein, dass die eigentliche Arbeit für die Datenarchivierung und die technische Kommunikation mit dem SCAR-MarBIN Portal bei den Datenprovidern liegt - nicht bei SCAR-MarBIN.

Portale stecken in den Kinderschuhen. SCAR-MarBIN ist ein gutes Beispiel: langsam, unzuverlässige Links, technische Sachzwänge, undurchsichtige Struktur - ohne regelmäßige explizite Reviews und ständige Obtimierung verbrennt dieses Portal viel Zeit des Nutzers oder wird gar nicht erst genutzt. Zur "Relativierung" und der Überlegung, wo finanziell die Prioritäten zu setzen sind, noch eine Ergänzung zum letzten und wichtigsten Satz von Julian Gutt zur Datenverfügbarkeit: In den wachsenden internationalen Daten-Infrastrukturen wird zunehmend auf Portale gesetzt - man vergißt dabei, dass diese Portale nur die Daten liefern können, die auch in (portalfähigen) Datensystemen abgelegt wurden - wie z.B. in PANGAEA, das seit Beginn diese Portale mit Inhalten beliefert. Zitat Nature Vol 457, S.129: Initiatives for digital research infrastructure should focus more on making data available, and less on developing new portals.

Requirements zum Aufsetzen eines Portals einsammeln muss (Sisyphus-Programmiererei)
 * Anzahl und Art der Datenprovider
 * Verfügbarkeit der Metadaten
 * OAI-PMH mit DIF, FGDC, ISO, DC (best case)
 * WAF (web accessible folder) mit XML-Dateien in obigen Formaten (zur Not)
 * einzeln einsammeln (worst case)
 * Zeitbedarf:
 * ein Tag für Einrichtung der Indexe und Test
 * 1 Tag für Erstellung der Webseite, Einbinden des Suchfeldes
 * 1 Tag pro Datenprovider und Format für Nicht-Standard konforme Datenformate zum Erstellen der XSLTs
 * endlos wenn der Datenprovider seine Metadaten nur als HTML hat und man die irgendwie