Talk:ESciDoc Workshop 2007-09-24

MPDL This page collects some thoughts and discussions while the

Matthias presentation: FIZ perspective on eSciDoc (0:30)
Zitat 1: "Bei der Definition neuer Schnittstellen in den Basis-Diensten darauf achten, dass sie keine sehr spezifischen Anforderung von Pubman - sondern tatsächlich generische Anforderungen implementieren.

Frage: Was wäre denn die Schlussfolgerung, wenn eine Funktion nicht generisch, aber trotzdem fuer die Applikation notwendig ist?

Antwort von Matthias: Das hängt vom konkreten Fall. Wenn die Funktion zwingend notwendig ist, muss sie trotzdem gemacht werden.

Frage/Kommentar von Johannes: Die Bestimmung der Beziehung von eSciDoc<->Pubman (als eine oder wichtigste Solution) ist eine grundlegende Frage.

Zitat 2: "eSciDoc muss auch nach aussen gehen, um weitere Anforderungen zu sammeln"

Frage: Scheitert es denn nicht daran, dass wir nichtmal für die MPG Anforderungen gut funktionierende Solutions liefern?

Zitat 3: "management of expectation" ist erforderlich, damit die Anforderungen nicht erdrücken

Frage: Ist das nicht von vornherein problematisch, weil eSciDoc immer als "das" eScience Flagschiff praesentiert wird ?

Zitat 4: "eSciDoc eignet sich nicht für alles

Frage: was sind denn die Messwerte, die das framework auszeichnen? Fer welche Anwendungsfälle ist das Framework geeignet

Zitat 5: Leute kommen, schauen sich die Infrastruktur an und wollen wissenschaftliche Lösungen oben drauf bauen

Frage: Aus meiner Sicht kommen die Leute zu den beteiligten Einrichtungen, weil sie auf der Suche nach Lösungen sind. Ob eSciDoc auch eines der Probleme effektiv und effizient loesen kann, haben wir bislang nicht nachgewiesen.

Brain storming, Round I: Problems
Brainstorming mit dem Thema: Problem, offene Punkte im eSciDoc Projekt.


 * Alle Workshop Teilnehmen wurden aufgefordert ihre Bedenken, offenen Punkte aufzuschreiben. Anschließend wurden die Punkte in Themen aufgeteilt, geclustert und in ein Mindmap übertragen. Zunächst sollen Punkte besprochen werden, die die granze Gruppe angeht.


 * Es wurde festgestellt, dass die Punkte die in kleine Teilaspekte unterteilt werden sollten, damit sie besser bearbeitet und diskutiert werden können.

Falscher Entwicklungsansatz
Problem: Spezifikation sollte auf der einen Seite generischer sein und auf der anderen Seite genauer und spezieller.

Das Feedback der Programmierer kommt erst zu spät und gibt erst spät seine Einschätzung ob es machbar/realisierbar sind. Funktionaler Experte ist dann schon wieder aus dem Thema draußen.

Konsequenz: Konzepte müssen gelesen werdern und zwar sofort wenn sie fertig sind.

Themen für die Diskussion für den heutigen Tag

 * Digilib
 * Spezifikation und Entwicklung
 * Performance und AA

Teilgruppe Performance und AA

 * Skalierbarkeit: Derzeit skaliert das eSciDoc-Framework nicht. Das FIZ baut derzeit eine Umgebung auf, um die moeglichen Bottleneck zu analysieren und dann (falls moeglich) zu behen
 * Die Größe eines XML files beim Ingest:
 * Vorschlag: eDoc Daten dumpen und einspielen um zu testen
 * vielleicht sollte die Größe neu definiert werden. Matthias will eine klare Ansage von der MPDL haben, was gebraucht wird. Das FIZ muss nur garantieren, dass bis zu der Grenze hochgeladen werden kann.
 * Listen
 * kann problematisch für die Performance sein
 * MPDL benötigt immer das gesamte Objekt, was schlecht für die Performance ist
 * besser wäre es, wenn man z.B. nur auf den Metadatenstrom zugreift, bzw. auf einen Resource Index
 * Ergebnis:
 * FIZ erstellt einen Prototyp des Frameworks mit Transformationsmechanismus für Listretrieval-Metadaten, mit AA, ohne Paging, Listformat: RSS in RDF
 * Evaluation
 * ESciDoc Item List

Brain storming, Round II: Goals
Die Wünsche und Vision zur Entwicklung des eSciDoc-Projekts bis 2009 und ab 2009 werden gesammt. Malte wird die Ergebnisse clustern und verteilen.