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

Disagree with the header - Must follow GFF3 #10

Open
Juke34 opened this issue Nov 7, 2019 · 1 comment
Open

Disagree with the header - Must follow GFF3 #10

Juke34 opened this issue Nov 7, 2019 · 1 comment

Comments

@Juke34
Copy link

Juke34 commented Nov 7, 2019

Hi, I think this is really confusing you must not use ## mirGFF3. VERSION 1.1 as top most line in the header. The mirGFF3, should be fully included within the GFF3 specification, otherwise you start a dichotomy with the official GFF3 specification.

The GFF3 specification requires already this type of header:

##gff-version 3.2.1
The GFF version follows the format of 3.#.# in this spec. This directive must be present, must be the topmost line of the file. The version number always begins with 3, the second and third numbers are optional and indicate a major revision and a minor revision respectively.

In top of that you create an header different, while it will be much easier to keep consistency, so instead of ## mirGFF3. VERSION 1.1 it must be ##mirGFF3 1.1. I would even be more keen to see something like ##mir 1.1.

So in my opinion the header for the mirGFF3 files must look like that:

##gff-version 3.2.1
##mirGFF3 1.1

The same with all other header lines, instead of:

## source-ontology: miRBasev21 doi:10.25504/fairsharing.hmgte8
## COLDATA: let7a-5p

it should be:

##source-ontolog: miRBasev21 doi:10.25504/fairsharing.hmgte8
##coldata let7a-5p

I'm really picky because I always met problems using the GFF and GTF formats because many groups have made their own flavour, and tools struggles from one flavour to another one (here a review I have done about it ). This was due because the formats have not not always been well defined and allowed some freedom in their interpretation. I would like as much as possible avoid to end up again in such situation while we have a well defined GFF3 specification.

@lpantano
Copy link
Contributor

Hi @Juke34,

Thanks a lot for the feedback, I think they are all very valid points. We tried to get some advice in some places and adapted from there.

I like a lot the header idea, thanks for giving an example.

And I would really update the other headers to follow 100% that. I may ping you in the PR so you can check whether something else is needed. I will do something for next month.

Thanks!

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

No branches or pull requests

2 participants