CourtsSC 2014-12-16 Meeting Notes

[John Quentin Heywood <heywood@wcl.american.edu>]

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

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.

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

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)

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.

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