JusCMS Requirements

JusCMS,MPDL

Based on the workpackages agreed in the project description, and the user-requirements known from the current CMS-system (cf. "Anforderungen an ein System zur Erfassung von Publikationsdaten - Langfassung" 2008), following are the relevant functional requirements for the joint project. The list of requirements can be modified based on the final architectural decision. Details of each requirement will be specified during the corresponding workpackage.

Document-type specific Metadata
Aim of workpackage (WP): The document-type specific metadata for legal artifacts will be defined and mapped to a Dublin Core Application profile to enable a high degree of sustainability and interoperability.


 * Coverage of 24 different publication types and their respective metadata (about 30-50 fields)
 * Definition for each publication type includes
 * functional definition
 * mandatory and optional metadata (for role-or institute-specific entry masks within local CMS)
 * Controlled terms/Vocabulary (optionally)
 * Depending on final architecture, mapping of terms (i.e. CMS-relevant categories/data/properties and eSciDoc relevant categories/metadata/properties) might be needed, for proper transformation for citation lists
 * Example: "abstract" as Metadata or fulltext category
 * Example: eSciDoc: "type of fulltext" (publisher pdf) vs category in local CMS during submission

Citation styles
Aim of WP: The discipline-specific citation styles will be identified and modeled.


 * Provision of an agreed number of different citation styles, which are valid for all institutes involved
 * Defined syntax and format for each publication type, incl. exceptions
 * Depending on the overall architecture, the citation styles will be delivered in a certain structured format (XML, snippet, HTML, PDF, ODT, TXT)

Citation lists
Aim of WP: Once citation styles have been defined, the styles will be applied to list of items.


 * Provision of defined list views of publication items, based on the defined citation styles
 * for re-use in CMS
 * depending on final architecture, update workflow and user rights needed for eSciDoc have to be defined (submission/modification in local system - export - transformation - import - presentation)
 * Possibility to choose between short and detailled view, incl. optional link to fulltext, based on access conditions (open or closed access for the public)
 * Possibility to sort lists
 * by publication type
 * by family names
 * by institute/department
 * by date of publication
 * by date of submission/last modification (depends on single source of reference)
 * by local tags (to sort by individual category "Bedeutung") (depends on possibility to provide local tag)
 * by multiple sorting
 * Compilation of lists and sorting depends on search indexes and language flags supported in the single source of reference
 * Example: lists of references with english abstract or english title
 * Unclear - depends on final architecture:
 * The final provision of the citation style depends on the purpose of the list: If the list is generated for a specific staff member, the name of this staff member is not part of the author names. Instead, the syntax will be somehting like: "Gemeinsam mit...".
 * Generation of citation lists has to consider the affiliation of the authors (single source of reference?) and the envisioned re-use (e.g. for homepage of staff member N.N.)

Reports
Aim of WP: The required reports will be specified and implemented.


 * Provision of defined number of different reports
 * Report includes (?):
 * (list of) publication data in XML, based on defined search criteria
 * defined layout
 * modeled in defined citation style (optional)
 * Manual/individual sorting for defined data/elements
 * Depending on the overall architecture, the citation styles will be delivered in a certain structured format (XML, snippet, HTML, PDF, ODT, TXT)
 * What format is needed for InDesign?

Conversion old Metadata
Aim of WP: The existing metadata for about 10,000 items will be converted to the metadata profile defined. This work will be accomplished by students and reviewed by the staff of the institutes afterwards.


 * Requirements for versioning?
 * Unclear: Conversion of about 7000-8000 references per institute (as from 2008) or 10 000 items (as calculated in project proposal)?

Interoperability
Aim of WP: The scenarios for export and import of bibliographic references will be specified and implemented.

Damit ist folgende Anforderung gemeint: "Die Ausgabe der Publikationsdaten soll auch auf anderssprachigen (dh primär englischen) Internetseiten erfolgen können". Ist damit eine automatische Übersetzung gemeint?--Ulla 08:54, 26 February 2009 (UTC)
 * Support for export (a list of) publication data in XML, HTML, PDF, ODT, Snippet
 * including fulltext, i.e. by locator?
 * google/google scholar support (depends on single source of reference)
 * Export for the MPG Yearbook
 * as XML data
 * Depending on final architecture/single source of reference, compilation, validation and modification of Yearbook data has to be defined
 * Export data to SSRN
 * fetch MD scenario?
 * including fulltext, i.e. by locator?
 * transscription of labels of publication types from german to english (depends on single source of reference)
 * Compatibility with Metadata standard for VG Wort
 * automatic electronic submission?
 * export of reference data to VG Wort?
 * OAI interface
 * Local-specific definition of sets

Structured Text Format
Aim of WP: Depending on the specific requirements of the institutes, initial TEI profiles will be specified to enable search and browse for encoded, text-inherent information. Based on the TEI profile, an easy-to-use editor will be developed. In addition, different representations on the TEI-based transcriptions will be provided.


 * Development and provision of sample TEI profiles
 * Editor-environment to enrich encoded information
 * Provision of TEI-encoded text in HTML, ODT, PDF
 * Link to reference data and binary fulltext

Additional pages
JusCMS_Requirements_Wissenschaftler JusCMS_Requirements_Assistants

Anforderungen aus dem ursprünglichen Katalog, die von dieser Aufstellung nicht abgedeckt sind:
--Kortuem 11:35, 20 April 2009 (UTC)
 * A.II. Einsatz und Funktionen des Systems
 * 1. Zeitnahe Eingabe und Darstellung der Daten
 * 2. Eingabe und Bearbeitung der Daten (durch Mitarbeiter, durch ZS, außerhalb des Instituts; Änderungsmöglichkeiten)
 * 3. Überprüfung der Daten


 * A.II.4.b Darstellung und Verwendung der Publikationsdaten
 * Darstellung auf eigenen Internetseiten


 * A.II.5. Weitere Sprachen für Eingabemasken


 * A.II.6. Weltweite Sichtbarkeit


 * A.III. Funktionen für Benutzer, Administratoren und EDV-Administratoren

3.a. Internetseiten (=korrekte Darstellung der Publikationen auf den Internetseiten)
 * A.IV. Publikationen, Publikationskategorien und Publikationsdaten


 * B.I. MPI für Völkerrecht
 * auf ein Minimum reduzierte Menge an Publikationskategorien und -feldnern
 * Interesse an Veröffentlichungen in weiteren Publikationsdatenbanken
 * besondere technische Anforderungen (z.B. OAI Schnittstelle)
 * detaillierte Anmerkungen zu den Publikationskategorien und -feldern im System


 * B.II.MPI für Strafrecht
 * auf ein Minimum reduzierte Publikationskategorien und -felder

weitere Anforderungen, die sich aufgrund der internen Umfragen und Diskussionen ergeben haben:
--Kortuem 12:32, 20 April 2009 (UTC) Eingangsfrage: Welche der neuen Anforderungen können überhaupt vom Projektrahmen "JusCMS" abgedeckt werden?


 * MPI für Privatrecht (entnommen aus "Talk: JusCMS Architecture Options", "JusCMS Requirements" und "JusCMS Prioritäten"; hier Bitte an MPI Priv. um Vervollständigung und Abgleich mit urspr. Anforderungskatalog)
 * auf aktueller Contens-Version (3.0+) entwickeln/testen
 * Vorschaufunktion soll auf PubMan-Seite verfügbar sein (Wie wird es im CMS aussehen?)
 * Flexible Rechtezuweisung für Volltexte: Vollzugriff, Teilzugriff, Vollzugriff ab Datum X, Zugriff nur im CMS
 * Anmeldung über LDAP oder Shibboleth, Single-sign-on PubMan/CMS
 * Disziplinspezifische Eingabehilfen und Validierungsmechanismen
 * Unabhängigkeit der Systeme
 * Datenhaltung in "Speziallösung" der MPDL und gleichzeitig im eSciDo-Repository
 * Eingabemasken in beiden Systemen (Qualität der Eingabemasken hängt von Workflow ab)
 * Ausgabe nach Autor, pro Autor nach Publikationstyp, innerhalb Publikationstyp sortiert nach Jahr/Datum
 * (Ausgabeproblem?)
 * alle reports sollten auf- und absteigend sortierbar sein (mind. Datum, Alphabet)
 * flexible Filterkombination (z.B. nach Autor, innerhalb eines bestimmten Zeitraums etc.)
 * monatlich, vierteljährliche oder halbjährliche Listen mit allen Publikationen, die seit letzter Liste hinzugekommen sind; Sortierung: 1. Publikationstyp, 2. alphabetisch nach Autor, 3. nach Veröffentlichungsdatum
 * auch als CMS-Seite darstellbar
 * Unverfälschbarkeit der Daten (Zeichensatzproblematik! Sonderzeichen müssen lesbar erhalten bleiben, unabhängig von Weitergabe über Schnittstellen/Export)
 * Export in Wiki-Systeme (z.B. Mediawiki)


 * offene Frage MPI für Privatrecht
 * Inwieweit können/sollen PubMan und CMS unabhängig von einander arbeiten und selbständig zu bedienen sein?


 * Überlegungen zu Anbindung SSRN - "Automator"


 * MPI für Völkerrecht
 * eSicDoc-Sever über den weltweiten Verbund von OAI-Servern sichtbar/vernetzt (möglichst mit allen Daten)
 * Zertifizierung (von PubMan?) nach DINI-Standards als Dokumenten- und Publikationsserver


 * MPI für Geistiges Eigentum
 * neue Anforderungen
 * Schnittstelle zu Stammdaten-Editor (CMS der MPG)
 * Anbindung zu google books
 * Verschlagwortung(!)
 * Anregungen, Wünsche, Vorschläge
 * Aufnahme von "Kolumne", "Editorial", "Stellungnahme" als weitere Publikationskategorie
 * Verbesserte Sortiermöglichkeiten (der Objekte) in CMS
 * Vereinheitlichung des Zitierstils Tätigkeitsbericht
 * Auflistung der Stellungnahmen auf der Startseite
 * Vereinheitlung der jur. Zitierstile und Umfang eines Werkes
 * Zitierfähigkeit von Online-Publikationen