Digital resources in the Social Sciences and Humanities OpenEdition Our platforms OpenEdition Books OpenEdition Journals Hypotheses Calenda Libraries OpenEdition Freemium Follow us

[Best-Practice-Dokumentation] Project Medieval Maritime Predation: Project Phase 01.06.2024 – 30.11.2024

DMMP Project Phase 01.06.2024 – 30.11.2024

Persons involved

Project Group: Nikolas Jaspert (ZEGK, Principal Investigator), Victòria Burguera (ZEGK, Postdoctoral Researcher), Laurin Herberich (ZEGK, Doctoral Researcher), Silvia Girona Espino (ZEGK, Research Assistant 1), Viola Herschbach (ZEGK, Research Assistant 2), Nabi Bauermeister (ZEGK, Research Assistant 3)

IT-Team: Nils Weiher (UB), Leonhard Maylein (UB)

Extended Project Group: Leonhard Maylein (UB), Nils Weiher (UB), Nikolas Jaspert (ZEGK), Victòria Burguera (ZEGK), Laurin Herberich (ZEGK), Kilian Schultes (ZEGK), Dominic Kempf (SSC), Florian Nieser (HCDH)

Timeline of the Project

June 2024

  • Shift from work on easydb model (data entry) to designing neo4j query visualisation (data navigation and analysis)
  • Cypher instructions
  • SSC application for detail viewer plugin and itinerary plugin

July 2024

  • Cypher instructions
  • Detail viewer alpha ready
  • Four out of eight workshop queries implemented

August 2024

  • Eight out of eight workshop queries implemented

September 2024

  • DMMP beta Update 1.3 changes and oversight list ready
  • IT-team prioritises testing DMMP model in fylr
  • “Saving” issue

October 2024

  • “Template” workaround for “saving” issue
  • IT-team opens ticket with Programmfabrik
  • “Export” issue International workshop

November 2024

  • Programmfabrik solves “saving” issue

Knowledge and data management

After the last major model improvements had been implemented in Update 1.2 for the DMMP beta, the project moved on to phase five and from modelling the easydb data entry “backend” to designing data navigation as well as analysis in the neo4j data extraction “frontend”. This shift in focus necessitated an initial knowledge transfer from the IT-team to the two researchers of the project group to speed up the design process with the query language Cypher. Throughout June 2024, the IT-team in coordination with the two researchers generated queries out of the initial 28 questions contained within the DMMP green paper (10/2022) and tested them in the neo4j-browser. Once a query returned data as intended in the green paper, the ITteam enhanced it for usage in the eventual DMMP frontend UI. This meant replacing the constants of the neo4j browser with the variables necessary for flexible navigation in the neo4j dashboard and augmenting the query to visualise the data in the most meaningful way, be it in table, graph, map, bar or pie chart form.

As the long-term sustainability of the DMMP depends to a large part on a continuous and reliable expert user base, the project group had programmed an international workshop for 30 and 31 October 2024. To be able to show the core functions of the DMMP to its potential users, while still continuing data entry and query design, the project group could count once more on the support of the SSC. After the latter had already successfully implemented the Zotero plugin for the easydb data entry “backend” in February 2023, the next step would be a detail viewer plugin API linked to the DMMP’s easydb instance plugin as well as an itinerary plugin, this time both for the neo4j dashboard data extraction “frontend”. Shortly after the project group had filed its application to the SSC in mid-June, three man-months of developing time were granted. Only a month later, the SSC demonstrated a first version of the detail viewer plugin to the ITteam. The IT-team had not been idle itself. By late July 2024 it had implemented four out of the eight queries deemed necessary for the DMMP’s presentation to the workshop participants in the neo4j dashboard data extraction “frontend”. By mid-August all eight queries were ready and the knowledge transfer from the IT-team to the researchers had progressed so far as to enable the latter two to design queries on their own, while the IT-team went on summer break.

In the meantime, the project group went over the easydb model once more to prepare DMMP beta Update 1.3. This was necessary to detect all oversights by the IT-team in applying the model to the easydb instance and to note all changes deemed necessary due to the experience of everyday data entry. The latter turned out to be minor in scale and included mostly additional click-boxes, fields, and the coherent implementation of the standard actor templates already introduced in May. While the respective list was ready by mid-September, Update 1.3 had to be delayed due to workload related reasons as well as the impending introduction of the sixth version of easydb called fylr. It had been presented to the IT-team by Programmfabrik in early September and due to it being programmed in Go, fylr promised to further improve on the performance of easydb 5. Thus, the IT-team decided to reduce the work on Update 1.3 and prioritised testing the DMMP model in fylr instead.

From late September until the end of November 2024, the main challenge faced by project group and IT-team was the “saving” issue. After having created a new document object containing data in its document head as well as in its findings section in the DMMP’s easydb instance, the doctoral researcher discovered that all data entered and objects linked in the findings section had not been saved. Even more concerning was that there no error message had indicated this loss of data. Instead, a new login produced two types of error messages, one regarding several missing “permissions” for the respective user and another regarding the user’s attempt to save various objects in an “old version”. Further investigation by the doctoral researcher revealed that the document head of document OT’s as well as objects created in a new document object were saved, even if those objects had been created in the findings section. Indeed, only the data entered and object linkages in the latter section seemed to be lost. The “saving” issue persisted even in different browsers, with or without activated add-ons, and independent of OS. Finally, it only seemed to affect the doctoral researcher’s account and one research assistant’s account, incidentally the two accounts that had entered the most documents (DR: 479, RA 1: 129), while the other accounts (PR: 88, RA 2: 83, RA 3: 63) remained unaffected.

Three factors helped to avoid a serious setback. First, at the beginning of October the doctoral researcher found a workaround to keep data entry going. By saving the data entered in a document object as a template before saving the document itself, data loss could be avoided, as the saved template could be used to replace the lost data in the findings section. This mitigated the loss of time, limiting it to a week. While all project group members were back at data entry, the IT-team’s troubleshooting efforts were the second factor contributing to a solution. Immediately after its discovery, the team was trying to find the cause of the issue. A suspicion was raised that being logged into the DMMP in several tabs, while simultaneously editing and saving the same document object caused Elasticsearch to return old versions of document objects, which when filled with new data, could then not be saved as these old document versions did not correspond to anything stored on the server. But working in several tabs simultaneously was a modus operandi which was not blocked by easydb and did work in all other accounts. While possibly a cause for the second error message, multiple logins were seemingly unrelated to the “saving” issue. A second suspicion was that this issue might be limited to certain accounts, but then the issue appeared in the doctoral researcher’s newly created second account on the day of its creation. Still, the other accounts were seemingly unaffected. During a live demonstration of the issue to the IT-team on the very same day, the latter saved all browser logs from the doctoral researcher’s pc and added them to the ticket at Programmfabrik which had been filed already in early October. Programmfabrik’s continuous support was the third factor contributing to a solution of the “saving” issue. By mid-October, a week after the IT-team’s addition to their ticket, Programmfabrik had one of their specialists working the case. A DMMP account was set up for them and, while a live demonstration of the issue failed, screen recordings of it were uploaded into a shared heibox folder. They started by fixing some underlying errors, which caused the two error messages to appear after login. While succeeding in stopping their further appearance, the “template” workaround stopped working in the process and templates could neither be saved nor deleted. But, after only three days, the workaround was functioning again. Finally, by the end of November 2024, the “saving” issue was fixed by Programmfabrik. As it turned out, the DMMP’s model, which links the event OT in the findings section of the document OT, but also the findings section in the event OT, created a conflict in the data during saving, as the easydb took the data from the event OT and not the document OT.

Even though the “saving” issue was not fixed by Programmfabrik before the DMMP workshop on 30 and 31 October, the detail viewer plugin was. The SSC was tweaking its alpha version in coordination with the IT-team throughout September, and by early October the beta version was presented to and discussed with the project group. While the issue of the display language occasionally switching between German and English had to be postponed, the beta was still in a presentable shape for the workshop. An issue that could and was not postponed was the “export” issue affecting the DMMP’s neo4j instance, i.e. the browser and dashboard. Two days before the workshop, the project group discovered that random objects existent in the easydb instance were missing in the neo4j one. In the end, the IT-team was able to identify and fix the issue the very same day of its discovery. In a similar way to the “JSON size” issue from phase four, a random setting in neo4j had only allowed import of 1,000 objects per OT and, thus, a good amount of data was missing from the neo4j instance, as at this point 1,207 event objects and 1,640 person objects had been introduced. To make sure the DMMP would run smoothly during the workshop, the IT-team was on call for the entire time of its presentation.

The workshop itself, which aimed at bringing together historians working with quantitative medieval sources of the Mediterranean that convey information on maritime mobility, succeeded not only in presenting the DMMP to a potential expert user base, but also in assessing the capabilities of other existing databases focussing on the medieval

Mediterranean. While there are impressive efforts being undertaken in data collection mostly with first generation SQL systems, the technological advantages of the DMMP’s combination of SQL, Search, and Graph database systems could not be denied.

Collaboration/Communication within the project

Phase five was characterised by mostly email communication from June to early September, not because there was less cooperation, but because data entry, query testing, and the implementation of the queries in the neo4j dashboard did not require direct communication. In fact, questions regarding Cypher in particular were better solved using mail, as faulty queries could be contemplated, corrected, and then send back. The IT-team’s quick response time rendered this modus operandi even more efficient.

While almost daily email exchanges remained a hallmark of phase five, interpersonal exchanges were handled flexibly and according to demand. In June, July, August, and September the two researchers and the IT-team met only twice online to discuss the two plugins as well as specific dashboard visualisations. In stark contrast, when confronted with the “saving” issue and under pressure to present a resilient system during the workshop, researchers and IT-team discussed these topics seven times online and in person between October and November.

In this sense, phase five marked, for the larger part, a return to the reliance on the electronic communication of phases one and two. As in all phases, all of the design relevant communication was recorded in gitlab by the IT-team. The latest version of the neo4j dashboard concept for the DMMP’s eventual frontend may serve as an instructive example here: https://gitlab.ub.uni-heidelberg.de/fdm/dmmp/-/blob/main/analysis/examplesdashboard.json.

 

Gallery:

 

— German Version —

DMMP Projektphase 01.06.2024 – 30.11.2024

Involvierte Personen

Project Group: Nikolas Jaspert (ZEGK, Principal Investigator), Victòria Burguera (ZEGK, Postdoctoral Researcher), Laurin Herberich (ZEGK, Doctoral Researcher), Silvia Girona Espino (ZEGK, Research Assistant 1), Viola Herschbach (ZEGK, Research Assistant 2), Nabi Bauermeister (ZEGK, Research Assistant 3)

IT-Team: Nils Weiher (UB), Leonhard Maylein (UB)

Extended Project Group: Leonhard Maylein (UB), Nils Weiher (UB), Nikolas Jaspert (ZEGK), Victòria Burguera (ZEGK), Laurin Herberich (ZEGK), Kilian Schultes (ZEGK), Dominic Kempf (SSC), Florian Nieser (HCDH)

Bisheriger zeitlicher Verlauf des Projekts

Juni 2024

  • Wechsel von der Arbeit am easydb Modell (Dateneingabe) zum Design der neo4j Visualisierungsoptionen (Datennavigation und -analyse)
  • Cypher instructions
  • SSC Antrag für das Detailansichtsplugin sowie das Itinerarplugin

Juli 2024

  • Cypher Instruktionen
  • Detailansichtsplugin Alpha bereit
  • Vier von acht Workshop-Queries implementier

August 2024

  • Acht von acht Workshop-Queries implementiert

September 2024

  • DMMP beta Update 1.3 – Ergänzungsliste bereit
  • IT-Team priorisiert das DMMP Modell in fylr zu testen
  • “Speicher”-Problem

Oktober 2024

  • “Template”-Zwischenlösung für “Speicher”-Problem
  • IT-Team eröffnet Ticket bei Programmfabrik
  • “Export”-Problem Internationaler Workshop

November 2024

  • Programmfabrik löst “Speicher”-Problem

Wissens- und Datenmanagement

Nachdem die letzten größeren Modellverbesserungen in Update 1.2 für die DMMP-Beta implementiert worden waren, ging das Projekt in die fünfte Phase über, genauer, von der Modellierung des easydb-Dateneingabe-„Backends“ zur Gestaltung der Datennavigation sowie -analyse im neo4j-Datenextraktions-„Frontend“. Diese Schwerpunktverlagerung erforderte einen ersten Wissenstransfer vom IT-Team zu den beiden Forschern der Projektgruppe, um den Entwurfsprozess mit der Abfragesprache Cypher zu beschleunigen. Im Juni 2024 generierte das IT-Team in Abstimmung mit den beiden Forschern Abfragen aus den ursprünglich 28 Fragen des DMMP-Grünbuchs (10/2022) und testete sie im neo4j-Browser. Sobald eine Abfrage die im Grünbuch vorgesehenen Daten lieferte, wurde sie vom IT-Team für die Verwendung in der späteren DMMP-Frontend-Oberfläche optimiert. Das bedeutete, dass die Konstanten des neo4j-Browsers durch die Variablen ersetzt wurden, die für eine flexible Navigation im neo4j-Dashboard erforderlich sind, und dass die Abfrage so erweitert wurde, dass die Daten auf die aussagekräftigste Weise visualisiert werden, sei es in Form von Tabellen, Diagrammen, Karten, Balken- oder Tortendiagrammen.

Da die Nachhaltigkeit der DMMP zu einem großen Teil von einer zuverlässigen Expertenbasis von Nutzern abhängt, hatte die Projektgruppe für den 30. und 31. Oktober 2024 einen internationalen Workshop geplant. Um den potenziellen Nutzern die Kernfunktionen der DMMP zu zeigen und gleichzeitig Dateneingabe und Entwurfsprozess weiterzuführen, konnte die Projektgruppe erneut auf die Unterstützung des SSC zählen. Nachdem dieses bereits im Februar 2023 das Zotero-Plugin für das easydb-Dateneingabe-„Backend“ erfolgreich implementiert hatte, sollte als nächster Schritt ein mit der easydb-Instanz via API verknüpftes

Detailansichtsplugin sowie ein Itinerarplugin, diesmal für das neo4j-DashboardDatenextraktions-„Frontend“, folgen. Kurz nachdem die Projektgruppe Mitte Juni ihren Antrag beim SSC eingereicht hatte, wurden ihr drei Personenmonate Entwicklungszeit bewilligt. Nur einen Monat später führte das SSC dem IT-Team eine erste Version des Detail-Viewer-Plugins vor. Das IT-Team war selbst nicht untätig gewesen. Bis Ende Juli 2024 hatte es vier der acht Abfragen, die für die Präsentation der DMMP als erforderlich erachtet wurden, in das neo4jDashboard-Datenextraktions-„Frontend“ implementiert. Mitte August waren alle acht Abfragen fertig und der Wissenstransfer vom IT-Team zu den Forschern war so weit fortgeschritten, dass die beiden letzteren in der Lage waren, selbständig Abfragen zu entwerfen, während das ITTeam in die Sommerpause ging.

In der Zwischenzeit überprüfte die Projektgruppe noch einmal das easydb-Modell, um das DMMP beta Update 1.3 vorzubereiten. Dies war notwendig, um alle Versäumnisse des ITTeams bei der Implementierung des Modells in die easydb-Instanz zu registrieren und alle zusätzlichen Änderungen zu notieren, die aus der Erfahrung alltäglicher Dateneingabe als notwendig erachtet wurden. Letztere erwiesen sich als geringfügig und umfassten hauptsächlich zusätzliche Klickboxen, Felder und die kohärente Umsetzung der bereits im Mai eingeführten Standard-Akteursvorlagen. Während die entsprechende Liste bereits Mitte September fertig war, musste das Update 1.3 aus Gründen der Arbeitsbelastung sowie der bevorstehenden Einführung der sechsten Version von easydb namens fylr verschoben werden. Diese wurde dem IT-Team Anfang September von der Programmfabrik vorgestellt und versprach, da programmiert in Go, eine Verbesserung der Performance im Vergleich zu easydb 5. Daher beschloss das IT-Team, die Arbeit an Update 1.3 zu reduzieren und stattdessen dem Testen des DMMP-Modells in fylr Vorrang zu geben.

Von Ende September bis Ende November 2024 war die größte Herausforderung für die Projektgruppe und das IT-Team das „Speicher“-Problem. Nachdem ein neues Dokumentenobjekt mit Daten im Dokumentenkopf und im Befundteil in der easydb-Instanz der DMMP erstellt worden war, stellte der Doktorand fest, dass alle eingegebenen Daten und die Verlinkung im Befundteil befindlicher Objekte nicht gespeichert worden waren. Noch beunruhigender war, dass keine Fehlermeldung auf diesen Datenverlust hinwies. Stattdessen gab es bei einer erneuten Anmeldung zwei Arten von Fehlermeldungen, eine über mehrere fehlende „Berechtigungen“ für den jeweiligen Benutzer und eine weitere über den Versuch des Benutzers, verschiedene Objekte in einer „alten Version“ zu speichern. Weitere

Nachforschungen des Doktoranden ergaben, dass sowohl der Dokumentenkopf von Dokumenten-OT’s als auch Objekte, die in einem neuen Dokumentenobjekt angelegt wurden, gespeichert wurden, auch wenn diese Objekte im Befundteil kreiert worden waren. Tatsächlich schienen nur die im Befundteil eingegebenen Daten und Objektverknüpfungen verloren zu gehen. Das „Speicher“-Problem trat auch in verschiedenen Browsern, mit oder ohne aktivierte Add-ons und unabhängig vom Betriebssystem auf. Schließlich schien es nur das Konto des

Doktoranden sowie einer wissenschaftlichen Mitarbeiterin zu betreffen, also die beiden Konten, welche die meisten Dokumente eingegeben hatten (DR: 479, RA 1: 129), während die anderen Konten (PR: 88, RA 2: 83, RA 3: 63) nicht betroffen waren.

Drei Faktoren trugen dazu bei, einen ernsthafteren Rückschlag zu vermeiden. Erstens fand der Doktorand Anfang Oktober eine Lösung für fortgesetzte Dateneingabe. Indem man die in ein Dokumentobjekt eingegebenen Daten als Vorlage speicherte, bevor das Dokument selbst gespeichert wurde, konnte ein Datenverlust vermieden werden, da die gespeicherte Vorlage verwendet werden konnte, um die verlorenen Daten im Befundteil zu ersetzen. Dadurch konnte der Zeitverlust auf eine Woche begrenzt werden. Während alle Mitglieder der Projektgruppe wieder mit der Dateneingabe beschäftigt waren, trugen die Bemühungen des

IT-Teams als zweiter Faktor zur Lösung des „Speicher“-Problems bei. Unmittelbar nach seiner Entdeckung versuchte das Team, die Ursache des Problems zu finden. Es wurde der Verdacht geäußert, dass das gleichzeitige Bearbeiten und Speichern desselben Dokumentenobjekts in der DMMP in mehreren Tabs dazu führte, dass Elasticsearch alte Versionen von Dokumentobjekten anzeigte, die dann, wenn sie mit neuen Daten gefüllt wurden, nicht gespeichert werden konnten, da diese alten Dokumentversionen nicht mit den auf dem Server gespeicherten Daten übereinstimmten. Das gleichzeitige Arbeiten in mehreren Tabs war jedoch ein Modus Operandi, der nicht von easydb blockiert wurde und auch in allen anderen Accounts funktionierte. Obwohl dies möglicherweise eine Ursache für die zweite Fehlermeldung war, hatten mehrere Logins scheinbar nichts mit dem „Speicher“-Problem zu tun. Ein zweiter Verdacht war, dass dieses Problem auf bestimmte Konten beschränkt sein könnte, aber dann trat es im neu erstellten, zweiten Konto des Doktoranden am Tag seiner Erstellung auf.

Die anderen Konten waren jedoch anscheinend nicht betroffen. Bei einer Live-Demonstration des Problems vor dem IT-Team am selben Tag speicherte dieses alle Browserprotokolle vom PC des Doktoranden und fügte sie dem Ticket bei Programmfabrik hinzu, das bereits Anfang Oktober eingereicht worden war. Die kontinuierliche Unterstützung durch Programmfabrik war der dritte Faktor, der zur Lösung des „Speicherproblems“ beitrug. Mitte Oktober, eine Woche nachdem das IT-Team sein Ticket ergänzt hatte, hatte Programmfabrik einen ihrer Spezialisten mit dem Fall betraut. Für diesen wurde ein DMMP-Konto eingerichtet, und obwohl eine LiveDemonstration des Problems fehlschlug, wurden Bildschirmaufzeichnungen davon in einen gemeinsamen Heibox-Ordner geladen. Programmfabrik begann mit der Behebung einiger zugrunde liegender Fehler, die dazu führten, dass die beiden Fehlermeldungen nach der Anmeldung erschienen. Es gelang zwar, ihr weiteres Auftreten zu verhindern, doch funktionierte die „Template“-Zwischenlösung nicht mehr und Vorlagen konnten weder gespeichert noch gelöscht werden. Aber schon nach drei Tagen funktionierte die Umgehung wieder. Ende November 2024 wurde das Problem des „Speicherns“ schließlich von Programmfabrik behoben. Wie sich herausstellte, verursachte das Modell der DMMP, das die Ereignis-OT im Befundteil des Dokument-OT verknüpft, aber auch den Befundteil im den Ereignis-OT, einen Konflikt in den Daten beim Speichern, da die easydb die Daten aus den Ereignis-OT und nicht aus dem Dokument-OT entnahm.

Auch wenn das Problem des „Speicherns“ von der Programmfabrik nicht vor dem DMMPWorkshop am 30. und 31. Oktober behoben wurde, so war das Detailansichtsplugin bereit.

Das SSC feilte den ganzen September über in Abstimmung mit dem IT-Team an seiner AlphaVersion, und Anfang Oktober wurde die Beta-Version der Projektgruppe vorgestellt und mit ihr diskutiert. Während die Behebung des Problems des gelegentlichen Wechsels der Anzeigesprache zwischen Deutsch und Englisch verschoben werden musste, war die BetaVersion für den Workshop immer noch in einer vorzeigbaren Form. Ein Problem, das nicht verschoben werden konnte, war das „Export“-Problem der neo4j-Instanz der DMMP, d.h. des Browsers und des Dashboards. Zwei Tage vor dem Workshop stellte die Projektgruppe fest, dass wahllose Objekte, die in der easydb-Instanz vorhanden waren, in der neo4j-Instanz fehlten. Letztendlich konnte das IT-Team das Problem noch am Tag seiner Entdeckung identifizieren und beheben. Ähnlich wie beim „JSON-Größe“-Problem aus Phase vier, hatte eine zufällige Einstellung in neo4j nur den Import von 1.000 Objekten pro OT erlaubt und somit fehlte eine große Menge an Daten in der neo4j-Instanz, da zu diesem Zeitpunkt 1.207 Ereignisobjekte und 1.640 Personenobjekte eingegeben worden waren. Um ein reibungsloses Funktionieren der DMMP während des Workshops zu gewährleisten, blieb das IT-Team während der gesamten Zeit ihrer Präsentation auf Abruf.

Der Workshop selbst, der darauf abzielte, Historiker*innen zusammenzubringen, die mit quantitativen mittelalterlichen Quellen des Mittelmeers arbeiten, welche Informationen über maritime Mobilität vermitteln, war nicht nur erfolgreich darin, die DMMP einer potenziellen Expertenbasis vorzustellen, sondern auch darin, die Leistungspotenziale anderer bestehender Datenbanken mit Schwerpunkt auf dem mittelalterlichen Mittelmeer zu bewerten. Zwar gibt es beeindruckende Anstrengungen im Bereich der Datenerfassung, vor allem mit SQL-Systemen der ersten Generation, doch die technologischen Vorteile der Kombination von SQL-, Such- und Graph-Datenbanksystemen der DMMP waren unbestreitbar.

Zusammenarbeit/Kommunikation innerhalb des Projektes

Die fünfte Phase war von Juni bis Anfang September durch einen überwiegenden E-Mail Verkehr gekennzeichnet, und zwar nicht, weil es weniger Zusammenarbeit gab, sondern weil die Dateneingabe, das Testen der Abfragen und die Implementierung der Abfragen in das neo4j-Dashboard keine direkte Kommunikation erforderten. Vor allem Fragen zu Cypher ließen sich besser per Mail lösen, da fehlerhafte Abfragen bedacht, korrigiert und dann zurückgeschickt werden konnten. Die schnelle Reaktionszeit des IT-Teams machte diesen Modus Operandi noch effizienter.

Während der fast tägliche E-Mail-Austausch ein Charakteristikum von Phase fünf blieb, wurde der zwischenmenschliche Austausch flexibel und je nach Bedarf gehandhabt. Im Juni, Juli, August und September trafen sich die beiden Forscher und das IT-Team nur zweimal online, um die beiden Plugins sowie bestimmte Dashboard-Visualisierungen zu besprechen. Im Gegensatz dazu diskutierten die Forscher und das IT-Team zwischen Oktober und November sieben Mal online und persönlich, als sie mit dem „Speicher“-Problem konfrontiert wurden und unter dem Druck standen, ein belastbares System während des Workshops zu präsentieren.

In diesem Sinne bedeutete die fünfte Phase zum größten Teil eine Rückkehr zur elektronischen Kommunikation der ersten und zweiten Phase. Wie in allen Phasen wurde die gesamte designrelevante Kommunikation vom IT-Team in gitlab dokumentiert. Die neueste Version des neo4j-Dashboard-Konzepts für das spätere Frontend des DMMP mag hier als Beispiel dienen: https://gitlab.ub.uni-heidelberg.de/fdm/dmmp/-/blob/main/analysis/examples-dashboard.json.

 

Galerie:


OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Laurin Herberich (13. Januar 2025). [Best-Practice-Dokumentation] Project Medieval Maritime Predation: Project Phase 01.06.2024 – 30.11.2024. DH in HD . Abgerufen am 19. Februar 2026 von https://doi.org/10.58079/132gy


Das könnte dich auch interessieren …