Create Semsimian object with concerned predicates only.

[hrshdhgd]

• Create semsimian object only with concerned predicates
• Pydantic version < 2
• Semsimian anchored at 0.2.0
• Add in-memory caching for better efficiency
• termset-similarity command returns TermSetPairwiseSimilarity object

[cmungall]

pinned too tightly

[cmungall]

I don't think the logic is quite right. Consider the case where the client does:

sim1 = adapter.pairwise_similarity(x,y, predicates=[IS_A])
sim2 = adapter.pairwise_similarity(x,y, predicates=[IS_A, PART_OF])
<some kind of comparison of the two...>

I believe that sem2 will give the same result. It will silently use the same cached filtered closure, and the user will be none the wiser.

If we do thing that the standard use case of semsimian is that you will never want to switch predicate sets in one session (not ideal but acceptable in the short term), then it is vital that the above code will fail fast on the second call and inform the user that the cached object is already frozen on the IS_A-only closure.

However, I think a more standard solution is that you have a cache of semsimian objects keyed by the tuple of the ordered list of predicates (ordered to avoid unnecessary re-computation as [IS_A, PART_OF] is the same as [PART_OF, IS_A]).

e.g. one of the object attributes would be

    semsimian_cache: Dict[Tuple, Semsimian] = None

Then create_pairwise_similarity_output_object would turn predicates to a tuple tuple(sorted(predicates)) and use that as a key.

There is a danger here that the client could exhaust memory by iterating through all combos of 100 predicates in uberon... but I think that is acceptable for now (later on we could have a system that did more active cache management).

[codecov-commenter]

Codecov Report

Patch coverage: 82.35% and project coverage change: -0.04% ⚠️

Comparison is base (4a306aa) 77.08% compared to head (ed804dd) 77.04%.
Report is 1 commits behind head on main.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #631      +/-   ##
==========================================
- Coverage   77.08%   77.04%   -0.04%     
==========================================
  Files         245      247       +2     
  Lines       28415    28540     +125     
==========================================
+ Hits        21903    21990      +87     
- Misses       6512     6550      +38     

Files Changed	Coverage Δ
...lementations/semsimian/semsimian_implementation.py	85.88% <70.00%> (-9.44%)	⬇️
tests/test_implementations/test_pronto.py	90.93% <100.00%> (-0.86%)	⬇️
...t_implementations/test_semsimian_implementation.py	87.80% <100.00%> (+2.29%)	⬆️

... and 15 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[caufieldjh]

Because changes in this branch are necessary for Monarch use cases and will not be impacted by Windows-specific errors, I'm going to consider this state sufficient for an RC release and will open a fresh PR for the Windows issue.