Not that things have to or even ought to be done this way, but I wanted to just post some thoughts I have been having about markup and get them out there.
Jurisdiction: Should be presented like this in this order: 1.Country, 2.Jurisdictional Subdivision, 3.Court name, 4.Location.
Presented in this order, with just this order of priority, item 4 to be optional.
If it is done this way, everything will sort out.
The words "decision", "order", "opinion", and "judgment", and even "case" tend to be used both loosely and interchangeably to mean either the act that delivers a court's ruling in a particular case, or the text of the ruling itself. To make things even more confusing, a decision (in either sense) may affect (either dispositively or nondispositively) more than one case, and a decision (in the sense of the text that records the court's ruling) may consist of more than one document.
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:
As metadata standards for case law evolve, it will be necessary to identify certain entities, such as courts, in an unambiguous way. The simplest way to achive this is by adopting a standardized vocabulary.
URIs on the Semantic Web
The RDF / Semantic Web community has developed the concept of the URI as an identifier for non-document entities such as people and organizations. See, for example, Cool URIs for the Semantic Web.
Standards promulgated by the Open Archives Initiative are the basis for much of what is in OAI4Courts. Some of the basic standards documents are listed here:
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,
[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.