Time Domain presentation at CSP

[Rob Seaman]

On Jun 17, 2015, at 8:12 AM, Enrique Solano <esm at cab.inta-csic.es> wrote:

> Hi John, hi VOEvent,
> …
>> - Enrique’s note (\S 2.6) points out that there’s no “DatasetType” parameter in SimpleTimeSeries. I’m sure that’s true, but one might also regard such a parameter as redundant (if I’m looking at a SimpleTimeSeries, there’s probably a pretty good chance that it involves time series data).
> DatasetType is definitely necessary for data models with a broader scope
> (e.g. Spectral Data Model) but even in STS it could play a role, for
> instance to distinguish between light curves and radial velocity curves.

Or Roy’s example of gravitational-wave strain, one supposes. However, any vector of data where one axis is time is a time-series.  Subdividing the DatasetTypes to distinguish between classes of phenomena seems redundant with simply recognizing what it is a series of. Not to mention that a time series may have multiple columns representing different things. In your example variations in light and variations in radial velocity might both be included yet the entire data product remains a time series. Time domain science often includes correlating multiple time series vectors.

The IVOA has never met a “type” paradigm it never liked.  Is DatasetType supposed to provide an exhaustively exclusive list of all possible variations of time series, etc?  Or is it rather more like a mime type in concept; capturing the broad essence like “I am an image” versus “I am a spectrum” versus “I am a time series”?

>> - At the recent Hotwired meeting, there was a fair bit of discussion about handling event notifications, but nothing much about the details of how to access time series data. The average astronomer regards it as “just” fetching a list of numbers from a database. Clearly that’s inadequate, but what’s _actually_ required to meet their needs? Why doesn’t the community regard this as a problem?
> It depends on what you understand by "community". Of course, there are
> not crowds of people knocking at my door and praying for standards :-)

More to the point there will never be crowds clamoring for data models.  Rather, they will clamor for practical file formats and the tools and libraries needed to create them for internal use and for interchange. The amount of clamor will be directly proportional to actual science they want to achieve, not to any philosophical vision of computing.

STS was never just an interim IVOA DM “solution”, it is a pre-existing community standard format (that grew out of the first Hotwired meeting). On the other hand SDM v2.0 is explicitly an IVOA DM. Perhaps the question might best be posed as how to represent SDM v2.0 compliant data using STS. Maybe this will require adding some parameters to STS, but this will be more persuasive after attending to Arnold’s comments, for instance. In general IVOA will find more success at incrementally evolving pre-existing standards (toward adherence to shiny new IVOA DMs) than with convincing astronomers and projects to drop what they are doing and pick up something new entirely.

> Maybe the attendance to the hotwired meeting was statistically biased
> towards transients... :-)

A sequence of measurements expressed as transient alerts (e.g., a citation trail of VOEvents) is another way to convey a time series.

However broad the IVOA’s collection of time series use cases, the astronomical community’s ever-growing set of time domain science use cases will always outstrip it. By all means work to create broad data models capturing a snapshot of the essence of some scientific discipline. But Postel’s Law (https://en.wikipedia.org/wiki/Robustness_principle) suggests that reifications need to be forgiving.

Rob