| A | B | C | |
|---|---|---|---|
1 | Taxonomy Title | Sanity Taxonomy Manager Plug-in | |
2 | Project Title | 1/30/2025 | Last Updated: January 30, 2025 07:53:58 |
3 | Introduction | Notes | |
4 | This spreadsheet is a starter template for creating W3S SKOS compliant taxonomies and thesauri. It is designed to be used as a starting point for creating interoperable, standards-compliant controlled vocabularies and is formatted to integrate smoothly with the Sanity Taxonomy Manager Plugin and migration script. This overview includes information on basic features and use of this sheet, but does not cover taxonomy research, authoring, and governance in detail. For more information on those subjects, please see: • the W3C SKOS Primer and W3C SKOS Reference • the ANSI/NISO Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies • the Taxonomy Design recommendations in the Sanity Taxonomy Manager plug-in documentation Spreasheet Scripts This template contains two scripts intended to assist with taxonomy authoring: • A "Last Updated" timestamp, which willl automatically update the "Last Updated" value in the upper right hand corner when edits are made to any sheet in the workbook. • An "IA Tools" menu bar item, which provides Google Sheets affordances for expanding or collapsing grouped rows in order to show or hide particular levels of the taxonomy hierarchy. You'll need to authorize these scripts the first time you use them. You can inspect them beforehand in the "Apps Scripts" view (in the "Tools" menu). Header Rows Rows 1 - 3 on the Taxonomy Template script are locked to prevent unintentional editing of labels. The "Taxonomy Title" field (A1) and "Project Title" (A2) fields are automatically populated from the title fileds on this Overview sheet: changing them here changes them on the Template sheet (and any copies you make of it in this workbook). If you're using the Sanity Taxonomy Manager plug-in migration script, rows 1 - 3 are assumed to be development header information and are skipped. If you add or remove rows to the top of the template, you'll need to modify the migration script. Read on below for details on the primary taxonomy template sections. | ||
5 | |||
6 | Hierarchy | ||
7 | The hierarchy section is used to capture the preferred labels and parent-child relationships between your taxonomy terms. Preferred labels must be unique (this is not a SKOS requirement, but will make your modeling much easier). Each term must appear on a row all its own, as shown in the placeholder terms on the template. This ensures that each term is associated with a distinct place in the taxonomy hierarchy and with a unique set of related metadata (description, scope notes, etc.). Top Concepts "Top Concepts" are "used to link a concept scheme to the SKOS concept(s) which are topmost in the hierarchical relations for that scheme" (SKOS Reference). Top Concepts are commonly used as the highest level entry point to a taxonomy hierarchy. Top Concepts are not required; you may also simply start your concepts at Level One. Hierarchical Levels Each succeeding "Level" represents a child concept of the higher level preceding it. Each row must only have one label in this section. Avoid gaps between hierarchical levels. Do not, for instance, jump from level two to level four on the next row. | ||
8 | |||
9 | Documentation | ||
10 | Definition Definitions are optional, but highly recommended. Creating definitions as you develop the taxonomy helps you vet the integrity of your structure, and definitions help users tagging content choose the correct term. Definitions also increase the accuracy of LLM assisted tagging if you're planning to use this taxonomy in conjuction with AI. Definition values are migrated as plain text. Scope Notes According to the ANSI/NISO Guidelines scope notes are used to: • restrict or expand the application of a term • distinguish between terms that have overlapping meanings in natural language • provide other advice on term usage to either the indexer or the searcher Examples Examples provide sample instances to help the indexer determine when and how a term should be applied. | ||
11 | |||
12 | Additional Labels | ||
13 | Additional labels are optional. If multiple labels are used, add them as a comma separated list. Alternate Labels Alternate labels are those added in addition to the preferred label of a concept. Alternate labels are helpful for documenting synonymns. Hidden Labels Hidden labels are used to assign character strings that should be accessible to applications performing text-based indexing and search operations, but which should not otherwise be visible. Hidden labels are helpful for documenting misspelled variants of other labels. | ||
14 | |||
15 |