Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Möglichkeit zum Laden von gespeicherten, aber (evtl. versehentlich) geschlossenen Korrekturen #21

Open
LetschM opened this issue Apr 21, 2016 · 7 comments
Assignees

Comments

@LetschM
Copy link

LetschM commented Apr 21, 2016

Wenn man im Tool eine Seite bearbeitet, speichert und anschliessend schliesst, obwohl sie noch nicht fertig durchgearbeitet ist, sollte man sich die Nummer der bearbeiteten Seite merken, um sie nachträglich wieder aufzurufen. Hat man sie sich nicht gemerkt, wird es schwierig, genau die Seite wiederzufinden. Daher wäre evtl. eine Lösung gar nicht schlecht, welche es erlaubt, die letzte bearbeitete Seite wieder aufzurufen. Oder man muss den Bearbeitenden sagen, dass sie sich grundsätzlich die Nummer (z.B. 0044) jeder begonnenen Seite aufschreiben.

@zuphilip
Copy link
Member

Ja. Momentan ist die Arbeitsanweisung jeweils 5 Seiten zu erfassen (Anfang, Mitte, Ende). Die Beabeiter müssen aber wohl momentan noch extern sich die PPN und die entsprechenden bereits bearbeiteten Seiten merken.

Könnte man beispielsweise die 12 letzten bearbeiteten Seiten anzeigen lassen? Global (server) oder lokal (client)? @kba

@zuphilip zuphilip assigned zuphilip and kba and unassigned zuphilip Apr 22, 2016
@kba
Copy link
Collaborator

kba commented Apr 22, 2016

Im Prinzip ist das möglich, ich wäre allerdings dafür, in Absprache einen manuellen Workflow für das Durcharbeiten der Seiten abzusprechen.Das Tool weiß im Moment nicht vieles, außer serverseitig die Korrektur-Formulare zu erzeugen, ausgefüllte Formulare in Verzeichnisse gemäß der Struktur der URL speichern und clientseitig die Texteingabe zu vereinfachen.

Hat man sie sich nicht gemerkt, wird es schwierig, genau die Seite wiederzufinden.

Das sollte in der Tat nicht passieren. Daher denke ich, dass es wichtig ist, sich vor Beginn der Transkription ein Minimum an Metadaten zu den Seiten elektronisch zu notieren (PPN oder Goobi section/id, Seitennummer, URL der Grafik). Das wäre ohnehin gerade in der Anfangsphase gut, um den Aufwand pro Seite abschätzen zu können und erste Auswertungen zu machen..

Wenn wir dann erkennen, dass Authentifizierung oder zusätzliche Tools die Arbeitsabläufe verbessern kann, dann können wir das ja nochmal im Detail besprechen.

Ich habe aber eine einfache Anpassung gemacht, mit der man sieht, was zuletzt bearbeitet wurde, pushe ich sobald es getestet ist.

@LetschM
Copy link
Author

LetschM commented Apr 22, 2016

Sehr gut. Also ich habe bisher immer mit der PPN gearbeitet, denke damit ist es am einfachsten, zumindest habe ich bisher auch die neu zu bearbeitenden Werke in Goobi immer über die PPN aus der Tabelle abgerufen. In der URL der einzelnen Dateien zu einer Seite in Goobi (hOCR/JPEG etc.) ist ja auch immer die PPN mit verpackt. Vielleicht kann man zu Beginn einfach die PPN per Copy/Paste in eine extra Textdatei kopieren. Oder wir könnten für die Metadaten auch ein einfaches Formular (PDF, Word-Vorlage o.ä.) bereitstellen, in dem man die Metadaten einheitlich ablegen und auch für weitere Zwecke -- - wie die Auswertungen - wieder extrahieren kann.

Ist mit der Anpassung von dir die Info auch noch da, nachdem man den Browser geschlossen hat? Bzw. kann man dafür - einfach mal blöd gefragt - irgendwie eine Art Cookie oder so einsetzen? Oder werden einfach immer alle oder x zuletzt bearbeiteten Seiten (egal von wem) angezeigt?

kba added a commit to kba/ocr-gt-tools that referenced this issue Apr 23, 2016
js: make cgiUrl configurable
request logging: expose via action=history
@BFallert
Copy link
Collaborator

BFallert commented May 3, 2016

Als zweite Lösung wird jetzt eine Liste der bereits erfassten Seiten einer PPN ausgegeben, unabhängig vom aktuellen Bearbeiter.

An der Optik wird gerade noch gearbeitet. Funktion ist aktuell nur im Branch feature-pagelist enthalten.

@BFallert
Copy link
Collaborator

BFallert commented May 4, 2016

Feature Pagelist wurde in master übernommen, Optik noch nicht angepasst.

@BFallert
Copy link
Collaborator

BFallert commented May 4, 2016

Wenn man nur weiss das von einer PPN Seiten erfasst wurden, aber keine Seitennummer hat, gibt es aktuell keine Möglichkeit (ohne das erzeugen eines weiteren Unterverzeichnisses) alle Seiten auflisten zu lassen.

Wenn man aber eine Seite weiss, können die weiteren Seiten mit dem Feature pagelist bequem erreicht werden.

Ohne bekannte Seite wird ggf. eine weitere Seite vorbereitet, aber z.B. aus Zeitgründen nicht weiter gefüllt. Diese Seite bleibt dann als nicht ausgeüllte Seite vorhanden, da sie via Web ja auch nicht gelöscht werden kann.

Irgenwie fehlt die Möglichkeit nur einen Index abrufen zu können

@kba
Copy link
Collaborator

kba commented May 4, 2016

Irgenwie fehlt die Möglichkeit nur einen Index abrufen zu können

Deswegen bin ich etwas zögerlich, was seitenübergreifende navigation angeht. Im Moment macht das Tool das Erfassen von Ground Truth sehr gut und sonst nichts. Im Sinne der UNIX-Philosophie ("Mach nur eine Sache, aber diese Sache gut") finde ich das auch ganz vernünftig.

Wenn man wirklich auf Werk-Ebene oder auf Sammlungs-Ebene navigieren will, dann sollten wir nochmal über das Backend (CGI-Skript) nachdenken, denn die Pfade sind schon sehr spezifisch, die URLs, die wir erwarten sind sehr spezifisch und vieles ist relativ adhoc gelöst. Können wir gerne, aber sollten wir planen.

BTW: Im Moment sieht das so aus:

sidebar-2016-05-04

kba added a commit to kba/ocr-gt-tools that referenced this issue May 4, 2016
js: make cgiUrl configurable
request logging: expose via action=history
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants