Managing LINGUIST Codes for Ancient and Constructed Languages Anthony Aristar, Wayne State University and LINGUIST List

DRAFT 2002-05-19

Making the Code-Set Available

The LINGUIST code-set is designed to be a supplement for Ethnologue. This means that it must be made available in a form which is directly usable by databases which are using the Ethnologue code-set. Thus the form in which the code set will be provided will be identical to that used by Ethnologue, and will mirror the system and tables proposed in Simons [2002], where a detailed description of the table-structure can be found. The LINGUIST code-set will thus be made available in the form of tab-delimited files whose form mirror exactly those by which Ethnologue disseminates its set. Three tab-delimited files will be provided. One will be the LanguageCodes table, containing the four-letter language code, the country code, the language status (containing one of two values, E(xtinct) and C(onstructed)) and the name. The second will be a LanguageIndex table of alternate names containing the four-letter language code, the country code, the name type, and the name. The third table to be provided will be the ChangeHistory table, containing three fields: the affected code, the type of code (whether C(reated), E(xtended), R(etired), or(U)pdated), the date of the release, and the description of the change.

Facilitating changes and comments on the code-set

The set of codes provided by LINGUIST is only as good as the community can make it. Furthermore, it is important that the community feel that these codes are decided by consensus, rather than by fiat. As a result, we will do all we can to facilitate comments and suggestions on our codes. In particular:

• LINGUIST and E-MELD language pages will have a link to a form through which comments can be made and emendations suggested.
• Current suggestions for emendations will be made publicly available on the LINGUIST website.

The process by which changes to the code-set can be suggested

In order to assure that proposed changes to the code-set can be assessed and ultimately justified, certain information should provided. In particular, proposers must provide the following:

• Their name
• Their affiliation
• Their email address, so that feedback can be provided, and an explanation of the process by which their input will be assessed
• A statement justifying the need for the proposed changes
• Documentation for the changes proposed

The documentation to be provided must contain either one of the following:

• References to published work that supports the change
• References to unpublished but accessible material that support the code

Once this information is provided, proposers should receive:

• An explanation of the process that will be used to process the input.
• Eventual notification of the eventual outcome of the proposal.

Processing of the Proposal

For the purposes of processing proposals for changes to the code-set, a panel of experts will be set up. This panel will be composed of linguists who are knowledgeable in different linguistic groupings. The number of panelists will vary as needs require it, but will have at least five members. Where necessary for coverage, outside experts may be co-opted for specific tasks.

For each proposal, one member of the panel will be identified as sponsor, whose tasks will be to:

• Announce the proposal to the panel
• Request names of suitable external experts
• Consult with external experts
• Submit a recommendation back to the panel when the process of review is complete.

In the case of disagreement as to a proposal, the decision will be made by majority vote. The chair of the panel will have an additional deciding vote when the vote is evenly split.

Possible outcomes of the process

Proposals for code changes will have four possible outcomes:

• Release. In the case of a change being accepted, the change will be queued to be incorporated in the next release of the code-set.
• Revise. In the case of a proposal possessing some merit, but needing changes, proposers will be asked to revise their submissions.
• Resubmit. This will take place when a proposal has merit, but needs to be rewritten to explain its case better, or is otherwise misdirected.
• Reject: This will occur when the panel decides that a proposal is without merit.

All rejections will be documented, and the reasons for the rejection made available to for public scrutiny on the LINGUIST and E-MELD web-sites.

References

[1] Aristar, Anthony. 2002. LINGUIST codes for ancient and constructed languages. Available online at http://www.language-archives.org/wg/language/linguist-20020219.html.

[2] Simons, Gary F. 2002. SIL Three-letter Codes for Identifying Languages: Migrating from in-house standard to community standard. Available online at http://www.language-archives.org/wg/language/ethnologue-20020423.html