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

Project organisation - discussion forum? #2

Open
blahah opened this issue Apr 18, 2013 · 5 comments
Open

Project organisation - discussion forum? #2

blahah opened this issue Apr 18, 2013 · 5 comments

Comments

@blahah
Copy link

blahah commented Apr 18, 2013

Is there a discussion platform for this project somewhere? It's hard to see from just this repo what current work is being done, and what contributions I can make.

@danmaclean
Copy link
Member

Hi,

There isn't really a full list of what is ongoing on right now. But it is a good idea so I've started a wiki page (here https://github.com/ash-dieback-crowdsource/data/wiki/Who-is-doing-what) for anyone who chooses to say what they are doing. Not everyone wants to say what they are doing as they just want to play with the data and see what happens. We aren't enforcing reporting like this. In fact we are very happy to have overlapping analyses, different people take different approaches to the same problem and that is very valuable to us

If what you have planned is quite time or resource consuming then feel free to contact me and I'll let you know if I know of anyone doing it already.

The data and analyses that have been pushed back to the repo are all listed in the wiki on this page https://github.com/ash-dieback-crowdsource/data/wiki and on our hub for the project at http://oadb.tsl.ac.uk

Hope this helps,

Dan

@blahah
Copy link
Author

blahah commented Apr 18, 2013

Hi Dan,

No problem. My initial plan is:

  • grab all the ash reads including mixed
  • separate out as many chalara reads as possible by bloom filtering against the existing chalara assembly
  • clean, error correct and k-mer coverage normalise
  • feed the set of all ash reads into my de-novo assembly optimiser to iteratively improve the ash assembly
  • annotate it with our conditioned reciprocal best blast pipeline
  • repeat the same process for chalara

From there, if the data are suitable:

  • expression quantification
  • DE for ash infected vs. uninfected
  • involve colleagues working in fungal plant pathology to start mining interesting stuff from the transcriptomes

I have three questions initially:

  1. Is there anything you know of that makes this approach redundant or inappropriate?
  2. Is there any more sequencing underway?
  3. Does the project have a data store where can I put the intermediate data (e.g. cleaned/normalised reads) so others can use them if they wish?

@danmaclean
Copy link
Member

Looks great, I think improved transcript assemblies from these data would be great.

To answer the questions

  1. I don't think anyone is doing an improved transcript assembly for the ash from these data, so yes that would be useful. Though the chalara stuff is getting some discussion at the moment (see issue AT2 Transcript assemblies - which one?! #1 ).
  2. Lots, multiple ash transcriptomes, and multiple strains of chalara from across the continent are being done. Some ash genomic is being done too. Though for some of that we might not see the reads quickly as we know this is being done outside the crowdsourcing effort (which is fair enough, I should add).
  3. Yep, we have ftp. But rather than store subsets of reads its probably better to provide the tool version and command line you used for cleaning and normalising so that they can be regenerated if needed.

@RichardBuggs
Copy link

Dear all,

With reference to (2) below, a very preliminary ash genome assembly based on low coverage 454 can now be found here: http://ashgenome.org. We are awaiting Illumina data that should lead to considerable improvements of the assembly.

best wishes

Richard

On 19 Apr 2013, at 09:25, Dan MacLean wrote:

Looks great, I think improved transcript assemblies from these data would be great.

To answer the questions

I don't think anyone is doing an improved transcript assembly for the ash from these data, so yes that would be useful. Though the chalara stuff is getting some discussion at the moment (see issue #1 ).
Lots, multiple ash transcriptomes, and multiple strains of chalara from across the continent are being done. Some ash genomic is being done too. Though for some of that we might not see the reads quickly as we know this is being done outside the crowdsourcing effort (which is fair enough, I should add).
Yep, we have ftp. But rather than store subsets of reads its probably better to provide the tool version and command line you used for cleaning and normalising so that they can be regenerated if needed.

Reply to this email directly or view it on GitHub.


Dr Richard Buggs | Senior Lecturer | School of Biological and Chemical Sciences, Queen Mary University of London, E1 4NS, United Kingdom | email: [email protected] | website: http://www.sbcs.qmul.ac.uk/staff/richardbuggs.html | office: +44(0)207 882 3058 | mobile: +44(0)772 992 0401 | twitter: @RJABuggs

@danmaclean
Copy link
Member

Brilliant! Thanks Richard!

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

3 participants