اشترك بالحزمة الذهبية واحصل على وصول غير محدود شمرا أكاديميا
تسجيل مستخدم جديدIVOA Recommendation: VOEvent Transport Protocol Version 2.0
49
0
0.0
(
0
)
اسأل ChatGPT حول البحث
ﻻ يوجد ملخص باللغة العربية
The IVOA VOEvent Recommendation defines a means of describing transient celestial events but, purposely, remains silent on the topic of how those descriptions should be transmitted. This document formalizes a TCP-based protocol for VOEvent transportation that has been in use by members of the VOEvent community for several years and discusses the topology of the event distribution network. It is intended to act as a reference for the production of compliant protocol implementations.
قيم البحث
اقرأ أيضاً
VOEvent defines the content and meaning of a standard information packet for representing, transmitting, publishing and archiving information about a transient celestial event, with the implication that timely follow-up is of interest. The objective
is to motivate the observation of targets-of-opportunity, to drive robotic telescopes, to trigger archive searches, and to alert the community. VOEvent is focused on the reporting of photon events, but events mediated by disparate phenomena such as neutrinos, gravitational waves, and solar or atmospheric particle bursts may also be reported. Structured data is used, rather than natural language, so that automated systems can effectively interpret VOEvent packets. Each packet may contain zero or more of the who, what, where, when & how of a detected event, but in addition, may contain a hypothesis (a why) regarding the nature of the underlying physical cause of the event. Citations to previous VOEvents may be used to place each event in its correct context. Proper curation is encouraged throughout each events life cycle from discovery through successive follow-ups. VOEvent packets gain persistent identifiers and are typically stored in databases reached via registries. VOEvent packets may therefore reference other packets in various ways. Packets are encouraged to be small and to be processed quickly. This standard does not define a transport layer or the design of clients, repositories, publishers or brokers; it does not cover policy issues such as who can publish, who can build a registry of events, who can subscribe to a particular registry, nor the intellectual property issues.
The Simple Spectral Access (SSA) Protocol (SSAP) defines a uniform interface to remotely discover and access one dimensional spectra. SSA is a member of an integrated family of data access interfaces altogether comprising the Data Access Layer (DAL)
of the IVOA. SSA is based on a more general data model capable of describing most tabular spectrophotometric data, including time series and spectral energy distributions (SEDs) as well as 1-D spectra; however the scope of the SSA interface as specified in this document is limited to simple 1-D spectra, including simple aggregations of 1-D spectra. The form of the SSA interface is simple: clients first query the global resource registry to find services of interest and then issue a data discovery query to selected services to determine what relevant data is available from each service; the candidate datasets available are described uniformly in a VOTable format document which is returned in response to the query. Finally, the client may retrieve selected datasets for analysis. Spectrum datasets returned by an SSA spectrum service may be either precomputed, archival datasets, or they may be virtual data which is computed on the fly to respond to a client request. Spectrum datasets may conform to a standard data model defined by SSA, or may be native spectra with custom project-defined content. Spectra may be returned in any of a number of standard data formats. Spectral data is generally stored externally to the VO in a format specific to each spectral data collection; currently there is no standard way to represent astronomical spectra, and virtually every project does it differently. Hence spectra may be actively mediated to the standard SSA-defined data model at access time by the service, so that client analysis programs do not have to be familiar with the idiosyncratic details of each data collection to be accessed.
The Simple Line Access Protocol (SLAP) is an IVOA Data Access protocol which defines a protocol for retrieving spectral lines coming from various Spectral Line Data Collections through a uniform interface within the VO framework. These lines can be e
ither observed or theoretical and will be typically used to identify emission or absorption features in astronomical spectra. It makes use of the Simple Spectral Line Data Model (SSLDM [1]) to characterize spectral lines through the use of uTypes [14]. Physical quantities of units are described by using the standard Units DM [15]. SLAP services can be registered in an IVOA Registry of Resources using the VOResource [12] Extension standard, having a unique ResourceIdentifier [13] in the Registry. The SLAP interface is meant to be reasonably simple to implement by service providers. A basic query will be done in a wavelength range for the different services. The service returns a list of spectral lines formatted as a VOTable. Thus, an implementation of the service may support additional search parameters (some which may be custom to that particular service) to more finely control the selection of spectral lines. The specification also describes how the search on extra parameters has to be done, making use of the support provided by the Simple Spectral Line Data Model (SSLDM [1])
SAMP is a messaging protocol that enables astronomy software tools to interoperate and communicate. IVOA members have recognised that building a monolithic tool that attempts to fulfil all the requirements of all users is impractical, and it is a b
etter use of our limited resources to enable individual tools to work together better. One element of this is defining common file formats for the exchange of data between different applications. Another important component is a messaging system that enables the applications to share data and take advantage of each others functionality. SAMP builds on the success of a prior messaging protocol, PLASTIC, which has been in use since 2006 in over a dozen astronomy applications and has proven popular with users and developers. It is also intended to form a framework for more general messaging requirements.
Approved client-server authentication mechanisms are described for the IVOA single-sign-on profile: No Authentication; HTTP Basic Authentication; TLS with passwords; TLS with client certificates; Cookies; Open Authentication; Security Assertion Marku
p Language; OpenID. Normative rules are given for the implementation of these mechanisms, mainly by reference to pre-existing standards. The Authorization mechanisms are out of the scope of this document.
سجل دخول لتتمكن من نشر تعليقات
التعليقات
جاري جلب التعليقات
سجل دخول لتتمكن من متابعة معايير البحث التي قمت باختيارها
