Konferenzfelder zum Datenmodell hinzufügen

[j3nsch]

Bisher werden häufig Enrichment-Felder hinzugefügt, um Dokumente mit Konferenzen verknüpfen zu können.

• Konferenzname
• Konferenzort
• Beginndatum der Konferenz
• Enddatum der Konferenz

TODO Es muss erfasst werden, welche Anforderungen im Zusammenhang mit diesen Feldern existieren.

Wie werden die Felder angezeigt? In Exports ausgegeben? Werden sie für die Suche verwendet? Was sind die Key-Namen der Enrichments?

Da die Felder bereits als Enrichments verwendet werden, sind sie vielleicht nicht ideale Kandidaten, um neue Konzepte im Framework auszuprobieren. Welchen Vorteil hat die Umwandlung in "richtige" Felder?

[j3nsch]

@stconradr Ergänze mal bitte.

Ist der Punkt, dass man die Enrichments dann nicht mehr konfigurieren müsste, die einzige Verbesserung, die wir durch eine Umstellung erreichen würden? Wenn ja, dann würde ich hiermit warten bis wir die alten Enrichments abschaffen.

[j3nsch]

Wenn man beschließt die Änderungen vorzunehmen macht es vielleicht Sinn, die vier Felder in einem Objekt "Konferenz" zusammen zu fassen.

[stconradr]

Wo werden die Felder genutzt? Die Konferenzfelder werden in der Frontdoor angezeigt und bei XMetaDissPlus für den Typ "conferenceobject" als Angabe bei dc:source benutzt. Existieren diese Felder, so wird dc:source daraus zusammengebaut. Alternativ gibt es ein Metadatenfeld "Quelle", wo die Informationen kummuliert eingetragen und dann für dc:source verwendet werden.

Wie werden die Felder angezeigt? Im Publishformular und in der Frontdoor. Bei den Betreibern unterschiedlich übersetzt, mitunter als Veranstaltungsort, etc, oder als Konferenzort

In Exports ausgegeben? Ja, bei XMetaDissPlus und beim XML-Export.

Werden sie für die Suche verwendet? Beim KOBV-Hosting bisher nicht.

Was sind die Key-Namen der Enrichments? Leider unterschiedlich. z.B. eventName - Veranstaltungsname ; ConferenceName - Konferenztitel oder eventPlace - Veranstaltungsort; ConferencePlace - Konferenzort oder eventStart , eventEnd - Beginndatum bzw. Enddatum der Veranstaltung; ConferenceDate -Konferenzdatum

[j3nsch]

Die Alternative "Quelle" nützt hier nichts ohne zusätzliche Informationen. Warum wird das alternative Feld verwendet? Ist es relevant hier?

Geht es nur um Konferenzen oder wäre ein Event-Objekt sinnvoller? Der Typ "conferenceobject" deutet ja darauf hin, dass es nur um Konferenzen geht, aber wir wollen später nicht lauter parallele Felder für andere Event-Typen anlegen müssen.

Also

• Conference - Name, Place, StartDate, EndDate

oder

• Event - Name, Place, Type, StartDate, EndDate

Ich neige dazu StartDate und EndDate und nicht nur Start und End zu bevorzugen.

Müssen wir damit rechnen, dass ein Dokument mit mehr als einem Event verknüpft werden muss?

Vorsicht! Wir wollen nicht "vorsichtshalber" ein System bauen das alles und Kaffee kochen kann. Wenn es keine bekannten Use Cases für andere oder mehrere Events gibt, dann bauen wir jetzt die einfache Lösung.

@alw-bsz Wie ist Eure Einschätzung?

Für mich geht es im Augenblick darum neue Ideen bei der Implementation des Frameworks auszuprobieren. Gibt es andere Gründe diese Felder in das Standardmodell zu heben? Wir dürfen auch nicht die Folgen vergessen. Als Standardfelder, wo kommt das hin im Metadatenformular? Wenn wir in Zukunft alle möglichen Felder direkt unterstützen und nicht nur als Enrichments, wächst das Formular immer weiter.

[j3nsch]

Vielleicht noch kurz für das Verständnis zu den Plänen für Enrichments. Genaueres wird es in den jeweiligen Issues geben. Ob ich es Enrichments oder "Custom Field" bzw. "Anwenderdefiniertes Feld" nenne ist letztendlich egal. Es geht darum, das was Enrichments im Augenblick bieten, anders zu implementieren. Warum? Um das Datenbankschema zu vereinfachen und weil im neuen Framework die Standardfelder flexibler werden. Der Abstand zu den Enrichments wird damit immer geringer, bis der einzige Unterschied sein wird, dass Standardfelder nicht entfernt werden können.

Ich denke neue CustomFields (formerly known as Enrichments) werden per Default im gleichen Bereich des Metadaten-Formulars landen. Vielleicht benennen wir die "Enrichments" Sektion in "Miscellaneous" um. Man könnte aber auch eine "Konferenz" Sektion definieren oder evtl. sogar neue Felder zu anderen existierenden Sektion hinzufügen, alles über die Konfiguration. Ich halte das für machbar und die Grundlagen dafür ergeben sich aus der Neuimplementation des Frameworks. Es geht dabei vor allem auch darum die Weiterentwicklung zu vereinfachen.

[stconradr]

Bisher sind wir mit den Feldern als Enrichmentfelder ausgekommen. Die Betreiber, die diese Konferenzfelder nicht angefordert haben, verwenden entweder "TitelParent" als Bezugsfeld zur Konferenz oder das Feld "Quelle".

Die Verwendung der Enrichmentfelder, entsprang bei einigen Betreibern wahrscheinlich dem Wunsch, bei "conferenceobject" eine eigene Bezeichnung für den Namen der Konferenz und nicht TitleParent zu benutzen. Darüberhinaus auch den Konferenzort (der nicht Verlagsort ist) sowie das Datum anzugeben, da dafür keine eigenen Felder bestehen.

Wenn die Felder ins Standardmodell aufgenommen werden sollten, dann hätte es den Vorteil, dass man es perspektivisch einheitlich gestalten kann. Dann gerne mit der Bezeichnung:

Conference - Name, Place, StartDate, EndDate

Es reicht aber auch die Lösung als Enrichmentfelder.

Eine Mehrfachbelegung ist sicher nicht erforderlich.

[alw-bsz]

Aus unserer Sicht sollte es für die Angaben zu Konferenzen Standardfelder geben. Das hätte den Vorteil, dass die Daten in allen OPUS-Instanzen von Anfang an einheitlich erfasst und weiterverarbeitet, z.B. exportiert, werden.

Optimal wäre ein wiederholbares Konferenzobjekt mit den bereits genannten Feldern Name, Place, StartDate, EndDate. Darüber hinaus gibt es Bestrebungen, eindeutige Identifier für Konferenzen zu etablieren, beispielsweise von Crossref und DataCite (https://www.crossref.org/working-groups/conferences-projects/). Daher sollte ggf. auch die Erfassung einer ID vorgesehen werden.

[j3nsch]

Danke, Ihr seht also wirklich Bedarf für ein wiederholbares Feld? Das ist natürlich machbar. Der Aufwand liegt nicht wirklich in der Datenbank, sondern das User Interface ist aufwendiger für eine wiederholbares Feld.

Einzelne Attribute wie ConferenceId kann man gleich oder später hinzufügen. Wenn alles klappt, werden Erweiterungen des Datenmodells in Zukunft wesentlich einfacher sein und keine Änderungen an der Datenbank erfordern.

Ich denke ich werde Conference als zweiten "Test" nehmen, wenn FundingReference umgesetzt ist. Dann hat man zwei Felder, die nach dem neuen Konzept funktionieren und kann besser einschätzen wo es noch Schwierigkeiten gibt.

Auf der Datenbank-Ebene wird das vermutlich in die 4.8 einfließen, um zu klären, ob das ein gangbarer Weg ist. Im User Interface wird es erst später kommen, vielleicht mit 5.0.

[alw-bsz]

Die Wiederholbarkeit ist nicht zwingend, da sie nur selten gebraucht werden würde. Aber es gibt (oder gab es zumindest vor Corona ...) gemeinsame Konferenzen ("Joint conferences - two or more conferences share the conference venue and also integrate the conference program, which is also open to all attendees."). Diese könnte man über ein wiederholbares Feld sauber abbilden.

Ich denke, dass es die ConferenceId für den Anfang noch nicht braucht. Nach meinem Eindruck haben sich Identifier für Konferenzen bislang nicht etabliert.

Kann man das ID-Feld flexibel gestalten, d.h. trennen in "Art des Identifiers" (z.B. "DOI") und den Value? Das wäre auch an anderen Stellen hilfreich, z.B. bei der Personenverwaltung. Auf dem Gebiet der Identifier ist zum einen noch einiges in Entwicklung und teils noch nicht absehbar, was sich am Ende durchsetzt, zum anderen haben unsere Anwender Bedarfe für weitere Identfiier.

[j3nsch]

Gut, ich denke die Umwandlung in ein wiederholbares Feld wird später möglich sein. Es spielt eigentlich erst dann eine Rolle, wenn das User Interface umgesetzt wird. In der Datenbank wird es in Zukunft, zumindest nach meinen Plänen, kaum einen Unterschied machen.

Ja, es gibt einige offene Fragen zum Thema Identifier. Ich bin dabei das in Issues zu formulieren. Bei den Typen von Identifieren kann man mindestens zwischen zwei Varianten der Umsetzung wählen. Bei Personen haben wir für drei Identifier-Typen, jeweils ein separates Feld. Bei den Dokumenten haben wir Identifier mit Type-Property. Beides hat Vor- und Nachteile. Wir warten mal ab. Mit dem neuen Design sollte es keine große Rolle spielen.