Authorities

Arctos maintains authorities in order to standardize content that is shared amongst all collections using Arctos.

Code Tables

Code Tables enforce data consistency, which results in more-usable pick lists to better provide users with what they need, and allow more flexibility in communicating with other data. Authorities exist to maximize discoverability, and any value or proposal which is contrary to this core principle should be rejected.

Principles

All code table values should adhere to our principles developing document) in support of standardized, normalized, properly-categorized, connected, sharable “Research Grade” data.

Concepts

All code tables provide a definition; values are concepts which mean what they’re definied to mean, and meanings cannot be drawn from the values alone.

Procedures

Additions or changes generally require open discussion through Issues, and the Issue/discussion must be recorded with the new value.

Table Definitions

All code tables should have a prescriptive, functional definition. (Some of these allow expedited additions.)

Content

Code tables cannot contain HTML. (Cleanup is an ongonig process; file an Issue for prioritization.)

Reality

Arctos is a Community, and often cleaning up “legacy” data in favor of ideals is a difficult process involving local processes across hundreds of collections. We remain convinced that Arctos data are more capable of supporting deep research than anything else in existence, but we also acknowledge the realities of humans, traditions, resources, funding, etc.

Collection-Specific Values

Many code tables are collection-specific. Operators with ``manage_collection`’’ roles may select individual values for use in their collections under manage collection, or at the top of the relevant code table page. For example, parts:

Rules of the Road for Code Table Terms

General Rules for Adding Code Table Terms

• Use predictable Punctuation
  Allowed characters:
  • a-Z
  • 0-9
  • space
  • underscore
  • apostrophe (UTF-8) (e.g., ‘)
• Whenever possible terms should have a published reference or citation.
• Terms and their definitions should be as general and unambiguous as possible.

Specific Rules for Specific Code Tables

Parts

• Part names should be compatible with an ontological framework. Best practice would be a link to an ontology
• It is preferable to create a general part that can then be refined with a modifier (e.g. girdle -> with the ability to add a modifier such as pectoral or pelvic).

Taxonomy

Taxonomy is included here only for completeness. See Taxonomy Documentation for more information.

Geography

Geography is included here only for completeness. See Geography Documentation for more information.

Agents

Agents are included here only for completeness. See Agent Documentation for more information.

Edit this Documentation

If you see something that needs to be edited in this document, you can create an issue using the link under the search widget at the top left side of this page, or you can edit directly here.