The Terminology Engine (v2) is a set of specifications and tools that caters for the creation and maintenance (i.e. curation) of terminologies. This repository contains the sources for the tools.
The problems I keep running into as I try to accommodate the tools for work in an EU project cause me to suggest a number of things that I think should be refactored.
[ ] All tools should get a -d (or --debug option) that gets a parameter such as none, info, warning, debug, trace (the standard stuff, and uses that as its loglevel during its operation. This should also go in the config files. The default value is info. All logging should go through the same function log.xxxxx as defined in "@tno-terminology-design/utils".
[ ] All tools should leave the logging that has proved useful in there. You never know when you'll need it again.
[ ] Functions should become much smaller, and the reasoning behind things should be better documented.
[ ] Functions should become much more robust e.g.: thorougly check their arguments for existence, null, etc., and throw errors if calls produce errors.
[ ] Expect arguments to NOT exist, e.g., a termType field in a curated text, or in an imported glossary.
[ ] Some fields are only used by some tools - fields such as locator , website, navpath, navurl, etc. are only used by the TRRT - in projects where the TRRT isn't used, they should not be needed and hence not required. Testing for the existence of such fields MUST be done in the tools that use them, and nowhere else. That'll also need restructuring of the specs perhaps, but it makes things much more modular, extendable, etc.
[ ] The creation entries to be added to an MRG should be refactored such that (a) it gets an initial entry, e.g., from ctext front matter or an imported mrg entry. Then, it ensures the entry satisfies the most minimal requirements, e.g., the field term exists and is regularized, the field termType exists or is provided a default value (error if there's no default value) and is regularized, and constructs a termid from them and adds/overwrites it. Next, there should be a mechanism that enables the generator to add and/or modify other fields, as needed for particular tools, such as the TRRT. In a similar fashion, the handling of 'synonyms' should be appendable, and the creation and handling of aliases (which is currently not part of the tooling - alias: "term" would mean that another, new entry must be created, with term: "term", and all the other fields the same as the entry from which it was generated, which is similar, but not the same as what we do with 'synonym'). The mechanism for adding 'co-constructors' to the generation of mrg entries must be carefully designed.
The problems I keep running into as I try to accommodate the tools for work in an EU project cause me to suggest a number of things that I think should be refactored.
-d(or--debugoption) that gets a parameter such asnone,info,warning,debug,trace(the standard stuff, and uses that as its loglevel during its operation. This should also go in the config files. The default value isinfo. All logging should go through the same functionlog.xxxxxas defined in "@tno-terminology-design/utils".locator,website,navpath,navurl, etc. are only used by the TRRT - in projects where the TRRT isn't used, they should not be needed and hence not required. Testing for the existence of such fields MUST be done in the tools that use them, and nowhere else. That'll also need restructuring of the specs perhaps, but it makes things much more modular, extendable, etc.termexists and is regularized, the fieldtermTypeexists or is provided a default value (error if there's no default value) and is regularized, and constructs atermidfrom them and adds/overwrites it. Next, there should be a mechanism that enables the generator to add and/or modify other fields, as needed for particular tools, such as the TRRT. In a similar fashion, the handling of 'synonyms' should be appendable, and the creation and handling of aliases (which is currently not part of the tooling -alias: "term"would mean that another, new entry must be created, withterm: "term", and all the other fields the same as the entry from which it was generated, which is similar, but not the same as what we do with 'synonym'). The mechanism for adding 'co-constructors' to the generation of mrg entries must be carefully designed.@Michiel-s : can you comment on the above?