Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

extend query track(s) when genes "just outside" neighborhood belong to families of genes within neighborhood(s) #269

Open
adf-ncgr opened this issue Feb 25, 2020 · 2 comments

Comments

@adf-ncgr
Copy link
Contributor

Currently, there's a bit of asymmetry in terms of the way that query and result tracks behave with respect to their bounds. A result track extent is "greedy" in the sense that it will be extended to include genes belonging to families considered matchable, while query track(s) have fixed boundaries based on the neighborhood parameter. This can lead to some potentially misleading results, suggestive of copy number variation on the edges of tracks (as in an example which I thought I had open in one of many browser tabs, but it's not coming to hand- will update this issue if I find it or an equivalent example later). It seems as though the new architecture might facilitate this since the query tracks should be easily extendable without needing to make this a server-side decision?

@alancleary
Copy link
Contributor

Is this the same as issue #77? If so, you've been waiting a long time for this feature!

I think this is tricky because it's sort of a chicken-and-egg thing; query tracks would be extended in the context of their cluster but the family content of the extended tracks could change the clustering. I suppose if we used a two pass strategy (as you describe in the other issue) we could just cluster again.

Perhaps the thing to do is come up with a few examples where this feature would be useful. As is, I don't feel like I'm completely grasping it. That said, I can't help but think about graphs for this problem.

@adf-ncgr
Copy link
Contributor Author

Yes, it's related to #77 but differs slightly (perhaps insignificantly) in that #77 pertains only to the query tracks and their relationships, whereas this one pertains to the relationship between queries and result tracks. This isn't urgent, I was just getting it into an issue before I forgot about it. But, I will definitely try to re-find my example or come up with a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants