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

The RelationTypeEnum, EdgeAnnotationType are so unnecessary constraints. #1

Open
IgorRodchenkov opened this issue Jun 8, 2018 · 2 comments
Assignees

Comments

@IgorRodchenkov
Copy link
Member

RelationTypeEnum, EdgeAnnotationType in this library unnecessarily tie it to the Pathway Commons SIF or TXT (extended SIF, XSIF) data files (and even this is hard to maintain due to PC and Paxtools use similar but different enumerations for the same purpuse anyway).

Let's make this library more fexible and capable to load and query any SIF or SIF-ish text data files!
Column names and edge types can be simply String[] type parameter in the RelationTypeSelector and Loader Constructor. This library should allow to work with relationship (edge) and annotation (4th,.. columns) types which are actually present in the input data file.

Attn: @ozgunbabur

@ozgunbabur
Copy link
Contributor

Hi Igor, I somehow missed your issue in my inbox, sorry, now noticed by chance.

This sifgraph package is already not tied to Pathway Commons. But there is a specific handling of the Pathway Commons case, which I think you misinterpreted as a constraint.

RelationTypeEnum is the specific handling of the Pathway Commons use case. This enum implements the RelationType interface. For other use cases, one has to simply do the same thing and define their types by implementing RelationType. Why is this not a simple String? Because it has to tell us if the relationship is directed or not. This information is not in the SIF file and we cannot understand it for the relation types that we have never heard of. But it is necessary information for the graph queries.

EdgeAnnotationType is specific to Pathway Commons, yes, but it can simply be omitted for an arbitrary SIF file. Then the software will use only the first 3 columns. You have a point if you are complaining that this module does not support arbitrary annotations in SIF files. I did not intend to do that originally. Let me know if you think this has a use case.

@IgorRodchenkov
Copy link
Member Author

Thanks @ozgunbabur. This can wait, I think.

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