Reconsider what components get inforeses and need to be referenced in retrieval provenance chains.

[mbrush]

This issue will need to be discussed more broadly with other working groups - but wanted to get ingest folks input here first.

At present, it seems like retrieval chains captured in RetreivalSource objects in the TRAPI data (and displayed on the ARAX UI) references components like dogpark tier 1, dogpark tier 0, retriever, arax-shepherd.

For example, this is the provenance chain for a simple "Oxiglutation ‘treats’ Breast Cancer” edge provided by an external source (TTD), and retrieved through a Tier 0 lookup, in the ARAX UI here.

ttd (primary) -> dogpark tier 0 (aggregator) -> retriever (aggregator) -> arax (aggregator) -> shepherd-arax (aggregator)

Another example (where a tier 1 resources is used, not tier 0) :
faers (primary) -> multiomics-dakp (aggregator) -> dogpark tier 1 (aggregator) -> retriever (aggregator) -> arax (aggregator) -> shepherd-arax (aggregator)

Questions:

• Do we want/need to capture and distinguish all of these components (retriever and dogpark, arax and shepherd arax) in these chains?
• Should we create inforeses for each source KG Tier 1 endpoint (e.g. infores:ttd-translator)? (analogous to what was done in Phase 2, where we created separate inforeses for things like ttd and automat-ttd)

[sierra-moxon]

In general, it makes sense to me to both:

• Attribute a Translator knowledge source in the provenance chain when the existence of an edge is inherently dependent on Translator tooling.
• UI provides a user-friendly design to make the provenance understandable by folks unaware of the Translator ecosystem.

[mbrush]

This makes sense to me. We would need to define what it means that "the existence of an edge is inherently dependent on Translator tooling". e.g. if a tooling component is merely pulling the data into a new document / store within the retrieval pipeline, or re-serializing the data in a different format - does this qualify and warrant attribution in the retrieval provenance chain?

First thing to do may be to document what each component is actually doing when it "aggregates" an edge, and document users/use cases for the retrieval provenance chain (end users, internal devs debugging data, third part developers) - so we can decide what is important to track in the retrieval chain.

[gglusman]

I'm not sure I understand what the driving issue here is.
Is the question whether we need to track what all components were involved in a processing chain? If so, the answer seems to be obviously 'yes', for debugging purposes. There is no 'merely' moving data or changing its format. Every operation can give rise to error, and not tracking such hand-offs and modifications would make it impossible to debug when things fail.
Is the question whether all these intermediaries need to be displayed as provenance in the Translator UI? Probably not, as it only adds clutter that the user doesn't care about. The ARAX UI is different though, and more detail is better there.
Which intermediaries would make sense to display to the user? Certainly those that actually modify/reorganize/interpret the content in a meaningful way, beyond just "I retrieved this and passed it on".

[mbrush]

@gglusman I think there are a few questions to consider. Two of them are exactly as you state:

1. Which components need inforeses and attribution in the retrieval provenance chain, and for what purposes? It sounds like your opinion is that, for debugging at least, all components that retrieve and pass along a given edge should be added to its retrieval provenance chain. For this purpose, it seems that even the distinction between retriever and dog-park, or between arax and shepherd-arax should be captured explicitly. And the ARAX UI is probably the place to display this fully detailed retrieval chain (As opposed to the public web ui). Additional questions:

   • Are there retrievals/handoffs that happen every time/for any edge, and if so do these need to be captured?
   • Do we want to create and attribute an infores for Translator's ingest of each source (i.e. the tier 1 resource "infores:ttd-translator" - analogous to what was done in Phase 2 for resources like "infores:automat-ttd". And reference these in retrieval chains (e.g. ttd -> ttd-translator -> dogpark tier 0 -> retriever . . . ) (not in the web ui, but internally and in the ARAX UI)

2. Which components in the retrieval chain should be displayed in the Web UI for end users? At present, only the primary_knowledge_source is displayed. I would argue that supporting_data_sources should also be displayed, and perhaps also which source the data was ingested from, where relevant (which is usually but not always the primary_knowledge_source). End users probably don't need to see other 'aggregating' resources/components that perform internal retrievals in the Translator pipeline.

3. A third question that follows (but we can address in the near future) concerns how and where we want to represent these retrieval provenance chains going forward. We developed a fairly verbose/expressive/nested model during Phase 2 - based on needs under the more distributed Phase 2 architecture and use cases at that time. Evan and others have raised questions about whether this level of detail is still needed, and whether we might streamline our representation, and/or capture some info externally (i.e not on every edge in the TRAPI data).

Of these questions, I think (1) should be addressed first/now - and we can save (2) and (3) for later consideration.