Notes from the HTN Workshop Meeting, July 2005
From TelescopeNets
The meeting was held in the Southgate Hotel (http://www.southgate-hotel.co.uk/) between the 18th and 21st July 2005, hosted by the eSTAR Project and the University of Exeter (http://www.ex.ac.uk/).
| Table of contents |
ACKNOWLEDGEMENT
If you use data from a telescope on the network then you MUST acknowledge that telescope in any published papers if REQUIRED by the telescope (see their website).
MESSAGE DIALOGUE
All messages WILL have a globally unique & permanent ID, and the reply will use the same one.
Is this a telescope -> (OPTIONAL) <- Yes, No, (DB maybe) What kind -> (OPTIONAL) <- Information Can you do X? -> (OPTIONAL) <- Yes, No, How well Will you do X? -> <- Yes, No <- Data return (or status report)
IN DETAIL
Is this a telescope (register) [OPTIONAL]
Don't care whether people have a hub or a flat/peer-to-peer architecture underneath the top level so long as they present a top level interface that is "standards compliant". Advertise this interface via a number of distributed registers.
This is an example of a register file,
ip.twiddle.edu:7070 soap urn:/node_agent handle_rtml
sftp.thingy.edu:2222 sftp /pub/incoming
www.monet.edu:80 http /handlertml.cgi POST
ip.monet.edu:7000 soap urn:/node_agent handle_rtml
ip.raptor.lanl.gov:4001 tcp
each protocol "soap", "sftp", etc has a unique mapping to a protocol description which is available on the HTN website. A protocol must be approved by the HTN group to be placed onto the list.
All communication is via an HTN standards compliant RTML document, including phase 0 (request for phase 0 is a simple RTML document).
This "file" is served via HTTP, in initial distribution of the software, and from the HTN website. There is also a list of registers in the register file, e.g.
ip.twiddle.edu:7070 soap urn:/node_agent handle_rtml sftp.thingy.edu:2222 sftp /pub/incoming www.monet.edu:80 http /handlertml.cgi POST ip.monet.edu:7000 soap urn:/node_agent handle_rtml ip.raptor.lanl.gov:4001 tcp www.htn.org register http://www.telescope-networks.org/register.html
What kind (phase 0) [OPTIONAL]
Return a complete list of RTML tags that the "telescope" understands along with a list of RTML tags that are REQUIRED by an observation request as well as other descriptive stuff in RTML (machine readable). Must also include the TYPES of document the telescope supports (e.g. abort?). Should advertise whether the telescope is TAG controlled.
Answer to the question "Can you do an observation every night for the next six months"? This is NOT a scoring, this is a phase zero question.
Can you do X? [OPTIONAL] (is it possible for you to do X?)
We send an RTML document to the "telescope". Return an RTML document with tagged scoring block (below).
Can change things in the returned document within limits, e.g. Change camera from "generic" to "UFTI", may want to send generic back (if that's what you can score).
May tweak RTML to reflect exactly what the observatory is offering. Return exactly what you have scored. The returned RTML must be compatible with the original request.
If there is insufficient information available to answer the scoring request a 'reject' message will be sent rather than a scoring reply.
The scoring reply MAY include a "cost" quantity, which may also have "units". The scoring reply MAY include an estimated duration of the observation.
Will you do X? (observation request)
We may skip directly to this stage!
We send an RTML document to the "telescope". If the telescope demands a "cost", there is a magic value which means "any cost", if there is no cost included (and this is mandated by the telescope) this means the request will be rejected.
If a telescope is outside the "cost system", and a "cost" tag isn't mandated by the telescope, it's all totally optional.
If a "cost" has been returned in the score reply, a cost should be included in the observation request. If the cost in the obs request is out of line with the current cost of the observation, a 'reject' should be sent.
We receive a reply (which is an RTML document, either 'confirm' or 'reject'). Reject messages MAY have information telling you why it's being rejected.
If you require a fail message if the data has not been taken, you MUST include an expiry time (ExpiryTime is an attribute of the RTML tag, not the TimeConstraint).
If an observation request is made in reply to a scoring request post-expiry of the offer, a 'reject' message will be sent. The user can of course re-score.
If "costs" are being returned, an updated "cost" will be returned with the RTML 'confirm' message.
Abort (request to abort)
Once an observation request is submitted and confirmed it can be aborted by an 'abort' message to the "telescope" with the same unique ID. The response is an 'ack' message, or a 'reject'.
Data Return
Optional 'update' message whenever the "telescope" feels like it has something to say. Range of update messages: data taken, start of obs, informational, etc. MAY have optional data products.
Mandatory 'complete' OR 'incomplete' OR 'fail' message.
- complete - we have taken all your data (MAY contain data products)
- incomplete - we have taken SOME data (MAY contain data products) (e.g. if an expiry time passes and some data taken, get incomplete message)
- fail - we have NOT taken data OR the data we have taken is totally useless (probably) (MAY contain data products) (e.g if an expiry time has been specified, and it passes and no acceptable data has been taken, you get a fail)
Things that can be included,
- data products (which are optional)
- links to data products (optional)
- tabular results (if included) MUST be in VOTable format
SCORING
Answer to the "Give me a measurement of probability of doing my observing request between now and 10 hours from now at 1 hourly intervals"
The interval is specified by user (where time now and 10 hours are time stamps), e.g.
time diff cumulative now undef 0.0 1hr 0.3 0.3 2hr 0 0.3 3hr 0.9 0.9 4hr 0 0.9 5hr 0 0.9 6hr 1.0 1.0 7hr undef 1.0 8hr undef 1.0 9hr undef 1.0 10hr 0.3 1.0
Can change the sample interval (or 2 hourly, or 3 hourly)
Answer to the question "Give me a measurement of probability of doing my observation in the next 10 hours"
time diff cumulative now 0 0 10hr 1.0 1.0
Answer to the question "Give me 30 observations spread over the next 2 hours"
time diff cumulative now 0 0 2hr 0.7 0.7
ALWAYS return the CONSERVATIVE ESTIMATE of the cumulative probability distribution. MAY ALSO return the differential probability distribution (desired).
Can return 'undef' if we don't know, or 'oor' (out of range) for beyond the range of scheduler, e.g. semester boundary, beyond accuracy of the scheduler.
As long as a telescope can satisfy the minimum requirement set by the user, then the telescope would return some non-zero probability. We don't care about a telescope exceeding the minimum requirement.
If you cannot match the constraints of the RTML rquirements, then you must return a score of 0.
AUTHENTICATION & AUTHORISATION
Telescopes need to map requests to a project which has time on that telescope.
You may send all local project IDs (which may be relevant) you have for a specific observing programme in the RTML when you send a scoring/observing request (or the correct one only). Authentication depends on transport mechanism, and must be defined in the transport standards document for each protocol.
There is no such thing as an HTN global project ID... project IDs must be unique, these are in the RTML as multiple <Project> tags.
e.g.
<Project telescope="jach.ukirt">
U/05A/42
</Project>
If a user happens to have more than one project on a telescope and sends all (or some) of those project IDs, the telescope will be able to choose which project scoring will be returned for.