oai4courts layer two is intended to be a "working" schema adequate to represent most caselaw metadata using OAI-PMH. The approaches taken will also be useful to other caselaw-metadata efforts (for example, metadata that is embedded in case files themselves). Its place in the overall plan for developing the oai4courts metadata standard is documented here.
Elements vs. attributes
How do we choose between
Some courts publish decisions as a single document that contains all of the opinions (majority, concurrences, dissents) that comprise the decision. Others issue the opinions in different writings. The challenge is to contrive a model that is equally useful in either situation.
[merely a stub]
Court names and identifiers
Relationship with other courts
[[ NB: if you're looking for systems to use in marking up dates in judicial opinions, you might take a look at
Dates are a surprisingly complicated topic, with many subtleties and variations. That is because almost any milestone in the process of hearing the case and carrying out its resolution can have a date associated with it, as can any of the documents generated along the way. Every case will have a date of decision. Most appellate cases will have an argument or hearing date. Beyond that the varieties are practically infinite:
[nb.: if you're here looking for sane approaches to marking up names in judicial opinions, or in general, take a look at the relevant sections of TEI ]
(mostly a stub for now)
This page is an index of overview documents that describe, non-technically, different classes of element found in Layer 2 of the oai4courts caselaw metadata standard. They provide descriptions of the different logical entities described by the oai4courts Layer 2 elements, as well as pointers to each.
Note that these are intended for use in caselaw metadata (as opposed to caselaw markup), but some of the thinking involved applies to both.
Overview descriptions exist for:
Here's what you'll need to run oai4courts:
- A database package that works with Rails (mySQL, Postgres, and Oracle should all work, but see here), and that you're comfortable pushing data around with it
- ruby, of course.
- You'll need some additional gems
- appropriate gems for connecting with your database from the utility scripts you'll use to populate it
- login_generator for authentication (don't think this packages itself with the app, but it might).
- possibly additional gems to use with whichever relational database you're running -- see the database-specific information below
- Ruby on Rails.
- Capistrano -- a configuration and deployment manager -- is recommended but not required.
- the oai4courts package itself
The long version:
Sets and tags
OAI-PMH supports a system for the creation of sub-collections that it calls "sets". oai4courts adds database support for a less-formal system of tags. Sets are named according to a hierarchical system that implies an equally hierarchical partitioning of the database. Tags may be applied in any way you like.