Re: Court spec issues

[Frank Bennett <biercenator@gmail.com>]

I have added field overrides to the source descriptions for all of the
neutral citation entries:

    http://fbennett.github.io/legal-resource-registry/us-neutral.html

The following two fields are currently required for all US cite forms.
These are always included, and should not be set in an override:

    casename
    jurisdiction

The following fields can be manipulated in an override. If omitted,
they will drop out. If included, they must have a value of "required"
or "optional":

    date-published
    volume
    reporter
    page
    decision-number
    date-decided
    docket-number
    court-place

You can propose edits to the field overrides with a pull request. If
additional fields are required, let me know (either via the
legalcitem-courts list, or by posting an issue to the project tracker
on GitHub).

Frank



On Mon, Dec 8, 2014 at 8:53 AM, Frank Bennett <biercenator@gmail.com> wrote:
> The LRR site now has a page showing all neutral cites.
>
>     http://fbennett.github.io/legal-resource-registry/us-neutral.html
>
> Frank
>
> On Mon, Dec 8, 2014 at 12:11 AM, Frank Bennett <biercenator@gmail.com> wrote:
>> I did some more work on the Legal Resource Registry this weekend. Highlights:
>>
>> * Rendering and exports can now be controlled via a plugin. This
>> permits individual consumers of LRR data (Free Law Project, OASIS,
>> MLZ) to refactor the data independently in a repo fork, in the form
>> that each requires.
>>
>> * Japanese courts now show English translations in title attribute
>> revealed on cursor rollover.
>>
>> I'm also close to implementing a dedicated page for neutral citation
>> forms in US courts.
>>
>> While pulling it all together, I spotted a few issues that might
>> benefit from discussion. They are listed below, in case they are
>> useful to the group.
>>
>> ***
>>
>> # Purposing and scope issues
>>
>> (1) CountListener uses the data for parsing citations out of plain
>> text. To validate and disambiguate citations, the date range of
>> reporters and the courts covered by them are useful information.
>> Should the specification include a framework for handling this
>> information, or is it out of scope?
>>
>> (2) MLZ uses the data for the rendering of citations. For consistency,
>> a full controlled list of court names and IDs is useful. Should the
>> specification include guidance on the composition of such a controlled
>> list, and for casting court IDs?
>>
>> (3) Should the specification cover the method of citing unreported
>> cases for a given court?
>>
>> (4) Should the specification cover the pinpoint method for individual
>> resources (such a page or paragraph)?
>>
>> (5) Is the aim to assure sufficient information in a cite bundle to
>> identify the target resource? Or is it to specify the core information
>> needed to fully describe a resource? Or both?
>>
>>
>> # Feature specification issues
>>
>> Features can have several classes of characteristics. Which of these
>> should be specified for a given field in a given source?
>>
>> (6) Whether the field is required or optional in OASIS cite data for
>> that source.
>>
>> (7) Whether or not the field is *essential* for identifying a specific
>> resource (the case name comes to mind as something we could expect to
>> required, but which is non-essential if other details are complete).
>>
>>
>> # Multilingual issues
>>
>> (8) Are transliterations and translations of court and reporter names
>> within the scope of the specification? If so, is the aim to assign
>> uniform values to individual resources, or only to provide a framework
>> for individual cites into which arbitrary values can be written?
>>
>> (9) Where there is an official translation of a resource (for example,
>> a court-sponsored reporting service), should that status of the
>> translation be recorded in the cite data?
>>
>>
>> # Court Identifier issues
>>
>> (10) Is the court identifier scheme of the LRR (loosely based on
>> URN:LEX) acceptable?
>>
>> (10) If so, is it sufficient to adopt a local logic for the segments
>> of a court identifier, or is a more rigidly consistent set of
>> requirements necessary?
>>
>> (11) Specifically for the US federal system, is it acceptable to adopt
>> the current pattern of setting a named segment for the federal
>> jurisdiction, and placing all bodies outside of federal authority in
>> the global national namespace? That is, US Supreme Court =
>> us;federal;supreme.court; and California Supreme Court =
>> us;ca;supreme.court.
>>
>> (12) When the constitutional foundation of court changes (say, Article
>> 1 -> Article 3), should its identifier be changed?
>>
>> (13) When the name of a court changes (with or without a change in
>> constitutional foundation), should its identifier be changed?
>>
>>
>> # Maintenance/workflow issues
>>
>> (12) Should the specification provide a procedure for recommending and
>> adopting changes when new services (such as a newly introduced neutral
>> citation form, or the appearance of a new court) are introduced?
>>
>> ***
>>
>> Frank