I’ve been investigating the VO options for AtomDB/SPEX/others to make a uniform interface for online queries and interactive line identification. I’ve spoken to people at VAMDC and with Markus Demleitner who develops the LineTAP protocol.
A big part of where we go next depends on what exactly we would want an interface to do:
- Spectra/linelist output only: This would be a simple line list as a function of whatever plasma parameters (e.g. temperature).
- Full access to the underlying atomic data in a standardized format.
I am only going to discuss option 1 here as I think that’s a more achievable goal, but if we want to consider option 2 then that’s a possibility.
LineTAP is an evolution of SLAP, which is still in development. It is a simplified option which will integrate nicely with the VO. My understanding (limited!) is that you convert your database into another format using a tool such as DaCHS and then convert it into The downside is that the format is (as I understand it) unable to incorporate temperature dependence any more complex than on the fly conversion from oscillator strengths. It doesn’t have the capability of any in-built temperature dependence, and that would be a stretch goal if it was ever to be achieved.
VAMDC would meet our requirements (the example case I specified was “can you return the lines of oxygen between 19 and 26 Angstroms in a 1MK plasma”, and they said that was possible). In theory you make your database accept a VSS2 query and return an XSAMS output. This would, in theory, allow us to specify extra keywords such as plasma temperature, density, etc on the input, as long as our database interface can run the model and return the relevant line list.
However, they did issue a few caveats about VAMDC. One is that implementing the VSS2 language is apparently quite tricky, and as relatively few (no?) other sites have similar requirements to us it might be a big time sink. Essentially, if the only inter-database comparisons are between ourselves, getting the VAMDC queries to work might not be worth it. On the output side, they also didn’t think XSAMS was a great format as it cannot be ingested easily into most codes. One idea for the future of VAMDC is to streamline this part but they are not there yet.
Instead they suggested a JSON structure for query with keywords (e.g. {“lambdamin”:19, “T”:1e6} etc) and returning something like a csv file which can be easily read by the end user.
My initial hunch is that that the JSON query should be straightforward to implement and probably to adapt to VSS2 if necessary later on. As for the output, once you have a table, putting a linelist in XSAMS, csv or other format should be straightforward enough. Since standards are good, I would suggest that if we make our own input/output we pick which keywords we want to use from the XSAMS and VSS2 standards, and make our reponses compatible with those where possible, so future changes would be not require another conversion layer.
Thoughts welcome!