Locator (bell) code data
Locator code data is used by GPO for typesetting government documents, notably the US Code. The system was created in the early 1980's and is still in use today. It is basically a highly modal system that uses escape sequences to encode typesetting commands, similar to procedural markup coding used in older word-processing software. The documentation here is somewhat aged material obtained from the House LRC by the LII in 2000 or so.
DC element usage
These approach reflects decisions and definitions documented here.
Name of the case. It is expected that party names will be embedded in this title in a way that will allow user-space applications to parse them easily, eg. Atlantic Dental Products v. Bruce.
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.
Implementation scenarios: where does the metadata come from?
OAI-PMH repository implementations consist of request- and error-handling scripts that draw on a relational database (RDBMS) for the metadata they deliver. In practice, this is because implementations that relied on real-time extraction of metadata from documents in a file tree would be unacceptably slow. So for practical purposes the question becomes one of how the metadata finds its way into the RDBMS, and that in turn depends on the nature of the documents themselves,
Where does this fit?
Level One is the first metadata schema implemented in OAI4Courts, and corresponds to the mandatory unqualified Dublin Core schema required by OAI-PMH.
[this is mostly a placeholder for now -- unedited notes follow]
Here's what we have in mind:
This example is the identifier for the majority opinion in NY Times v. Tasini.
It breaks into
-- the scheme oai_lii should be the same for all identifiers, everywhere, and
be associated with a series of standards documents and formal xml schemas.