Structure of the tsv

[YvonneKallberg]

I don't know if mentioned and discussed earlier, but the way the .tsv file examples are structured when automatically generated is not the way it is structured when doing a submission. My question is, should they be? Is the purpose of creating .tsv templates to make it easier for a submitter/researcher to submit, or is the purpose to have templates for the data producers to fill?

• Interactive .tsv has a first row with 3 columns: 'FileType', the actual file type value e.g. 'fastq' and 'Read submission file type'
• Automated .tsv is missing this (currently at least), and the file_type is given in a column

I'm open for both, but think we need to make it clear.

[somathias]

Very good question (and important difference in the current state) to be raised.
So far we have been trying to cater to both researchers/submitters and data producers at the same time and I agree that however we chose to go forward, we need to make the purpose more clear.

Personally I think, a large motivation (although not the only one) for us to collect the technical metadata in this form is to facilitate data submission to end repositories. This motivates me to try to have tsv files be in a format easy for submitters to work with.

However, we are of course dependent on the data producers being able to supply the technical metadata to enable submission. This means that it is even more important that the template is in a format the data producers can easily work with. If that can be the same format as will be submitted (minus the orga metadata), perfect. If not, it would of course also be possible to reformat a "data producer suitable tsv" to a "submission suitable tsv" later on.