Add ingress tool

[brianorwhatever]

@Ca5e @RieksJ Adding the ingress tools for wikis

[RieksJ]

Nice to see non-TNOers contribute to the tools development.

This comment is only about necessary updates to the tev2-specifications repo. @Ca5e, @Michiel-s: could you do a review of the code?

Please reconsider the name of the tool. 'Ingress' sounds generic, but the tool only does (specific) wiki's. How about wiki-ingress?

Regarding additions to the tev2-specifications, I would expect to see:

• [ ] in every text that you write as you create the files as mentioned in the other bulletpoints, to use term-refs for every term/concept that we have defined within TEv2. If you think a particular term should be defined (i.e., you find that you want to create a term-ref for a term for which the reference doesn't resolve/for which there is no terms-document), propose one by adding a file in the /docs/terms directory, the structure of which is similar to that of the other files in that directory.
• [ ] In the spec-files section, add a file 41-ingressable-wiki-file.md, with a structure similar to the other file specifications in that directory. Its contents should enable a reader to determine what is, and what is not, an ingressable wiki file.
• [ ] in the spec-tools section, add a file 31-wiki-ingress.md (if that's what the tool will be called), with a structure similar to the other tool specifications in that directory. Its contents should enable a reader that knows how to execute a program but is not a developer, to install and run the program from the commandline.
• [ ] edit the configuration file documentation, and add a Tab Wiki Ingress (if that's what the tool is called). It contents should document all tool-specific fields in the config file (similar to the options on the command line) that the tool uses.
• [ ] I'm starting to develop practical guides (there's only one right now) that aim to help tool-users not only to use the tools but also , but
  • [ ] add a file 21-wiki-setup, the contents of which should be readable by curators that want to create/organize a TEv2-enabled github/gitlab repo that uses the wiki-ingress tool. It would tell them not just the technical things to be arranged, but also that they would need to have some 'ingress procedure', i.e. their way of working for transferring the wiki pages into curated texts. Stuff like this may need to be discussed in ToIP/CTWG first.
  • [ ] add a file 22-wiki-authoring.md, the contents of which should be a readable for people in the ToIP CTWG meeting (e.g., Nicky), and they would then know how to structure the pages in a wiki that they already use for their purposes.

[Ca5e]

The observations below are my first observations, mostly from comparing the tool to the other tools within the repo.

• Commander has the option to add certain text to help text. The other tools use this to display the help text in addition to the error when required options are missing. This way, executing a command without any options doesn't display an unwanted error trace.
• Match the styling of the latest version of the other tools. The last few month I've changed some of the aspects of the Run.ts files. Things like removing the chalk dependency, noticing parse is executed twice on program, and editing how errors are thrown at the base level. In this sense the code is not wrong, but I would match these before integrating. This tool also still says The CLI for the Term Reference Resolution Tool.
• View the existing utils package and possibly reuse some of that code. For instance using writeFile instead of the local saveToFile. Also reusing the logger that is used by all of the tools would be nice.
• Move necessary options from config.yaml to __tests__/content/terminology-config.yaml. Although the actual automated test doesn't work yet, it would be nice to also add the ingress-wiki to this, so it can be run/tested in a similar manner.

[RieksJ]

@brianorwhatever: last week, the maintenance of the repo has officially been transferred to TNO's Semantic Treehouse (STH) development team, of which @Michiel-s is the group lead. When discussing this pull request, he mentioned that the STH dev-team welcomes contributions to the opern-source tools that they maintain, but there are a few rules for that.

One such rule is that a contribution for a new tool/feature must be of such a generic nature that it warrants its maintenance to be taken on by the STH dev team. The reason is that if people start adding all sorts of features, this would increase the maintenance burden of the dev team and it would soon become too much to handle.

Having looked a bit at this PR, the dev team thinks it is serves too specific a goal to warrant it becoming a part of the tev2 itself. The path that this tool should take in their opinion is that it should be maintained elsewhere, e.g., within the context of TOIP (as a TOIP repo), where it could then still use the TEv2 tools as they are just npm packages.

I suggest that based on this feedback, we should close this PR and take it to the CTWG group for discussing how to further proceed.

[RieksJ]

Closing this PR as per my previous comment. If that's incorrect, pls. reopen it.