Approach to the OAI4courts standard

Strategy

All metadata standards are compromises between completeness and accuracy of representation (on one hand) and ease of formulation and implementation on the other. Gathering support for any particular standard or set of standards requires momentum that can easily be lost in debate over minutiae. There is a built-in tendency to make the perfect the enemy of the good, when what is need are functional standards that are designed not to stand in the way of their own refinement at some later time.

Fortunately, OAI-PMH supports the use of multiple schemas. Only one is mandatory. The overall strategy imagined here is one in which successive schemas are created to provide increasing levels of functionality over time. And since practical interoperability involves agreement over many more things than metadata schemas -- for example, creation of metadata registries, agreements about how repositories are to identify themselves and their semantics, and so on -- I refer to these successive bundles of schema and surrounding agreements and apparatus as "Layers". They are meant to provide increasing layers of functionality, and to present increasingly difficult challenges for representation and consensus.

Layer One is the Dublin Core metadata representation required by the OAI-PMH standard. It is valuable in that it can provide a useful level of interoperability with repositories outside the legal domain (eg. public libraries and other kinds of collections) as well as a practical, easy-to-implement point of departure for legal repositories. Because it is limited to the use of unqualified Dublin Core, it incorporates a number of awkward compromises and clumsy but hopefully effective representations. [[wiki/lexcraft/oai4courts_layer_two_approach_and_what_youll_find_here|Layer Two]] is intended as the working standard for most repositories. It will be intentionally designed to be implemented as an extension to existing case-management systems, and to be quickly ratified by a wide variety of stakeholders. It thus avoids mandating the use of any metadata that requires human judgement, or that will require extensive deliberation as part of the standard-setting process. Layers Three and beyond are not specified in detail here, but are intended to be specified and implemented as a series of agreed-on extensions that take on more difficult representation problems such as tables of authorities, procedural postures, information supporting the construction of forward citators, and so on.

The picture of surrounding agreements, standards, practices, and registries needed to support each level is hazy. Obviously there are many places in even the Layer One schema that could benefit from some form of authority control. Equally obviously we will need agreement about use of collection-level metadata in the <description> element returned in response to an Identify request; this might in turn highlight a need for standard representations of the structure and naming of issuing authorities such as courts. Again, the trick is to maintain momentum ; we neither wish to get lost in details nor to design heedlessly.