Support co-annotation analysis #7
Assignees
Comments
print(bl.obs[['cell_type', 'cell_type_ontology_term_id', 'subclass.l1']].drop_duplicates().sort_values(by=['cell_type']).to_csv(sep='\t'))
All of these are 1:1 so:
print(bl.obs[['cell_type', 'cell_type_ontology_term_id', 'subclass.l2']].drop_duplicates().sort_values(by=['cell_type']).to_csv(sep='\t'))
Here there are many cases where the cell_type term defines a cluster with many subclusters: e.g.
potential issue: Do we enforce a single direction? What does this mean for ease of deriving a graph? Would it be better to use a different underlying formalism (e.g. networkX) to store and then treat tables as useful reports? |
|
(TODO - add example of cluster overlaps) |
|
CC @hkir-dev |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Multiple fields are tagged as representing cell type.
Use of each value in a cell type field defines a cell set.
We can analyse co-occurence of these values to infer relative granularity:
set(X) cluster_overlaps set(Y)
set(X) cluster_matches set(Y)
set(x) subcluster_of set(y)
field_name1; value1; predicate; field_name2; value2
e.g.
To analyse co-occurence in AnnData files we can just do this:
anndata.obs[['author_cell_type', 'cell_type']].drop_duplicates()
(example looks at co-occurence of just 2 fields). Resulting dataframe can be analysed for co-occurence of key:value pairs.
See #7 (comment) for examples of co-annotation analysis to inference of relationship
The text was updated successfully, but these errors were encountered: