-
Notifications
You must be signed in to change notification settings - Fork 5
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
Bewertung: Unterscheidung zwischen Mapping und Relation #667
Comments
Mir ist etwas aufgefallen: Wenn ein Mapping bewertet wird, dann gilt diese Bewertung ja für das Mapping in dem Moment. Wenn jedoch danach das Mapping verändert wird, ist nicht ersichtlich, dass die Bewertung eigentlich auf die vorherige Version des Mappings bezogen ist. (Selbst wenn man unterscheidet zwischen Bewertung der Konzepte des Mappings und Bewertung der Relation, bleibt das Problem bestehen.) Wie gehen wir damit um? Könnte man z.B. in der Bewertung eine Zusatzinformation speichern (z.B. einen Content Hash), anhand der wir ermitteln können, ob sich das Mapping seitdem geändert hat, und falls das der Fall ist, wird die Bewertung anders gehandhabt? Ich kann mir noch nicht so richtig vorstellen, wie man mit diesem Problem vernünftig umgeht. Man bräuchte dann ja auch eine Möglichkeit, dass der bewertenden Person angezeigt wird, welche Mappings, die sie bewertet hat, sich seitdem geändert haben, damit sie ihre Bewertung überarbeiten kann. |
Aus meiner Praxis kann ich berichten, dass ich bisher meine Mappings, die negativ bewertet wurden, genau aus diesem Grund immer gelöscht und komplett neu angelegt habe. Das ist aber natürlich keine so elegante Methode. Grundsätzlich fände ich es toll, wenn man sich überhaupt eine Liste anzeigen lassen könnte, die alle eigenen Mappings und Bewertungen übersichtlich (also am besten auf einer Seite z.B. 50 Einträge pro Seite) enthält. Wenn man so etwas hätte, könnte man an dieser Stelle vielleicht anzeigen, welche der eigenen Bewertungen überarbeitet werden müssen. Also so eine Art Dashboard. Weiß jetzt nicht, ob das zu weit geht, aber ich stelle das mal zur Diskussion :-). |
Ist es möglich, dass die Bewertung verfällt sobald das Mapping geändert abgespeichert wurde? Ich stimme David zu, aber vielleicht geht es auch ohne Dashboard (wobei ich solche Funktionen sehr schätze). Eine Übersicht der Mappings einer Person gibt es ja schon, aber darin noch ein Filter auf Bewertungen (nicht bewertet / bewertet und wenn möglich auch positiv bewertet / negativ bewertet) würde hoffentlich einen ähnlichen Zweck erfüllen. |
Ich befürworte dass Bewertungen automatisch gelöscht werden, sobald sich das Mapping inhaltlich ändern (Mapping-Typ und/oder in from/to gelisteten Konzepte). Bewertungen sind ja nicht für die Ewigkeit gedacht sondern Arbeitsmittel. |
@nichtich Genau das hatte ich gemeint. 👍 Das sollte dann serverseitig (also in jskos-server) getan werden, denke ich, wobei ich die Bewertungen nicht löschen, sondern invalidieren würde (man kann dann darüber debattieren, ob sie dann in Cocoda gar nicht mehr gezeigt werden oder ausgegraut mit Hinweis, dass sich das Mapping seitdem inhaltlich geändert hat). Jetzt ist nur noch die eigentliche Frage offen: Können wir die Bewertungen so anpassen, dass man das Mapping (also die Konzepte) und die Relation des Mappings unabhängig bewerten kann? Soweit ich das sehe, ist das bisher im Datenmodell der Bewertungen nicht vorgesehen. |
Nein, das ist bisher nicht vorgesehen und ich denke das würde zu kompliziert. Reicht es nicht das Mapping insgesamt zu bewerten und ein alternatives Mapping zu erstellen? |
Ich finde mittlerweile auch, dass es nur eine Möglichkeit geben sollte, das Mapping zu bewerten, also so, wie es jetzt ist. Wie @nichtich sagt, finde ich auch, dass nach einer negativen Bewertung einfach ein alternatives Mapping angelegt werden kann. Allerdings bleibt dann das Problem offen, dass, wenn ein als "falsch" befundenes Mapping sich in einer Konkordanz befindet, das alternative Mapping für die Nachnutzung im DA und coli-rich nur dann etwas nützt, wenn es auch in dieselbe oder zumindest in eine separate Konkordanz gespeichert werden kann. |
Also was wir letztendlich wollen, ist eine (optionale) Erklärung zu einer negativen Bewertung, und zwar aus einer Menge von vordefinierten Optionen. (Freitext müsste man moderieren, daher will man das eher vermeiden.) Eine dieser Optionen wäre dann "Mapping-Typ ist falsch". Der Workflow wäre dann so, dass ich als Ersteller eines Mappings meine negativ bewerteten Mappings abarbeiten kann und hoffentlich sehe, was genau an dem Mapping falsch ist. Wenn ich nun mein Mapping bearbeite (sei es den Mapping-Typ anpassen oder das Zielkonzept), ändert sich der sogenannte Content Identifier des Mappings. Über diesen können nun die vorherigen Bewertungen als veraltetet markiert werden (siehe auch #687). Unsere Idee ist, dass ich als Mapping-Ersteller dann diese veralteten Bewertungen entfernen kann, da sie sich ja auf eine nicht mehr aktuelle Version des Mappings beziehen. So müsste die bewertende Person selbst nichts mehr unternehmen. Offen ist noch, ob dies komplett ohne Account möglich sein wird (wodurch wieder neue Fragen entstehen), oder ob man alternativ die Login-Möglichkeiten noch erweitert, dass man sich z.B. mit einem Bibliotheksaccount einloggen kann. Zum Datenformat siehe gbv/jskos-server#194. |
Client implementation for gbv/jskos-server#194.
Unterscheiden zwischen der Bewertung von Mapping oder Relation ermöglichen
The text was updated successfully, but these errors were encountered: