This page is a work in progress.
In Hyacinth, you can create Controlled Vocabularies that contain Controlled Terms. You can also create dynamic fields that are linked to these Controlled Vocabularies.
Types of Terms in a Controlled Vocabulary
A term from an external controlled vocabulary. Example: We want to add an entry for U.S. President Abraham Lincoln to our UriService datastore, so we'll create an external term that references his Library of Congress URI.
A locally-minted URI. Example: We want to maintain a vocabulary for various departments within a university, and we want to create locally-managed URIs for these departments.
Used when you want to add a value, but have no authority information about the term or do not wish to create a local URI. No two temporary terms within the same vocabulary can have the same value. Basically, a temporary term is intended to identify an exact string value rather than identifying an intellectual entity. Temporary terms should eventually be replaced (by the user) with external or local terms when more information is known about the entity to which you are referring . Example: We want to record information about the author of an old and mysterious letter by "John Smith." We don't know which "John Smith" this refers to, so we'll create (or re-use) a temporary URI that's associated with the value "John Smith." One day, when we figure out more about the letter and the author, we'll be able to update the record information and refer to an external term that has a globally-recognized URI, or we'll create a local URI if an external URI is unavailable.
More About Temporary Terms
In an ideal world, everything would have a real URI in some external vocabulary, or one maintained in a local vocabulary (i.e. a "local" term, in Hyacinth speak). However, some users don't have the time/interest/ability to look up external terms or create URIs for every controlled term value they enter into Hyacinth, so that's why temporary terms exist. Temporary terms generally have very little metadata associated with them -- usually just a string value -- and their temporary URIs (with format "temp:abcdefg...") are derived from the string value itself. So that's why you can't have two temporary terms in the same controlled vocabulary with the same value.
Big picture: temporary terms were designed to be a way to identify string values that don't have real URIs, so that one day later records could be "cleaned up" to use real URIs. They're bridging the gap between some people wanting to use strings and other people wanting to use URIs.
So if you're looking to create a term that should be distinguished from other terms with the same string value in the same Controlled Vocabulary, and that term doesn't exist in an external controlled vocabulary like the Library of Congress NAF, a local term is the way to go.
Updating Labels for Controlled Terms
When you change an existing controlled term label, it doesn't actually change any existing Item/Asset records because they're stored with only a reference to the underlying URI. For this reason, changing the label doesn't lead to an immediate update in the facets displayed on the Hyacinth search page, and also doesn't allow you to use the "Custom Filter" to search for that value. To complete the update, you need to re-save any Items/Assets that referenced the updated controlled term. And related to all of this, you need to re-publish the Item/Asset to get that updated label out to DLC or AC.
Note that when you view an individual Item/Asset page after a controlled term label change, you actually WILL see the new label in the UI before you re-save it because that information is generated on demand. However, to truly propagate the controlled term label change (so it's available for search), re-saving is a must.
As a result of the above logic, this means that if you changes a controlled term label -- but doesn't save any records that use it -- and then you change it back, there will be no net change.
Automatic re-saving of records associated with updated controlled term labels is a feature that is being planned for in a future Hyacinth 3 release.
Deleting Controlled Terms (best to avoid this!)
There is a known issue where if you delete a controlled term that's in use by a record, it will break rendering of that record. For this reason, it's best to avoid deleting a controlled term unless you're absolutely sure it's not in use by any records. Note that due to project permissions, a user may not be able to see all records in the system that use a given term, so it's generally risky to delete any controlled terms. In a future release of Hyacinth 3, there will be better reporting about whether a controlled term is used by any records.