This section provides details and background info on termcodes. How they have been used until now, how they supported the creation of concepts in the modern AGROVOC, and more. 

How A termcode is assigned for A NEWLY created concept and terms?

VocBench (VB) still manages to keep all preferred terms to have same termcode:

• Whenever a new concept is created, a unique id is suffixed to the local name of its URI (i.e. the localname will look like this: c_<UUID>) and the new term added while creating new concept gets that same id as its termcode. 
• If any new preferred term is added for another language, VB first checks if any other preferred term in any language already exists before adding the termcode.
• If another pref term exists, the newly created term will be assigned the same term code of the previously existing pref term.
• In case no other preferred term exist, or in case of a non-preferred term, a new unique id is generated and associated to the as a term code.

From the above scenario, we can say that:

• The preferred terms could have precise term-to-term translation with different languages as they share the same term code (though we must verify that this is being enforced by the users!)
• We adopted "could" in the statement above, because terms always preserve their term code, thus if the status of "preferred" is switched between two different terms, the newly promoted term will have a term code which is no more corresponding to the code of the concept.
• But in case of non-preferred term, we cannot say which term is the exact translation of other terms in different languages as they are just attached to concepts with new unique term code.
• In VB, it could happen (in theory) that two xLabels with identical literalForm are created for two different concepts, and there is no enforcement nor warranty that the two labels share the same termCode (conversely, it is not allowed, in general, to have two xLabels with the same literalForm for the same language, attached to the same concept).

How concepts have been created by using term codes from the original term-based AGROVOC

AGROVOC in original MySQL format is completely term based. All these terms were conceptualized based on following facts:

• All descriptors terms (prefLabels) in different languages share same term code.
• Based on this descriptor term code, the concept URI is generated by adding them as suffix at the end (http://aims.fao.org/aos/agrovoc/c_<term code>)

Example: http://aims.fao.org/aos/agrovoc/c_29551

• All the non-descriptor terms (altlabels) have different term codes.
• In MySQL DB, <agrovocterm> table has composite primary key based on <termcode> and <languagecode>.

In OWLIM triple store, if we query we will find that for each concept all the prefLabel shares same termcode:

Inconsistencies found

• There are different concepts bound to different labels, sharing same term codes. 
  Note: this is not necessarily an inconsistency, as the term could have different meanings. However, this clearly proves that term codes (even of the sole preferred babels), should not be used as concept identifiers:

Running above query, we see that there are 16 cases where same term code is linked to two different concepts.

Case example:  

Explanation: This is because in the original MySQL DB, these terms were related to both the descriptor terms, which were used to create 2 unique concepts:

Thermal shock (36475) <hasSynonym> Heat shock (34015) [http://aims.fao.org/aos/agrovoc/c_34015]

Thermal shock (36475) <hasSynonym> Heat stress (11488) [http://aims.fao.org/aos/agrovoc/c_11488]

Reference: http://agro-pedia.org/ahsan/agrovoc/link.php?mylang_interface=EN&mytermcode1=36475