{"action":"opened","issue":{"url":"https://api.github.com/repos/cerebis/meta-sweeper/issues/47","repository_url":"https://api.github.com/repos/cerebis/meta-sweeper","labels_url":"https://api.github.com/repos/cerebis/meta-sweeper/issues/47/labels{/name}","comments_url":"https://api.github.com/repos/cerebis/meta-sweeper/issues/47/comments","events_url":"https://api.github.com/repos/cerebis/meta-sweeper/issues/47/events","html_url":"https://github.com/cerebis/meta-sweeper/issues/47","id":180424578,"number":47,"title":"Adopt a space efficient graph interchange format","user":{"login":"cerebis","id":6006667,"avatar_url":"https://avatars.githubusercontent.com/u/6006667?v=3","gravatar_id":"","url":"https://api.github.com/users/cerebis","html_url":"https://github.com/cerebis","followers_url":"https://api.github.com/users/cerebis/followers","following_url":"https://api.github.com/users/cerebis/following{/other_user}","gists_url":"https://api.github.com/users/cerebis/gists{/gist_id}","starred_url":"https://api.github.com/users/cerebis/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cerebis/subscriptions","organizations_url":"https://api.github.com/users/cerebis/orgs","repos_url":"https://api.github.com/users/cerebis/repos","events_url":"https://api.github.com/users/cerebis/events{/privacy}","received_events_url":"https://api.github.com/users/cerebis/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-09-30T23:55:16Z","updated_at":"2016-09-30T23:55:16Z","closed_at":null,"body":"Though flexible, GraphML is not a space-efficient format (shock! XML). This becomes a real consideration with larger projects. Some particularly compact formats exist (Sparse6) but often make a compromise by excluding many facilities. \r\n\r\n**Frequent limitations include:**\r\n- the inability to place any attributes at all on nodes or edges\r\n- only supporting one attribute in the form of integer edge weights,\r\n- only supporting nodes with integer ids (keys).\r\n\r\nWithout these abilities, information would have to be moved to secondary files. Does this accomplish anything in terms of storage? \r\n\r\n**Side-effects:**\r\n- It definitely creates loosely coupled data.\r\n- Memory footprint of working graphs would be smaller with integer IDs.\r\n- Would still require floating point weights or suffer precision loss and utilise a trick such as employed in quality scores.\r\n\r\n**Short-Term**\r\nAs a short-term solution, GML is a more compact text format and supports what we require. It is actually more readable that GraphML as it has little cruft.\r\n\r\n**Long-Term**\r\nThe adoption of surrogate keys requires storing of details such as source genomic entity (name, coords). This is because there will come a time in a workflow when *\"where\"* things came from will matter to the researcher. Adopting finer-scale graphs, such as SNV based, would have a large effect on graph order, making a change to integer surrogates increasingly beneficial and in the reduction of scale, the nodes themselves become increasingly abstract anyhow. I.E. the names dealt with now (contig names) are comfortable, but will not be a long-term endpoint in HiC analysis.\r\n\r\n\r\n"}}
{"actor":{"display_login":"cerebis"}}