-
Notifications
You must be signed in to change notification settings - Fork 0
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
consider implementing in sasCIF #4
Comments
What was the extent of this proposal and what was the reasoning? |
At SAS2015, in the presentation of the sasCIF, it was mentioned by the speaker that the format should be able to express multidimensional reduced SAS data. Given the adoption of sasCIF for biological SAS data (for both analysis and deposition), it is important to attempt to implement the canSAS standard in sasCIF. This action may broaden the sasCIF standard to encompass a greater fraction of SAS data than at present. Some members of the canSAS community have expressed that data files must be text while others emphasize that binary is the most practical for large datasets. The sasCIF format is text based. Furthermore, already it has the sponsorship of the IUCr Commission on Small-Angle Scattering, something which is sought by canSAS for this new multi-dimensional format. We must be careful and avoid spreading ourselves too thinly. Yet the progress of the sasCIF should not be ignored. Of particular concern is that the approval process for adoption of new components into sasCIF appears to be vested in one individual. |
The drive by the one individual of sasCIF makes it uniquely geared towards (particularly) his purposes. Practically, though, I do not see the compatibility options of mixing HDF5 with the text-based sasCIF (and the intercompatibility horrors of having to figure out binary blobs in text files again). |
We need to be clear: CIF was not invented as a data interchange format, but rather for data deposition and archiving. The responsibility for generating CIF therefore lies with those programs that are performing analyses (and hence generating output) that users wish to deposit/archive in some archive/library. The biological SAS community have long been disadvantaged (compared to the MX community) because the PDB has made it extremely difficult to deposit structures originating from solution scattering. This has led to several alternative structure deposition databases. But, if what is deposited is to have any worth it needs to be in a meaningful and helpful format. This is why sasCIF was developed some 15 years ago now (I was one of those that helped develop it, and actually implement it!). The problem, just like with our SASXML/canSAS1D format, is that you can lead a horse to water but you can't make it drink: adoption is difficult. What has happened now is that the IUCr SAS Commission has given its blessing to sasCIF as its preferred deposition format. I think canSAS should welcome and encourage this development, but I see it as completely separate to the work of canSAS on 1D and nD data interchange formats. Put another way, canSAS formats should be helping facilitate the use of programs that offer sasCIF output (after suitable analysis). |
It appears that the NXcanSAS standard aims to describe reduced SAS data of any dimensionality while the sasCIF standard describes 1-D data. |
at SAS2015, it was proposed that the canSAS2012 be implemented in sasCIF
explore if that is feasible
The text was updated successfully, but these errors were encountered: