Thanks for the answer, I would like to also add some suggestions On Wed, Jan 30, 2013 at 6:31 PM, Dana Robinson <derob...@hdfgroup.org> wrote: > Hi Jeff, > > I had a look at your document I have some comments: > > (page 2) It looks like you intend for your "schema" to be a human-readable > description of how the data are organized and not a formal specification > that can be used to validate an HDF5 file via a check tool of some sort (as > in an XML schema). Although I'm sure this is informally useful to you, this > lack of a machine-verifiable formal specification would be a major weakness > of HDF5ds. Perhaps one can use hdf5 to XML and verify the XML > > (page 3) HDF5 not specifying how user metadata should be structured is not > really a "limitation" of HDF5. Different users will have differing ideas > about what metadata is important so we don't lock people into a particular > arrangement. I think this is a stronghold of hdf5, Instead of specifying metadata structure it might make more sense to let everyone use a wider range of data structure that better represents their data, but instead specify a structure for meta-meta-data. What I mean is each company can describe its meta-data inside the file itself using standard nodes, remember hdf5 also accepts symbolic/soft links (shortcuts). For example I can record my channels on "/channels/channel01/dataset" while another company may record in "/recording/1" Now if standards specifies something like "/experiment/info/channel/continuous/1" each company should only create the shortcut to its own data. > > (page 3) You can store mixed types in an attribute using a compound type. Yes and the nice thing about the mixed type [1] is that it will appear as a table when viewed in tools such as HDFViewer > > > (page 4) The term "settings" is probably too experimentally oriented for > general HDF5 use. What does "settings" mean in a file that stores > phylogenetic tree data or patient history data? Yes, maybe something like /experiment/info can be standardized (with the link approach) > > (page 5) The idea of associating attributes to collections of objects in > the HDF5 file is an interesting one, though I'm not sure how to cleanly > handle that off the top of my head. Definitely something to keep in mind. > I would want to handle that inside the library, though, and not via easily > broken parseable string attributes. > I think this can be also achieved using soft links, you can record the attribute once and reference it in multiple nodes
dashesy Unless explicitly stated, the opinions expressed in this email do not represent the official position of the company I work for. [1] One reference implementation (using structured attributes): https://github.com/dashesy/CereLink/tree/master/n2h5 _______________________________________________ Hdf-forum is for HDF software users discussion. Hdf-forum@hdfgroup.org http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
