Concept ID that links multiple Term IDs together

[ronaldtse]

Right now a "term id" is assigned for every term/designation, but it doesn't link up the revisions (e.g. retired terms have a different id).

We will want a "concept system" where each concept has a Concept ID, and the Concept ID links up multiple revisions (i.e. multiple term ids).

We can use the IEV concept ID pattern as an example, i.e. 'IEV 111-01-01'.

Once we do this we will need to build a "tree" from the term IDs we have today.

[ronaldtse]

The Concept ID for MLGT may look like "ISO NNNN NNN-NN-NN". But there may be more than one identifier of different types we can assign per Concept. Different concept sets may use different identifier patterns.

From @strogonoff

(1) We want to offer a generic widget that allows to look up concepts quickly, by typing their name or ID. (2) This widget must be aware of “external ID” we assign to concepts.

as far as data goes, we could refer to [UUIDs], and substitute them with [these] concept IDs when rendering representation (for a website or another deliverable) we want to allow to store and retrieve those official IDs

we can‘t assume each organization has such an ID, or has exactly one such ID, etc. Perhaps they have multiple systems, some legacy, some future, etc.

[strogonoff]

Right now a "term id" is assigned for every term/designation, but it doesn't link up the revisions (e.g. retired terms have a different id).

We will want a "concept system" where each concept has a Concept ID, and the Concept ID links up multiple revisions (i.e. multiple term ids).

We can use the IEV concept ID pattern as an example, i.e. 'IEV 111-01-01'.

Once we do this we will need to build a "tree" from the term IDs we have today.

This is a misunderstanding. Our “termid” (legacy name) is the global internal unique concept ID, the identifier of a unit of understanding. All language-specific entries are connected to each other via that global concept ID.

I believe what is discussed here is the external reference to a concept and/or revision that should be attached to Glossarist.

[strogonoff]

Per our discussion(s),

• termid is a misnomer, legacy field identifier on the way to becoming obsolete, currently trying to act as both our “concept ID” and “external ID”.

• Our true concept ID will have to be a unique, random, system-assigned read-only ID per entry at creation time. Likely a hexadecimal hash or UUID.

• External IDs, on the other hand, can be edited, and specified in accordance with the requirements of particular organization’s relevant external systems or deliverables. It could be e.g. concept ordinal number in a standard (like in IEV), or anything else. (Under the hood it’s going to be a field on pass-through schemaless payload object we will allow to be associated with a concept, or a language-specific entry of that concept, or [possibly] a revision of that entry—especially useful in case legacy system used to create new IDs once a revision of an entry was superseded with another revision.)

[ronaldtse]

Right. Let's call the "true concept ID" the "Glossarist concept ID", and the "External ID for MLGT concepts" as the "MLGT concept ID". We will likely model the "MLGT concept ID" after "IEV ID".

[strogonoff]

@ronaldtse Sure.

Request for input: can we map in detail how MLGT concept ID relates to abstract concepts vs. localized items? or is there a resource that describes that?

For example, is MLGT concept ID shared across langauge-specific terminology entries, does it increment when any of those entries gets updated, how substantial must a change be for MLGT ID to be incremented (and previous to be “superseded”), and such.