Re: [legalcitem-courts] CourtsSC 2014-12-16 Meeting Notes

[Frank Bennett <biercenator@gmail.com>]

This all looks really great. Sorry that I wasn't able to make the
meeting - we're in our own end-of-term rush here, which lasts until
the day after Christmas (always the submission deadline for theses
here).

On Sat, Dec 20, 2014 at 5:06 AM, John Quentin Heywood
<heywood@wcl.american.edu> wrote:
> Hey Folks,
>
> Here are the notes from our meeting this last Tuesday, together with the
> chatlog.
>
> The agenda for the meeting is in the chatlog below.
>
> Folks seemed happy with the use-case document draft as a prototype, and
> Ken Hirsh pointed out a glaring typo in one of my cites. I am grateful
> for his editor's eye.
>
> There was much discussion on question II.1, with some arguing for the
> first option (the cite refers to the expression of the case as issued by
> the court), and some arguing for the second option (the cite refers to a
> instantiation of the case, a manifestation of the case in a particular
> reporter). John Joergensen explained why he thought the first option was
> correct, and we came to that consensus.
>
> On questions II.2-4, which are about the same thing, we agreed that what
> we are doing is creating a standard around which resolvers may be
> written. The spec needs to provide for the minimum uniqueish identifiers
> necessary to specify the cited document, working with what is actually
> available "in the field", which is usually a print citation. John
> Joergensen said he thinks all court decision citations are going to boil
> down into one of three types:
>
> 1. some kind of docket number/string reference
> 2. universal citation
> 3. print reporter citation

Sounds right here too. A couple of questions are:

(a) Do we want to explicitly specify the field req's for the existing
universal citation forms (since there is some drift between them).

(b) For print reporter citations, do we:
    - normalize (so abbrevs are remapped to canonical reporter
abbrevs, and "3d" becomes "3"); and
    - reduce to minimum data needed to identify the source (so
dropping date and case name); OR
    - expand to full details (so adding court name where implicit from
reporter).

>
> The resolver will take the info sent to it using the spec and return a
> unique reference to the cited document that will link that expression
> with all available manifestations of it.

Eagerly awaiting said resolver. :-) But seriously, that must be how it
will work.

>
> We talked about Frank Bennett's proposed fields, and the consensus was
> that another needed to be added: name.

No objection - but to note that it will not be possible to assure
consistency in this field across parsed-out citations. Reporters are a
limited namespace that can be normalized with a mapping table, but
case names are too numerous and diverge in too many ways. Useful to
have that in there, though.

>
> So my conception of the standard (with input from John J.) looks like
> this for court documents right now:
>
> type of document (decision, order, pleading, etc.)
> courtid (some string that identifies the court)
> volume (for print citations)
> reporter (also for print citations)
> page (also for print citations)
> docket indentifier (string, usually unique)
> name (string)
> decision date
> publication date (year)
> parenthetical information  (This must be exploded)
> Country
> Jurisdiction
> Venue
> Posture (may or may not collapse into document type, listed above)
> Further court identifiers (sometimes needed.)
> accession number (for Universal Citations!!!)
> Paragraph Number (for Universal Citations!!!!!!)
> Pinpoint cite Page number (for Olde Schoole Citationes)

Looks like a good and full list. Might it be good to specify three
field-sets, for each of the three categories of reference? ... For
older cases that available only through the commercial reporting
services, the docket number and some other stuff may be unavailable,
so it would be optional. On the other hand, for unreported cases,
docket number would be indispensable, and should be required. ...

If Jurisdiction is expressed in something like URN:LEX, the Country
field could be folded into it. That would have the advantage of
covering not only national laws, but arbitration awards and other
non-state tribunals (since URN:LEX allows identifiers for non-nation
rule-making bodies).

About pinpoints, I'm slightly puzzled, now that I think about it. The
return from the resolver should provide canonical cite data for
individual manifestations, and with luck a resolvable link to each. It
seems to me that the pinpoint would be something for the calling
client to apply to the source, after the document is retrieved. It
seems like you wouldn't expect the resolver DB to store all pinpoint
permutations against a source, would you? The same issue affects
parentheticals, which seem purely local information - possibly useful
to capture locally, but not relevant to the resolver call. If that
description fits, it would make sense to separate the fields into
"persistent" and "ephemeral" segments in the spec, and set aside the
latter with respect to resolver calls.

>
> Am I correct on this?
>
> On III (What's Next?), we agreed I will do a lot of work over break
> instead of grading papers. No, along with grading papers. I will add US
> Federal non-decision documents to the use-case document. I will ask
> Frank Bennett to add some stuff on Japanese citations (Hi, Frank!) I
> will adapt an essay from John Joergensen on the non-unique nature of
> most citations and the need to allow for ambiguity, as an introduction
> to the use-case document. I will then post it on the wiki for the rest
> of the TC to critique.

Awaiting your command. :-)

Frank


>
> The next meeting will be in the new year, on Tuesday, 13 January 2015,
> at 4:00 pm EST (21:00 UTC).
>
> Happy Solstice everyone!
>
> Here is the Chatlog:
>
> ===============start of chat=================
>
> [15:47] John Heywood: Hello everyone. Here is our agenda:
> [15:48] John Heywood: Agenda
>
> I. Do folks feel that the document I sent out on 10 Dec. 2014 is on the
> right track as our use-case document?
>
> II. Questions that have been raised on the listserv this week (paraphrased):
>
> 1. Should the citation-to-be-specified identify the text of a judgment
> as issued by a court, or the text available in a specific reporting service?
>
> 2. Should the machine-readable markup syntax we will create enable
> people to indicate exactly what the citation looked like in some text
> they may be
> trying to faithfully represent, or should it only provide a way to
> refer to some sort of standardized citation?
>
> 3. Does our spec need to include elements of all existing printed
> citations? Or does need to specify only the elements of all printed
> citations needed to uniquely identify the resource? Or does it only need
> to specify the minimum number of elements necessary to uniquely identify
> the resource?
>
> 4. If we go the minimal data route, is this enough info:
>
> type (decsion)
> courtid
> docket number (string)
> decsion (date)
>
> Does this need a name string of some kind?
>
> III. What's next?
> [16:02] Ken H.: Kris, are you calling in?
> [16:21] John Heywood: Here is something Frank wrote earlier this week:
> In the technical group, Fabio presented on a three-stage resolution
> process. For cases, it would look something like this:
>
> (1) Some readily accessible features are fed to the resolver:
>
> {
> name: "Ingle v. Landis Tool Co.",
> volume: "272",
> reporter: "F.",
> page: "464"
> }
>
> (2) The resolver attempts to match the features to some unique key
> that identifies the work, say:
>
> us-272-fed-464
>
> (3) The unique key is used to return a set of references to the case.
> If there is only one available reference, or if resolution is limited
> by constraints imposed by the original call, the resolver might return
> something like this:
>
> {
> name: "Ingle v. Landis Tool Co.",
> volume: "272",
> reporter: "Federal Reporter",
> page: "464",
> decisionDate: "1921-03-08",
> publicationDate: "1921",
> courtID: "us;federal;court.appeals.3.circuit",
> publisher: "West",
> }
> ===============end of chat=================
>
> Have a Happy Solstice everyone!
>
> --
> 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
>