Prioritization Spring 2021

[cbizon]

This thread will serve as an experimental voting platform for prioritizing the topics to tackle next. After everyone votes (or on Monday 5/24) we will add up the scores and tackle them roughly in order of voting.

It's ok to add new items for voting if you have thought of something else.

Voting is not limited to 'official committee members'

Vlado's Voting Scheme:
+2 Highest (heart), please use no more than 2 of these
+1 High (thumb up)
0 Medium (none)
-1 Low Priority (thumb down)

[cbizon]

Security: Some KPs may require APIKey or other authentications. How do we handle such things? What other security level requirements do we need to implement (protection against coin miners if we're running in the cloud).

[karafecho]

Exposures Provider requires an APIKey for access to its ICEES+ DILI instance. This requirement was mandated by the data providers, who have not yet published findings on the dataset, which is derived from a 20-year longitudinal study (i.e., very unique and resource-intensive). Here is an example TRAPI query.

While the authentication approaches seems to be working, several unresolved challenges remain that may be applicable to other team who adopt the same approach. For instance, it is unclear how best to distribute the key to Translator team members, ensure that access is restricted to the consortium, implement approaches or policies to remove the key from any public-facing resources (e.g., Jupyter notebooks), and socialize the need to apply the key to TRAPI queries. In addition, the approach we've adopted for the ICEES+ DILI instance and for ICEES+ in general requires an NCATS ITRB policy waiver.

[webyrd]

From @karafecho : "In addition, the approach we've adopted for the ICEES+ DILI instance and for ICEES+ in general requires an NCATS ITRB policy waiver." I'm curious what that means. Does ITRB have a policy against API keys?

[karafecho]

Late to reply, @webyrd (sorry!), but no, I don't believe the ITRB has a policy against API keys. That said, we may be changing our approach. Please see this issue.

[cbizon]

Logging requirements for tools

[webyrd]

I'm not sure what this means, exactly. A common logging format for all tools? A central repository for logs? The ability to retrieve the log related to a specific query, perhaps using TRAPI? Something else?

[cbizon]

Licensing issues: Some data sets have licenses or data use agreements, even for freely available data. Where and how to track and implement these requirements.

[cbizon]

/metakg: How should this be populated? If a KG is going to do semantic operations, does it need to put an entry for every superpredicate it knows about? Or a minimal set? Does it need to report the most specific version of a query? Most of these can be made to work, but we need to standardize on one to allow ARAs to effectively navigate the KP environment.

[cbizon]

Conflation tooling: The Data Modeling group will be proposing rules for conflation of entities, which may be based on property chains. What kinds of tools do we need for entity conflation? (e.g. treating genes and proteins as a single entity). Is this part of nodenormalizer or something else?

[webyrd]

While tooling may be useful, and may serve as a reference implementation, any ARAs that are pursuing a "Big KG" approach may find this tooling to be less useful, since those teams may need to re-implement the logic, potentially in a different language or ecosystem.

For example, I doubt Unsecret Agent would find a Python library (for example) for entity conflation directly useful, since we will implement these rules directly in mediKanren 2.

However, being able to test an alternative implementation of the rules would be nice, even for Unsecret Agent.

[cbizon]

Operations: Discuss the operations and workflow evolving standards, and getting them implemented on ARAs.

[cbizon]

Query Options: Do we want to allow per-query controls on e.g. semantic operations. (Don't expand this one to subclasses, I want exactly what I'm asking for)

[karafecho]

I'm not sure I understand this enough to vote. Which component would be imposing the per-query controls?

[cbizon]

That would be part of the discussion...

[cbizon]

Ranking: What are the requirements around ranking? Do we need a common scale of scores? Do we want a default ranker? An answer merger? What is the role of the ARS in ranking?

[cbizon]

TRAPI responses given semantic node operations: KPs are going to look for information on subclasses of entities. What should their responses look like. This is the analog of the discussion we had around edges that determined that results should return the more specific edge. Some slides listing possible choices are found here

[cbizon]

Query expansion: Are there other forms of query expansion that we need common tooling for? Similarity searches? Siblings?