{"action":"created","issue":{"url":"https://api.github.com/repos/ga4gh/server/issues/305","labels_url":"https://api.github.com/repos/ga4gh/server/issues/305/labels{/name}","comments_url":"https://api.github.com/repos/ga4gh/server/issues/305/comments","events_url":"https://api.github.com/repos/ga4gh/server/issues/305/events","html_url":"https://github.com/ga4gh/server/issues/305","id":65264449,"number":305,"title":"Dockerize ga4gh server + example data","user":{"login":"macieksmuga","id":6685511,"avatar_url":"https://avatars.githubusercontent.com/u/6685511?v=3","gravatar_id":"","url":"https://api.github.com/users/macieksmuga","html_url":"https://github.com/macieksmuga","followers_url":"https://api.github.com/users/macieksmuga/followers","following_url":"https://api.github.com/users/macieksmuga/following{/other_user}","gists_url":"https://api.github.com/users/macieksmuga/gists{/gist_id}","starred_url":"https://api.github.com/users/macieksmuga/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/macieksmuga/subscriptions","organizations_url":"https://api.github.com/users/macieksmuga/orgs","repos_url":"https://api.github.com/users/macieksmuga/repos","events_url":"https://api.github.com/users/macieksmuga/events{/privacy}","received_events_url":"https://api.github.com/users/macieksmuga/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":25,"created_at":"2015-03-30T17:47:12Z","updated_at":"2015-03-31T18:33:46Z","closed_at":null,"body":"Once the first stable release is reached."},"comment":{"url":"https://api.github.com/repos/ga4gh/server/issues/comments/88200889","html_url":"https://github.com/ga4gh/server/issues/305#issuecomment-88200889","issue_url":"https://api.github.com/repos/ga4gh/server/issues/305","id":88200889,"user":{"login":"benedictpaten","id":593440,"avatar_url":"https://avatars.githubusercontent.com/u/593440?v=3","gravatar_id":"","url":"https://api.github.com/users/benedictpaten","html_url":"https://github.com/benedictpaten","followers_url":"https://api.github.com/users/benedictpaten/followers","following_url":"https://api.github.com/users/benedictpaten/following{/other_user}","gists_url":"https://api.github.com/users/benedictpaten/gists{/gist_id}","starred_url":"https://api.github.com/users/benedictpaten/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benedictpaten/subscriptions","organizations_url":"https://api.github.com/users/benedictpaten/orgs","repos_url":"https://api.github.com/users/benedictpaten/repos","events_url":"https://api.github.com/users/benedictpaten/events{/privacy}","received_events_url":"https://api.github.com/users/benedictpaten/received_events","type":"User","site_admin":false},"created_at":"2015-03-31T18:33:46Z","updated_at":"2015-03-31T18:33:46Z","body":"These are good points Erik, worth starting an alternative thread.\n\nI'd point out there are several graph alignment schemes now in\nexistence/aborning - none are likely to be using the GA4GH API directly for\ntheir data structures/algorithms.\n\nI view the API we've defined as a not crazy way of communicating our\nresults in a common format and comparing them. It may well grow and change\nover time, but that is the initial aim. On the issue of SQLite - we\ncertainly won't keep it around long term, but it is pragmatic starting\npoint for this project.\n\nOn Tue, Mar 31, 2015 at 7:35 AM, Erik Garrison <notifications@github.com>\nwrote:\n\n> @pgrosu <https://github.com/pgrosu> brought me here by mentioning my work\n> with vg <https://github.com/ekg/vg>. I'd like to contextualize that\n> within the overall GA4GH efforts around changes in reference technology and\n> compressed evidence and population data.\n>\n> Although I support the work of the GA4GH standards groups in principle, I\n> do not think that specification-first development is likely to generate\n> usable systems. Ideally, we should seek to produce standards when there are\n> several existing systems that operate in the same space and need to\n> communicate using a common pattern. This gives teeth to the standards\n> process, which it needs in order to have impact.\n>\n> I urge participants to avoid the bikeshedding\n> <https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality> trap of\n> familiar client/server interface minutia and familiar system architectures\n> and instead tackle the difficult issues and concepts here which necessarily\n> lie outside of our experience. The only way to do this is to try to make\n> something that works and see what happens. A number of people need to do\n> this to be able to have a constructive or meaningful standardization\n> process.\n>\n> vg has taken almost exactly 6 months to develop from a protobuf schema I\n> sent @lh3 <https://github.com/lh3> to a system that is capable of\n> constructing variation graphs, indexing them, and align reads against them\n> efficiently enough that we can consider putting it into production at the\n> Sanger provided minor improvements in performance and work flow. (\n> @macieksmuga <https://github.com/macieksmuga> one lesson is that\n> compressed graph indexes are 10s of GBs and compressed kmer indexes are\n> 100s of GBs. sqlite may be inappropriate for dbs of this scale.)\n>\n> 6 months of a PhD student's time is a substantial commitment, but it\n> should be encouraging that millions of $ or £ is not required to make an\n> equivalent system. Others should not be afraid to take on the task as a\n> clearly-defined project with a reasonable time frame. This means there is\n> still enough time for several other groups to develop functioning systems\n> within the 2 year time frame. With luck, in another six months we can\n> figure out how to get them to talk to each other. Before getting them to\n> talk to each other, they should at least be able to communicate with\n> themselves and their human operators. They should work, and produce useful\n> results. The basic interfaces and functions they are built from will\n> describe the likely aspects of any common, standard, public interface they\n> might have.\n>\n> This all said, I'd like to stress that I feel the GA4GH community is\n> immensely valuable, and I have learned a lot from these conversations, even\n> incorporating lessons from discussions among group members into my own\n> work. I suspect others have had similar experiences, and in this sense I\n> see the last year as a great success. My point is that now is the time to\n> put our hands to work on practical systems, or the legacy of the work will\n> be mostly conceptual and community-building.\n>\n> And, finally, I invite everyone here to participate on the development of\n> vg. *It is a fully-functional, open source graph genome implementation*.\n> It's been developed in a test-driven pattern that should make it very easy\n> for other contributors to extend without breaking. It is designed to be\n> integrated as library into other projects. The vg executable\n> <https://github.com/ekg/vg/blob/master/main.cpp> is itself a\n> loosely-coupled integration of various functions provided by the library\n> and also the primary point of testing. This could be a viable option if\n> you'd prefer to work on a particular aspect of the problem (such as the\n> GA4GH APIs) than develop the entire stack from scratch. I will be more than\n> happy to support anyone who pursues this.\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/ga4gh/server/issues/305#issuecomment-88112329>.\n>\n"}}