+ Home

Taxonomy Overview

What syntax should be used for NASA Taxonomy terms when they are used to index content or to store metadata in a database?

Each NASA term has an ID which is unique in the NASA Taxonomy namespace. These UID's should be written out with the term and stored whenever the metadata is published or exposed as a database. This will make it easier to identify terms that have been used to index content, in case they need to be changed in the future.

Can the Taxonomy path be stored with the term? If the Taxonomy path is stored then what happens if the term is moved in the Taxonomy?

The taxonomy path can be stored with the term. This provides extra information that makes it easier to display the term and content that has been indexed in a hierarchical context. But if the Taxonomy path is stored with the term, then if a term is moved in the Taxonomy, the term path will need to be updated.

Tagging content is more difficult than making a taxonomy. You don't want to tag content more than once. What happens when new terms are added to the Taxonomy?

The NASA Taxonomy is not perfect. We want a tool that's stable, that has enough categories in it to usefully begin to tag some content and provide access to it, and that can be extended and maintained as needed. The goal of the demo was to test whether the Taxonomy had sufficient detail to provide useful discrimination in a large, heterogeneous collection. Our general rule is that discrimination will be provided over a collection that is 10 times the number of facets--for NASA the Taxonomy has been designed to handle a collection of approximately 10 to the 10th power items.

There are more lists of projects, e.g., Dryden Flight Research Center aircraft, that are not in the current Taxonomy. Can additional lists of projects be added to Missions & Projects facet? And if so how? What constitutes a project that should be added to the Missions & Projects facet?

The NASA Taxonomy is intended to be more general than the controlled vocabulary lists used to support databases for particular projects. Editorial rules are needed that provide guidance on when and how to add new terms to a facet like Missions & Projects. The Taxonomy is not intended to hold all the detail all the time, just enough to allow users outside the project or process to find content. NASA like any large organization needs a definitive list of its products and services. The Missions & Projects facet of the Taxonomy is the logical place for this list to be maintained.

The Missions & Projects facet sub-divisions "Planetary Missions" and "Space Sciences" are time-based--operating, past and planned. Is this the best way to sub-divide? Since missions & projects will inevitably need to be moved from planned to current and then to past. Would an alphabetical list with acronyms be more useful?

It is a good practice to avoid long lists by breaking them up with some "natural" subdivisions. Some "natural" sub-divisions that can generally be understood are by space and time.

The top level Missions & Projects facet divisions are similar to the Subject Categories facet. Would it make sense to combine the facets into a single larger taxonomy?

The top level Missions & Projects facet divisions are the NASA Enterprises. It's not surprising that the Enterprises are similar to the Subject Categories because these represent the major research areas that the enterprise undertakes. The goal of the NASA Taxonomy is to avoid a single, monolithic hierarchy. Instead, the taxonomy has been broken up into discrete, mutually exclusive facets with smaller controlled vocabularies. This design for the taxonomy makes it more flexible, and easier to use and maintain.