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

VOEvent 2005, CalTech, 2005-Apr-14 1

Remote Telescope Markup Language Remote Telescope Markup Language

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


Where I’m coming from…..Where I’m coming from…..

• MONET = “MOnitoring NEtwork ofTelescopes”

• Two 1.2m f/7 imaging telescopes (Texas, South Africa)

• 60% science, 40% educational

• Strong interest in global networking


VOEvent = STC+ ?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


The Purpose of RTMLThe 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)


A Short History of RTMLA 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öttingen2004 : 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


What RTML DoesWhat RTML Does

• Fairly completely & succinctly encapsulates standard astronomical information about targets, catalogues,(currently ground-based) telescopes, instruments, andmiscellaneous 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


What RTML Does (continued)What RTML Does (continued)

• WebService/VO-like syntax for server names

• Support for document permanence, server-side macros & variables via references to unique document plusinternal document IDs

• Provides a document format for standard “Phase I & II”project information, including multi-institutional PI’s/Co-PI’s and time-charging - as a by-product!

• Simultaneous use of foreign schemata supported (3.1)

• Currently minimal support for IVOA/STC :<VOObservatoryLocation> and <VOObservationLocation> asalternatives to native <Location> and <Coordinates> elements


What RTML Doesn’t DoWhat RTML Doesn’t 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”,

http://INDI.sourceforge.org)


Basic Building BlocksBasic 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,


Scheduling PatternsScheduling Patterns

• Simple State-Model : need a complete set of primary elements

(Telescope+)Target+Camera/Spectrograph/Device+Exposure+Trigger 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 id’s & ref’s


Managing the Creation of the Schema

Managing the Creation of the Schema

• XML Schema

• TWikiXML

• http://monet.uni-sw.gwdg.de/twiki/bin/view/RTML/WebHome

• “Self-documenting”

• “Manual” schema definitions

• Dynamic Schema checking

• XML syntax checking

• Dynamic graphical syntax images


Current Uses of RTMLCurrent Uses of RTML

➢ ACP2 : request interface for many advanced amateurs and small professional installations using DC3’s Astronomer’s 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…..


RTML and VOEventRTML and VOEvent

• Some things match (at some level)– Curation, Where, When, How, What, Hypothesis– Informal “registry” via unique document id’s– ~STC-compatible already (3.1)

• Some things don’t 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?


Solution(s)?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)


FinisFinis


A Simple RTML (3.1a) DocumentA Simple RTML (3.1a) Document<RTML

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns=http://www.rtml.org http://MONET.Uni-Goettingen.DE/RTML/RTML-3.1a.xsd"

version="3.1a" mode="request"uid="de.uni-goettingen.MONET://G2003-0001">

<History> <Entry timeStamp=“2003-05-19T11:43:54”> <Agent name=“Handy RTML Editor Version 1.0”/> <Description>Creation of document</Description> </Entry> </History> <Project> <Contact principleInvestigator=“true”> <Username>DE.Uni-Goettingen.MONET:fhessman</Username> <Name>Frederic V. Hessman</Name> <Communication> <Email>[email protected]</Email> </Communication> <Institution name=“Georg-August-Universitaet” type=”university”> <Communication> <AddressLine>Geismarlandstr. 11, 37083 Goettingen, Germany</AddressLine> <Fax>+49-551-39-5043</Fax> </Communication> </Institution> <TimeCharge units=“percent”>100</TimeCharge> </Contact> <Title>Dark Matter in Markarian 1234?</Title> <Abstract>By using deep images of....</Abstract> </Project>

Unique doc. I.D.

History mechanism

User info

Time-charge info

Project info

XML stuff


A Simple RTML 3.1a Document (cont.)A Simple RTML 3.1a Document (cont.)

... <Target name=“Markarian 1234”> <Classification>agn</Classification> <Coordinates> <RightAscension><Value units=“hours”>1.23456<</Value></RightAscension> <Declination> <Degrees>1</Degrees><Arcminutes>2</Arcminutes><Arcseconds>3</Arcseconds> </Declination> <Epoch>2002</Epoch> <Coordinates> </Target> <Camera> <FilterWheel> <Filter><Type>V</Type></Filter> </FilterWheel> </Camera> <Schedule> <DateTimeConstraint> <DateTimeStart> <Value>2003-05-31</Value><System>UT</System><Error>P1D</Error> </DateTimeStart> </DateTimeConstraint> <SeeingConstraint maximum-”1.5” units=“arcsecs”/> <Observation/> </Schedule></RTML>

Target info

Instrument info

Scheduling constraints

Triggered only if an <Observation> is in a

<Schedule>

RTML could fill the niche needed by VOEvent to describe astronomical information beyond STC’s 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


FinisFinis

http://HOU.lbl.gov/rtml

http://www.Astro.physik.Uni-Goettingen.DE/~hessman/RTML

Pennypacker et al., 2002, A&A 395, 727 (RTML 2.1)

http:/MONET.Uni-Goettingen.de/bin/twicki/RTML

Documents

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