You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now cliques are saved as arrays of curie's that correlate with matrices of beacon ID's (where the column of the matrix correlates with the column of the array, indicating which beacons have produced which curie's.
It would be nicer to represent cliques as subgraphs with "same as" edges. That way merging cliques would be trivial (adding an edge between two otherwise disconnected subgraphs). Retrieving and adding cliques would become a bit more complicated than it is now, but not much more. When adding nodes we could ensure that the subgraph is a tree (always add nodes in the direction (new node)-[same as]->(pre-existing node)), and then take the "clique leader" to be the root of the tree. When retrieving nodes something like this query should suffice:
MATCH path=(n)-[:`same as`*0..]-(m) RETURN DISTINCT m;
It would also allow us to add ontological depth to cliques with "sub class of" edges. I think this is an important aspect of cliques that we've so far overlooked.
This would also allow us to add curie's to cliques without specifying a source beacon, which we cannot currently do. For example, if we see that a clique contains OMIM.DISEASE:137220 then we can infer that it should also contain OMIM:137220.
Right now cliques are saved as arrays of curie's that correlate with matrices of beacon ID's (where the column of the matrix correlates with the column of the array, indicating which beacons have produced which curie's.
It would be nicer to represent cliques as subgraphs with "same as" edges. That way merging cliques would be trivial (adding an edge between two otherwise disconnected subgraphs). Retrieving and adding cliques would become a bit more complicated than it is now, but not much more. When adding nodes we could ensure that the subgraph is a tree (always add nodes in the direction (new node)-[same as]->(pre-existing node)), and then take the "clique leader" to be the root of the tree. When retrieving nodes something like this query should suffice:
It would also allow us to add ontological depth to cliques with "sub class of" edges. I think this is an important aspect of cliques that we've so far overlooked.
It appears we can set up Spring to use multiple Neo4j databases: https://michael-simons.github.io/neo4j-sdn-ogm-tips/using_multiple_session_factories.html, it may be nice to have one solely for cliques and one for general data.
The text was updated successfully, but these errors were encountered: