docuteam:improvements
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
docuteam:improvements [2020/05/25 21:28] – [Erledigt] Andreas Nef | docuteam:improvements [2022/06/12 16:52] – Andreas Nef | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
======Roadmap für die docuteam-Applikationen====== | ======Roadmap für die docuteam-Applikationen====== | ||
- | ===== Einleitung ===== | ||
Wir erhalten regelmässig Inputs und Vorschläge für die Weiterentwicklung [[https:// | Wir erhalten regelmässig Inputs und Vorschläge für die Weiterentwicklung [[https:// | ||
Um die Roadmap allen Benutzern unserer Software zugänglich zu machen, publizieren wir nicht nur die Vorschläge, | Um die Roadmap allen Benutzern unserer Software zugänglich zu machen, publizieren wir nicht nur die Vorschläge, | ||
- | ==== Vorschläge/ | + | ===== Vorschläge/ |
* **GEVER-Dossier-Viewer** zur Anzeige von AIPs, die ursprünglich aus einem GEVER-System abgeliefert wurden. | * **GEVER-Dossier-Viewer** zur Anzeige von AIPs, die ursprünglich aus einem GEVER-System abgeliefert wurden. | ||
* Vorschlag mit groben Anforderungen wurde im April 2020 von Kunden an uns herangetragen. | * Vorschlag mit groben Anforderungen wurde im April 2020 von Kunden an uns herangetragen. | ||
- | * Wir verifizieren aktuell die Umsetzungsmöglichkeiten. | + | * Wir verifizieren aktuell die Umsetzungsmöglichkeiten. Die naheliegendste Möglichkeit besteht im Kontext des neuen Lesesaals, der in einer ersten Version im Verlauf von 2022 verfügbar sein wird. |
- | * Kontrolliertes **Löschen von AIP** aus dem Repository. Eine Möglichkeit wäre, in einem Workflow die Root-PID des Objekts anzugeben und dann das gesamte Objekt zu löschen. Die Herausforderung dieser Funktionalität sehen wir vor allem auch in der sorgfältigen Konzipierung, | + | * Kontrolliertes **Löschen von AIP** aus dem Repository. |
+ | * Eine Möglichkeit wäre, in einem Workflow die Root-PID des Objekts anzugeben und dann das gesamte Objekt zu löschen. Die Herausforderung dieser Funktionalität sehen wir vor allem auch in der sorgfältigen Konzipierung, | ||
+ | * Primär im Kontext von F6/docuteam box zu konzipieren. | ||
* Umsetzung sollte dann auch über docuteam bridge zugänglich sein. | * Umsetzung sollte dann auch über docuteam bridge zugänglich sein. | ||
- | * **Web-basiertes Ablieferungswerkzeug** | + | * **Web-basiertes Ablieferungswerkzeug |
* Anforderungen wurden am Community Day 2018 grob diskutiert. | * Anforderungen wurden am Community Day 2018 grob diskutiert. | ||
- | * Ein Umsetzungskonzept haben wir 2019 ausformuliert inkl. Aufwandschätzung und der Usergroup zukommen lassen. | + | * Ein Umsetzungskonzept haben wir 2019 ausformuliert inkl. Aufwandschätzung und der Usergroup zukommen lassen: {{ docuteam: |
- | * Sobald sich (wohl 2-3) Interessenten | + | * Sobald sich 4 Institutionen |
- | * docuteam bridge Implementierung der offenen APIs | + | * docuteam packer mit **Submit-Funktion nach docuteam bridge |
- | * Deletions in Planung | + | |
- | * Updates sollen nach Deletions folgen | + | |
- | * docuteam packer mit **Submit-Funktion nach docuteam bridge** | + | |
* Überarbeitung der **Ablieferungsvereinbarungen** | * Überarbeitung der **Ablieferungsvereinbarungen** | ||
* Die aktuellen Ablieferungsvereinbarungen bieten – aufbauend auf ISO 20652:2006 (CCSDS 651.0-B-1: | * Die aktuellen Ablieferungsvereinbarungen bieten – aufbauend auf ISO 20652:2006 (CCSDS 651.0-B-1: | ||
* In der Praxis zeigt sich jedoch, dass nur ein kleiner Teil davon effektiv genutzt wird. Eine künftige Version soll sich darauf konzentrieren, | * In der Praxis zeigt sich jedoch, dass nur ein kleiner Teil davon effektiv genutzt wird. Eine künftige Version soll sich darauf konzentrieren, | ||
+ | * Das [[https:// | ||
+ | * Überarbeitung von **Matterhorn METS** | ||
+ | * Representations | ||
+ | * Split fileSec from structMap | ||
+ | * Abstract file names | ||
+ | * upgrade from PERMIS 2.2 to PREMIS 3 | ||
+ | * PREMIS Agents/ | ||
+ | * Dynamic metadata (EAD) | ||
+ | * Sub-SIPs | ||
+ | * Container around the METS (BagIt)? | ||
+ | * Umsetzung **komplexe Dateiformat-Konvertierungen** | ||
+ | * Konvertierungen, | ||
+ | * Automatische detaillierte Validierung der Konvertierungsresultate (nach Verfügbarkeit von entsprechenden Werkzeugen). | ||
+ | ===== In Arbeit ===== | ||
+ | Unsere Softwareentwicklung konzentriert sich gegenwärtig auf die folgenden Punkte (Stand Dezember 2021): | ||
- | + | | |
- | ==== In Arbeit ==== | + | |
- | Unsere Softwareentwicklung konzentriert sich gegenwärtig auf die folgenden Punkte (Stand Juni 2019): | + | |
- | + | ||
- | | + | |
* Daten- und Metadaten-Modell basierend auf [[https:// | * Daten- und Metadaten-Modell basierend auf [[https:// | ||
- | * Storage-Adapter für docuteam feeder, um Objekte in Fedora | + | * Action(s), um Objekte in Fedora 6 zu speichern |
- | * Anpassung | + | * Update- und Migrationsmethoden Fedora 3.8 auf Fedora 6 |
- | * Update- und Migrationsmethoden Fedora | + | * Ersatz |
- | * Java 11-Kompatibilität | + | * Upgrade von frameworks/ |
+ | * ruby -> 3 | ||
+ | ===== Erledigt ===== | ||
+ | * Upgrade von frameworks/ | ||
+ | * rails -> 6 | ||
+ | * bootstrap -> TailwindCSS | ||
+ | * Integration von bridge (als API) in feeder | ||
+ | * Künftig wird es nur noch eine Applikation geben | ||
+ | * Die bridge-API wird 1:1 übernommen. | ||
+ | * Das Konzept der " | ||
+ | * Java 11-Kompatibilität | ||
* Mit dem Wechsel von Oracles Release-Zyklus für Java unterstützen wir künftig jeweils die Long Term Support (LTS)-Versionen. | * Mit dem Wechsel von Oracles Release-Zyklus für Java unterstützen wir künftig jeweils die Long Term Support (LTS)-Versionen. | ||
- | * Wir entwickeln seither mit (Adopt)OpenJDK | + | * Wir entwickeln seither mit (Adopt)OpenJDK. |
- | * Im Sommer 2020 (mit Verfügbarkeit | + | * Unterstützung |
- | * Aktuell sind die Anpassungen bereits vollzogen, wir haben aber mit der effektiven Umstellung der Entwicklungsumgebungen und Build-Plattformen absichtlich noch zugewartet. | + | |
- | + | ||
- | ==== Erledigt ==== | + | |
* Entkoppelung von rservices und Fedora | * Entkoppelung von rservices und Fedora | ||
- | * Im Hinblick auf den Wechsel zu Fedora | + | * Im Hinblick auf den Wechsel zu Fedora 6 haben wir Umstellungen gemacht, um rservices unabhängiger vom verwendeten Repository-System zu machen. |
* Autorisierung wird nun gänzlich und konsequent dem Repository übertragen. | * Autorisierung wird nun gänzlich und konsequent dem Repository übertragen. | ||
* done with [[docuteam: | * done with [[docuteam: |