{"action":"created","issue":{"url":"https://api.github.com/repos/alchemistry/fileformat/issues/13","repository_url":"https://api.github.com/repos/alchemistry/fileformat","labels_url":"https://api.github.com/repos/alchemistry/fileformat/issues/13/labels{/name}","comments_url":"https://api.github.com/repos/alchemistry/fileformat/issues/13/comments","events_url":"https://api.github.com/repos/alchemistry/fileformat/issues/13/events","html_url":"https://github.com/alchemistry/fileformat/issues/13","id":179051850,"number":13,"title":"Evaluate alternative formats","user":{"login":"avirshup","id":9388007,"avatar_url":"https://avatars.githubusercontent.com/u/9388007?v=3","gravatar_id":"","url":"https://api.github.com/users/avirshup","html_url":"https://github.com/avirshup","followers_url":"https://api.github.com/users/avirshup/followers","following_url":"https://api.github.com/users/avirshup/following{/other_user}","gists_url":"https://api.github.com/users/avirshup/gists{/gist_id}","starred_url":"https://api.github.com/users/avirshup/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/avirshup/subscriptions","organizations_url":"https://api.github.com/users/avirshup/orgs","repos_url":"https://api.github.com/users/avirshup/repos","events_url":"https://api.github.com/users/avirshup/events{/privacy}","received_events_url":"https://api.github.com/users/avirshup/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-09-24T21:05:57Z","updated_at":"2016-09-26T06:52:23Z","closed_at":null,"body":"Speaking personally, the best outcome of this would be to find that someone has already solved the problems we're thinking about, or at least at least has a solution that can be extended to cover this project's specific application focuses (#1 and #10)\r\n\r\nBelow is a continuously-updated list of other projects. Everything here should be with a grain of salt, as it's an attempt to glean information from many different specifications :)\r\n\r\n**MOSAIC**\r\nFormats: XML, HDF5 (with straightforward extensions based on the data model)\r\nLicense: Creative Commons 3.0\r\nUnits: List of supported units in spec\r\nDesign criteria: https://mosaic-data-model.github.io/design_criteria.html\r\nData stored: topology, CG info, selections (i.e., subsets of the file's data), references to other \"universes\"; \"properties\" (unclear if these are whole-system properties or atomic properties?)\r\nSpecification: https://mosaic-data-model.github.io/\r\n\r\n**Rich molecule format**\r\n_todo_\r\n\r\n**H5MD**\r\nType: Binary (HDF5)\r\nSelf-describing: yes\r\nDomain: molecular dynamics\r\nFlexible units: [yes](http://nongnu.org/h5md/modules/units.html)\r\nHuman readable: not without HDF5 viewer\r\nLicense: GPL (need to understand copyleft implications here)\r\n[Data stored](http://nongnu.org/h5md/h5md.html): MD state data; atoms and their connectivity. Arbitrary atom lists/groups can be defined (nothing specific for chains/residues/etc)\r\nSpecification: http://nongnu.org/h5md/\r\n\r\n**Amber NetCDF**\r\nType: Binary (HDF5)\r\nSelf-describing: Yes\r\nHuman readable: not directly (GUI viewers available)\r\nFlexible units: yes\r\nDomain: biomolecular dynamics\r\nData stored: Trajectory (no topology)\r\nSpecification: http://ambermd.org/netcdf/nctraj.xhtml\r\n\r\n**MDTraj HDF5**\r\nType: HDF5\r\nSelf-describing: Yes\r\nHuman readable: no\r\nData stored: Trajectory (+ topology as a JSON string)\r\nFlexible units: yes\r\nDomain: biomolecular dynamics\r\nSpecification: https://github.com/mdtraj/mdtraj/wiki/HDF5-Trajectory-Format\r\nNotes: This is an extension of Amber NetCDF format. FF-focused topology storage (as JSON)\r\n\r\n**Chemical Markup Language (CML)**\r\nType: XML\r\nHuman readable: yes\r\nSelf-describing: sort of - must adhere to a schema\r\nSpecification: http://www.xml-cml.org/\r\nFlexible units: yes\r\nDomain: small molecule modeling\r\nData stored: coordinates, molecular properties, topology w/ stereochemistry, calculation parameters, electronic wavefunctions, computational metadata (i.e. hostname, programVersion, etc.). No support for biomolecules or trajectories.\r\nNotes: I like this project's aims, but there's a LOT of conceptual overhead for understanding XML schema. I don't think I've ever used software that supports CML.\r\n\r\n**PDBx / MMCif**\r\nType: CIF (text-based, see http://www.iucr.org/resources/cif/spec/version1.1/cifsyntax)\r\nSelf-describing: yes\r\nFlexible units: no\r\nDomain: Crystallography / NMR\r\nSpecification: http://mmcif.wwpdb.org/docs/tutorials/content/atomic-description.html\r\nhttp://mmcif.wwpdb.org/docs/tutorials/content/molecular-entities.html\r\nNotes: Vast improvement over original PDB. Medium-to-high conceptual overhead. Parsers are still hard to come by.\r\nData stored: everything you'd expect in a PDB file: topology + coordinates + crystallographic metadata. \r\n\r\n**Chemical JSON**\r\nType: JSON (text-based)\r\nSelf-describing: yes\r\nNotes: I think this is more of a proof-of-principle (implemented in Avogadro) than a mature spec, but interesting nonetheless. JSON is by far the easiest language here to read and write, both with machines and by hand.\r\nSpecification: http://wiki.openchemistry.org/Chemical_JSON\r\n"},"comment":{"url":"https://api.github.com/repos/alchemistry/fileformat/issues/comments/249492423","html_url":"https://github.com/alchemistry/fileformat/issues/13#issuecomment-249492423","issue_url":"https://api.github.com/repos/alchemistry/fileformat/issues/13","id":249492423,"user":{"login":"khinsen","id":94934,"avatar_url":"https://avatars.githubusercontent.com/u/94934?v=3","gravatar_id":"","url":"https://api.github.com/users/khinsen","html_url":"https://github.com/khinsen","followers_url":"https://api.github.com/users/khinsen/followers","following_url":"https://api.github.com/users/khinsen/following{/other_user}","gists_url":"https://api.github.com/users/khinsen/gists{/gist_id}","starred_url":"https://api.github.com/users/khinsen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/khinsen/subscriptions","organizations_url":"https://api.github.com/users/khinsen/orgs","repos_url":"https://api.github.com/users/khinsen/repos","events_url":"https://api.github.com/users/khinsen/events{/privacy}","received_events_url":"https://api.github.com/users/khinsen/received_events","type":"User","site_admin":false},"created_at":"2016-09-26T06:52:23Z","updated_at":"2016-09-26T06:52:23Z","body":"@avirshup Two comments on your summary of Mosaic:\r\n\r\n1) Mosaic properties are per-atom or per-site properties. Think masses, charges, force-field atom types (perhaps better served by Mosaic labels), etc.\r\n\r\n2) The list of units in the Mosaic spec can easily be extended if necessary. The point of having it is not to limit the list of units, but to ensure a unique spelling for each one.\r\n\r\nThat said, my experience is that units in a file format are a mixed blessing. The more flexibility a format provides for units, the easier it is to write data but at the same time it becomes harder to read data, because the reader must know all the units with their conversion factors and apply them properly. If I were to design a closed file format (i.e. fully specified without any possibility for extensions), I'd prescribe a single unit for everything. Google for \"convention over configuration\" for discussions of the advantages of such an approach. Mosaic being open-ended (properties, for example, can be anything and thus have unforeseeable units), that was not an option.\r\n"}}
{"actor":{"display_login":"khinsen"}}