Skip to content
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

Open
prjemian opened this issue Sep 15, 2015 · 5 comments
Open

consider implementing in sasCIF #4

prjemian opened this issue Sep 15, 2015 · 5 comments

Comments

@prjemian
Copy link
Contributor

at SAS2015, it was proposed that the canSAS2012 be implemented in sasCIF

explore if that is feasible

@ajj
Copy link
Member

ajj commented Sep 17, 2015

What was the extent of this proposal and what was the reasoning?

@prjemian
Copy link
Contributor Author

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.

@toqduj
Copy link

toqduj commented Sep 17, 2015

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).
CanSAS is on the right path, I suspect.

@smk78
Copy link

smk78 commented Sep 29, 2015

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).

@prjemian
Copy link
Contributor Author

It appears that the NXcanSAS standard aims to describe reduced SAS data of any dimensionality while the sasCIF standard describes 1-D data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants