Online publication of the “Cyprus Law Review” by the Supreme Court of Cyprus
This document is the property of the Council of Europe. It's a part of a consultation launched by Innovative Solutions for Human Rights and Justice Unit, Directorate General Human Rights and Rule of Law. The supplier will treat this document as strictly confidential. It may not be reproduced or communicated without the author's prior agreement. The content of this document will be disclosed to potential business partners in good faith by the supplier. No part of this document may, in itself, constitute a commitment of the Council of Europe or its staff.
Distribution list |
|||
Entity |
Name |
Role |
Purpose of distribution |
3.3 Presentation of the relevant directorates / departments................................... 7
3.5 Identified stakeholders, users, roles & responsibilities..................................... 16
3.7 Replacement of existing / older systems...................................................... 17
3.9 Method of requirements capture used.......................................................... 18
5.2 Hardware and infrastructure requirements................................................... 26
5.3 Access modes and security requirements..................................................... 28
5.5 Business Continuity plan (Disaster recovery)................................................. 28
5.7 Service level: availability, performance and support....................................... 29
7.2 Data outputs and reporting requirements..................................................... 32
8 User Documentation and Training Requirements.......................................... 34
10 Critical Success Factors (CSF) and measurements...................................... 35
This document presents the detailed business requirements for the Tools to support the online publication of Cyprus Law Reports system that will be delivered by the “Foster Transparency of Judicial Decisions and Enhancing National Implementation of ECHR” project (hereinafter: TJENI project).
List all documents describing the application and provide their hyperlink, for example, Business Requirements, User guide, etc. In connection with the various developments in the solution's "history", it may be helpful to provide a link to the detailed "delta" specifications drawn up for each project.
Name/Description |
Link to the document |
List all the specific terms and abbreviations used in the document.
Term |
Definition |
CLR |
Cyprus Law Reports |
cCMS |
collaborative Content Management System |
CyLII |
Cyprus Legal Information Institute |
ECLI |
European Case Law Identifier |
ECLI Cdb |
ECLI Cyprus Database |
LLM |
Large Language Models |
NLP |
Natural Language Processing |
OPAC |
Online Public Access Catalogue |
SLA |
Service Level Agreement |
SCC |
Supreme Court of Cyprus |
SEO |
Search Engine Optimization |
TJENI (project) |
Foster Transparency of Judicial Decisions and Enhancing the National Implementation of the ECHR |
VPS |
Virtual Private Server |
WAF |
Web Application Firewall |
The Supreme Court of Cyprus has been publishing since 1961 the Cyprus Law Reports (CLR), which constitute the standard reference for quoting its published decisions. The publication process is currently lagging behind, with the last volumes printed for 2017.
In order to keep up with the ongoing digitalisation process which has invested also the justice sector, the Court has the intention to publish CLR as e-books made available online on the Court website. This will contribute also to save resources and to shorten the publication process.
The purpose of this project is to streamline the process of publication of the digital CLRs and to enable its fruition. The project will to this end build two sub-systems: a collaborative Content Management System (cCMS) to support the publication process and a dedicated CLR webpage that extends the Court’s website.
The cCMS will support all phases of the publication process, starting from the selection of the collected decisions, until the finalisation of the volume which will include them. The preparation of the volume will be made through the layout design and desktop publishing software which is already being used for the preparation of the printed volumes, QuarkXpress, but the system will allow to streamline internal working processes, allowing legal officers, clerks to perform all activities within a single environment, without the need to look at emails, and to follow the state of progress of the publication process. The system will also facilitate the preparation of indexes and the use of the same meta-data to facilitate structured searches via the website.
The CLR webpage will allow to consult online or download volumes in the preferred format, and for combined searches on structured data and free-text. The provision of hyperlinks to quoted legal provisions and judgements and the possibility to copy parts of the text pasting together with it the reference to CLR will constitute other new functionalities which will facilitate the work of legal professionals.
The Supreme Court of Cyprus has been publishing since 1961 the Cyprus Law Reports (CLR), which contain a selection of the court jurisprudence issued on a given year. Each decision is preceded by a short summary of the decision which includes a short description, the main legal provisions and relevant keywords.
CLR are divided in three parts: Part 1 contains civil cases decisions, Part 2 is devoted to criminal cases and Part 3 to administrative cases decisions. Each part is as a rule published as a separate physical volume, but due to its size Part 1 is published on different volumes (1a, 1b, …). Each volume contains front indexes and a final thematic index, all based on the decisions’ summaries and referencing page numbers where the corresponding decision. CLR volume and page numbers are used a standard reference to quote a published decision. **** (This is under revision as a result of the judicial reform and the additional publication of the decisions of the appeal court)
The production of the summary by legal advisors requires time (for this reason, a parallel project within the same TJENI programme is investigating the possibility to use LLM and possibly other NLP tools to partially automate it) and the publication is lagging behind. The last CLR volumes have been published for the year 2017.
The tool for the online publication of CLR will afford a series of advantages:
- Make CLR more readily available to legal professionals and the public, as the whole printing and distribution phase will be skipped. It is true that the Supreme Court decisions are currently published online almost in real time on the Bar association portal Cylaw (freely available) and in the commercial portal Leginet, but they do not contain summaries and keywords.
- Make CLR available to a larger audience, as currently only 115 copies are printed for each volume (they are distributed to all Cyprus judges, the Cyprus Bar association, Greek Courts and the Council of Europe) and make possible the publication of pre-print volumes without waiting for the end of the year.
- Increase usability of the published volumes, making possible to consult them via PC, tablet or mobile phone and including hyperlinks to quoted legal provisions and judgements and making possible to copy parts of the text pasting together with it the reference to CLR.
- Streamline internal working processes, allowing legal officers, clerks to perform all activities within a single environment, without the need to look at emails, and to follow the state of progress of the publication process.
- Facilitate the publication process, in particular with the automated production of indexes.
The process of preparation of the summary of the decision, including the identification of proposed relevant keywords, which can benefit from the use of Natural Language Processing methods, is not included in the scope of this Project, but the design should take into account the perspective integration with such system.
Likewise, the integration with the case management system used by the Supreme Court (currently the i-justice system, to be replaced by the e-Justice case management system, under development) is not included. However, the design should take into account the possibility to interface with the case management system once this goes online in order to automate the addition of a decision to the cCMS. The new editorial task – of processing the decision for publication – should originate directly from e-Justice, transferring via API to the cCMS the decision’s metadata that are already stored in the case management system.
The Legal Publication department which includes a team in charge of the preparation of CLR (five legal officers) and a clerk who assists them and is in charge of the formatting and composition of the CLR publication (hereinafter: LP clerk). Each of the five CLR legal officers is in charge for the relevant part of the CLR to be published: Part 1 (Civil law), Part 2 (Criminal law) and Part 3 (Administrative law). Each of the LP unit members performs also other tasks.
Court secretaries assist judges in their work, and currently transmit final decisions to the LP clerk.
A Registrar is in charge of maintaining the Court webpage content.
The administration and maintenance of the court case management system are fully outsourced, and two designated Registrars are in charge of submitting requests to the contractor.
The IT team of the Ministry of Finance of Cyprus government, which hosts all public institutions webpages, is in charge of any update of the pages’ appearance and functionalities.
There is an anonymization team which consists of two legal officers.
NOTE: In italics are marked actions and steps which even if not relevant for the CLR publication should be handled differently if the process is modified.
1. Collection and selection of decisions to be published.
a. The court secretaries, daily or weekly, send via email to the LP clerk the final version (in MS Word) of all the decisions that the Judge they assist has signed. The same version has been uploaded in the i-CMS.
From 2020 only two selected decisions on Prerogative Writs, per judge, will be published.
A few decisions are excluded from publication for privacy reasons, and by specific instruction of the Judge they are not sent.
The original signed decisions are transmitted by court secretaries to the LP clerk, who keeps them until the publication process is not finished (at which stage they are archived).
b. The LP clerk forwards via email the received decisions to the legal officer in charge of anonymisation who counts the decision received by type every month and sends a summary report to the Chief Registrar.
c. The legal officers in charge of anonymisation check/perform anonymisation and send the decision back to the LP clerk.
d. The LP clerk after anonymization, sends the decision by email to the Legal officer in charge of the relevant Part, saves it locally in her own PC, and at the same time also to the Cyprus Bar chamber and Leginet in order to have them published on Cylaw.org and leginet.eu.
2. Processing of decisions
a. Each CLR legal officer reads a decision, prepares the summary (including keywords) and once it is finalised and sends it via email to the LP clerk. If any trivial mistake is found it is corrected immediately.
b. The LP clerk revises the formatting of the decision and summary and, using QuarkXpress layout design and desktop publishing software, adds it according to the chronological order of the decisions, to the monthly fascicle of the relevant Part of the volume that is under preparation.
c. The LP clerk, once a monthly fascicle is completed, sends it by email in Word version to the legal officer in charge of the corresponding Part, who checks and points at any need for correction.
3. Publication and distribution
a. The LP clerk, once the last fascicle of the year is completed for a certain CLR Part, creates using QuarkXpress two additional files: the front indexes (parties, case number, laws) and the end index (thematic keywords). For Civil law cases (Part 1), given their size, the publication is split in more volumes.
b. The final PDF of the volumes for publication is shared by the LP clerk with the publishing house which has been previously selected via a competitive tender.
c. The printed volumes are delivered by the publishing house to the Registrar, which distributes them to judges, courts, Bar chambers in Cyprus and abroad and the Council of Europe.
Figure 1 represents the current business process.
NOTE: the new system should allow more users to be registered for each role, each of them with the same permissions.
Roles: Anonymiser, Volume Coordinator/contributor * (the same person), Volume Contributor, Clerk, WebMaster, Volume Contributors )****(as a result of the additional publication of the Appeal Judgments the number of contributors may be increased) will be assigned one or more Volumes, determined by subject matter and year of the decisions.
Table 1: Statuses and permissions: Decisions
Decision Status |
Main role who can select it |
What can see |
To be anonymised |
Anonymiser |
All |
To be published |
Volume Contributor |
Only for assigned Volumes |
Not to be published |
Volume contributor (view only) |
Only for assigned Volumes |
Summarisation ongoing |
Volume Contributor/ |
Only for assigned Volumes |
Summarised |
Clerk |
All |
Formatted |
Clerk |
All |
To be improved |
Contributor Clerk |
Only for assigned Volumes |
Reviewed |
Clerk Contributor |
All |
Added to Volume |
Clerk |
Only for assigned Volumes All |
Published |
Volume Conributor (view only) |
Only for assigned Volumes |
Table 2: Statuses and permissions: Volumes
Volume Status |
Main role who can select it |
What can see |
Open |
Clerk |
All |
Complete |
Volume Contributor |
Only for assigned Volumes |
To be improved |
Contributor |
All |
Approved |
Clerk |
All |
Ready |
Web-master Clerk |
All |
Published |
Volume Contributor (view only) |
NOTE to Tables 1 and 2
In addition to the main roles in the Tables above, the following roles have additional permissions:
- Clerks can see all decisions and volumes and select all Statuses but can change only the Statuses from the ones for which they are the main role. or edit documents.
0. Preparatory steps
1. Collection and selection of decisions to be published.
a. Clerks save on the central repository all Supreme Court decisions with a folder structure that includes the year, Part and publication attribute (“To be published”, “Not to be published” – based on the indication by the judge who signed the decision – or “Received” if a decision about publication has yet to be taken). This step should eventually be replaced by an automatic transmission of decisions with this information and other meta-data from the e-Justice case management system.
b. When the clerk triggers the import, the system uploads the decisions and uses the information contained in the name of the files and the folder where they were stored to assign initial corresponding meta-data. The initial Status is assigned as “To be anonymised” and to the text are automatically included hyperlinks to legal provisions (to Cylaw.org) and judgments (to the CLR volume if available, or to Cylaw.org, HUDOC and Curia).
c. Anonymisers revise/anonymise the decision and save it. When they have concluded this task click on a “Anonymisation completed” button, which will change the Status to the one determined by the previously saved publication attribute and will trigger the transmission via API from the cCMS to the ECLI Cdb (see page 16) of the anonymised decision with the relevant available meta-data.
d. Volume Contributors review the decisions with status “Received” and flag them as “To be published” or “Not to be published”.
1. Preparation for publication.
a. The legal officer (Volume Coordinator or Volume Contributor) selects and opens a decision with status “To be published” then push a button “Summary elements” which opens an input mask with the elements (fields) of the summary. The legal officer fills them copying some of them from the decision (e.g. date, parties, number etc.) and drafting others based on their expert analysis of the judgement and save them. The fields of the input mask which require structured data from closed lists (such as legal provisions and keywords) should suggest entries based on the first letters typed. Adding a new entry should be possible, but subject to confirmation by the user.
b. When the legal officer presses the button “Produce summary” the cCMS creates a read-only MS Word file (with the same name as the file with the decision but with the word “summary”, in Greek, appended at the end) which will contain the summary already formatted, with the automated inclusion of hyperlinks to legal provisions (to Cylaw.org) and judgments (to the CLR volume if available, or to Cylaw.org, HUDOC and Curia). The file is made available in the detailed view of the decision, along with the previous versions. Any change necessary after review should be entered into the mask as in a) and this step can be repeated (the cCMS will overwrite the file already created, unless it was last saved by another user).
c. Once the legal officer considers the summary ready for publication, she will change the status of the decision to “Summarised”.
d. The Clerk opens with MS Word the decision with status “Summarised” and the corresponding summary, adds the second to the first, checks and corrects formatting and adds missing hyperlinks and when finished changes the Status to “Formatted”.
e. The Volume Contributor opens and checks the decisions with status “Formatted”. If she notes any change to be made in the text of the summary, she will go through steps a – c and change the Status of the decision to “Reviewed” or she may, if only formatting has to be improved, add MS Word comments to the decision indicating what should be changed and change its status to “To be improved”. The change of a decision to the “Reviewed” status will trigger the transmission via API from the cCMS to the ECLI Cdb (see page 16) of the relevant elements of the summary.
f. The Clerk opens with MS Word the decisions with status “To be improved”, checks and corrects formatting and hyperlinks, removes any comment and changes the status to “Formatted”.
2. Publication and distribution.
a. The Clerk creates a new volume in QuarkXpress format (status: “Open”).
b. The Clerk selects from the decisions which are in the status “Reviewed” the ones to be added to the new volume (for example ticking the corresponding box in the List view”) and then triggers the action “Include”: the system pulls them and imports them, in chronological order according to the decision date, in the new volume, changing their status to “Included”.
c. Once the selection of decisions for the volume is complete, the Clerk presses the button “Create indexes” which will trigger the automated creation of indexes for the volume. These files are automatically added (replacing any previous index version) to the QuarkXpress file relative to the open volume, which changes its status to “Indexed”.
d. The clerk creates a PDF version and ePUB of the volume, optimised for web-publication.
e. The Volume Contributor reviews the PDF version and changes the status of the volume to “Approved” or to “To be improved”. In this latter case she will, through annotations on the PDF file, inform the clerk about the necessary changes to be made.
f. If the volume has the Status “To be improved”, the Clerk will perform the requested changes and repeat step c. and d.
g. If the volume has the status “Approved”, the Clerk will save the volume in PDF and ePub format and change the Status to “Ready for publication”.
h. For any Volume which has the Status “Ready for publication”, the Web-master will retrieve (via API or downloading a CSV file) the files to be published and the corresponding meta-data of the decisions included in the Volume and change the status of the volume to “Published”.
i. Optionally, if it has been decided to proceed with a printed publication, the Clerk creates a high-definition PDF version from the QuarkXpress corresponding file and delivers it to the selected publishing company, changing the status to “Printed” once the volumes are handed over to the Court.
Figure 2 represents the To-Be process. Figures 3-4 shows the evolution of statuses for decisions (light blue boxes) and volumes (dark blue boxes); the boxes in grey connected with dots indicate steps which may be skipped.
Appendix I (attached to the document) shows the sequence diagrams for the future business processes.
Internal interface users:
- Legal officers
- Clerks
- Court webmaster
External interface users (via Internet ) / no authentication required
- Judges of the Supreme court
- Other judges, prosecutors, attorneys
- Citizens
- Academics
- Foreign legal professionals and academics (especially in Greece)
External stakeholders:
- Government Publishing House, that currently participates to the selection of the contractor for publishing
- Bar Association and CyLII, the non-profit company that manages the Cylaw portal.
The new system will interact with the following existing systems:
- Court case management system: now it is not interacting, but it would be advisable to make sure that all decisions that are candidate for publication are made available via the CMS (automatically or upon selection by the reporting judge, depending from the type of case) to the publication system.
- Court’s Active Directory services for the unified and integrated management of the internal users access profiles.
- Court’s library catalogue, integrated with the national public library web portal (OPAC): once entered into the catalogue as both printed holdings and ebooks (linking to the CLR website) the digital CLR issues can be found by a wider audience.
- Court’s website, to be extended with the CLR webpage.
The new system should interact also with the following system to be developed by the University of Cyprus:
- ECLI Cyprus database (ECLI Cdb): a database which will collect and store the European Case Law Identifier (ECLI) meta-data for all judicial decisions issued by Cyprus courts and share them via Application Programme Interface (API) with the European ECLI search engine[1], the Cylaw portal, Leginet and any other interested stakeholder.
The new collaborative CMS to support the editorial process of writing, editing and publishing the CLR substitutes the previous manual, email-based processes.
The new website for the online publication of the CLR adds functionalities that were not provided by any other system already in place.
Decisions for the CLR yet to be published from the previous years (since 2018 included) are stored in electronic form. Before proceeding with the publication it may be necessary to check once again that the set is complete.
It may be good to include in the search page also the electronic versions of the CLR published earlier (since the year 1989, when the publication switched from English to Greek language), at least the volumes for which the PDF is available (see the Data migration section below).
An indicative calendar of the major phases and milestones of the project implementation is outlined in the following table.
Table 3 – Phases, milestones and duration
D = Initial date of implementation = 15/01/2024
Deliverables ▼ |
Deadline for delivery ▼ |
Website for the online publication of the Cyprus Law Reports (CLR web) |
D+6M |
Collaborative Content Management System (cCMS) |
D+5M |
Subsystem 1– CLR Website: Phases ▼ |
Deadline for completion ▼ |
Initial configuration (hosting, system-level), web development, including graphic design and search function (Beta version) |
D+90d |
Online publication of the first volume (website online with initial content, but not publicly accessible yet) |
+15d |
Security vetting of the website prior to publication |
+15d |
Public launch of the portal with initial content |
D+120d |
Data migration. |
+60d |
The old issues of the publication are uploaded. The website is populated with legacy content as soon as this is processed, on a rolling base |
D+60d rolling |
User manuals |
D+105d |
Training |
D+120d |
System documentation |
D+6M |
Maintenance |
(ongoing, till end of contract) |
▼ |
Deadline for completion ▼ |
Initial development, including graphic design (Beta version) |
D+90d |
Revised, production version |
+30d |
User manuals |
+15d |
Training |
+15d |
System documentation |
D+5M |
Maintenance |
(ongoing, till end of contract) |
The consultants conducted two in-depth interviews via video-conference with the staff of the Court’s Legal publications unit on 12/4/2023 and on 21/4/2023. The second meeting was attended also by the manager of the e-Justice initiative and Court’s webmaster.
Additionally, two pre-assignment inception meetings were held via video-conference on 13/02/2023 and 24/03/2023 to discuss the overall beneficiary’s needs and scope of work, including the question of partially automating the generation of judicial summaries using state-of-the art generative models. The latter requirement was eventually assigned to a separate working group initiative.
On 27/04/2023 a virtual meeting was held with representatives of the Cyprus Bar association.
The Court provided a digital issue of the last published Criminal book of the CLR to the consultants, as well as other data about previous publication statistics.
The staff that manages the Court’s IT infrastructure were not available during the assignment for an interview and data gathering.
On 16/05/2023 an in-person validation meeting was held with the legal officers of the LP unit.
Part 1 – Business requirements for the collaborative Content Management System for the CLR publication |
BR1 – Business Requirement Roles, Views and Statuses § Description: Definition of the basic functionalities of the system § Priority: High § Scope: Users should be assigned different roles: Administrator, Clerk, Anonymiser, Volume Coordinator, Volume Contributor and Web-master. Roles should determine permissions to see and edit decisions and volumes (see Tables 1 and 2 and Note to Tables 1 and 2 above). Users should be provided with a List and Detail views both for Decisions and Volumes [in these specifications by Volume is meant what will become a CLR e-book, i.e. one per Part per year] and access to a dashboard showing how many decisions and volumes they can see there are for each of the Statuses. The Status of a decision and the Status of a volume should be automatically determined according to the processing stage or selected by authorised users. Simple statistical reports should be available § Benefits: Clear view by each user of pending tasks avoiding the need to check emails, possibility to monitor the progress of the publication process. § Need: Must have. § Test Approach and Acceptance Criteria: Import of a sufficiently large group of decisions and simulation of the whole publication process with all roles included. § Business Rules: The changes of status made by each user should be logged. Users will be allowed to change Statuses of decisions and volumes according to predefined transition rules (see Figure 3). Users will be also allowed to flag decisions with own tags, and to include such flags as criteria to filter lists. The List view will allow to sort and filter items, and clicking on each item it should be possible to open its Detail view or to open the last version of the item. The Detail view for an item will show the relevant meta-data, with the possibility to correct them, and allow to access the related documents as well as their previous versions. |
BR2 – Business Requirement Initial import of decisions § Description: Final decisions sent by email to Court secretaries to the LP clerk(s) are imported in the system with basic meta-data to identify them, are automaticaly parsed to add hyperlinks to jurisprudence and legislation on the basis of pre-defined rules to form the URL and when the manual revision/anonymisation is complete are assigned a Status based on given rules to be applied on its meta-data. § Priority: High. § Scope: The clerk should import decisions in the system from a chosen local folder, and the associated meta-data should be extracted from the names of the folder and of the file and saved in the system. The system should be ready also to import decisions and their meta-data from an Application Programme Interface (API) exposed by the cases management system used by the Court. § Benefits: Allow to initiate the processing of decisions with basic information without overloading the clerk with initial recording details (NB: the clerk should however take care that the names of files respect the given convention – see example in the Business Rules – which Court secretaries/e-Justice should ideally follow when the document is created). § Need: Must have – if the API will be already available at the moment of creating the system, the first part described in the scope (manual import from folder) becomes unnecessary. § Test Approach and Acceptance Criteria: § Business Rules: Imported decisions should be automatically assigned the “To be anonymised” Status and be associated other meta-data according to the name of the last subfolder where they are uploaded from and the name of the file if formed according to a pre-defined structure (example: “Pn-yyyy-nnnnnn” where Pn is the corresponding Part number of the CLR, “yyyy” is the year of issuance of the decision and “nnnnn” is the decision number). Files with names of files already successfully imported or badly formed should be skipped and a message should inform the user about which file was in which of these two situations. A button “Anonymisation completed” should trigger the new Status to be assigned on the basis of the decision’s meta-data. |
BR3 – Business Requirement Creation of decision summary along with meta-data and automated inclusion of relevant links · Description: Users should be able to input all elements of the decision summary according to a predefined structure, saving them for further use and for creating a formatted summary. · Priority: High. · Scope: Legal officers and clerks should enter structured data and textual parts. In the future, any tool for the automatic production of suggested summaries could be interfaced with the mask, filling some of the fields automatically. · Benefits: Legal officers can be assisted by clerks in filling part of the data (which in the future should be imported directly from the e-Justice system). Data will be used later for the automated production of indexes, streamlining the whole publication process, and for allowing successive searches in the Court web-page limited to specific fields. · Need: Must have. · Test Approach and Acceptance Criteria: The produced summaries should be well formatted and ready to be published. · Business Rules: Legal officers should be able to initiate the creation of a summary of a decision within the detail view, pressing a button “Summary elements” which will open the input mask where fields (already pre-populated to the largest possible extent) will be used for input and data will be saved for further use. For closed lists data (keywords, statuses and articles), typing the first letters should provide suggestions, based on the volume to which the decision belongs. It should be always possible to add elements to a closed list, but subject to confirmation. Another button “Produce summary” should create the summary in Word format according to the predefined formatting for each part (e.g. line numbers every 5 lines, italic, etc.). The system should automatically add hyperlinks to legal provisions (to Cylaw.org) and judgments (to the CLR volume if available, or to Cylaw.org, HUDOC and Curia). It should be possible also to save the formatted summaries as HTML files in order for the clerk to send (by email) to the webmaster selected summaries ready for publication. |
BR4 – Business Requirement Creation and preparation of Volumes · Description: Clerks should be able to upload a new Volume and to add decisions to it. · Priority: High · Scope: Clerks will continue to use the QuarkXpress publishing software, but the files will be saved in the cCMS database · Benefits: Having all process in one place, and possibility to include more than one clerk in the process of preparation. · Need: Must have. · Test Approach and Acceptance Criteria: Creation of partial and complete volume should proceed seamlessly. · Business Rules: Users with Clerk role should be able to upload a QuarXpress file as a new Volume, assigning it a title (based on the part) and year, and to include decisions which are in the status “Reviewed”, changing their status to “Included”. Decisions should be included in chronological order according to the decision date. Volumes should be composed with a clear hierarchy of headings, chapters, sections etc. in such a way that the generated PDFs have an internal table of contents (not necessarily “printed” on page) for easier navigation by users. It should be possible to delete a volume which is not in the status “e-Published” or “Printed”, and to replace it with another. |
BR5 – Business Requirement Automated creation of indexes and export of meta-data · Description: Clerks should be able to trigger the automated creation of indexes and meta-data packages for any volume they want to prepare for publication. · Priority: High · Scope: The indexes will be automatically created from the already saved meta-data. · Benefits: The preparation of indexes is one of the most time consuming tasks during the publication (after the production of decisions’ summaries), so that the whole process would gain in efficiency thanks to this automation. · Need: Must have. · Test Approach and Acceptance Criteria: Check the completeness of indexes and possibly compare with the index prepared with the previous procedure. · Business Rules: Users with Clerk role should be able to trigger the automated creation of indexes for any volume in the status “Open”. The indexes will make use of the available meta-data already stored in the system: one file with Front indexes (introductory text from a given template, cases sorted by alphabetical order of parties, by increasing number of case and by legal provision applied; separate page numbering) and one file with Index by keyword (no page numbering). These files should be added to the QuarkXpress file relative to the open volume, respectively at the beginning and at the end of the volume, replacing any previous version. A button should allow to download as zipped CSV file all meta-data associated to the volume. |
Part 2 – Business requirements for the online publication and search of CLR reports |
BR6 – Business Requirement Main publication page · Description: A main page should list all available volumes and leave to users the possibility to choose the format for opening and reading each volume. · Priority: High · Scope: The CLR main page should be created on a sub-site to be hosted and maintained by the supplier (unless otherwise decided by the SCC). · Benefits: Legal professionals and citizens will be able to read, download and search CLR e-books Volumes. · Need: Must have · Test Approach and Acceptance Criteria: Online reading · Business Rules: A main page should list all available volumes and leave to users the possibility to open and read each volume in-browser as flip book, scrollable PDF, paged PDF or ePUB, and to download each volume as PDF or ePUB. |
BR7 – Business Requirement Search page · Description: A search sub-page of the CLR main page should allow users to perform searches on all volumes available in the main publication page · Priority: high · Scope: The server-side search engine will rely on a database to store indexes and meta-data related to each decision as received from the cCMS as well as on the texts of decisions · Benefits: Increased value of the website for professional users · Need: Must have · Test Approach and Acceptance Criteria: · Business Rules: Boolean searches combining structured data (such as for example parties, thematic keywords or legal provisions) and free-text criteria (including in the decision) should be enabled. The results should show a list of the CLR volumes with the number of decisions which satisfy the given criteria, omitting volumes with no decision. Clicking on each volume, it should be opened and it should be possible to navigate among decisions satisfying the chosen criteria. |
BR8 – Business Requirement Clever pasting · Description: The user should be able to select and copy text from the volume, and have the possibility to paste together with the text (to be included between inverted commas) the full citation with reference to the CLR volume and page in standard format, together with a hyperlink which would open it at that page. · Priority: Medium · Scope: · Benefits: Increase the precision and productivity of professional users of the CLR website while ensuring that due credit is given to the source. · Need: Nice to have · Test Approach and Acceptance Criteria: · Business Rules: n.a. |
BR9 – Business Requirement Extraction of meta-data from already published CLR · Description: Starting from the PDF or QuarkXpress versions of past printed CLR volumes, the corresponding meta-data should be extracted and saved in the CLR website search database in order to make possible the search via the module · Priority: Medium · Scope: See the detailed specifications in the Data migration section. · Benefits: Migrating old CLR issues to the new digital platform allows to build a coherent and complete system of references to the Court’s jurisprudence. · Need: Nice to have · Test Approach and Acceptance Criteria: Random check comparison of meta-data and printed indexes / 5% of false negatives could be considered acceptable but no false positives should be found in order not to undermine the credibility of the website. · Business Rules: n.a. |
BR10 – Business Requirement: Data and systems Security § Description: To ensure that the content of the publications' website are not interfered with by hostile actors. § Priority: High § Scope: For session (data in transit) security installation of a Domain Validation (DV) + Organization Validation (OV) SSL Certificate provided by the Ministry of Justice, or Ministry of Finance, or Department of Information Technology Services. Besides, the Supplier will outline the security best practices they intend to follow at the code and system levels, e.g. avoiding obsolete libraries, unmaintained plugins, read/write permissions in the server file-system, application level firewall (WAF), etc. Anti-DDoS protection should be factored for both volumetric and application layer attacks. The Supplier has to monitor the web application 24×7×365 from security threats and ensure its uninterrupted functioning. The Supplier shall provide high performance tools for securing the site from hacking. Necessary alerts also need to be configured for a Court’s specified email address. § Benefits: increased security § Need: Must have § Test Approach and Acceptance Criteria: Security validation with scanners like Acunetix or Burp or similar tools, probing for vulnerabilities before taking the website online. The website shall be cleared for publication until all high and medium vulnerabilities are eliminated. § Business Rules: n.a. |
The following requirements apply to both systems – the intranet collaborative Content Management System and the CLR website – to be developed under this assignment.
Visitors’ journeys shall be defined for every targeted segment. In keeping with the main site design, pages shall not be cluttered, adopting ergonomic navigational aids like flip-cards displayed upon hovering on clearly marked icons or question marks signposts.
Specific features of the interface:
· Dark / light modes options tested (independently on the theme and graphic design)
· Compatible with the main browser engines: Blink, Webkit, Gecko
· Ergonomic and easy to use
· Fully responsive, adaptive to high and low bandwidth, and ready for high resolution modern displays
· User interface language: Greek. The main Court’s website is bilingual in English and Greek, however the new CLR publication will have content in Greek only.
Interface requirements specific to the CLR webpage:
· The sub-site object of the present intervention will be an extension of the main SCC’s website and shall blend with its graphic style, adopting an easy and intuitive navigation.
· The visitors’ shall be able to journey seamlessly between the main site and the publication sub-site – regardless of the fact that the latter might be hosted on a different 4th-leve subdomain on a different server.
· Navigation reproducing the same main menu as the parent (main) site.
· Ensure that the core content of the website (excluding advanced functions, e.g. search) is accessible and readable even if JavaScript is disabled in the users’ browsers, for better accessibility and user security. A clear message should be displayed informing the user that enabling JavaScript is recommended for the best user experience on the website.
· The interface will use tags, categories, and other content structuring semantics.
· Deep linking with permanent, search-friendly links
· SEO optimization to allow the highest possible ranking of the individual pages within the site from all major search providers, including, but not limited to, Bing, Google, DuckDuckGo.
· The sub-site should provide Meta title and Meta descriptions tags that are maintainable and able to auto correct and/or provide results that best match misspelled words or phrases. The search feature should be able to search both HTML pages and documents, such as PDF files and Microsoft Word documents.
· Option to download, print, CLR volumes.
· Automated XML and HTML maps.
Interface requirements specific to the intranet cCMS:
· A key functional feature described above with direct implications on the interface designs is the ability of users to open files stored as objects on the CMS and edit them with their favourite desktop applications, while saving them seamlessly on the CMS (i.e. no manual download, edit, save locally, manual re-upload to CMS). In order to simplify the implementation of this function, concurrent local editing of the same file by more than one user is not required and the file being edited will appear as locked to the other users. This trade-off allows to save development costs and is justified on the basis of the small number of users in the system.
· The ability to seamlessly edit locally the files stored on the CMS shall be accomplished at least for the following desktop applications: MS Word, LibreOffice and QuarkXpress for the Windows operating system that is prevalent in the Court’s digital ecosystem.
Accessibility
In keeping with the policy already adopted on the main website, the sub-site should be easily accessible complying with W3C standards, namely the Web Content Accessibility Guidelines, WCAG, as part of the web accessibility initiative. These standards, recommended inter alia by the European Union, strive to ensure that as many users as possible with a variety of different abilities will be able to access online content, for example always adding a descriptive ALT tag to images, avoiding text embedded in images, etc. and providing easy integration with voice search facilities offered by third-parties (e.g. user’s device operating system).
Modern web technology
Both systems (CLR website and editorial workflow support CMS) shall be developed in modern web-app frameworks (e.g. but without prejudice of other proposed solutions, NodeJS+Javascript, Django+Python, Ruby-on-Rails, etc.) separating the backend from the presentation layer communicating via API calls. React, or Angular frameworks shall be preferred for the frontend (presentation layer) development. This will afford a better user experience, higher rate of technological innovation and long term support from the community.
In order to contain development time and costs, an approach leveraging existing open-source frameworks, libraries and components is to be preferred.
CMS internal users according to the access profile:
User category |
Functions and duties |
User profiles |
Supervisor |
Oversees the content and editorial process at different levels. Authorizes the final online publication. Authenticated access to intranet services. |
Supervising judges (including the Court President); Head of Legal publications unit. |
Editor |
Draft content (decisions’ summaries) and changes their status on the CMS Authenticated access to intranet services. |
Legal officers |
Production |
Collect contributions from the editors; archiving; formatting and producing the digital CLR in various formats. Changes the status on the CMS. Authenticated access to intranet services. |
Legal publications' secretariat. |
CLR webpage users according to the access profile:
User category |
Functions and duties |
User profiles |
Administrator |
Can modify the content and structure of the sub-site, liaising with the Supplier for technical interventions and maintenance. Authenticated access to sub-site administration interface and intranet services. |
Court’s webmaster |
Editor |
Assists the webmaster in their tasks, in particular ensures that the website’s internal links are functioning and the search engine indexes content correctly and returns meaningful results to users’ queries. Authenticated access to sub-site administration interface and intranet services. |
Assistant webmaster |
External users (no authentication required), readers:
- Judges of the Supreme court
- Other judges, prosecutors, attorneys
- Citizens
- Academics
- Foreign legal professionals and academics (especially in Greece)
There are no special operational standards, e.g. military grade, to be followed beyond what is required by Law for civilian installations.
The Court’s website, as well as all other public institutions’, is hosted by the central government data centre, a facility managed by the Ministry of Finance. The current website runs on an HCL Lotus Domino web server. The Court’s webmaster liaises with a contact point at MoF for changes in the structure of the website, while having direct access to the publication of contents within the given structure.
At the time of writing it was not possible to ascertain from the requirements capture interviews (see section 3.9) whether the MoF has specific guidelines or constraints on the kind and size of web application they may host on behalf of other public institutions. Taking into account that the CLR and other contents are by definition of a public nature and that there are no confidentiality or strict security requirements (see dedicate section) Court’s officials have expressed their preference for an externally hosted solution for the publications sub-site.
The Supplier will therefore rent or otherwise provide a server with related connectivity as needed to implement the software solution and to ensure the quality standards as part of the overall provision of services. Given the highly specialized nature of the publication, and the limited size of the potential audience made of Greek-speaking legal professionals it is estimated that a virtual private server (VPS) with the following minimum hardware requirements will be adequate to handle the expected workload: 8 vCPU, 16 GB RAM, 160GB storage, 20TB annual traffic, EU location. The Supplier will set up and configure the needed server software (system and application level) as appropriate.
Taking into account that the main publication will consist of a collection of static PDF files that are seldom updated once published, an appropriate configuration of web caching and CDN delivery can greatly improve the system responsiveness and user experience, while at the same time decreasing the web server workload.
Storage needs estimation |
|
Number of books per year: P1 (civil law) in three volumes, P2 (criminal law), P3 (administrative law) |
5 |
Sample book size (Criminal law 2017), PDF format |
11 MB |
Estimated average book size, PDF or EPUB format |
20 MB |
Storage needs per year [MB] for PDF + EPUB |
200 MB |
Storage needs per decade of publications |
2 GB |
Given the type, amount, low update frequency of the data to index (without OCR needs), the minimum server requirements above are sufficient for running a minimum, one-node, self-hosted search engine alongside the web server and database server for a medium to low traffic website. If this should not be feasible, it is recommended that the Supplier opt for search cloud services (e.g. Algolia) rather than increasing the number, or capabilities, of servers dedicated to this task. This will ensure an overall more efficient use of resources at a lower cost. At the same time, the non-confidential nature of the publications does not require the additional level of privacy normally ensured by self-hosted services.
The overall solution shall be based on free and open source software for web, database, caching and in general other server software, as appropriate to fulfil the service level and performance requirements. This will ensure that the best industry standards are followed and avoid licence recurring fees and lock-in.
The web server communications to and from the users shall be encrypted with standard SSL/TLS secure socket layer technologies.
On the Court’s premises there are no additional hardware requirements.
The new system shall be hosted on a server on the Court’s intranet. With no more that ten concurrent users and computationally average to low intensity tasks (web server with dynamic web applications, database server, file server), the expected workload can be met – with margin to spare – by any modern small business server, or virtual equivalent, with similar features as those specified above, i.e. 8 cores/vCPU, 16 GB RAM, 2x 1TB SSD storage (RAID1), gigabit ethernet connectivity.
If the Court’s IT infrastructure already can count on a similar server with spare capacity, either metal or virtualized on their hypervisors, the new system could be hosted there. In this case the Court will specify at a later stage their operating system of choice and other possible constraints. Otherwise, the action may provide financial resources to procure new hardware, a mono processor, multi-core, small business server with CPU e.g. Intel® Xeon® E-2314 2.8GHz, 8M Cache, 4C/4T, Turbo (65W), 3200 MT/s or equivalent AMD;
RAM 16GB UDIMM, 3200MT/s, ECC; storage 960GB SSD SATA Read Intensive 6Gbps 512 2.5in Hot-plug AG Drive,3.5in HYB CARR, 1 DWPD, software RADI1; gigabit ethernet.
Other ancillary infrastructure requirements, like UPS, networking, incremental backup etc. shall be provided by the existing Court’s IT services.
The Court’s webmaster shall have remote access to the publications sub-site CMS via web-interface for editorial work.
The Supplier shall have remote access to the VPS for system administration (SSH) and to the sub-site administrative web interface for maintenance and upgrade work (site structure, plugins installation etc.) during the period of the contract.
Access to the cCMS is limited to intranet users according to the Court’s access policy (e.g. as defined in and managed via Active Directory).
There are no changes to the Court’s current operational security procedures. The remote VPS is a virtual server hosted on a larger machine in data centre. The hosting machine will be accessible physically by the data centre staff for maintenance, as regulated by the data centre terms of service.
The data centre administrators will have also software access to the contents of the VPS, including its RAM, via the Hypervisor control panel and other tools.
The Supplier shall have remote software access at root level to the VPS via SSH.
The Court’s staff shall have remote software access as CMS users via web interface.
The intervention shall not modify the current Court’s business continuity plan for its internal operations. The following refers only to the publications’ sub-system:
Disaster type |
Coping approach |
Implementation |
Responsibility |
Loss of access credentials to VPS / CMS |
Archive redundancy |
Password manager (individual level) |
Court’s IT department, webmaster, Supplier |
Virtual filesystem failure |
On-system redundancy |
Incremental back-up, encrypted, hosted on cloud services |
Supplier |
Hypervisor filesystem failure |
On-system redundancy |
RAID-like |
Hosting provider |
Server failure |
On-site redundancy |
Replica system in sync with the main one, ready to go live |
Supplier for both system and application level |
Site failure |
Off-site redundancy |
Full content back-up, encrypted, hosted on cloud services |
Supplier + Hosting provider |
CLR website.
The Supplier shall be responsible for the system-levels backups (operating system and server configurations).
The Supplier shall be responsible for the application-level and full content backup following industry best practices.
Intranet cCMS.
The Court’s IT services shall be responsible for the system-level (operating system and server configurations) and content backups.
Both databases – CLR website and cCMS – shall have a Point in time Recovery of no more than 3 hours. The code must be validated in unit, integration and end-to-end tests. The encrypted backups should be hosted off-site on the infrastructure of either a reliable commercial cloud service, or another government-provided storage service, following modern DevOps practices.
Performance, speed and latency: the overall system response time should match industry standards for user interface design, taking into account the limits determined by human perceptual abilities, ultimately evaluated by user satisfaction metrics.
Reliability and Availability: minimum downtime as compatible with scheduled maintenance and in any case confined to time slots of very low user engagement.
Length of expected use: five years with ordinary maintenance.
Security: as detailed in the specific section.
The contents of the publications sub-site are not subject to confidentiality requirements.
Service level maintenance timing
Severity Level |
Initial response |
Temporary Resolution |
Final Resolution |
1 - moderate |
1 hour |
4 hours |
7 days |
2 - medium |
2 hours |
48 hours |
14 days |
3 - high |
3 hours |
7 days |
30 days |
"Initial Response" means a verbal, written, or electronic response, in each case non-automatic, from the Supplier to the beneficiary regarding a reported or discovered error.
"Temporary Resolution" means a temporary fix or patch to bring the functionality of either the cCMS or the CLR website back into compliance with the Documentation until a Final Resolution is available.
"Final Resolution" means a permanent fix to bring the malfunctioning service functionality back into compliance with the Documentation.
The Supplier shall provide the technical documentation for both systems (cCMS and CLR website), thorough and complete in line with industry standards, in particular specifying:
§ Functional and technical specifications as implemented
§ The user manuals for authenticated users (if based on an off-the-shelf open-source solution like e.g. WordPress it is sufficient to refer to the online documentation and just explain how the actual solution differs from the standard one).
§ Known errors and workarounds
§ The commented source code
A constitutional reform of the justice sector will enter into force in the coming months, probably leading to an increase in cases brought to the Court and therefore to a need to increase the efficiency of the legal publications editorial processes as a whole and the resources allocated to it.
The new e-Justice case management system deployment. After a pilot phase during the summer of 2023, the new case management system is expected to go live in September 2023. The new system will be directly managed by the Court, and is supposed to include at a later stage the ability to provide a public facing web page for the publication of decisions. However, it does not include tools for the editorial development of legal journals or annual reports and their online publications. There, there is no overlapping with the present intervention. On the contrary, the new publications CMS could be seen as a natural extension of e-Justice’s capabilities with an increased process efficiency once the two will be linked via API as described in the business process section above.
Digital copies of most of the previously published decisions already exists in either the Court’s case management system or its archives as MS Word and/or PDF files.
The QuarkXpress licenses do not need annual fees or renewal, and the version in use will not be discontinued or will be replaced by a new one at no additional cost.
The capacity of the Court’s legal department in processing the current backlog and increase its output in producing the CLR will increase, thus providing up-to-date content for the new publications sub-site.
A new, fourth part of the CLR dedicated to Constitutional law that would result in an additional volume per year will not actually be included in the publication.
The Supplier will be able to fulfil its contractual obligations for the whole duration of the contract.
At the end of the five years contract period, and after a successful evaluation of the project, the Court will either have the financial resources to either extended it or to migrate the publications sub-site on its own – or government-provided – infrastructure, thus ensuring the sustainability of the intervention.
The current hosting of the Court’s main website by the MoF will continue. The Court’s management approves the modification of the Court’s website and the addition of the CLR section.[As per an email communication dated 28/04/2023 this authorization has already been granted].
The upstream governmental institutions that regulate, approve and host the Court’s internet infrastructure and services – Ministry of Justice, Ministry of Finance, Department of Information Technology Services – will:
1. Authorize that part of a governmental web service can be hosted on commercial infrastructure.
2. Provide a 4th level sub-domain name for the new publications sub-site, e.g. clr.supremecourt.gov.cy (or equivalent), pointing to the new server hosting the publications sub-site.
3. Issue the Organization Validation (OV) SSL certificate for the new publications sub-site in order to secure web communications with it.
The Court’s IT general infrastructure and technological policies allows for the installation of a new small business server on the Court’s premises to host the intranet CMS to support the CLR editorial process. Alternatively, the Court may already have spare hosting capacity on their current infrastructure to host said system, e.g. on dedicated hardware or on a virtual server.
The Court’s IT services have spare capacity to provide the new intranet CMS system with ancillary infrastructure services like UPS, networking, incremental backup etc.
Time constraint: the Donor’s policies and budget execution regulations require that the project should be completed before the TJENI project conclusion in April 2024.
Availability of the source files (i.e. MS Word originals, or QuarkXpress or other desktop publishing software files upstream from the production of PDF output) of the old issues of the CLR printed for the years before 2017 may limit the searchability of old volumes posted on the website, and the availability of PDF versions will limit the number of volumes posted.
A broad risk analysis for the new system is summarised in the following table.
Category |
RISK |
Impact |
Probability |
Overall |
Proximity |
Current Mitigation |
Assigned to |
What type of risk this is? |
RISK TITLE |
Severity of the risk occurring (from 1=Low to 4=High) |
Likelihood of the risk occurring (from 1=Low to 4=High) |
Overall rating reflects the combination of Probability and Impact |
When is the risk likely to occur (in X months) |
Specific measures in place to counter the risk |
The person appointed to keep an eye on the risk |
Security |
HACKER ATTACK: Data encryption, ransomware that disables the website |
2 |
2 |
1 |
anytime |
Security policy. |
Supplier |
Security |
HACKER ATTACK: defacement |
2 |
2 |
1 |
anytime |
Security policy. System, application and content restore from backups |
Supplier |
Infrastructure |
FIRE or other PHYSICAL DAMAGE to the servers |
4 |
1 |
1 |
anytime |
Security policy. System, application and content restore from backups |
Hosting company, Supplier |
Procedural |
SUPPLIER’s FAILURE |
3 |
2 |
1.5 |
6 |
Vetting during tender |
CoE’s project manager |
Communication |
SUPPLIER MISUNDERSTANDS REQUIREMENTS: |
2 |
2 |
1 |
2 |
“Agile” approach to development, continuous feedback from users |
Supplier, SCC’s webmaster |
Resources |
HUMAN ERROR (rm -rf /) |
4 |
2 |
2 |
anytime |
Security policy. |
Supplier |
At the time of writing, communications between users and both the Court’s website and Cylaw are not secured with standard SSL/TLS encryption layers. This results in all modern browsers to throw a security alert. While probably most readers will overrule the browser’s alert and proceed to the site anyway, this exposes them to several risks. Although it is out of the scope of the current assignment it is worth recalling that these are to be taken seriously. Considering that these websites are frequented by the whole community of legal practitioners in Cyprus and beyond, the current situation potentially enables malicious actors to monitor all interactions on the sites, building profiles of users’ interests. Miscreants could also surreptitiously inject malware in the unencrypted packets flowing from say Cylaw to a lawyer or judge’s web browser, thus infecting their PCs with a range of exploits, from total stealth surveillance of their digital life to blackmailing via ransomware threat and so on. It therefore highly recommended that communications with the main Court’s website and those of other key publishers of legal information like the CyLII foundation (Cylaw) are secured as soon as possible according to standard practices.
Decisions as signed by Court’s judges, sent by email as MS Word files (as well as hard copy for the record), are the main input to the Legal Publications unit.
The Legal Publications unit produces the CLR annual reports in digital format (PDF and ePUB) which are fed to the Court’s webmaster for online publication.
For each decision processed by the Legal Publications unit, its secretariat logs the main coordinates of the decision (date, number, parties involved, etc.) and compiles statistics that are reported to the Court’s Registrar’s office on a monthly basis.
The webmaster will similarly compile access statistics reports about the publications' website usage (provided by the web analytics component of the project) and report them periodically to the Legal Publications officers and to the Registrar’s office.
According to SCC data reports, there are an average of 560 decisions per year to be published for the years 2020-2022, i.e. spanning all three parts (civil, criminal, administrative law). Taking a longer view to the past, there are approximately 21 thousands Supreme Court’s decisions on Cylaw’s database since 1/1/1990, for an average for 630 per year.
As a rule, old issues of the CLR that have already been published in print and for which a digital version already exists in the Court’s archive shall be included in the digital publication, automatically indexed and made searchable from the user interface. In order to accomplish this functional requirement, it might be necessary to improve the quality of the existing PDFs.
Where possible, the Court will provide the Supplier with the source files, i.e. MS Word originals, or QuarkXpress or other desktop publishing software files upstream from the production of PDF output.
If this will be necessary and the source files are available, the Supplier will re-generate the PDF files – in principle one file for each month, for each annual book for civil (3 volumes), criminal and administrative law – of each issue taking care of:
· Producing PDF files optimized for online publication.
· Strictly maintaining the same pagination as the original printed volume
· Extract the relevant meta-data from the indexes of the volume
· If resources allow: Generating a well-structured table of contents, for better in-document navigation and external linking taking into account that each decision has the following typical outline (sections):
◦ Date of the judgement
◦ Parties
◦ No of Appeal
◦ Names of judge(s) issuing the judgement
◦ Thematic keywords with a brief summary of the legal matters/questions of the case.
◦ Summary of Facts and Reasons of Appeal
◦ Decision by the Appellate court
◦ Referred Case-law (names of cases that the Court was based to issue its decision)
Each volume includes an average of approximately 100 decisions (taking 500 decisions per year split over 5 volumes, three for civil law, one each for criminal and administrative law).
A further step for the full migration of the old CLR issues requires the re-creation of the metadata for each CLR volume in order to make them suitable for structured – field-based searches from the web interface. In particular, the thematic keywords included in the CLR for each decision.
Each CLR volume already includes several indexes with the following keys:
· Parties to the case, in all possible permutations (i.e. “Doe, John v. Appleseed, Jane ... page 100” and “Appleseed, Jane v. Doe, Joht ... page 100” are both listed)
· Appeal (or application) number
· Law / article referred to in the judgement
· Thematic keyword, followed by a short excerpt from the corresponding section of each summary.
The page number within a given volume corresponding to each key is just printed in the PDF file, without and internal link that would allow the user to jump from the index to the corresponding decision, thus limiting the ergonomic quality of the reading experience.
Taking into account that the CLR are consistently formatted, and thus the internal sections for each decision are clearly identifiable, the supplier will be able to automatically parse and extract from the digital copies of the old CLR issues the metadata corresponding to the indexes and migrate them into the web search database thus enabling the structured search function. Among all the metadata, the thematic keywords are or particular interest because the structured search function using them as main key across all CLR volumes is not currently present in the other public online repositories of Cypriot case-law.
Once the old CLR digital issues are aligned with consistent table of contents, filenames, internal reference links, it will be possible for the search engine to implement deep linking to them at the decision level using the #named_destination (if available[2]) or #page linking technique.
Estimation of the maximum number of PDF files that may need to be regenerated |
|
Number of books per year: P1 (civil law) in three volumes, P2 (criminal law), P3 (administrative law) |
5 |
Number of PDF files per book containing decisions (i.e. excluding printed indexes and ToC): 11 |
11 |
Number of PDF files per year |
55 |
Number of years of past CLR publication for which the source files are available (from 2008 to 2017, included) |
1010 |
Total estimated number of old PDF files to be refreshed |
550 |
The Supplier shall provide the technical documentation for the system, thorough and complete in line with industry standards, in particular specifying:
.Functional and technical specifications as implemented
.The user manual for the cCMS (intranet)
.A concise user guide for the CLR website
.Known errors and workarounds
.The commented source code
Following the assumption that documentation is part and parcel of the overall product, the SCC will be involved in the production of the documentation following the same Agile approach to software development in order to ensure that the documentation is focused on users’ needs and answers to their expectations.
The supplier will keep the documentation up date in case of software updates.
The documentation will be released in digital format (PDF and/or HMTL and/or ePUB).
Training.
An initial training of 3 full-time working days, with full time presence of suppliers’ trainers on SCC premises (or remotely if this should not be legally possible, e.g. because of sanitary restrictions), during which, in separate sessions:
· the Legal Publications team will be trained on the use of the intranet CMS
· training the Legal Publications relevant staff on advanced QuarkXpress use for production of CLR ebooks in ePUB format and possibly HTML5 format.
· Training the Court’s webmaster on the use of the CLR website administrative interface.
· training the Court’s IT Department staff on the maintenance of the server hosting the intranet CMS.
A follow-up training period (2 full time working days) to be held not before than 2 weeks after the initial training week as reinforcement learning, troubleshooting, addressing users’ questions.
Ten (10) developer/days to be used in the period of 5 years starting from the date of the system acceptance to accommodate new feature requests (not including maintenance, bug-fixing etc. on the initial feature set).
The public facing CLR website shall meet the standard requirements for personal data protection as per GDPR and national legislation.
The systems shall retain their records and, where applicable, logs according to legal requirements.
Personal data protection as per EU’s GDPR and national legislation.
- End of document -
[2] The re-generation of the PDF files of all the old CLR issues in order to add internal references (e.g. headings) may not be feasible for technical or economic reasons.