What should the /meta_knowledge_graph for ARAs be?

[edeutsch]

• The content of /meta_knowledge_graph (MKG) for KPs is pretty obvious.
• But what should the /meta_knowledge_graph for ARAs be?
• An important factor is: who needs it?
• ARAs clearly need KPs to furnish a MKG
• But who would need ARAs to furnish a MKG? The ARS? An eventual GUI? The workflow runner? maybe
• It seems like there are two reasonable options:
  1. An ARA should merge all the MKGs that they glean from their KPs and present that
  2. ARAs don't need to do an MKG because no one will use it, so whatever they want

I'll post some possibilities below. Please vote for the ones you like

[edeutsch]

Option 1: vote with the thumbs up if you like: An ARA should merge all the MKGs that they glean from their KPs and present that

[edeutsch]

Option 2: vote this comment with the thumbs up if you like: ARAs don't need to do an MKG because no one will use it, so whatever they want

[edeutsch]

Option 3: vote this comment with the thumbs up if you like: Escalate this to the Architecture Working Group since this is a policy decision on how to use TRAPI (even if you vote for this, you could still vote for 1 or 2)

[suihuang-ISB]

Are OPT 1 an OPT 2 mutually exclusive? I agree with both. Yes, no one may use the ARA-MKG ... but may still be good for future understanding of the entire Translator and perhaps some future integrative operations at the ARS level in to have this documented.

[marcdubybroad]

From a system design perspective, if we keep ARA/KP APIs the same, you could:

• use the same client to interface with either one; you don't need to know if the service you are querying is a KP or ARA, just that it provides the data and the implementation details are hidden. The responsibilities of the ARA/KP systems are still different, but the abstracted interface the same. Similar to an abstracted class/interface in software methodology.
• also add in an extra system tier down the road, if needed. For example, a new somewhat simple layer could allow groupings of ARAs or KPs by function, yet with the same API.

[edeutsch]

Addressed in PR #320