TAP | Monday, May 25, 14.0015.30 | Théâtre |
---|---|---|
Speaker | Title | File |
KeithNoddle | Introduction | |
GerardLemson | The SimDB perspective on TAP and DAL in general | ppt |
Pierre Le Sidaner & Mathieu Hirtzig | Implementation of TAP in planetary data | |
DougTody | Cross matching and Data Discovery with TAP (also PQL update) | |
PatrickDowler | TAP V0.5 | |
KeithNoddle | Discussion of outstanding TAP issues | |
S*AP | Tuesday, May 26, 16.0017.30 | Amphithéâtre |
Speaker | Title | File |
JesusSalgado | Introduction, progress review and key issues | |
JesusSalgado | Simple Line Access Protocol (SLAP) 0.9 WD | |
FrancoisBonnarel | SIAv2 and Aladin/TOPCAT interaction | |
DougTody | SIAv2 interface and issues | |
DougTody | Generic dataset (GDS) developments | |
FrancoisBonnarel | GDS link with Observation |
MCT:
Priority in this first semester is to review status of recommendation level and working draft level documents of relevance for time domain, and decide on priorities based on current status of the field of time domain astrophysics. In particular, upcoming surveys (LSST, LIGO) and the increase number of transient alerts across wavelengths (including high energy transients, of relevance in multi-messenger science), as well as the emergence of spectral time-domain surveys, such SDSS-V, set the following priorities:
VOEvent 2.1 working draft: new version coordinated by DAL, but the TD IG should follow and read the draft to provide feedback. The current, stable version of VOEvent is at https://www.ivoa.net/documents/VOEvent/20110711/
Evaluate if new version of VOEvent requires updates to the VOEvent Transport Protocol => Protocol for publishing VOEvent => https://www.ivoa.net/documents/VOEventTransport/20170320/index.html
Pick up discussion on Time Series Cube Data Model (2019), to get status, establish if it leads to a recommendation, etc. Does the datacube only have a time dimension, or also a spectral dimension? Of relevance for upcoming spectral time domain surveys. We need to ensue that it also fits high energy data (i.e. event files) => https://www.ivoa.net/documents/Notes/CubeDM/20190318/index.html
Status of (S)TMOC => Space and Time coverage => Does this require updates? Is it currently being used? https://www.ivoa.net/documents/MOC/20220727/index.html
Cone search service that allows for time constraints
Other, dormant documents: VOEventRegExt => Extension of the VO registry to describe a service providing VOEvents (dormant still 2014 ); STC-S => Space Time coordinate linear definitions (dormant still 2013)
Priority in 2023B is to continue the discussions and review of the VOEvent standard, and align it with current practices for transient alert reporting, Expertise from ZTF, and broker alerts for Vera Rubin will be reviewed and hopefully incorporated into a new version of the standard.
VOEvent 2.1 working draft: new version coordinated by DAL, but the TD IG should follow and read the draft to provide feedback. The current, stable version of VOEvent is at https://www.ivoa.net/documents/VOEvent/20110711/
Pick up discussion on Time Series Cube Data Model (2019), to get status, establish if it leads to a recommendation, etc. Does the datacube only have a time dimension, or also a spectral dimension? Of relevance for upcoming spectral time domain surveys. We need to ensue that it also fits high energy data (i.e. event files) => https://www.ivoa.net/documents/Notes/CubeDM/20190318/index.html
Status of (S)TMOC => Space and Time coverage => Does this require updates? Is it currently being used? https://www.ivoa.net/documents/MOC/20220727/index.html
Cone search service that allows for time constraints
Other, dormant documents: <a href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/VOEventRegExt?topicparent=IVOA.2023ARoadmap;nowysiwyg=0" rel="nofollow" title="VOEventRegExt (this topic does not yet exist; you can create it)"> VOEventRegExt </a> => Extension of the VO registry to describe a service providing VOEvents (dormant still 2014 ); STC-S => Space Time coordinate linear definitions (dormant still 2013)
Registry Session: Tuesday May 21 2024 @ 16:00-17:30 (Session #7) Room C122 | |||
---|---|---|---|
Speaker | Title | Materials | Time |
Tess Jaffe | Brief Registry Orientation | ||
Pat Dowler | update on a re-usable OAI publishing registry | 10 + 5 | |
Gilles/Renaud | Update on linking capabilities with tablesets | Slides Minutes | 10 + 5 |
Markus+TJ | productTypeServed in VODataService | lecture notes | 10+5 |
TJ | Registry spring cleaning Following up on Markus' Confessions of a Registry Janitor, I propose a yearly spring cleaning effort. I'll describe what I have in mind and show however far I get by then. |
10 + 5 | |
Discussion |
TAP
1.2 - User managed persistent tables + Experiment with Open API spec (context: P3T)
DALI
Polygon definition clarification
PR-1.2 by Malta
ADQL
WD-2.2 by Malta (PEG grammar only)
SODA
return extended metadata
New transformation types
WD-1.1 by Malta
SIA
Issue errata for minor issues already noted in GitHub
SSA
Issue errata for minor issues already noted in GitHub
DAP (Data Access Protocol)
SIAP-2.0 into DAP
Gregory D.-F. become the 2nd Editor with Pat D.
Proceed with renaming, expansion of supported data product types
Miscellaneous changes
WD-1.0 by Malta
User Defined Functions catalogue
Ready to be endorsed
Conesearch
Modernize required UCDs (UCD 1.0-> UCD 1+)
RESPONSEFORMAT, MAXREC
Allow services to reject unknown parameters (work to be covered by P3T)
WD-1.1 by Malta (PR pending validators and implementations)
LineTAP
Work to continue
Status about client and server implementations
Raise PRec once implementations ready
ObjObsSAP
WD-1.0 by Malta
ADQL
2.3 - INTERVAL support, MOC support, Array support, string functions, OFFSET
View Eating for ADASS: Overview in a larger map |
-- Notable for quality or convenience -- Region containing multiple restaurants -- Conference hotels -- Conference Center |
git clone https://github.com/ivoa-std/ADQL.git
separator
rule is present, with the following definition:
<separator> ::= { <comment> | <space> | <newline> }...However this nonterminal token is only referenced in the rule for the
character_string_literal
, i.e.
<character_string_literal> ::= <quote> [ <character_representation>... ] <quote> [ { <separator>... <quote> [ <character_representation>... ] <quote> }... ]It is uncontroversial that the intent is to allow comments and white-space wherever SQL-92 allows them. The ADQL standard however says differently, and there should be a clarification. Between two alternatives, adding a clarifying subsection to the ADQL-2.0 standard or removing the
separator
.
1.1.4 Whitespace and Comments The rules on where whitespace is allowed and required are as in SQL92; essentially, any <token> may be followed by a <separator>.
unsigned_integer x
to be an optional argument (the seed) to the random mathematical function. This is not made explicit in the description in Table 1.
We suggest to amend the description changing the final "where x is a seed" into "where x is an optional seed" value.
ROUND optional places number
ADQL BNF grammar (pages 29-30 of ADQL-2.0) reports the signed_integer n
of ROUND(x, n) to be an optional argument. This signed integer number of places to round the value of x to is not made explicit to be optional in Table 1 description. Also, as per SQL standard, it should default to 0 when not explicitly present.
We suggest to amend the description of round(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".
TRUNCATE optional places number
ADQL BNF grammar (page 30 of ADQL-2.0) reports the signed_integer n
of TRUNCATE(x, n) to be an optional argument. This signed integer number of places to truncate the value of x to is not made explicit to be optional in Table 1 description. Also, as per SQL standard, it should default to 0 when not explicitly present.
We suggest to amend the description of truncate(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".
mod(x, y) Returns the remainder of y/x. rand(x) Returns a random value between 0.0 and 1.0, where x is a seed value. round(x, n) Rounds double value x to n number of decimal places, with the default being to round to the nearest integer. To round to the left of the decimal point, a negative number should be provided. truncate(x, n) Returns the result of truncating the argument x to n decimal places.to
mod(x, y) Returns the remainder of x/y. rand(x) Returns a random value between 0.0 and 1.0. The optional argument, originally intended to provide a random seed, has undefined semantics. Query writers are advised to use the form without the argument. round(x, n) Rounds double value x to n number of decimal places, with the default being to round to the nearest integer. To round to the left of the decimal point, a negative number should be provided. The integer n is optional and its value should default to 0. truncate(x, n) Returns the result of truncating the argument x to n decimal places. The integer n is optional and its value should default to 0.
POINT
, BOX
, CIRCLE
and POLYGON
functions. This alert has been raised while adapting the grammar of the functions above for an alternative function signature introduced in ADQL-2.1 (see the GitHub Issue #29). This argument represents the coordinate system of the geometry coordinates. The grammar of ADQL-2.0 admits any string expression ( <string_value_expression>
) here, which includes string concatenation, column references, User Defined Functions (UDFs), any other function returning a string, but also numerics. Considering that a coordinate system cannot be represented by a numeric expression, this case should have already been excluded. In particular, allowing a non-constant expression as coordinate system makes its interpretation very difficult by an ADQL-SQL translation engine (indeed, parsing and transform functions are required on the database side). Also, users have no explicit way to know what kind of coordinate transformation is applied.
This Erratum restricts the coordinate system argument of POINT
, BOX
, CIRCLE
and POLYGON
to a string literal ( <character_string_literal>
) to mitigate these problems.
<coord_sys> ::= <string_value_expression>into:
<coord_sys> ::= <character_string_literal>The description of the first argument of the functions is also changed for:
BOX
, section 2.4.3 (p.13),
CIRCLE
, section 2.4.5 (p.14),
POINT
, section 2.4.12 (p.18), and
POLYGON
, section 2.4.13 (p.18),
the coordinate system is a string value expression as defined in Section 2.4.1.into:
the coordinate system is a string literal as defined in Section 2.4.1.
=1
)
DISTANCE()
to other geometries (not only POINT()
)
INTERSECTION()
into:
<value_expression> ::= <numeric_value_expression> | <string_value_expression> | <geometry_value_expression>
<value_expression> ::= NULL | <numeric_value_expression> | <string_value_expression> | <geometry_value_expression>
ADQL also provides support for STC-S based geometric regions. While a fully normative definition of the argument of REGION has not been written, implementations are advised to follow Section~6 in TAP 1.0 \citep{2010ivoa.spec.0327D}.That's a lot more helpful than a reference to the WD that should have been pulled from the doc repo a long time ago. This will then also be consistent with what we write in 3.5.4 (where I'd not argue against dropping this discussion on p. 20 entriely).
Group | Yes | No | Abstain | Comments |
TCG | * | |||
Apps | * | |||
DAL | * | |||
DM | * | |||
GWS | * | |||
Registry | * | |||
Semantics | * | |||
DCP | * | |||
Edu | ||||
KDIG | * | |||
Ops | * | |||
Radio | ||||
SSIG | * | |||
Theory | ||||
TD | * | |||
<nop>StdProc |
This function computes the area, in square degrees, of the region given by the function's only argument.Prepend the 2nd paragraph with the line:
The argument can be represented with one of the region functions, BOX, CIRCLE, POLYGON, or REGION.
A box is a special case of Polygon, defined purely for convenience, and it corresponds in meaning to the STC-S "Box" subphrase [4].The second paragraph sufficiently describes the arguments.
This function computes the centroid of the region given by the function's only argument and returns a POINT (See 2.4.11).Prepend the 2nd paragraph with the line:
The argument can be represented with one of the region functions, BOX, CIRCLE, POLYGON, or REGION.
This function expresses a circular region on the sky (a cone in space) and corresponds in meaning to the "Circle" STC-S subphrase [4].The rest of paragraph sufficiently describes the arguments.
The first argument is a point or region value representing the contained geometry, and the second argument is a region value representing the containing region. The function returns 1 (meaning true) if the contained geometry is entirely within the boundary of the containing region and 0 (meaning false) otherwise. When the first argument is a point, it is considered inside the containing region if it lies on the containing region's border.Using the following text, move the contents of the last paragraph to a new paragraph after the first one:
Either argument can be given by the appropriate functions (the region functions--BOX, CIRCLE, POLYGON, or REGION--for the second argument, and the region functions or POINT for the first argument) or by a single column name or alias. When a column name or alias is provided, the value in the column or alias must be interpreted the appropriate value type. Since the two argument geometries may be expressed in different coordinate systems, the function is responsible for converting one (or both). If either argument cannot be converted to the proper geometry in a usable coordinate system, the function should throw an error message (as defined by the service making use of ADQL).Drop the last paragraph.
This function returns the first coordinate value, in degrees, of a position given by the first argument. The argument may be given using the POINT function (See 2.4.12) or a column reference.
This function returns the second coordinate value, in degrees, of a position given by the first argument. The argument may be given using the POINT function (See 2.4.12) or a column reference.
This function returns the coordinate system string value from *the geometry given by the first argument. The argument value may be given as a geometry data type function (POINT, BOX, CIRCLE, POLYGON, or REGION) or as a column reference that can be interpreted as a geometry.
This function corresponds in meaning to the "Polygon" STC-S sub-phrase [4].The explanation of the arguments is sufficient.
This document provides the general semantics for the language elements; where these semantics are ambiguous, the specification of the service or application using ADQL should clarify how the elements should be applied.
The query should be interpreted much like an SQL92 query: where ADQL and SQL92 keywords are identical, the ADQL keywords and their operands should be interpreted in the same way as defined in SQL92.
<languageFeatures type="ivo://org.gavo.dc/std/exts#extra-adql-keywords"> <feature> <form>VECTORMATH</form> <description>You can compute with vectors here. See https://wiki.ivoa.net/twiki/bin/view/IVOA/ADQLVectorMath for an overview of the functions and operators available. </description> </feature> </languageFeatures>
[element-index]
, where element-index is an integer-valued expression. In keeping with common SQL practices (and regrettably working against most programming languages), indexes in ADQL are 1-based (rather than 0-based). That is, the first element of an array with N elements has the index 1 and the last element has the index N.
Again in keeping with common SQL practices, accessing elements outside of that range gives NULL.
It is also possible to access to multiple elements of a vector (as a sub-array). To access, write [lower-bound:upper-bound], where lower and upper bounds are integer-valued expressions and are both included. Lower-bound must be equal or greater to 1 due to indexes in ADQL are 1-based and if upper-bound is greater to the lenght of the array not error is going to be returned.
Select centroid(mytable.centre) from mytable
SELECT
list: The service is free to return a standard String serialization of the geometry.
where CIRCLE('ICRS', 123, 45,12) contains Point('ICRS', mytable.ra, mytable.dec)
(b1) where CONTAINS(Point('ICRS',mytable.ra, mytable.dec), CIRCLE('ICRS', 123, 45,12)) = 1
(b2)where CIRCLE('ICRS', 123, 45,12) contains mytable.coo
where CONTAINS(mytable.coo, CIRCLE('ICRS', 123, 45,12)) = 1
rand(x)
function? I guess x
is the seed - is it an integer or a float? It looks like you need a seed every time you invoke it, but that wouldn't be very convenient.round(x,n)
("Round to nearest integer") function has two arguments?LONGITUDE
and LATITUDE
AREA
LONGITUDE
and LATITUDE
functions are meant to extract the first and second coordinate from an attribute of POINT
type. No coordinate transformation is supposed to take place.
<string_value_expression>
. Are coordinate system specifications intended to be lifted from STC (or elsewhere) or is it intended that the implementation may define any values it likes for known coordinate systems? In practice - if only for testing purposes - it is often convenient to use "the default coordinate system", i.e. whatever is in use in the database; is there some way this can be selected?POINT
will be added.
yyyy[-mm[-dd[Thh[:mm[:ss[.s...]]]]]]
:
I would like to see a more restricted, unambiguous, and implementable definition than what we have here if it is to go forward as a REC.I believe that this can be easily rectified with the following:
When a geometry data type within the context of the WHERE clause, the given coordinate system may not match the system in use by the underlying database that the query is applied to. In this case, it is expected that the service or application will perform the necessary coordinate conversions to evaluate the constraints. If this conversion is not possible, then an appropriate error should be thrown as defined by the service or applicaiton using ADQL.VOQL Chair Answer * TOP falls under the category of ADQL Reserved Words, as it was understood as an extension to the SQL92 reserved keywords. First attempts on TAP to sketch query ranking functionalities for large datasets showed the need to provide such features in the language rather than in the service by combining the use of ORDER_BY and TOP. At that time, no problem was found to include TOP despite the fact that it can be named and implemented in different ways in different database systems. That is why it is defined as an ADQL extension and not and SQL reserved word. The first time TOP appears is in the April 2007 version. Later, in Beijing (May 2007), some people expressed concerns that TOP might have different implementations in different DB systems, but there was no final requirement from any party to remove it. Nor was there such a requirement within any of the members of the VOQL-TEG. In case the TOP would create troubles when implementing services making use of ADQL language, it could be deprecated in next ADQL version. For the time being, it would give a good functionality for eventual TAP-like services, and therefore it should stay in. * I am not sure I understand the part on implementations. The BNF parser is a full system very kindly developed by Jeff Lusted (Astrogrid) and which source code, packaging information, documentation, etc. is fully available at the pages given in the referred URL (you only have to click on the corresponding menu at the left to navigate through the source code, etc.). As an example, please find attached this URL where part of the java code can be seen: http://www.astrogrid.org/viewcvs/astrogrid/adql2/ The language is defined via a BNF (as was agreed several times in the past). The above implementation is a full implementation of the parser. Actually, I believe this is one of the most thorough implementation there has ever been of an IVOA proposed standard. The fact that Protocols (and Services making use of them) will make use of the ADQL within their future implementations shall not be confused with an implementation of the BNF of the language itself, which -as said above- is attained by the referenced parser. * A language should not give instructions for services to do any type of transformation. It is up to the service to understand that if coordinates are given to it in equatorial RA,DEC and the service only has galactic L,B then either an error shall be returned or the calculation done silently. * In response to: [...] blanket statement near the beginning indicating that where a term in ADQL is identical to that in SQL92, the semantics of that term (and its arguments) are the same as in SQL92[...] I believe the document clearly states what is SQL92 standard and what is ADQL specific. * In response to: [...]you mention that the region functions are based on STC; I recommend that an explicit statement indicating that the arguments are identical in type and meaning as the arguments defined for STC/s.[...] read points 2.4.1 and 2.4.14 of the document (see excerpt here) [...]A special attention has to be paid to the REGION function. As can be seen more in detail in Section 2.4.14, this construct is a general purpose function and it takes a string value expression as argument. The format of the string is to be specified by a service that accepts ADQL by referring to a standard format. Currently STC/s (See [3] and [4]) is the only standardized string representation a service can declare.[...] (end VOQL Chair Answer) RayPlante replies:
width: 99%
for full window width (default), width: auto
to disable. access_format
in the draft refers to MIME types, but no real mime types are provided. Real MIME types for FITS files are application/fits
for non-imaging, or multi-extension FITS files, and image/fits
for FITS files which can be directly interpreted as images. Following IETF RFC4047, image/fits
can be generalized for data cubes, as long as the corresponding WCS information is present, and software such as fv can interpret it as a 3D data cube. Even if all of the enumerated values shown in 4.7 and B5.2 (which by the way, are the same) were valid as MIME types, there would be a need to register all of those MIME types, and I think we are served with both image/fits
and application/fits
.
So, for the whole access_format
section, I would use an approach similar to UCD specialization, where we have a vocabulary composed of data formats, dimensionality, and compression.
fits
, class
, ms
, aedm
(corresponding to FITS, CLASS, Measurement Set, and ALMA Export Data Model).
z
, gz
, zip
, none
, embedded
(meaning tile compression in FITS, for instance)
image
, datacube
(regular mesh data cube from radio interferometry, or regridded radio OTF, for instance), spatial.spectral
(irregular spatial mesh, with possibly irregular spectral binning, such as those from non-regridded radio OTF, IFU, or MOS instruments).
Set VARIABLE = value
bullet, (3) do a "raw edit" of your user profile page, (4) add the bullet to the bullet list above, and (5) customize the value as needed. Make sure the settings render as real bullets (in "raw edit", a bullet requires 3 or 6 spaces before the asterisk).
Set VARIABLE = value
bullet, (3) do a "raw edit" of your user profile page, (4) add the bullet to the bullet list above, and (5) customize the value as needed. Make sure the settings render as real bullets (in "raw edit", a bullet requires 3 or 6 spaces before the asterisk).
wfau
, to prefix their user defined function names:
wfau_align() wfau_convert()and the German Astrophysical Virtual Observatory (GAVO) adopt a similar naming convention:
gavo_align() gavo_convert()this would help to avoid confusion when users encounter functions with similar names on different TAP services:
wfau_align() gavo_align() wfau_convert() gavo_convert()Note that the prefix indicates the origin of the function implementation, not the identity of the TAP service providing the function. If another TAP service provides a function with exactly the same behaviour as one of the WFAU functions, the function name should use the
wfau
prefix to indicate this.
wfau_align()By ensuring that different implementations use different names, this scheme avoids potential conflicts when a user takes a query written for one TAP service and sends it to another TAP service. With the name prefixes, the second TAP service will reject the query if it does not provide exactly the same function as the first. Without this fail fast approach, the second query may run without raising any errors or warnings, but due to differences in the algorithm used, the second query may produce subtly different results which could go undetected. On the other hand, if the second TAP service does implement the same function, with exactly the same behaviour, then selecting this function using the name prefix gives the user a level of confidence that a query would produce equivalent results when run on different TAP services.
ivo
prefix is reserved for defining functions that are specified in IVOA recommendations or endorsed notes.
If one of the GAVO functions is adopted as part of an IVOA standard, then we could use the ivo
prefix to indicate that it is an IVOA standard function.
ivo_align()For backwards compatibility, a TAP services could provide the same function using different names:
gavo_align() -- original GAVO version ivo_align() -- IVOA standard versionThe same TAP service could also provide the WFAU implementation of the same function:
gavo_align() -- original GAVO version wfau_align() -- alternative WFAU version ivo_align() -- IVOA standard versionIt is the responsibility of the IVOA working groups to ensure that the total set of
ivo
endorsed functions remains sensible.
In order to be accepted as an ivo
function, a function MUST be defined in a format suitable for TAPRegExt and ideally have reference implementations for one or more of the major RDMS platforms.
Note that in general a TAP service is not required to implement these functions. However, if they do implement functions with these names, then their implementation MUST be consistent with the behaviour defined in the specification.
An example for a Recommendation that defines ivo
functions is RegTAP, which defines the following functions:
ivo_nocasematch
case insensitive match.
ivo_hasword
word based search.
ivo_hashlist_has
hash '#' delimited word search.
ivo_string_agg
delimited string aggregate function.
prefix | name | link |
---|---|---|
ivo | IVOA standard functions | http://ivoa.net/ |
wfau | Wide Field Astronomy Unit, Institute for Astronomy, University of Edinburgh | http://www.roe.ac.uk/ifa/wfau/ |
gavo | German Astrophysical Virtual Observatory | http://www.g-vo.org/pmwiki/ |
mast | Mikulski Archive for Space Telescopes | http://archive.stsci.edu/ |
eso | European Southern Observatory | http://archive.eso.org/ |
cefca | Centro de Estudios de Física del Cosmos de Aragón (CEFCA) | https://archive.cefca.es/ |
Set VARIABLE = value
bullet, (3) do a "raw edit" of your user profile page, (4) add the bullet to the bullet list above, and (5) customize the value as needed. Make sure the settings render as real bullets (in "raw edit", a bullet requires 3 or 6 spaces before the asterisk).
Name | Arrival (airport, date, time, flight number) | |
---|---|---|
Norman Gray | norman@astro.gla.ac.uk | BWI, 25 Oct 14:10, C2355 |
Ivan Zolotukhin | iz_at_sai.msu.ru | JFK, 25 Oct 14:30, DL 31 -- see note |
Mireille Louys | louys@astro.u-strasbg.fr | IAD, 25 Oct, 15:40, KLM 0651 |
Sebastien Derriere | derriere@astro.u-strasbg.fr | IAD, 25 Oct, 15:40, KLM 0651 |
Thomas Boch | boch@newb6.u-strasbg.fr | IAD, 25 Oct, 15:40, KLM 0651 |
Andrea Preite-Martinez | andrea.preitemartinez@iasf-roma.inaf.it | IAD, 25 Oct, 15:40, KLM 0651 |
Hervé Wozniak | herve.wozniak@obs.univ-lyon1.fr | BWI, 25 Oct 16:20 BA 0229 |
Alasdair Allan | AlasdairAllan <aa@astro.ex.ac.uk> | BWI, 25 Oct 18:37, AC 7934 |
RickWagner | rick@ucsd.edu | BWI, 26 Oct, 10:32, DL 982 |
Andy Lawrence | al@roe.ac.uk | BWI, 26 Oct, 10:51am, UA1226 from ORD |
Vivekananda Moosani | vivekananda_moosani@persistent.co.in | BWI, 26 Oct, 14:00, DL 8939 |
Petr Skoda | skoda@sunstel.asu.cas.cz | BWI, 26 Oct, 17:20, BA229 |
Fabien Chereau | fchereau@eso.org | BWI, 26 Oct, 17:54, DL 734 |
Arnold Rots | arots@head.cfa.harvard.edu | BWI, 26 Oct, 18:49, DL6931 from BOS |
Sherry Winkelman | wink@head.cfa.harvard.edu | BWI, 26 Oct, 18:49, DL6931 from BOS |
Matthew Graham | mjg@caltech.edu | BWI, 26 Oct, 18:59, UA0306 from LAX |
Igor Chilingarian | Igor.Chilingarian_at_obspm.fr | BWI, 26 Oct, 23:03, CO 426 -- see below |
Set VARIABLE = value
bullet, (3) do a "raw edit" of your user profile page, (4) add the bullet to the bullet list above, and (5) customize the value as needed. Make sure the settings render as real bullets (in "raw edit", a bullet requires 3 or 6 spaces before the asterisk).
width: 99%
for full window width (default), width: auto
to disable. width: 99%
for full window width (default), width: auto
to disable. width: 99%
for full window width (default), width: auto
to disable.
|