Talk:MPI ICE Requirements PubMan

PubMan Piloten,MPDL,PubMan

=Discussion Requirements=

Export possibilities for website generation

 * They want to use the search and export interface, as they wanna access the data in real-time.
 * Lists needed:
 * Institute list: all ICE-Publications, not extern (http://www.ice.mpg.de/main/inst/publ/publ.htm?year=2008)
 * search and export example link: http://pubman.mpdl.mpg.de/search/SearchAndExport?cqlQuery=escidoc.any-organization-pids=escidoc:24027 NOT escidoc.any-organization-pids=escidoc:persistent22&exportFormat=APA&outputFormat=pdf&language=all
 * group list: all "ITB"-Publications, not extern (http://www.ice.mpg.de/itb/publ/publ.htm)
 * search and export example link: can be created as soon as OU structure is defined
 * personal homepage: all Publications from "sial3374" / Silke Allmann (http://www.ice.mpg.de/dbs-staff/hopa/sial3374/web/main_en.htm)
 * for personal home page we plan to have search by author ID (or Author name) and not by user-name of an author (as there may be publications submitted by other users) --Natasa 09:22, 19 December 2008 (UTC)
 * I think sial3374 is the ICE authorID for Silke Allmann. I..e shold be fine (as long as we ahve ICE data imported...would be one possible Identifier for CONE person Silke Allmann)--Ulla 14:08, 19 December 2008 (UTC)


 * Sorting: Year, author list
 * Sorting is possible by publication year, and any-persons index (first name and last name of all persons in the publication metadata, independently on their role, see Person index)


 * current procedure for creating the webpages:
 * own PHP-Scripts, control via CSS,
 * in the future (quite soon) the webpages will be generated via TYPO3, which means, that the export in html would make sense.
 * --Natasa 09:31, 19 December 2008 (UTC) Would be good to have requirements for this e.g.
 * is it only the HTML SNIPPET of the citation style that need to be exported
 * is it particular metadata that need to be exported from Item
 * references to fulltexts?

Assignement of PIDs for publications in the moment they are released

 * Implemented on pubMan, waiting for Handle system by GWDG --Natasa 21:55, 3 October 2008 (UTC)
 * Discussion is ongoing, Handle system at GWDG is available, interfaces to be tested and will be included into PubMan. --Natasa 09:23, 19 December 2008 (UTC)

PIDs for authors (has to include the local identifier)

 * Please note the following: The PIDs for authors will include the local identifier in the Cone service data. The Publication item will hold only Cone service identifier for this author. Therefore, extra matching from Cone service is needed. --Natasa 12:08, 15 January 2009 (UTC)

quality assurance workflow for releasing publications

 * is the WF already the one supported by pubMan or a new one should be implemented?--Natasa 21:55, 3 October 2008 (UTC)
 * Sent E-Mail to ICE today to clarify. --Nicole 14:08, 24 November 2008 (UTC)
 * ICE is fine for now with the standard WF. Ms. Bieniek will be Depositor and Moderator. --Nicole 08:22, 17 December 2008 (UTC)

import Endnote files, including the information in customizable fields

 * as long as 2 systems are used in parallel (Endnote and PubMan), update/synchronization has to be provided
 * duplicate check needed: original endnote items should be stored together with pubitem, to faciliate automatic diff. If endnote item has changed, pubitem is modified accordingly.
 * There will be extraordinary lot of changes to enable storing of endnote formatted metadata together with pubitem. PubMan needs to be changed completely. Enabling for such automatism will require a lot of efforts as it also supposes automatic versioning when updating. Batch updates will be discussed but are not yet scheduled in the core services. --Natasa 21:55, 3 October 2008 (UTC)
 * Maybe an alternative would be to do it like in eDoc? Make regular imports and have a duplicate checking on identifier basis and if there is a duplicate the user can make an update of the existing record. --Nicole 14:05, 24 November 2008 (UTC)
 * This can be taken as alternative, it will however still need some changes, as the endnote record must have also the date of last modification. If the policy would be endnote record if imported with same identifier always updates PubMan item, this will not be an issue. If items are in addition changed on PubMan and end note item that does not contain the last PubMan changes is imported it will overwrite automatically. Can this be agreed? --Natasa 09:26, 19 December 2008 (UTC)
 * I think it can be agreed as long as ICE agrees to update their data only in EndNote. a question in this context is, what do they need to switch off endnote...--Ulla 14:12, 19 December 2008 (UTC)
 * Fine with me. Will this already be possible in phase one? If yes, then I should write a UC soon ;-). --Nicole 10:26, 7 January 2009 (UTC)

Duplicate check possibility based on similarity (either on fulltext or on MD level)

 * we need to precise this requirement better--Natasa 21:55, 3 October 2008 (UTC)
 * Will do this in a later stage, as this is part of Phase II. Is that okay? --Nicole 14:08, 24 November 2008 (UTC)
 * Absolutely.--Natasa 09:27, 19 December 2008 (UTC)

E-Mail response from ICE with further specification


 * Der Duplettencheck sollte wahlweise automatisch oder manuell anstoßbar sein
 * a) automatisch (als Hinweis) z. Bsp. für einzelne Eingaben durch den Wissenschaftler
 * b) manuell (als Button) z. Bsp. nach Import von Datenpaketen, vor dem Erstellen von Listen, Laden zum Jahrbuch …
 * der Umfangs des Abgleichs sollte wählbar sein (markierter Eintrag, alle meine Einträge) der Abgleich sollte folgende Punkte zur Auswahl haben (vgl. endnote) Auswahl des Umfangs: markierter Eintrag, .. alle meine Einträge
 * Autor
 * Titel
 * Year
 * pages
 * Sourcetitle
 * Vol.
 * Iss.
 * Publisher
 * Place published
 * Short title
 * subsidary Author
 * Reference Type
 * (Anmerkung: bei manchen Publikationen ändert sich mit dem Publizieren auch alle bibliografischen Angaben; (1)„discission - (2) „published“, Beispiel: zuerst in BioGeoChemistry Discussion -> später in BioGeoChemistry)

Management of fulltexts

 * increasing visibility of open access publications (Example revisions: If one revision exists with OA access, make it visible)
 * management of visibility (highest priority: organisational unit levels, in addition restricted access for user groups)
 * as this is at present work in progress, can we get some more requirements on this topic, to check the design and implementation? check also ESciDoc_User_Group_Handler, ESciDoc_Access_Rights--Natasa 21:55, 3 October 2008 (UTC)

Export possibilites for reports (yearbook, annual report)

 * Identification of external publications (CU4) needed
 * Individual selection of "outstanding papers" needed for annual reports
 * Maybe the above two are candidates for a local tag (even though the outstanding paper may be a catalog) --Natasa 21:55, 3 October 2008 (UTC)
 * Would go for local tags at first and then think about catalog, as this is to my understanding a more complex topic, right? --Nicole 14:08, 24 November 2008 (UTC)
 * Yes, catalogs are quite different. Ok, Local tags are the mechanism for individual selection. --Natasa 09:28, 19 December 2008 (UTC)


 * Requirements for the annual report:
 * all not external publications, sorted by author (group) in APA citation style html
 * I think this should be possible. --Natasa 09:28, 19 December 2008 (UTC)

Open Questions/Issues

 * Frage zu Shibboleth – wie weit ist dieser Service? Welche Attribute sind vorgesehen?
 * At present the only attribute forwarded via Shibboleth is the username. We work on implementing and adopting Ldap and Shibboleth in eSciDoc and first test results are expected in February. --Natasa 12:27, 15 January 2009 (UTC)


 * zum IMPORT:
 * wann wird der Import aus Endnote (inklusive der benutzerdefinierten Felder) zu erwarten sein? Das ist für uns wichtig, um richtig testen zu können.
 * This feature is at present scheduled for March. --Natasa 12:27, 15 January 2009 (UTC)


 * zur EINGABE:
 * werden folgende Anpassungen möglich sein, wann?
 * a) eigene Bezeichnung der Felder (wie für NL)
 * not possible yet, can become critical for different users to understand the specific metadata. This was a topic before and for now is discarded. Technically is prepared, but can get rather complex to configure. --Natasa 12:27, 15 January 2009 (UTC)


 * b) eigene Reihenfolge in der Eingabemaske definieren
 * not possible, not considered yet, UIE Team first needs to make usability tests and interviews, only afterwards we would be able to approach this issue. --Natasa 12:27, 15 January 2009 (UTC)


 * c) Kennzeichnung eigener genrespezifischer Pflichtfelder
 * same answer as for b). There are several issues in this respect: allowing different genre-specific masks for entry means not only different entries via submission forms, but also defining and re-defining absolutely different and genre specific validation rules everywhere, and different mappings for each import and each institute (again, customizable genre specific). This will be very heavy to maintain and to enable consistency of data in the repository on one hand side, but also at some point tends to become unmanageable burden for the institute. --Natasa 12:27, 15 January 2009 (UTC)


 * zur erweiterte EINGABE:
 * wie soll mit „eigenen“ Feldern umgegangen werden (z.B. Werte sichtbar für andere? Werte durchsuchbar?)
 * If this would consider the Local Tags then these are visible for others (but are not prominently displayed) and are searchable as soon as the item enters the status "released". --Natasa 12:27, 15 January 2009 (UTC)

GUI Feedback

 * die prinzipielle Reihenfolge der aktuellen Eingabefelder (R4) hätten wir gern anders, Pflicht- Basis-, wichtige Angaben an oberster Stelle (damit so wenig wie möglich gescrollt werden muss)
 * -> irgendwie Einteilung in Basis- und Zusatzinfo-Bereich

Rupert: Die Reihenfolge der Metadaten ist zwar in den JSPFs änderbar (also GUI), aber bisher kann man es nicht institutsspezifisch konfigurieren. Soll die Reihenfolge für PubMan geändert werden, gilt das dann für alle Nutzer und müsste einem möglichst breiten Konsens entsprechen (Fachlich). Soll es in Zukunft konfigurierbar sein (Context/User Preferences) dann ist es eine Entwicklungstechnische Erweiterung. Aus GUI Sicht wäre das auch wünschenswert. --Rupert 08:20, 15 January 2009 (UTC)