JusCMS Contens Meeting 2010-04-15

JusCMS,MPDL =Treffen / Workshop mit Contens zur technischen Feinplanung=

Zeit: 15.04.2010, 11:00 - 14:00 Uhr

Ort: MPI für Geistiges Eigentum, Wettbewerbs- und Steuerrecht, München, Raum 225a

Teilnehmer: Frau Arndt, Herr Hoppe (Contens), Herr Karlic (Contens), Frau Kortüm (zeitweise) Agenda:
 * Erläuterung der Umsetzung der eSicDoc-items in Contens-Objekte im Contens 3-Testsystem
 * Klärung Fragen Contens zu den eSciDoc/PubMan-Export-Beispieldaten
 * Klärung genereller Fragen von Seiten Institute / MPDL
 * Besprechung Projektplan (erstellt durch Contens)
 * Sonstiges
 * ToDos

Erläuterung der Umsetzung der eSicDoc-items in Contens-Objekte im Contens 3-Testsystem

 * Die Objekte inkl. Subobjekte wurden manuell erzeugt
 * es war Ziel, die Objektstruktur von eSciDoc möglichst genau abzubilden
 * die Verschachtelung der Objekte ist keine Contens-seitige Notwendigkeit- im Gegenteil (s. Fazit nächster Abschnitt).

Klärung Fragen Contens zu den eSciDoc/PubMan-Export-Beispieldaten
 Fragen seitens CONTENS: 
 * Werden die alternativen Titel als Subobjekte benötigt?
 * Ergebnis: aktuell nicht.


 * Welches ist die eindeutige ID der Publikation? Dies ist wichtig für die Zuordnung bei Updates und zur Überprüfung, ob es Änderungen gegeben hat.
 * Ergebnis: Feld wurde im eSciDoc-XML-Export gezeigt. Hr. Karlic klärt, ob dies die Frage des Programmierers beantwortet.


 * Wird das type-Attribut für das Element dcterms:issued benötigt oder ist dies ein eindeutiger Wert?
 * Ergebnis: Weitergabe an Fr. Stoyanova.


 * Vorschlag: source kann für Filterung/Sortierung nach der Quelle verwendet werden
 * Ergebnis: Denkbarer Anwendungfall: Seite auf der Website des Instituts mit den neuesten Bänden der Institutsschriftenreihe (wird derzeit von Hand gepflegt).


 * Element dc:subject ist Beispiel-XML leer. Wird das Element verwendet?
 * Ergebnis: Wird derzeit nicht verwendet. Wird künftig ggf. mit dem stets gleichen Inhalt gefüllt sein und daher CMS-seitig als Filter eher nicht relevant.


 * Autor-Subobjekte können nicht anhand des Elemets eterms:creator role eineindeutig zugewiesen werden, da die jeweilige Rolle immer mit dabei ist. In CONTENS benötigen wir eineindeutige Daten, um sie innerhalb von Objekten (bzw. Subobjekten) abbilden zu können. Beispiel: Doralt in den Rollen AUT und HNR.
 * Ergebnis:
 * Sobald die Personen in CoNE geladen sind, erhalten sie eine eindeutige eSciDoc-ID. Diese wird beim Export mit übermittelt. Diese ID wird in Contens im Personenobjekt hinterlegt. Somit ist eine eindeutige Zuordnung möglich. Beispiel:

  Van Berkum Jos J. A. ...       http://pubman.mpdl.mpg.de/cone/persons/resource/persons189  
 * Contes benötigt kurzfristig Beispiel-Exportdaten, die auch die Personen-ID beinhalten
 * In den Autorensubobjekten können mehrere Rollen gespeichert werden (z.B. AUT (Autor) und EDT (Herausgeber))
 * dennoch braucht Contens eine verbindliche Aussage, welche Rollen maximal vorkommen können (s. nachstehende Frage)
 * Contens klärt ob eine Übernahme der Objekt-ID (z.B. ID des "Persönliche Daten"-Objekts für Personen) von Contens 2.5 zu Contens 3 möglich ist


 * Welche Rollen sind für die Publikationslisten und die Sortierung/Filterung relevant? Im PubMan-Formular sind folgende Rollen auswählbar:
 * Artist
 * Autor
 * Herausgeber
 * Maler
 * Illustrator
 * Fotograf
 * Kommentator
 * Transkribierer
 * Ratgeber
 * Übersetzer
 * Beitragender
 * Sind das alle Rollen oder kommen noch welche hinzu (s. http://lcweb2.loc.gov/diglib/loc.terms/relators/dc-relators.html)


 * Fazit:
 * Contens benötigt möglichst kurzfristig eine Liste, welche der übermittelten eSciDoc-item-Datenfelder auch im Contens-Objekt zur benötigt werden
 * hierarchische Verschachterlung macht die Schnittstellenprogrammierung komplex und die Inhalte der Objektbibliothek sehr unübersichtlich
 * Vorschlag Contens: für exotische Filterkriterien, die mit nur geringer Wahrscheinlichkeit benötigt werden (z.B. nach Sprache der Publikation) könnte Contens in der Objektklasse eine Select-Box machen und mit dem ersten vorkommenden Inhalt füllen- d.h. es wird kein Subobjekt erzeugt
 * Empfehlung Contens: es sollte alles entfallen, was nicht zur Darstellung, Filterung / Suche und Gruppierung gebraucht wird
 * Contens würde mit der Schnittstellenprogrammierung starten, sobald die Liste da ist. Es ist sinnvoller, den Ablauf zu verschieben, als überflüssigen Code zu produzieren.

Klärung genereller Fragen von Seiten Institute / MPDL (Contens_OpenQuestions)

 * Wie kann mit zurückgezogenen Objekten verfahren werden?
 * Ergebnis:
 * Dass der Status "zurückgezogen" fehlt, ist nicht problematisch. Contens wird vor Import einen Differenzabgleich von Datenlieferungen mit den Objekten in der Datenbank machen. Ähnliches wurde auch schon für andere Kundenprojekte realisiert.


 * Anzeige von Detailseiten, bei:
 * Inhalt im Feld Abstract
 * hochgeladene Datei vom Typ "Abstract" (Link zur Datei auf PubMan)
 * hochgeladener Volltext (je nach Zugriffsrecht angepasster Linktext)
 * externe Referenz: URL
 * Identifier: Typ=DOI
 * Identifier: Typ=URN
 * Identifier: Typ=URI
 * Ergebnis:
 * Die Erzeugung von weiteren Detail(seiten) ist unproblematisch
 * Es gibt technisch verschiedene Möglichkeiten, die Anzeige von Detail(seiten) zu lösen
 * Contens kann uns bei Bedarf bzgl. der verschiedenen Design-Lösungen beraten
 * Contens benötigt bis zur Projektmitte eine Designvorgabe (welche Infos sollen enthalten sein, wie soll die Anzeige designtechnisch gelöst werden)


 * Ist es möglich, die "localized"-Strings Contens-seitig auch in weiteren Sprachen zu hinterlegen?
 * Ergebnis: Ja, ohne großen Mehraufwand. Wie die Ablage der Strings technisch genau erfolgt klärt Contens noch.

Besprechung Projektplan (erstellt durch Contens)
Fragen zum Projektplan:
 * welche Abhängigkeiten gibt es zu Tätigkeiten auf Seiten der Institute / der MPDL?
 * z.B. PUSH-Variante (Vorgang 12). Zitat Angebot v. 18.1.: "Weiterhin muss die Schnittstelle aus PubMan heraus angesprochen werden können, indem CONTENS ausgelöst durch einen Befehl in PubMan einen PULL-Request für zuvor in PubMan markierte Datensätze auslöst."
 * Ergebnis: Contens kann die PUSH-Funktion schon vorbereiten- die aufzurufende URL kann durch einen Dummy ersetzt und ausgetauscht werden, sobald eine entsprechende Funktion in die PubMan-Oberfläche integriert ist.


 * Präzisierung Export-Funktion (Buttons etc.): Angebot S. 17
 * Ergebnis: Gemeinsam mit der Angabe, wann und wie Detail(seiten) angezeigt werden sollen, sollte Contens auch mitgeteilt werden, wie der Button für die Funktion "Publ.liste aktualisieren" aussehen soll: ein Icon (z.B. PubMan-Icon oder "Reload"-Icon aus dem Browser) oder eine Beschriftung?
 * z.B. Schriftenverzeichnisseiten für Wiss. im Testsystem nachbauen - mehrsprachig? Zitat Angebot S. 13 "Eine präzise HTML-Vorlage...wird CONTENS vor Projektstart zur Verfügung gestellt."
 * Ergebnis: Die Bereitstellung einer präzisen HTML-Vorlage entfällt, nach Template-Schulung kann dies jedes Institut auch selbst umsetzen.


 * Vorgang 15: Scheduler-Einstellungen- Ist hiermit die "Implementierung des Timing-Features" gemeint (Angebot S. 13)?
 * Ergebnis: Ja.


 * Vorgang 16: Rechtebeschränkung. Besteht hier ein Widerspruch zu "Objekt-Edit-Button öffnet PubMan-Formular"? (Angebot S. 18.)
 * Ergebnis: Nein, hier besteht kein Widerspruch. Die Zugriffsrechte z.B. direkt über die Objektbibliothek müssen trotzdem beschränkt werden.

Anmerkungen zum Projektplan:
 * Vorgang 21: erst möglich, wenn Umstieg auf Contens 3 erfolgt ist (Termin derzeit noch offen)
 * Ergebnis: Da sich das Migrationsprojekt ggf. noch verzögert, sollte die funktionale Abnahme Design-unabhängig sein.

Ausgabe / Design

 * die edit-Ansicht einer Direktoren-Publikationsliste (zahlreiche Objekte) wird mit max. 5 Sekunden Ladezeit beziffert. Die Web-Ansicht ist natürlich deutlich schneller (Millisekunden-Bereich)
 * es wird voraussichtlich nicht eine große Objektklasse für alle Publikationstypen geben, sondern doch eine Klasse pro genre type
 * Contens wird Templates und Outputtypes im Contens-Testsystem bauen, in denen die Publikations-Objektklassen angezeigt werden können. Das Design wird aber nicht exakt das MPG-Design abbilden (dies kann im Rahmen des Migrationsprojektes von den Instituten erledigt werden). Es geht in erster Linie um das Demonstrieren der Funktionalität (Anzeige der unterschiedlichen Objektklassen in 9 Kategorien)
 * Ein Template mit 9 Aktiven Locations ist ggf. zu aufwändig zu pflegen, daher denkt Contens an, die 9 Kategorien in einem zusätzlichen Datenfeld in den Publikationsobjekten zu hinterlegen. Vorteil von 9 Aktiven Locations: zwischen den einzelnen ALs kann bei Bedarf noch Text etc. eingefügt werden.
 * GGf. wird es ein Template mit nur einer Aktiven Location geben, die dennoch zu einer Darstellung in 9 Kategorien führt. Nachteil: Zwischen den Blöcken kann nichts eingefügt werden.
 * Contens wird beide Möglichkeiten prüfen.
 * Unabhängig davon, ob 1 oder 9 ALs eingebunden werden: es ist stets möglich, die Anzeige einer Kategorie zu unterdrücken, wenn in ihr keine Publikationsobjekte vorhanden sind.
 * Idee Contens: man baut 2 Templates. Das Template mit den 9 ALs wird z.B. für Publikationslisten der Direktoren verwendet, in denen ev. weitere Formatierungen gewünscht sind. Für alle anderen Wiss. wird das Template mit einer AL verwendet.

ToDos
Institute:
 * Contens benötigt die Zugangsinformationen zum PubMan-Jus-Testsystem (Mail von Fr. Arndt an Contens am 19.04.10.)
 * Contens benötigt schnellstmöglich eine Liste mit den tatsächlich benötigten Datenfeldern (ca. KW 18)
 * Contens benötigt Vorgaben für Detailseiten / Buttons (ca. 3 Wochen nach KW 18, also KW 21)

Contens:


 * Anpassung des Projektplans: Verschiebung des Blocks "Ausgabe/Output" in die Projekt"mitte" (ca. 3 Wochen nach "Erstellung Schnittstelle")
 * Klärung, ob eine Übernahme der Objekt-ID (z.B. ID des "Persönliche Daten"-Objekts für Personen) von Contens 2.5 zu Contens 3 möglich ist
 * Klärung, wie "localized"-Strings abgelegt werden