14
$\begingroup$

A lot of the daily tasks of a bioinformatician can be boiled down to simple text parsing. Yes, we will be dealing with text files containing some form of biological data, but the answer might not really require any biological knowledge at all. For example, this question was posted on Unix & Linux today:

I have 2 files. File1 is:

chr19 4124051 4124250 1
chrX  154458151   154458200   2
chr22 37019451    37019600    3
chr15 74995401    74995550    4
chr12 128823901   128824100   5

and File2 is:

chr19 4124051 4124250 1   CUP
chr15 74995401    74995550    4   CUP
chr12 128823901   128824100   5   CUP
chr12 122752651   122752950   8   CUP
chr13 113297001   113297350   9   CUP

and I would like to have a File3 like this:

chr19 4124051 4124250 1 CUP
chrX  154458151   154458200   2
chr22 37019451    37019600    3
chr15 74995401    74995550    4 CUP
chr12 128823901   128824100   5 CUP

I'd like to merge the two files according to column 4 of File1, and adding values of column 5 from File2 to the last column of File1 whenever there is a match.

This is obviously someone working in bioinformatics but the question itself is not really about bioinformatics. Nevertheless, it is relatively typical of the type of thing a bioinformatician does every day.

So, should we allow such questions even if they could be answered by anyone with knowledge of regular expressions and basic text parsing tools? If the question is one that a bioinformatician could encounter, should we consider it on topic even if it can be expressed as a general text parsing issue?

$\endgroup$
  • 1
    $\begingroup$ I think as soon as we mention the tool we want to use, it should be off-topic and worth migrating? Otherwise we will just be duplicating content over SE network? $\endgroup$ – zx8754 Jun 7 '17 at 20:12
  • $\begingroup$ @zx8754 first, the OP often doesn't know the tool. More importantly, the issue with text parsing Qs is that they are very often specific to the particular data being parsed. So duplicates aren't that clear. Also, I know I spend a lot of my time doing this sort of thing and very often help colleagues with it. Text parsing is very relevant to bioinformatics. Finally, there are sometimes considerations that a layperson won't be aware of (I can think of FASTA parsing questions, for example, where the OP didn't explain that the sequence can span multiple lines). Those are better served here. $\endgroup$ – terdon Jun 7 '17 at 20:16
  • 1
    $\begingroup$ Yes, agreed, if OP doesn't mention the tool, then it will be OK, as it will collect all solutions using different tools. But once the tool is specified, then regardless of bio knowledge anyone with particular tool proficiency would be able to answer the question, hence duplication over SE network and needs migrating (and most likely dupe hammered). Besides, I think most of SE traffic is coming form Google searches, so why would it matter which SE the Q is posted. $\endgroup$ – zx8754 Jun 7 '17 at 20:23
  • 2
    $\begingroup$ @zx8754 actually, we never migrate away a question if it is on topic on the site where it was posted. If we decide these are also on topic here, they should not be migrated. The only case for migration would be if we decide they're explicitly off topic here. $\endgroup$ – terdon Jun 7 '17 at 21:20
15
$\begingroup$

I would say we should allow these, yes. I opened a similar discussion about questions pertaining to biology and the consensus there seems to be clearly in favor of allowing them.

I feel this site only makes sense if our scope is essentially "Any question that a bioinformatician might face in the process of doing their job". We should aim to be a one-stop site for all questions that could be affecting someone trying to do bioinformatics. And since so much of bioinformatics is essentially parsing text files, it makes sense to me to allow them here.

I have seen such questions all over the place in the Stack Exchange network over the years. They are posted on Stack Overflow, Unix & Linux, Ask Ubuntu, and probably other sites too. I think all of those should come here and find a home.

Naturally, this would only apply if the text parsing in question is somehow connected to bioinformatics and not something like extracting text from a movie subtitle file or whatever.

$\endgroup$
  • 3
    $\begingroup$ Agreed with the explicit caveat that the text being processed should have at least a vague relevance to bioinformatics/biology. We don't want questions related to using grep to find something specific in /etc :) $\endgroup$ – Devon Ryan Jun 7 '17 at 19:29
  • 1
    $\begingroup$ @DevonRyan yes, of course. I added a note to that effect. $\endgroup$ – terdon Jun 7 '17 at 19:30
  • 2
    $\begingroup$ I agree, plus, I think often it takes a someone with a clear understanding of the file format to provide a good answer. For example, this SO question made no reference to bioinformatics until I added some tags and it was only then that it got a good answer (from Konrad). Other answers clearly didn't understand that FASTA permits multiple sequence lines stackoverflow.com/questions/44264127/… Sometimes it's even worse and the OP actually describes the file format wrongly, so it takes a bioinformatician to know this and provide the correct answer $\endgroup$ – Chris_Rands Jun 7 '17 at 21:17
  • 2
    $\begingroup$ @Chris_Rands yes, precisely. I have often had to clarify such things to people answering bioinformatics-related parsing questions on Unix & Linux too. $\endgroup$ – terdon Jun 7 '17 at 22:14
6
$\begingroup$

On one hand, posting this kind of question in Unix & Linux SE or stackoverflow may cause general and/or very efficient solutions to show up, due to the presence in those communities of people quite capable with general text handling skills.

On the other hand, such people might not be aware of bioinformatics tools specifically designed to efficiently solve the problem. If such tools exist, contributors to bioinformatics SE are more likely to know about them, and the answer may be of interest to a higher proportion of the readers here than in stackoverflow or Unix & Linux SE.

It is of course up to the poster to decide whether to post here or in another site, and I think we should probably accept such questions if we think that my "On the other hand" point is relevant, that is, on the basis that someone may come up with an answer based on the use of a tool specifically used in the bioinformatics field.

$\endgroup$
  • $\begingroup$ Of course it is up to the poster! That's not debatable. The question is whether we will consider such topics on topic here or not. Any form of text parsing question is already on topic on sites like Stack Overflow, Unix & Linux, Ask Ubuntu and even Ask Different, Super User and elementary OS. We're not going to move them if they're on topic where they were asked. But should we accept them if they are asked here? $\endgroup$ – terdon Jun 8 '17 at 11:14
  • $\begingroup$ I would say that we should generally accept them on the basis that they can be of interest to other bioinformaticians, and especially on the basis that someone may provide an answer based on specific tools for bioinformatics. $\endgroup$ – bli Jun 8 '17 at 11:16
  • $\begingroup$ Yes, me too. Could you edit your answer to clarify that that is your position then please? $\endgroup$ – terdon Jun 8 '17 at 11:18
  • $\begingroup$ I tried to edit my post accordingly. $\endgroup$ – bli Jun 8 '17 at 11:24
3
$\begingroup$

I think we should accept these questions, if they relate to biological data, for two reasons:

  1. The answer might reasonably be of interest to other bioinformaticians (This is mentioned in other answers).
  2. An acceptable solution might reasonably use a framework commonly used in bioinformatics, but not by anyone else. A hypothetical example: One could imagine that an acceptable answer converts the files to BED format and then merges them using bedtools. On other SE sites I would consider using bedtools for anything as too specific/off-topic.
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .