Many legal decisions, or case results, on national and international levels are available online - but are not accessible enough. The information is stored in opaque formats, with inadequate metadata and frustrating search tools. The aim of this project was to create a framework for Case Law as a Service (CLaaS), that is, a platform architecture that allows users and diverse applications easy access to case law.

CLaaS is at the same time an API for accessing cases, software to manage such cases, and an app ecosystem with a store to manage basic applications with added views and functionality on top of it. CLaaS will integrate into social media to include collaboration features like comments, preferences, recommendations, personal bookmarking and reputation.

The following design sketches were done to provide an idea for possible interfaces to the system.

• Crawl + Identify → Datasets of Cases
• Analyze + Classify → …
• Structure + Design → …
• Apply + Applications → …

Should we try to structure the law? Is it possible? Does it make sense? If yes - how?

Christian: Structure: Rule+Exception, Hierachy, Comment, Decisions, Statute Citations,

Jörn: Decision Tree - Pros and Cons

Christian: KMT: Tags, Context-Content but no rules

Florian: Case law search engine for cantonal, federal and international cases - efficient, open and transparent

Florian: Order and visualize case law: Leading case, last cast, heat maps, statistics, time line, graphs

Alexander: better search engine, will provide crawling

Christian: Visualization: Automatically attribute metadata to legal rulings in a case that facilate reading and understanding it (like rule, exception, references, hierarchies (major term), conditions+consequences, extension or restriction of rule)

Jean-Henry: Basic Infrastructure/Kernel for crawling, indexing, searching, basic structuring and then layers on top that visualize, condense, explain the law

Jörn: Annotation of court rulings and annotation of rule of laws with statistics on links, cases etc.

Jean-Henry: Simple kernel with API, second layer with hight functionality, third layer with applications

• Definition of potential Use Cases
• Break down into layers and functionalities
• CLaaS - Definition of API-layers

• Crawler
• BGE data: http://repository.opendata.ch/bundesgericht/
• Swisslex metadata
• merge data
• implementation of API? - Rather proof of concept! of some use cases than partial implementation of API

• Language
• area of law (2 levels)
• Object
• dossier number
• decision date
• cases cited (journal)
• cited by cases, journals
• article
• laws cited

A simple prototypical conversion of metadata to linked data can be found here: http://erbguth.net/CLaaS/caselaw-rdf.xsl. To extract the text we used this script: http://erbguth.net/CLaaS/caselaw.xsl

Workflow of a Juge deciding a case

1. Facts triggering a dispute
2. Trigger opening up the legal conversation, lawyers call it „question presented“ („Rechtsfrage“)
3. Methods to limit the conversation to some areas of the overall legal landscape (for efficiency reasons)
4. Exchange and weighting of arguments (dialectic)
5. Decision („Law is a Conversation and the Juge makes the final statement“)

Arguments

1. Basis of the model: Arguments are in the center of each case
2. What is an argument good for?
   1. Pushes forward a question presented to bring it closer to the decision (resolution of a case)
   2. Holds as an abstraction of a solution found in a specific case
3. Arguments have a texture
   1. Some allow to make general statements
      1. Rule: „As a rule, …“
      2. Exception: „In exceptional cases, …“
   2. Some allow to describe certain mechanisms
      1. Conditions for a consequence to kick in
      2. Consequences
4. Scope
   1. Arguments may apply only to a limited scope
5. Arguments may be found in a variety of sources
   1. Statute (article of the law; „an article in an statute is nothing else but a very strong argument“ – reason: agree by many)
   2. Case Law
   3. Theoretical text written by a legal writer

Elements helping to further describe an argument

1. Nature of the rule („Rechtsnatur“)
   1. Purpose: Helps finding the judge / the lawyer to limit the conversation to what is in fact relevant
2. Scope of the rule („Anwendungsbereich“)
   1. verortet innerhalb der Landkarte; hilft, systematisch zu sein
3. Technical Terms („Begriff“)
   1. Are good to make a conversation among experts more efficient
   2. Terms have definitions
      1. Each definition has elements
4. Comments / Catch-all
   1. Sometimes it may occur that a judge or a legal author discusses issues that are not pushing forward the case towards a solution
5. Obiter dicta
   1. Mentions that are not needed to push the conversation towards a solution
   2. Are commonly used by judges to flag to the audience that future cases may be decided in a different manner (for transparency / notification purposes)

In order to illustrate the potential of such a system, the components of which are not all available or open today, our team has worked on a number of prototype sub-projects:

1. Online case history crawler: based on data of the Swiss Federal Supreme Court, Alexander has built a custom search engine which can be accessed here: Demo server. For further information see: Swiss Supreme Court
2. Linked Data: cases should be linked on the Semantic Web. Reto and Jörn have built a translation into linked data (RDF). Tools based on linked data can immediately be used to search and interact with information. Check out the Demo server and SPARQL query API for advanced users. Further background here: Case Law Linked Data

Collecting a large number of cases will however make it even more difficult to find the right cases - there is a definite danger that many cases will simply end up being massive walls of text and lists. The following types of visualization should prove to be useful:

1. Visualise one case: Cases are often long (10-30 pages or even more) and it is time consuming to identify rules and reasonings of the court. Cases can be annotaded with Icons and the reasoning can be displayed in a structured manner (Case matrix) (Christian and Franziska are preparing an example case preparation for that) This is listed as a seperate project Case Law Linked Data
2. Visualise a list of cases: Hitlists and other lists of cases can be annotated with easily accessible information by icons indicating case outcome, type of case, type of reasoning, area/region of the court etc.
3. Visualise the connection between cases: Cases often cite each other. This can be displayed in graphs that also convey further information (metadata).
   
4. Geographic visualisation of a large number of cases: When a search retrieves a large number of cases (1000 or more) it is impossible to even glimpse over this list of cases. Facets help there but are not easily comprehensible because they just consist out of text and many numbers. A graphical visualisation helps, and by tracking cases over time it can actually be an analysis tool. The project is documented here: European Court of Human Rights Case Law Visualization.
   

• Use the data to prototype the platform further
• Combine different data sources
• Develop an effective social integration

• Jean-Henry Morin, UNIGE Information Systems Security “Security is bypassed not attacked” (Idea+Des+Dev)
• Jörn Erbguth http://swisslex.ch, http://erbguth.net
• Julius Chrobak, http://mingle.io “Query API for open data” (Dev)
• Christian Laux, Laux Lawyers “IT Law is our passion” (Idea)
• Alexander Poltorak, Free IT Foundation “Open Hardware & Free SW” (Idea)
• Lionel Lourdin, Free IT Foundation “Open Hardware & Free SW” (Idea+Des)
• Florian Ducommun, HDC Lawfirm, CC “Please copy & share my work”
• Oleg Burlaca, Ketse
• Friedhelm Weinberg, HURIDOCS “Make available and accessible human rights case law around the world”
• Franziska Nyffeler (Des)

• CC BY-SA
• AGPL