OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalcitem-courts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Court spec issues


(16) Since the technical spec contemplates feeding this data to a
resolver, we might want to specify the minimum combinations of data
that will resolve a cite to a unique reference. This may differ
depending on the reporting source, so a given court may have several
possible combinations that can lead to an unambiguous reference. Also,
the nature of fields might be specified -- specifically, the case name
could be specified as "fuzzy". It's not useful for a primary search,
but in the event of ambiguity, the item with the best Levenstein
distance on the case name could be selected, to resolve ambiguous
entries. Arguably that logic should be indicated in the specification.




On Mon, Dec 8, 2014 at 10:22 AM, Frank Bennett <biercenator@gmail.com> wrote:
> One further issue:
>
> (15) Many reporters cover decisions on a specific court. This hint is
> needed to render a correctly formatted printed citation. Should this
> information be required, where relevant, in OASIS citation data?
>
> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]