VOEvent 2005, CalTech, 2005-Apr-14 1 R emote T elescope M arkup L anguage F.V. Rick Hessman (MONET/Univ. Göttingen) plus many collaborators, e.g. C. Pennypacker (HOU), B. Denny (DC-3 Inc), R. Emmerich & E.C. Romero (SALT), G.Tuparev (TT Inc.)

VOEvent 2005, CalTech, 2005-Apr-14 2 Where Im coming from….. MONET = MOnitoring NEtwork of Telescopes Two 1.2m f/7 imaging telescopes (Texas, South Africa) 60% science, 40% educational Strong interest in global networking

VOEvent 2005, CalTech, 2005-Apr-14 3 VOEvent = STC+ ? IVOA/STC provides: standard VO description of target coordinates (space, time, velocity, wavelength/frequency) standard VO description of observatory coordinates What VOEvent needs in addition: physical description of event (type, origin, location, behavior) astronomical description of how event was observed or needs to be observed

VOEvent 2005, CalTech, 2005-Apr-14 4 The Purpose of RTML XML-based astronomical interface for… exchange of observation requests/reports, support of remote, robotic, and service observations transfer of telescope/observatory status information exchange of project information (Phase I & II, ToO)

VOEvent 2005, CalTech, 2005-Apr-14 5 A Short History of RTML Pre 1999 : Various inscrutable (if usable) formats for description of observing requests (e.g. ATIS) 1999 : Development of RTML 1.0 by S. Gordon of Hands-On Universe 2001 : Discussion of RTML 2, creation of eStar-RTML, adoption of RTML 2.1 by many interested parties (HOU, DC-3,...) 2002 : RTML 2.1 syntax published (Pennypacker et al., A&A 395, 727)Pre-release of 3.0 by Göttingen for discussion using XML Schema rather than DTD 2003 : First releases of RTML 3.0 by Göttingen 2004 : Schema administration via XML-parsing TWiki, prototype RTML editor Anduril, proposal of RTML-Server Registry (TT Inc.) 2005 : RTML 3.1 ready for MONET, SALT, VO

VOEvent 2005, CalTech, 2005-Apr-14 6 What RTML Does Fairly completely & succinctly encapsulates standard astronomical information about targets, catalogues, (currently ground-based) telescopes, instruments, and miscellaneous devices Permits either the use of generic cameras and spectrographs and/or detailed non-generic instruments (also non-optical) Provides a description of astronomical scheduling constraints Description of calibration constraints and observations Some support for pipeline data reduction and results

VOEvent 2005, CalTech, 2005-Apr-14 7 What RTML Does (continued) WebService/VO-like syntax for server names Support for document permanence, server-side macros & variables via references to unique document plus internal document IDs Provides a document format for standard Phase I & II project information, including multi-institutional PIs/Co-PIs and time-charging - as a by-product! Simultaneous use of foreign schemata supported (3.1) Currently minimal support for IVOA/STC : and as alternatives to native and elements

VOEvent 2005, CalTech, 2005-Apr-14 8 What RTML Doesnt Do Not (originally) intended to describe events per se Full integration of IVOA STC, VOTable (yet) Not intended for dynamical control of telescopes/instruments (e.g. Instrument Neutral Device Interface,

VOEvent 2005, CalTech, 2005-Apr-14 9 Basic Building Blocks History : time-stamped entries containing changes by agents Project : contact info, scientific and technical justification Catalogue : nameable collection of targets Target : celestial, terrestrial, calibration direction, brightness/flux Telescope : optical description, location Camera : spectral region, detector, filterwheel, filters, platescale, spectral efficiency, position angle Spectrograph : spectral region, dispersion, standard optical elements, detector, spectral efficiency, filter wheel, position angle, slit/slit mask Device : generalized instrument composed of hierarchical elements Setup : macro, collection of elements Schedule : structure for detailed planning, constraints,

VOEvent 2005, CalTech, 2005-Apr Scheduling Patterns Simple State-Model : need a complete set of primary elements (Telescope+) Target+Camera/Spectrograph/Device+Exposure+Trig ger in order to have schedulable event Ideal for expressing preliminary Phase I&II, ToO info Ease of interpretation: current state easily modified by changing/addition of elements Hierarchical scheduling blocks Hierarchical scheduling constraints : airmass, aperture, selection from catalogue, time, exposure, extinction, FOV, moon, phase, position, S/N, seeing, simultaneity, sky brightness, chaining Connection/association of blocks via ids & refs

VOEvent 2005, CalTech, 2005-Apr Managing the Creation of the Schema XML Schema TWikiXML Self-documenting Manual schema definitions Dynamic Schema checking XML syntax checking Dynamic graphical syntax images

VOEvent 2005, CalTech, 2005-Apr Current Uses of RTML ACP2 : request interface for many advanced amateurs and small professional installations using DC3s Astronomers Control Panel software (RTML 2.1, but update to 3+ planned) Hands-On Universe : observation request and database format (RTML2.1, but update to 3+ planned) eStar Project: request interface for eStar network, including 2x Faulkes 2.2m telescopes (RTML 2.2) MONET Project: request, report, and telescope server administration interface for 2x 1.2m robotic telescopes (RTML 3.1) Exposure Time Calculator: RTML 3.0 can be fed directly to the general- purpose MONET Imaging Telescope Simulator Editor: prototype RTML 3.0 editor/Phase I&II tool Anduril SALT: prototype phase I/II preparation tool document format (3.0) Other Projects: interest expressed by many other robotic telescope projects…..

VOEvent 2005, CalTech, 2005-Apr RTML and VOEvent Some things match (at some level) – Curation, Where, When, How, What, Hypothesis – Informal registry via unique document ids – ~STC-compatible already (3.1) Some things dont really (at some level) – Designed as triggered observation + report, not report of event – Explicit time-charge model – Areas which need VOEvent work – Stronger difference between events & triggers? – Better STC compatibilty?

VOEvent 2005, CalTech, 2005-Apr Solution(s)? Accept internal detail of STC and other VO standards Insist VO standards are flexible, as simple as possible RTML = VOInstrument + VOSchedule??? Create conversions between formats as needed (e.g. XSLT)

VOEvent 2005, CalTech, 2005-Apr Finis

VOEvent 2005, CalTech, 2005-Apr A Simple RTML (3.1a) Document <RTML xmlns:xsi=" xmlns= version="3.1a" mode="request" uid="de.uni-goettingen.MONET://G "> Creation of document DE.Uni-Goettingen.MONET:fhessman Frederic V. Hessman Geismarlandstr. 11, Goettingen, Germany Dark Matter in Markarian 1234? By using deep images of.... Unique doc. I.D. History mechanism User info Time-charge info Project info XML stuff

VOEvent 2005, CalTech, 2005-Apr A Simple RTML 3.1a Document (cont.)... agn V UT P1D Target info Instrument info Scheduling constraints Triggered only if an is in a RTML could fill the niche needed by VOEvent to describe astronomical information beyond STCs positions and coordinates RTML is designed to permit the transfer of observation requests Syntax is simple, straight-forward and humanly readable Conscious compromise between power/complexity and ease of implementation Development of XML Schema via parsing Twiki with graphics

VOEvent 2005, CalTech, 2005-Apr Finis Pennypacker et al., 2002, A&A 395, 727 (RTML 2.1)