[TDA_wg] Outline of discussion at Hotwired IV

[Rob Seaman]

Thanks to Andy for posting the outline from the spirited discussion at Hotwired, and glad to see his first bullet regarding nomenclature being discussed here.  The outline maps well onto VOEvent use cases and it may be worthwhile interjecting a few “virtual” comments:

> 1)  Naming schemes (current IAU SN naming system has these undesirable issues: SNe start with a PSN name, then transition to other names, may SNe go unnamed, and many groups give the same event different names).
> 
> A)  Name server? (i. e. there is a new transient at location X, returns name if one exists, assigns new one of not).
> 
> B)  Specific to event subtypes? (i.e. are separate naming conventions for GRBs / SNe / Novae, etc, a historical accident, or should they just all be 15abc as many surveys have done)
> 

A) In the VO, each survey or observatory would control its own namespace and either run its own server or coordinate with registered centralized naming authorities.  There would be relatively few rules limiting nomenclature outside what is needed to navigate to the right server.   As usual, the problem isn’t too few standards, but too many:

	http://ivoa.net/documents/index.html <http://ivoa.net/documents/index.html>

B) The unique naming of events requires a fairly lengthy string like a VOEvent IVORN or the position+time usage of various surveys.  More fundamental is the underlying workflow of whatever science use case.  Not all synoptic surveys are the same or are looking for the same thing. There are complications such as multiple events from multiple, or the same, facilities corresponding to the same physical phenomena.  On the other hand, one detection might correspond to multiple phenomena, or an historical SN, for instance, may correspond to a current SN remnant.  Names useful for SNe won’t make much sense for solar system objects or even galactic novae, etc.

At the end of the day it seems likely that an automated service to provide names for celestial events will be different than a human-moderated (or even automated) service to provide names for classified, vetted and confirmed astrophysical phenomena.  Not to mention that we continue to discover new types of phenomena and to reconsider the physical models of past phenomena.

> 2)  Communicating discoveries
> 
> A)  IAU
> 
> B)  ATEL
> 
> C)  Web pages
> 

Project web pages will always exist, but address a different need than a community “telegram”.  The strategy followed for VOEvent was to create a standard that could be adopted as an option by all the known event publishers.  There are many more than CBAT and ATel; see Josh Bloom’s slide from the 2006 Transient Universe meeting (that loaned its name to “Hot-wiring the Transient Universe”):

	http://online.kitp.ucsb.edu/online/grbtu_c06/bloom/oh/21.html <http://online.kitp.ucsb.edu/online/grbtu_c06/bloom/oh/21.html>

This is not a complete list.  The idea is that a project could publish events through some API (like https://comet.readthedocs.org <https://comet.readthedocs.org/>) and be directed to a publisher appropriate to the science sub community.  And an astronomer or follow-up project could subscribe to that stream of events via the same API.

> 3)  Sharing information in real time
> 
> A)  Scheduling resources e.g. I’m going to observer this tonight.
> 
> B)  Here’s the redshift, type, and spectrum.
> 
> C)  Here are the light curve points in all wavelengths
> 
> D)  Social media type interactions
> 
> 4)  Iterating the above (e.g.. based on latest LC point and redshift, this object is likely...)
> 
> 5)  Automated telescope triggering
> 

These are all use cases that were considered in creating VOEvent.  The requirements spanning them all is to provide enough control over the semantics that the needs of both humans and software systems are supported.  For example, there were several demonstrations of wiring up VOEvent streams to twitter or other social media; it’s pretty straightforward.

The issue of scheduling and triggering follow-up observations is distinct from that of describing celestial events, however.  VOEvent describes what a survey or pointed observation has seen.  Who and how and when to follow it up is a different calculus from who and how and when it was discovered.  See, for instance, sections 3-5 from:

	http://arxiv.org/pdf/1407.7552.pdf <http://arxiv.org/pdf/1407.7552.pdf>


> 6)  Archiving data / querying databases
> 

Archives are a broader issue than the time domain, of course, but among other things rapid response observing modes reveal the existence of strong performance requirements for automated archiving.

Several VOEvent related projects have demonstrated the capability of automating database queries of different sorts, starting with Ashish Mahabal’s VOEvent-enabled asteroid service at the 2005 NVO Summer School.  Our team injected events into the classroom demonstration event network and among other activities it triggered finding charts containing asteroids that were nearby at the time.

> Questions:  
> 
> 
> 
> - What types of events can work under the same system?  Supernovae, GRBs, microlensing, planets, variable stars, flares, etc.
> 

Each field of a synoptic survey will produce detections of all these.  The workflow needs to handle each, if only to filter them out.  Thus VOEvent has to be able to represent each.

> - Do we adapt existing infrastructure?  Build something new?
> 

Both.

> - Where does the money come from?
> 

Good question.  Part of the answer is to avoid having each sub community duplicate efforts on what is largely the same set of protocols and the same community-wide infrastructure.

> - Do we need the IAU?
> 

The system of astronomical facilities is international in scale with observatories on all continents, in the middle of oceans, in the air and in space.  The IAU is the only international astronomical organization we have.  We don’t, however, need to continue to use the IAU in the same way it always has been.  That is one message resulting from the commission reform.

To continue the nomenclature discussion, this does indeed seem like a reasonable standards activity and perhaps an operational responsibility of the TDA working group.  We could certainly define a tda_wg namespace that would be suitable for some, if not all, of the classes of phenomena mentioned above.  An organization would need to volunteer to host the WG name server with some service-level agreement over some period of time.

> - Does it need to scale to LSST?
> 

Yes.  Back of the envelope calculations showed that even technology from 2005 could keep up with the most inefficient version of one-by-one VOEvent processing for LSST.  One is confident that they will adopt a tabular variation of VOEvent that can represent the thousands of per-visit events and related provenance in one composite portfolio.

The infrastructure (event brokers, name servers, etc.) need to be fielded, tested and in regular community use long before the LSST survey is operating.

Rob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist10.pair.net/pipermail/tda_wg/attachments/20150522/f05f7b6b/attachment-0001.html>