Need a fool-proof deterministic mapping of KP Translator SmartAPI Registry entries onto their ARA counterparts

[RichardBruskiewich]

The original system of dereferencing "One Hop" KP test data templates from the ARA KPs tag of the ARA data templates relied on a simplistic heuristic of rewriting KP character string names (with embedded spaces) into file names (spaces replaced with underscores, and adding a .json file extension, and storing the file on a deterministic path duplicating the ARA team path under both the ARA and KP subfolders, under the repo's test_triples folder).

It was later decided to directly access ARA and KP Translator SmartAPI Registry entries to resolve test data templates by including a URL value for a new x-trapi.test_data_location property to resolve to the required JSON test data templates, generally in the Github repositories associated with their corresponding ARA or KP.

This change in ARA-to-KP mapping process created a new conundrum: how to uniquely identify the KPs dereferenced in the ARA specification, using available Translator SmartAPI Registry entry metadata. It was discovered that, in fact, KP entries don't yet have one unambiguous, human-readable identifier in their entries to serve in this function. A companion Git issue in the translator_extensions repository further discusses various KP entry identification options with trade-offs.

[RichardBruskiewich]

The interim decision is to use the full infores CURIEs to identify KPs being accessed. This won't deal with any multiplicity of TRAPI versions and x-maturity status. The code base will simply need to make some reasonable default assumptions about which specific KP endpoints to use which are compliant with the ARA version and x-maturity status.

[RichardBruskiewich]

Resolved by commit 3f99e6e