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: [legalcitem-courts] Usecase--US Federal Courts draft


To follow up on the scope issue, if the aim (or one aim) is to specify
minimal data that can be derived from the text, for the purpose of
generating a key for submission to a resolver, would this work for
cases:

    type (decision)
    court (id)
    docket number (string)
    decision date (date)

For the "court" element, an ID would be preferable to the court name,
since the latter can change without any change to the institution
proper.

Resolution would return further details (cites for each reporting
service carrying the case, with case name, etc.); the suggestion above
is only for the "handle" that uniquely identifies the case.

(Whether this makes any sense will depend on the scope of the
endeavor, of course.)


On Thu, Dec 11, 2014 at 7:31 AM, Frank Bennett <biercenator@gmail.com> wrote:
> John,
>
> Looks like a good start!
>
> This raises some questions about scope, I think. (The questions
> themselves are at the end.)
>
> Printed citation forms identify the resource, but involve a step of
> interpretation for several of the elements. We would need to know
> those should be cast in the electronic representation of the
> reference. Taking the first example ...
>
> (1) case name string
>     Is there a formula or a set of constraints for deriving this from
> the header information in a judgment? If it must be uniform across all
> citations to the case, it should either be possible to derive it
> programmatically, or there should be a canonical version of the case
> name somewhere that can be acquired via a resolver, using other
> elements that uniquely identify the case (I guess that's the middle
> layer in FRBR).
>
> (2) volume number
>     This would be an integer for this category of citation. Is it safe
> to specify it as an integer, or are there exceptions that would
> require more flexibility?
>
> (3) reporter abbreviation
>     As the LRR shows, there is a lot of variation in reporter
> abbreviations used in the wild (spacing, punctuation, abbreviations).
> If it is used as an element in an electronic representation of the
> reference, the abbreviation will need to be consistent across all
> references. How is it to be derived? The choice would seem to be
> between a canonical list of reporters and corresponding abbreviations,
> or the full name of the reporter. A secondary consideration would be
> whether the elements embedded in a reporter abbreviation (journal +
> series) should be broken out and represented separately.
>
> (4) first page number
>     This seems an integer. Same question about constraints as for volume number.
>
> (5) pinpoint page numbers
>     Pinpoints can include references to page numbers, note numbers,
> and possibly other document elements. Should these elements be
> specified, or is a dumb string sufficient?
>
> (6) circuit justice if applicable
>     This raises a question of whether the spec is aimed at full
> description of the resource, or at pinning down the essential
> information needed to unambiguously identify the resource. If the
> latter, this would not be needed.
>
> (7) year of decision
>     In this citation form, are the year of decision and the year of
> publication always aligned?
>
> (8) parenthetical information such as judge, type of document, weight
> of authority
>     This raises the same question as (6).
>
> (9) the court
>     SCOTUS citations are to a dedicated reporter, so the court is
> implicit. Should this be made explicit in an electronic citation?
> Alternatively, should reporters be made a separate domain in the
> specification, so that such information can be attached to each?
>
> ***
>
> I guess a threshold question is the scope of the spec:
>
>   (a) Does it aim to express the elements of all existing printed
> citations (this is also Brian's question, I think); or
>   (b) Does it aim to specify only the elements of all printed
> citations needed to uniquely identify the resource; or
>   (c) Does it aim to specific only the minimum elements (or
> combination of elements) needed to uniquely identify the resource?
>
> If the aim is the enrichment of document content with RDF-style links
> to meaningful text elements, that suggests (a).
>
> If the aim is to support parsers capable to linking specifically to
> cases, that suggests (b) -- this is the aim of the CourtListener
> database from which the LRR is derived.
>
> If the aim is to provide guidance for the construction of resolvers
> and data to feed to them, that suggests (c). My understanding is that
> this is what we're aiming for, but I could be wrong.
>
> Frank
>
>
>
> On Thu, Dec 11, 2014 at 6:34 AM, John Quentin Heywood
> <heywood@wcl.american.edu> wrote:
>> Hey folks,
>>
>> Following our meeting last week, and John Joergensen's gentle chiding
>> that perhaps we were getting too much into the weeds and needed to be
>> much simpler in approach, I said I would undertake an attempt to write
>> something up about US federal court citations. I have made a stab at it,
>> which is attached below. Please let me know what you think, good or bad.
>> Am I on the right track? I will post it to the doc depository on OASIS
>> as well.
>>
>> John
>>
>> --
>> John Quentin Heywood
>> heywood@american.edu
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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