[Kobv-opus-tester] Dev: Benutzerdefinierte Felder, Opus anpassen

Jens Schwidder schwidder at zib.de
Di Mär 7 15:42:01 CET 2017


Lieber Herr Hofer,

die Dokumentation hat leider wirklich noch einige Löcher, insbesondere 
für Entwickler. Das ist uns nicht egal, aber die Kapazität hier ist doch 
begrenzt. Dadurch, dass die Dokumentation jetzt auf GitHub gehostet 
wird, bietet sich zumindest theoretisch die Möglichkeit die Arbeit zu 
verteilen, was vorher mit dem PDF Handbuch nicht möglich war.

Updates über Git sind im Fall von OPUS sehr sinnvoll, da es häufig 
lokale Anpassungen gibt. Jede Instanz ist also im Prinzip ein Fork.

Ein Fork auf GitHub ist auf jeden Fall nicht verkehrt. Den kann man auch 
schon verwenden, wenn man nur kleinere Anpassungen vornimmt. Auf diese 
Weise lassen sich dann auch die Merges mit neuen Versionen gut managen.

Wir bemühen uns immer mehr Aspekte von OPUS konfigurierbar zu machen, so 
dass die Wahrscheinlichkeit von Konflikten geringer wird, aber bei 
größeren Modifikationen sollten wir uns unbedingt vorab verständigen.

Falls Sie in die OPUS 4 Entwicklung einsteigen, sollten wir Ihre Themen 
vielleicht als Issues auf GitHub festhalten. Evtl. wäre es auch 
sinnvoll, wenn Sie einen Account für unser JIRA bekommen. GitHub bietet 
viele gute Tools, aber die Ticketverwaltung ist mit JIRA doch noch 
besser. Unser JIRA ist nicht offen, aber ein Account sollte kein Problem 
sein und dort bekommt man einen besseren Überblick über die vielen 
offenen Aufgaben für OPUS (ca. 500 Tickets, eigentlich mehr).

Welche Anpassungen stellen Sie sich vor? Für zusätzliche Informationen 
zu Dokumenten gibt es Enrichments. Diese werden momentan aber noch nicht 
indiziert. Das ist geplant.

Für die Personen arbeiten wir an umfangreichen Änderungen für OPUS 4.7.
Insbesondere dort wäre es interessant Ihre Anforderungen mit unseren 
Plänen zu vergleichen. Wir planen unter anderem ein übergeordnetes 
Personenobjekt und ein Management für Personen in der Administration 
einzuführen.

Momentan arbeiten wir aber noch an OPUS 4.6. Dort geht es um eine SWORD 
Schnittstelle, Anpassungen für DINI 2016, mehr Transparenz bei der 
Indizierung, BibTeX/RIS Export für Suchergebnisse und viele weitere 
Kleinigkeiten und Bug Fixes.

Welche Felder möchten sie als Pflicht markieren und wo? Geht es um das 
Publish-Formular, die Administration oder die Datenbank?

Tiefgehende Änderungen werden sehr wahrscheinlich zu Konflikten führen. 
Es ist leider nicht möglich die restliche OPUS Entwicklung einzufrieren 
und erst einmal nur am "Fundament" zu arbeiten, obwohl ich das gerne würde.

Das Framework, das Datenmodell usw. werden sich langsam, schrittweise 
verändern. OPUS wir immer unabhängiger von SQL werden, bis irgendwann 
der Punkt erreicht ist, wo es evtl. möglich sein wird das Framework 
auszutauschen. Diese Pläne sollten natürlich öffentlich dokumentiert 
werden, aber vieles ist noch sehr früh in der Planung und bisher gab es 
nur sehr wenig externe Entwicklung. Das Framework Package wird zerlegt 
werden, mindestens in einen Kern, die Suche und die Datenbankanbindung.

In der Applikation wird es auch immer wieder Aufräumarbeiten geben. Es 
kann also durchaus sein, das Code verschwindet, verschoben wird oder auf 
einem völlig anders aussieht. Wie gesagt, es gibt noch viele offene 
Baustellen.

Ich denke nicht, dass wir irgendwann zu einem völlig freien Datenmodell 
wechseln werden. Dafür ist OPUS nicht gedacht, aber es gibt noch Luft 
für Verbesserungen und mehr Flexiblität.

Ich würde vorschlagen, die einzelnen Themen als Issues festzuhalten, 
entweder in unserem Git Repository oder in Ihrem Fork, und dort weiter 
zu diskutieren. Gerne aber auch hier. Ich benötige die Details, um das 
"Konfliktpotential" besser einschätzen zu können. :-)

Viele Grüße
Jens Schwidder



On 06.03.2017 17:09, Robert Hofer wrote:
> Liebe Kollegen der Opus-Mailingliste,
>
> bin erst seit kurzem dabei mich mit Opus als Entwickler auseinander zu
> setzen. Installation und viele andere Dinge konnte ich mit der Doku
> bereits lösen/klären.
>
> Aber bei den folgenden Themen werde ich nicht fündig:
>
>   * Wir benötigen benutzerdefinierte Felder bei Personen, Dokumenten usw.
>   * Wir wollen mehr Felder als Pflicht deklarieren.
>
> Das ist ein Problem im Zusammenhang damit, dass wir Opus in Zukunft auch
> (über git) updaten wollen. (Falls es dazu Doku gibt, habe ich das wohl
> übersehen. Tut mir leid, falls das der Fall ist!)
>
> Das einzige was mir dazu jetzt einfällt ist, das git Projekt forken,
> daran weiter zu entwickeln und hoffen, dass es nicht allzu oft zu
> Konflikten mit dem Original kommt.
>
> Bin für jeden Hinweis, und sei es nur ein Link auf eine Doku ;-), dankbar!
>
> Liebe Grüße aus Wien!
>
> Robert Hofer
>
> --
>
> *Robert Hofer*
> Senior Developer
> Technikum Wien GmbH
>
> Höchstädtplatz 6, 1200 Wien
> <https://maps.google.com/?q=H%C3%B6chst%C3%A4dtplatz+6%2C+1200+Wien%2C+%C3%96sterreich&z=10>
> T: +43 1 333 40 77-442 <tel:+4313334077442>
> E: robert.hofer at technikum-wien.at <mailto:robert.hofer at technikum-wien.at>
> I: academy.technikum-wien.at <https://academy.technikum-wien.at>
> I: alumni.technikum-wien.at <https://alumni.technikum-wien.at>
>
>
>
> --
> Kobv-opus-tester mailing list
> Kobv-opus-tester at zib.de
> http://listserv.zib.de/mailman/listinfo/kobv-opus-tester
>

-- 
==============================================================
Jens Schwidder
Kooperativer Bibliotheksverbund Berlin-Brandenburg (KOBV)
c/o Konrad-Zuse-Zentrum für Informationstechnik Berlin (ZIB)
Takustr. 7, D-14195 Berlin
Telefon: (030) 841 85 - 308
Telefax: (030) 841 85 - 269
  E-Mail: schwidder at zib.de
     WWW: http://www.kobv.de
==============================================================



Mehr Informationen über die Mailingliste Kobv-opus-tester