Feld PublicationState wird nicht verwendet

[j3nsch]

Das Feld PublicationState wird momentan nicht verwendet. Es muss geklärt werden wofür das Feld verwendet werden soll oder ob es entfernt werden kann.

[j3nsch]

Wir haben uns das Feld "PublicationState" mal etwas genauer in der Datenbank angeschaut.

• Es wird nur einmal beim Anlegen des Dokuments gefüllt mit dem Status "draft". Danach wird der Status nicht mehr geändert.
• Der aktuelle Dokumentenstatus wird über das Feld "server_state" abgebildet I- n der Administration gibt es keine Möglichkeit den Status im Feld "PublicationState" zu ändern.

Es ist für uns jedoch fraglich, für was man dieses Feld verwenden soll. Als möglichen Einsatz können wir uns eine Versionierung des Dokuments vorstellen.

Im Publishformular haben wir derzeit keinen einzigen Fall, wo dieses Feld verwendet wird.

Die Auslieferung von PublicationState über OAI macht nur Sinn, wenn damit eine Aussage zum Dokument getroffen wird. Warscheinlich ist hier auch die Betrachtung des Workflows erforderlich. z.B. Möchte man den Entwurf der Allgemeinheit zur Verfügung stellen oder möchte man den Entwurf an die DNB geben. Wenn nicht, bekommt das Dokument eine URN?

[j3nsch]

Die DINI schreibt dazu in den Vorgaben für das Zertifikat 2013:

A.2.4 Sets nach Publikationsstatus

In Open-Access-Repositorien und ‑Publikationsdiensten finden sich Versionen von Dokumenten, die unterschiedlichen Stufen im Veröffentlichungsprozess zuzuordnen sind. Zwischen diesem Status und der inhaltlichen Qualität des einzelnen Dokumentes kann ein Zusammenhang bestehen. Unter anderem deshalb ist eine grobe Kennzeichnung sinnvoll, die über den Status bzw. die Version im Publikationsprozess Auskunft gibt. Da in unterschiedlichen Wissenschaftsbereichen auch unterschiedliche Verfahren der inhaltlichen Bewertung und Qualitätssicherung von Publikationen angewandt werden, wird für diese Set-Struktur lediglich eine sehr grobe Unterscheidung hinsichtlich des Begutachtungsstatus zugrunde gelegt, die sowohl Peer Review als auch andere Begutachtungsverfahren wie etwa das Editorial Review mit einbezieht. Die Set-Struktur übernimmt genau die Vorgaben des Version Vocabulary der DRIVER-Guidelines.

Empfehlung

E.A.2-1 Es existiert eine Set-Struktur wie in Tabelle 3 abgebildet, in die alle Metadatensätze gemäß dem jeweiligen Status im Publikationsprozess
der zugehörigen Dokumente eingeordnet sind.

Tabelle 3: Bezeichnung und Beschreibung der Sets für den Begutachtungsstatus

setSpec | setName | Deutschsprachige Beschreibung -- | -- | -- status-type:draft | draft version | Eine frühere Version, die als in Arbeit befindlich in Umlauf gesetzt wurde. status-type:submittedVersion | submitted version | Die Version, die bei einer Zeitschrift eingereicht wurde, um durch Fachleute begutachtet zu werden. status-type:acceptedVersion | accepted version | Die Version, die vom Autor /der Autorin erstellt wurde, in die die Anmerkungen der Gutachter/‑innen eingeflossen sind und die zur Veröffentlichung angenommen wurde. status-type:publishedVersion | published version | Die Version, die veröffentlicht wurde. status-type:updatedVersion | updated version | Eine Version, die seit der Veröffentlichung aktualisiert wurde.

[j3nsch]

Danke. Das klingt als ob das Feld durchaus einen Sinn haben könnte. Wir sollten in diesem Monat eine Entscheidung bezüglich des Feldes treffen, damit klar ist, ob es bei der weiteren Entwicklung berücksichtigt werden muss.

Gibt es bei den gehosteten Instanzen Systeme die dieses Einteilung nach Status nachbilden, z.B. Collections oder Enrichments?

Momentan sehe ich das Feld als eines, daß im Modell vorhanden ist und wieder erreichbar gemacht werden kann, aber keine spezielle Funktion in OPUS hat (anders als server_state). Es ist einfach eine weitere Information, die anscheinend als OAI sets abgebildet werden sollte, ähnlich wie DocumentType.

[j3nsch]

Ich denke der Unterschied zwischen ServerState und PublicationState ist folgender. Der Status eines Dokuments im internen Workflow wird in ServerState dargestellt, also zum Beispiel, ob ein Dokument geprüft wurde (Audited). Das Feld PublicationState hingegen steht für den externen Status eines Dokuments, also ob ein Artikel eingereicht, aber noch nicht veröffentlicht wurde.

Anscheinend sind die Instanzen bisher ohne PublicationState ausgekommen. Sind Euch Mechanismen bekannt, die von OPUS 4 Repositorien eingesetzt werden, um dieses Feld "nachzubilden"? Das könnten z.B. ein Dokumenttyp "draft" sein, spezielle Sammlungen oder Enrichments.

[j3nsch]

Die korrekten Werte (DINI) für das Feld PublicationState lauten:

draft submittedVersion acceptedVersion publishedVersion updatedVersion

[j3nsch]

Wenn wir PublicationState verwenden wollen, muss das im Publish-Formular berücksichtigt werden.

Das Feld muss dann auch in OAI berücksichtigt werden.

Das Feld ServerState sollte wie folgt in den Export via XMetaDissPlus aufgenommen werden:

Element in XMetaDissPlus lautet "dini:version_driver"

Beispiel:

preprint draft

[j3nsch]

Aus der Beschreibung von XMetaDissPlus (Version 2.2, Stand: 21.02.2012):

Bezeichnung: dini:version_driver Attribut: obligatorisch: driver:VERSIONType (draft, submittedVersion, acceptedVersion, publishedVersion, updatedVersion) Kardinalität: 0..1 Beschreibung Inhalt: Das Element dient zur Festlegung des Status der Hochschulschrift. Hinweis: Für die Anwendung sollten die Empfehlungen im „Gemeinsamen Vokabular für Publikations- und Dokumenttypen“ beachtet werden. XML-Syntax: Status der Publikation aus dem „Gemeinsamen Vokabular für Publikations- und Dokumenttypen“</dini:version_driver> Beispiel: draft</dini:version_driver>

Brauchen wir das oder nicht? Wenn ja dann wäre das Feld dafür PublicationState. Wenn nein, dann sollten wir ganz klar in der Dokumentation sagen warum es "nicht" bzw. "momentan nicht" unterstützt wird.

[j3nsch]

Dokumententypen dürfen Werte für PublicationState nicht frei definieren

Der Dokumententyp all enthält momentan auch das Feld PublicationState mit zwei möglichen Werten. Das Framework und die Datenbank lassen nur bestimmte Werte zu. Die in einem Dokumententyp definierten Werte müssen nicht unbedingt passen, was dann zu einem Fehler führen würde.

Das Feld PublicationState für einen DokumentenType sollte entweder die möglichen Werte aus dem Framework beziehen, oder vom DokumentenTyp all entfernt und (falls das möglich ist) für die Verwendung in Dokumententypen gesperrt werden.

[alw-bsz]

Wir hosten einzelne Repositorien, in denen der Publikationsstatus über Enrichment-Felder oder Sammlungen abgebildet wird. Das könnte man auf PublicationState umstellen, daher wäre ich dafür, das Feld vollständig zu implementieren.

[alw-bsz]

Verwendet werden sollten die bei DINI definierten Werte, also draft submittedVersion acceptedVersion publishedVersion updatedVersion

und nicht jene, die derzeit in der Datenbank festgelegt sind.

[j3nsch]

Gut. Wo soll das Feld auftauchen (Formulare, Ausgabe, Export)? Wie soll es verwendet werden, hat es einen Einfluss auf Workflow, Zugriff, usw. oder ist es ein "einfaches" Feld, dass nur der Information dient?

[alw-bsz]

Das Feld ist hauptsächlich ein "einfaches" Feld, das nur der Information dient. Es soll in die Publish-Formulare implementiert und als Metadatum auf der Frontdoor angezeigt werden. XMetaDissPlus sieht den Export des Metadatums vor. Das Feld soll als Facette in der Trefferliste verwendet können. Es steuert keine Workflows und keine Zugriffe.

[j3nsch]

Das Feld existiert bereits in der Datenbank und im Datenmodell. Da muss nichts gemacht werden.

Im Metadaten-Formular der Administration kann es relativ einfach hinzugefügt werden. Wo wäre ein guter Platz dafür?

Die Integration ins Publish-Formular ist komplizierter, weil sich die notwendigen Änderungen über eine Reihe von Klassen verteilen. Das wäre der Hauptgrund die Umsetzung nach hinten zu schieben.

Die Abbildung als Facette erfordert ein Update des Solr-Schema und des XSLT für die Indexierung. Ich gehe davon aus, dass PublicationState bereits im internen OPUS 4-XML auftaucht. Die Facette braucht Default-Übersetzungen.

Es wäre gut, wenn die folgenden Aufgaben vom BSZ erledigt werden könnten.

• Die Anzeige in der Frontdoor ist auch relativ einfach, durch eine Erweiterung des XSLT.
• Um die Ausgabe in XMetaDissPlus würde ich mich nicht kümmern.

Die Änderungen dürfen nicht mit anderen Issues vermischt werden und brauchen separate Pull Requests.

[alw-bsz]

Wir kümmern uns gern um die Implementierung in die Frontdoor und die Exportformate sowie um die Übersetzungen. Wir können auch den Einbau in die Publish-Templates übernehmen, wenn das Feld für diese verfügbar gemacht worden ist.

Im Metadaten-Formular in der Administration ist m.E. am Ende des Abschnitts "Bibliographische Informationen" ein guter Platz - entweder noch innerhalb des Abschnitts (also nach "Gehört zur Bibliographie") oder als eigener Abschnitt "Version / Begutachtungsstatus".

[j3nsch]

Ihr könnt gerne mit Euren Teilen am BSZ anfangen. Ich kann vielleicht die Integration im Metadaten-Formular kurzfristig vornehmen. Die Umsetzung im Code des Publish-Formular kann ich mir anschauen, wenn alles andere für OPUS 4.8.1 erledigt ist.

[j3nsch]

Es muss auch noch über das Update von Instanzen nachgedacht werden, die für dieses Feld momentan ein Enrichment verwenden. Wird das manuell direkt in der Datenbank übertragen oder sollte/kann es dafür ein Update-Skript geben?

Wir müssen uns auch überlegen, wie wir damit umgehen, dass für alle Dokumente in der Regel momentan draft in der Datenbank steht. Müssen wir NULL mit in die möglichen Werte aufnehmen?

[alw-bsz]

Bei uns werden bislang nur in wenigen Instanzen Enrichment-Felder für diese Info verwendet. Das können wir manuell umziehen; ein Update-Script ist dafür nicht erforderlich.

NULL sollte erlaubt und auch der Default-Wert sein.

[alw-bsz]

Ich hätte vermutet, dass alle bestehenden Datensätze den Publication State draft haben, weil man den Wert bislang nicht über die GUI ändern kann. Wir haben allerdings eine ganze Reihe an Instanzen, die größere Mengen an Datensätzen mit dem Status published enthalten. Da wir diese Eintragungen sicher nicht auf Datenbank-Ebene vorgenommen haben, muss die Ursache eine andere sein.

Spontan vermute ich, dass es sich bei den published-Datensätzen um jene handelt, die vorhanden waren, als man von OPUS 3 auf OPUS 4 migriert ist. Das muss ich aber noch genauer analysieren.

[j3nsch]

Ja, ich werde die Datenbank anpassen und es wird ein Update-Skript geben, dass DRAFT in NULL umwandelt. Den Umgang mit anderen vorhandenen Werten könnt Ihr Euch noch überlegen.

FYI @stconradr, @vgerlach

[j3nsch]

Auf dem Branch publicationState814 gibt es jetzt ein erstes einfaches Formularelement, dass in das Metadaten-Formular in der Administration integriert ist. Es ist noch nicht weiter getestet. Das Feld PublicationState hat bereits Übersetzungen, aber nicht die Werte.

[j3nsch]

PublicationState lässt sich jetzt in der Administration auswählen und speichern. NULL ist auch möglich. Es gibt noch kein Updateskript, um den Wert für existierende Dokumente automatisch zu setzen.

[j3nsch]

Wir könnten das Update interaktiv machen und fragen, ob alle Dokumente mit draft auf NULL gesetzt werden sollen.

[j3nsch]

Beim Update wird zuerst die Datenbank aktualisiert und dann werden die restlichen Update-Skripte ausgeführt. Da wir die zulässigen Werte für PublicationState in der Datenbank ändern, würden Dokumente mit anderen Werten als draft auf NULL bzw. einen leeren String gesetzt. Wir hatten schon mal einen Fall wo Update-Schritte vor der Aktualisierung der Datenbank ausgeführt werden müssen. Das war aber ein Hack. Bislang gibt es dafür kein allgemeines Pattern im Code.

[alw-bsz]

Wir könnten das Update interaktiv machen und fragen, ob alle Dokumente mit draft auf NULL gesetzt werden sollen.

Die Interaktivität ist für uns nicht erforderlich, vielleicht aber für Selbstbetreiber hilfreich (so sie denn an dem Feld geschraubt oder es direkt in der Datenbank anderweitig belegt haben sollten).

[j3nsch]

FYI @alw-bsz, @stconradr

Die auf PublicationState basierenden OAI-Sets (DRIVER für DINI 2022) sind noch offen. Für die OAI-Formate und die Frontdoor gibt es Tickets, die dem BSZ zugewiesen sind. Das Publish-Formular ist noch offen.

Es gibt eine neue Option, um Werte von der Nutzung in Formularen auszuschließen. Ausgeschlossene Werte werden im Metadaten-Formular angezeigt, wenn sie vom Dokument verwendet werden. Ein anderer Wert kann dann, muss aber nicht ausgewählt werden.

model.document.fields.PublicationState.excludeValues

Indizierung, Facette, Übersetzungen sind umgesetzt.

Ihr könnt hier festhalten, was Euch noch auffällt.

[alw-bsz]

Ich habe die Übersetzungen etwas überarbeitet ("Version" statt "Status"). Ich denke, das ist etwas besser verständlich. "Status" bezieht sich eher auf den Begutachtungsstatus, was nicht falsch, aber zu eng gefasst ist. Alternativ könnte man auf Deutsch auch "Fassung" verwenden.

[j3nsch]

Erledigt. Das Feld PublicationState ist nun verwendbar. @alw-bsz, @stconradr Probleme bitte melden.