ViewVC logotype

Contents of /trunk/projects/utypes/current-usage/utypes-usage.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 2189 - (show annotations)
Fri May 10 13:14:03 2013 UTC (8 years, 5 months ago) by volute@g-vo.org
File MIME type: text/html
File size: 53933 byte(s)
current-usage: Layout and markup fixes for app.

1 <?xml version="1.0" encoding="UTF-8"?><!-- this source is meant to be processed with Paul Harrison's
2 ivoadoc toolkit, see somewhere at http://code.google.com/p/volute/ -->
3 <html xmlns="http://www.w3.org/1999/xhtml">
4 <head xmlns:h="http://www.w3.org/1999/xhtml" xmlns:xs="http://www.w3.org/2001/XMLSchema" profile="http://www.w3.org/1999/xhtml/vocab">
5 <title>Utypes Usage Note</title>
6 <meta http-equiv="content-type" content="text/html; charset=utf-8"/>
8 <link rel="stylesheet" type="text/css" href="http://www.ivoa.net/misc/ivoa_a.css"/>
9 <link rel="stylesheet" type="text/css" href="http://www.ivoa.net/misc/ivoa_wd.css"/>
10 <link rel="stylesheet" type="text/css" href="./ivoadoc/XMLPrint.css"/>
11 <link rel="stylesheet" type="text/css" href="./ivoadoc/ivoa-extras.css"/>
13 <style type="text/css" xml:space="preserve">
15 code {
16 font-weight: bold;
17 font-family: monospace
18 }
20 div.admonition {
21 margin-left: 3em;
22 background: #DDBBBB;
23 padding-top: 0.5ex;
24 padding-bottom: 0.5ex;
25 padding-left: 0.5em;
26 padding-right: 0.5em;
27 border: 1px solid #EE9999;
28 }
30 div.admonition:before {
31 content: 'Note';
32 font-weight: bold;
33 }
35 body {
36 counter-reset: section;
37 counter-reset: toc_section;
38 }
40 .figurecaption {
41 margin-bottom: 4ex;
42 }
44 .figure img {
45 position: relative;
46 width: 100%;
47 }
49 p.caption {
50 font-style: italic;
51 }
53 .redax {
54 background-color: #FFFF90;
55 font-style: italic;
56 }
58 </style></head><body><div class="head">
59 <div id="titlehead" style="position:relative;height:170px;width: 500px">
60 <div id="logo" style="position:absolute;width:300px;height:169px;left: 10px;top: 0px;">
61 <img src="http://www.ivoa.net/pub/images/IVOA_wb_300.jpg" alt="IVOA logo"/>
62 </div>
63 <div id="logo-title" style="position:absolute;width:200px;height:115px;left: 300px;top: 5px;">
64 <p>
65 <b>
66 <i>
67 <span style="font-size: 14pt; color: #005A9C;"> I</span>
68 </i>
69 </b>
70 <i>
71 <span style="font-size: 14pt; color: #005A9C;">nternational</span>
72 </i>
73 </p>
74 <p>
75 <b>
76 <i>
77 <span style="font-size: 14pt; color: #005A9C;padding-left:30px">V</span>
78 </i>
79 </b>
80 <i>
81 <span style="font-size: 14pt; color: #005A9C;">irtual</span>
82 </i>
83 </p>
84 <p>
85 <b>
86 <i>
87 <span style="font-size: 14pt; color: #005A9C;padding-left:30px">O</span>
88 </i>
89 </b>
90 <i>
91 <span style="font-size: 14pt; color: #005A9C;">bservatory</span>
92 </i>
93 </p>
94 <p>
95 <b>
96 <i>
97 <span style="font-size: 14pt; color: #005A9C;">A</span>
98 </i>
99 </b>
100 <i>
101 <span style="font-size: 14pt; color: #005A9C;">lliance</span>
102 </i>
103 </p>
104 </div>
105 </div>
107 <h1>Utypes: current usages and practices in the IVOA<br clear="none"/>
108 Version <span class="docversion"/></h1>
109 <h2 class="subtitle">Filled in automatically</h2>
111 <dl><dt>Working Groups:</dt><dd>
112 <a
113 href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/TCG"
114 shape="rect">Utypes tiger team</a></dd>
115 <dt>This version:</dt>
116 <dd><a href="" class="currentlink">filled in automatically</a></dd>
117 <dt><b>Latest version:</b></dt>
118 <dd><a href="http://www.ivoa.net/Documents/UTypesUsage/" shape="rect">http://www.ivoa.net/Documents/UTypesUsage/</a></dd>
119 <dt>Previous versions:</dt>
120 <dd>-</dd>
121 <dt>Authors:</dt><dd>
122 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/MarkusDemleitner" shape="rect">Markus Demleitner</a><br clear="none"/>
123 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/PatrickDowler" shape="rect">Patrick Dowler</a><br clear="none"/>
124 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/PierreFernique" shape="rect">Pierre Fernique</a><br clear="none"/>
125 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/MatthewGraham" shape="rect">Matthew Graham</a><br clear="none"/>
126 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/OmarLaurino" shape="rect">Omar Laurino</a><br clear="none"/>
127 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/GerardLemson" shape="rect">Gerard Lemson</a><br clear="none"/>
128 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/MireilleLouys" shape="rect">Mireille Louys</a><br clear="none"/>
129 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/JesusSalgado" shape="rect">Jesus Salgado</a><br clear="none"/>
130 </dd>
131 <dt>Editors:</dt><dd>
132 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/MatthewGraham" shape="rect">Matthew Graham</a><br clear="none"/>
133 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/MarkusDemleitner" shape="rect">Markus Demleitner</a><br clear="none"/>
134 </dd></dl>
135 <hr/>
137 <h2>Abstract</h2>
139 <p>The notion of utypes was introduced in the Virtual Observatory with
140 the VOTable 1.1 standard in 2004. Since then, various practices and
141 customs evolved regarding how utypes were actually used, interpreted,
142 and assigned. This document attempts to summarize and assess these
143 usages in the context of the Utypes Tiger Team. Its goal is to help the
144 wider VO community better evaluate the merits and understand the impact
145 of measures proposed by the Tiger Team.
146 </p>
148 <h2>Status of this Document</h2>
150 <p id="statusdecl"></p>
152 <p><em>A list of</em> <span style="background: transparent">
153 <a href="http://www.ivoa.net/Documents/" shape="rect"><i>current IVOA
154 Recommendations and other technical documents</i></a></span><em> can be
155 found at http://www.ivoa.net/Documents/.</em></p>
157 <h2 class="prologue-heading-western">Acknowledgments</h2>
159 <p>The editors gratefully acknowledge input from the various working groups,
160 in particular the authors and maintainers of the applications discussed
161 in section <span class="xref">apps</span>.</p>
164 <h2>Contents</h2>
165 <?toc?>
167 </div><!-- class="head" -->
169 <div class="body">
171 <div class="section"><h2><a id="introduction" shape="rect"/><span class="secnum">1. </span>Introduction</h2>
173 <p>Utypes are a core part of the IVOA Architecture (see Fig. 1);
174 however, they currently lack a formal definition within the IVOA
175 (see <a href="#ref_UTypes" shape="rect">[UTYPES]</a> for the current state).
176 In spite of this, they are employed in a number of situations. The most
177 general usage is as an identifier for a concept defined within an
178 IVOA data model, i.e., a label carrying no more than nominative
179 semantics. A more specific usage is as a pointer (parseable
180 identifier) to a data model concept, semantically equivalent to a
181 URI or XPath in XML. There are also related practices about reuse,
182 inheritance, extensibility, etc.</p>
184 <div class="figure">
185 <img src="UTypes-arch.png" alt="Utypes within the VO architecture" width="95%" align="center"/>
186 <p class="figurecaption"><strong>Figure 1:</strong> IVOA Architecture diagram with utypes and
187 the related standards marked up.</p>
188 </div> <!-- figure -->
190 <p>The growing availability and usage of data models within the IVOA
191 &#8212; e.g., <a href="#ref_ObsCore" shape="rect">[ObsCore]</a>, <a
192 href="#ref_SpecDM" shape="rect">[SpecDM]</a>, <a href="#ref_STC"
193 shape="rect">[STC]</a> &#8212; and, by extension, Utypes means that a
194 consistent (and formal) definition is required for interoperability
195 as well as implementation reusability.
196 A survey of current usages and practices is useful input to the
197 definition process, both to understand what is required and what works
198 and does not. It is also a reference that allows one to assess the impact
199 of proposed solutions on current practices.
200 This document aims to provide such a summary. </p>
202 <p>We note that the May 2012 IVOA Working Draft on utypes <a href="#ref_UTypes" shape="rect">[UTYPES]</a>
203 presents an approach to defining utypes within a broader context of
204 standardizing data model definition and serialization. Utypes are
205 defined as data model labels that point to their associated data model
206 element &#8212; they are a string representation of the logical path through
207 the classes and attributes in a UML representation of a data model
208 from the main data model element to a particular part of the data
209 model. A generating syntax is proposed based on this premise and the
210 resulting usage patterns for utypes in data model (de-)serialization
211 described. This is, however, work in progress and does not necessarily
212 reflect the existing community of practice which this document seeks
213 to capture.</p>
215 </div> <!-- section introduction -->
217 <div class="section"><h2><a id="currentusages" shape="rect"/><span
218 class="secnum">2. </span>Current usages</h2>
220 <p>The current usages and practices regarding utypes may be presented
221 in several ways, e.g., by specification (VOTable, ObsCore, etc.) or by
222 application (TOPCAT, IRIS, etc.). One useful perspective is to
223 consider utypes from an IVOA Working Group standpoint, i.e., their
224 usages within specific subdomains of VO activity, which is the
225 approach we have taken in this summary. Note that we have only
226 considered UType references in current IVOA Recommendations as normative
227 &#8212; those in IVOA documents at other stages of development are potentially too
228 fluid and unrepresentative for this analysis and should be
229 considered speculative.</p>
231 <div class="section"><h3><a id="dm" shape="rect"/><span
232 class="secnum">2.1. </span>Data Models</h3>
234 <p>Unsurprisingly the bulk of usages and practices of usage arise in
235 the various data models defined by the DM Working Group, with most
236 defining utypes in tables using different conventions.</p>
238 <div class="section"><h4><a id="definition" shape="rect"/><span
239 class="secnum">2.1.1. </span>Definition</h4>
241 <p>The Spectral DM 1.1 <a href="#ref_spec1.1">[Spectrum1.1]</a>
242 defines a UType as a standard identifier for a data model
243 field. They are case-insensitive and of the form "a.b.c.d" where "the dots
244 indicate a 'has-a' hierarchy with the leftmost element being the
245 containing model and the rightmost element being the lowest level
246 element referred to". Although there are similarities with XPath,
247 it is stressed that the UType does not indicate the exact position of
248 an element in an instance but is merely a label for a data model
249 field. Note, however, that unique utypes within a group in a VOTable
250 serialization of a Spectrum "can be used to infer the data-model
251 structure".</p>
253 <p>An enumeration syntax is also suggested for multiple instances of
254 the same UType: "Data.FluxAxis.Quality.n" where n is an integer.</p>
256 <p>The Spectral data model goes on to define three serialization
257 formats, two of which (VOTable and FITS) link the data and metadata to
258 the data model using utypes. In the VOTable case, utypes are used on
259 RESOURCE and TABLE (both having the identical utype
260 <code>spec:Spectrum</code>) as well as FIELD and PARAM, the latter for
261 data model elements constant for all data points of a spectrum.
262 Additionally, there are GROUP elements used to "delimit data model
263 objects", but "nesting beyond a single GROUP is optinal, as for cases
264 for which the utypes are unique within a group, the utypes can be used
265 to infer the data model structure" (p. 57). Indeed, in the example the
266 utype of a parent GROUP is -- excepting what can safely be considered
267 editorial oversights -- always a prefix of the utypes of child GROUP,
268 FIELD, or PARAM elements.</p>
270 <p>The spectrum data model does not actually give stringent rules for
271 extending its method to other data models but notes in passing that
272 there were only two "tricky parts" left for further discussion. The
273 Spectrum DM also muses whether a type attribute on the TABLEDATA element
274 might be useful to make explicit that the table structure "implicitely"
275 represents individual points.</p>
277 <p>In its FITS serialization, the Spectral Data Model suggests a
278 longish map of utypes to (pre-existing or new) header keywords for
279 metadata -- for instance,
280 the FITS header ‘OBJECT’ corresponds to the
281 'spec:Spectrum.Target.Name' UType.
282 Within the metadata of columns of FITS tables, utypes are assigned
283 using TUTYPn header cards.</p>
285 <p>The Photometry DM 1.0 <a href="#ref_phot1.0">[PHOT]</a> defines
286 its utypes "following the IVOA rules applied for other IVOA data
287 models and derived from a simplified XML schema." The form of a
288 UType is now "ns:a.b.c.d" where the element before the colon &#8212; 'ns'
289 &#8212; identifies the data model being used.</p>
291 <p>The ObsCore DM 1.0 <a href="#ref_obsccore1.0">[OBSCORE]</a>
292 defines a convention that utypes created from the UML ObsCore model
293 follow a Camel case syntax with "attributes of a class starting with
294 a lower case letter." Most of obscore's concepts orginate in other
295 data model (Spectral, Characterization, ...), which entails some
296 degree of re-use that is not quite made explicit. What is said is
297 that for "Utypes originating from the Spectrum Data model, we keep the
298 original writing," which is, however, to be understood as replacing
299 the utype "prefix" with "obscore" (p. 35).</p>
301 <p>Utypes are not actually used in the operation of obscore services,
302 since all querying is performed via standardized column names. Apart
303 from the obvious representation in TAP_SCHEMA and the VOSI tables
304 endpoint, to rules or recommendations on how the utypes should be
305 represented in user-visible results are given.</p>
308 <p>The Characterisation DM 1.0 <a href="#ref_char1.0">[CHAR]</a>
309 specifies that "UTypes are built from the XML schema representation
310 of the model which already enforces a hierarchical structure" using
311 the "a.b.c.d" form. The constructed string is "based on instance
312 variable paths in the object-oriented data model." The difference
313 between this and an XPath approach is that a UType may use
314 "constrained element (or attribute) values in its path".</p>
316 <p>The Simulation DM 1.0 <a href="#ref_simdm1.0">[SIM]</a> states
317 that a UType is a "pointer into a data model" and that it "should
318 allow one to uniquely identify a concept in a data model". It notes
319 that it has become common practice for IVOA data models to provide a
320 list of utypes that they are defining. It then specifies a set of
321 rules for deriving utypes directly from a UML data model rather than
322 as a separate process:</p>
324 <pre>
325 UType := [model-UType | package-UType | class-UType |
326 attribute-UType | collection-UType |
327 reference-UType | container-UType
328 model-UType := &lt;model-name>
329 package-UType := model-UType ":/" package-hierarchy
330 package-hierarchy := &lt;package-name> ["/" &lt;package-name>]*
331 class-UType := package-UType "/" &lt;class-name>
332 attribute-UType := class-UType "." attribute
333 attribute := [primitive-attr | struct-attr]
334 primitive-attr := &lt;attribute-name>
335 struct-attr := &lt;attribute-name> "." attribute
336 collection-UType := class-UType "." &lt;collection-name>
337 reference-UType := class-UType "." &lt;reference-name>
338 container-UType := class-UType "." "CONTAINER"
339 identifier-UType := class-UType "." "ID"
340 </pre>
342 <p>In fact, all material associated with the Simulation DM is
343 generated from the UML model using the VO-URP framework/tool <a
344 href="#vourp">[VOURP]</a> developed by Laurent Borges and Gerard
345 Lemson. A similar approach is described in the utypes Working Draft
346 and highlights the advantages of a common data model strategy and a
347 meta-model framework. Further discussion of this is outside the scope
348 of this document.</p>
350 </div>
351 <div class="section"><h4><a id="inheritance" shape="rect"/><span
352 class="secnum">2.1.2. </span>Inheritance</h4>
354 <p>The Spectrum DM 1.1 implies that when data models are inherited,
355 utypes with the same form except for the leftmost element
356 (identifying the model) are equivalent: "we say that SSA inherits
357 the Spectrum model, so that 'SSA:' UTypes overlap with the Spectrum
358 ones.". An unnoted consequence of this is that the same concept
359 across data models must have the same 'b.c.d' identifier.</p>
361 <p>The Photometry DM seems to take this even further by using the
362 "Access class defined in ObsTAP and inherited from SSA" but tacking
363 it onto "PhotometryFilter.transmissionCurve",
364 viz. PhotometryFilter.transmissionCurve.Access.*. This would imply that
365 field names must be unique across data models.
366 </p>
368 <p>Note, however, that the top level use of Spectrum from the Spectrum
369 DM must be denoted using the "spec:" namespace.</p>
371 </div>
372 <div class="section"><h4><a id="extensibility" shape="rect"/><span
373 class="secnum">2.1.3. </span>Extensibility</h4>
375 <p>Although not actually laid out in standards documents, discussion within
376 the IVOA has frequently addressed user-extensability of data models and,
377 by extension, utypes. A simple example of how this should work is
378 NED SEDs that use <code>FluxAxis.Published.Value</code>, which is
379 supposed to be related to the standard
380 standard FluxAxis element.
381 Unique field names across all data models would solve part of this
382 problem.</p>
383 </div>
386 </div> <!-- subsection dm -->
389 <div class="section"><h3><a id="dal" shape="rect"/><span
390 class="secnum">2.2. </span>Data Access Layer</h3>
392 <p>SSA 1.1 <a href="#ref_ssa">[SSA]</a> defines utypes as "pointers to
393 data model elements" and a mechanism
394 to "flatten a hierarchical data model so that all fields are
395 represented by fixed strings in a flat namespace." It notes,
396 however, that "if a data model becomes complex enough this will no
397 longer be possible." The standard proposes GROUP elements as a
398 solution but does not go into details. In the example response, there
399 are "flat" (one-level) GROUP elements reflecting the structure of the
400 utypes.</p>
402 <p>Although nothing is explicitly said about utypes being parsable,
403 this is certainly implied by the pseudo-grammar defined with a UType
404 being constructed using "embedded period characters to delimit the
405 fields of the UType". Utypes are defined within a single namespace
406 identifying the data model with the form "(component-name).(field-name)"
407 and are unique only within the context of the specified data model.
408 However, a convention is also described whereby concepts that are
409 common to both the Spectrum DM and the SSA query response do not
410 require the "spectrum." identifier when used in the SSA query
411 response; hence "Spectrum.Target.Name" and "Target.Name" are
412 to be considered equivalent in this particular context. </p>
414 <p>Utypes are also case-insensitive.</p>
416 <p>A 2011 survey of UType practices in SSA <a
417 href="#ref_ssastate">[SSASTATE]</a> response documents showed rather
418 inconsistent results .</p>
420 <p>In <a href="#ref_tap">TAP</a>, utypes enter as columns in TAP_SCHEMA.
421 They can be assigned to schemas, tables, columns, and foreign keys (this is analogous
422 to VODataService; cf. Registry). Utypes for columns are already used by
423 Obscore. No further details are given on the content of the columns
424 containing utypes by the TAP specification, but obviously at least these
425 particular utypes will have to work as simple, and presumably opaque,
426 strings if they are to be useful in SQL queries. That foreign keys can
427 have utypes furthermore demonstrates that, at least for TAP, utypes not
428 only annotate concrete data or metadata items but also relations between
429 those.</p>
431 </div>
432 <div class="section"><h3><a id="apps" shape="rect"><span
433 class="secnum">2.3. </span>Applications</a></h3>
435 <div class="section"><h4><a id="app-votable" shape="rect"/><span
436 class="secnum">2.3.1. </span>VOTable</h4>
438 <p>Utypes were introduced as an attribute of many VOTable elements in
439 VOTable 1.1 <a href="#ref_votable1.1">[VOT1.1]</a> (FIELD, PARAM,
440 FIELDref, PARAMref, RESOURCE, TABLE, and GROUP) as an identifier for
441 something in an external data model. They should have the form
442 "datamodel_identifier:role_identifier". Although the schema defines
443 UType to have a non-namespaced value, the VOTable REC recommends to
444 use "the xmlns convention which specifies the URI of the data model
445 cited", referring to an example along the lines of:</p>
447 <pre xml:space="preserve">
448 &lt;VOTABLE version="1.2"
449 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
450 xmlns="http://www.ivoa.net/xml/VOTable/v1.2"
451 xmlns:stc="http://www.ivoa.net/xml/STC/v1.30" > ...
452 &lt;FIELD name="RA" ID="col1" ucd="pos.eq.ra;meta.main"
453 ref="J2000" UType="stc:AstroCoords.Position2D.Value2.C1"
454 datatype="float" width="6" precision="2" unit="deg"/> ...
455 </pre>
457 <p>The IVOA Note "Referencing STC in VOTable" <a
458 href="#ref_votstc">[VOTSTC]</a> suggests embedding space-time coordinate
459 metadata in VOTables by means of references to FIELDs and PARAMs. These
460 references are kept in GROUPs with a defined UType. Each group should
461 define the data model used via a specific &lt;prefix&gt;:DataModel.URI
462 UType (which entails that the prefix is significant and
463 role identifiers from different data models can refer to completely
464 differnt concepts).
465 Abusing XML namespace declaration for the purpose of binding data model
466 names to URIs is explicitely discouraged.</p>
468 <p>The utypes themselves are defined essentially through XPaths into
469 STC-X instance documents, although child element and attribute names are
470 treated analogously (i.e., <code>&lt;elem attr="bla"/&gt;</code> and
471 <code>&lt;elem&gt;&lt;attr&gt;bla&lt;/attr&gt;&lt;/elem&gt;</code> are
472 not distinguished), and some special rules apply to deal with the substitution
473 groups of STC-X.</p>
475 <p>A short example for an STC metadata declaration might be:</p>
477 <pre xml:space="preserve">
478 &lt;GROUP utype="stc:CatalogEntryLocation">
479 &lt;PARAM name="href" datatype="char" arraysize="*"
480 utype="stc:AstroCoordSystem.href"
481 value="ivo://STClib/CoordSys#TT-ICRS-TOPO"/>
482 &lt;PARAM name="URI" datatype="char" arraysize="*"
483 utype="stc:DataModel.URI"
484 value="http://www.ivoa.net/xml/STC/stc-v1.30.xsd"/>
485 &lt;FIELDref ref="ra" utype="stc:AstroCoords.Position2D.Value2.C1"/>
486 &lt;FIELDref ref="de" utype="stc:AstroCoords.Position2D.Value2.C2"/>
487 &lt;FIELDref ref="dateObs" utype="stc:AstroCoords.Time.TimeInstant"/>
488 &lt;/GROUP>
489 </pre>
491 <p>Adoption of <a href="#ref_votstc">[VOTSTC]</a> has been moderate so far.</p>
493 <p>Similar approaches combining GROUP, PARAM, and FIELDref elements have
494 been tried by <a href="#ref_photnote">[PHOTNOTE]</a> for photometry. In
495 a related effort, prototype services have even combined utypes from
496 different data models in one such GROUP; at the time of writing, CDS'
497 VizieR service returns VOTable fragments like</p>
499 <pre xml:space="preserve">
500 &lt;GROUP ID="gsed" name="_sed" ucd="phot" utype="spec:PhotometryPoint">
501 &lt;DESCRIPTION>The SED group is made of 4 columns: mean frequency, flux,
502 flux error, and filter designation&lt;/DESCRIPTION>
503 &lt;FIELDref ref="sed_freq"
504 utype="photdm:PhotometryFilter.SpectralAxis.Coverage.Location.Value"/>
505 &lt;FIELDref ref="sed_flux" utype="spec:PhotometryPoint"/>
506 &lt;FIELDref ref="sed_eflux" utype="spec:PhotometryPointError"/>
507 &lt;FIELDref ref="sed_filter"
508 utype="photdm:PhotometryFilter.identifier"/>
509 &lt;/GROUP>
510 </pre>
513 </div> <!-- subsubsection app-votable -->
515 <div class="section">
516 <h4><a id="app-splat">SPLAT</a></h4>
518 <p>The SSAP client SPLAT (written by Peter Draper and Margarida Castro Neves)
519 <a href="#ref_vosplat">[SPLAT]</a> uses utypes in serveral ways.</p>
521 <p>When processing an SSA response, it tries to locate the columns
522 interesting to it using utypes. The approach may be illustrated by a
523 comment in the code that states:</p>
525 <blockquote>The choices
526 are controlled by a series of regular expressions that can be extended as
527 needed, or by looking for the standard set of utypes defined by the IVOA
528 Spectral Data Model (1.0).</blockquote>
530 <p>&#8212; which is supposed to mean that, when UType
531 matching fails, some heuristics are applied to guess based on column names. The
532 UType match here is case insensitive, and to dodge the confusing specifications
533 on the first few elements of a utype,
534 SPLAT matches what might be described as suffix patterns. Among
535 the UType patterns matched in this way are: access.reference, access.format,
536 target.name, char.spectralaxis.name, char.fluxaxis.unit, and the
537 like.</p>
539 <p>Within a spectrum deemed compliant to the Spectral Data Model,
540 SPLAT tries to locate flux and
541 spectral axes as well as errors and units of those using utypes. Again, the
542 match is case insensitive and employs suffix rules.</p>
544 <p>When processing a spectrum in VOTable format, SPLAT searches for TABLE
545 elements with a UType "sed:Segment" to extract the corresponding data. This
546 search is case sensitive, and a full match is required; the
547 specification that inspired that behaviour has not made it to IVOA REC
548 yet.</p>
549 </div> <!-- subsubsection app-splat -->
551 <div class="section">
552 <h4><a id="app-aladin" shape="rect"><span
553 class="secnum">2.3.3. </span>Aladin</a></h4>
554 <p>Aladin (written by Pierre Fernique and others) <a href="#ref_aladin">[ALADIN]</a> employs utypes for:</p>
556 <ul>
557 <li>Finding and interpreting coordinate columns</li>
558 <li>Recognizing data content (VOTable signature)</li>
559 <li>Interpreting STC regions</li>
560 <li>Interpreting DAL SIA responses</li>
561 <li>Interpreting DAL SSA responses</li>
562 </ul>
564 <p>The full list of utypes required for each task is given in
565 <a href="#aladin-utypes">appendix A</a>.</p>
567 </div> <!-- subsubsection app-aladin -->
569 <div class="section">
570 <h4><a id="app-vospec" shape="rect"><span
571 class="secnum">2.3.4. </span>VOSpec</a></h4>
573 <p>VOSpec (written by Juan Gonzalez) <a href="#ref_vospec">[VOSpec]</a> uses utypes for:</p>
575 <ul>
576 <li>SSAP parsing: utypes are identified by direct string comparison of
577 fragments with the documented utypes, i.e., after converting the UType
578 found in the table to upper case, a check is made whether this UType
579 contains a fragment of a certain fragment of the UType defined in the specification. In case the required UType is not found, a check of UCDs and ids is also
580 done in some cases to cope with severely non-compliant services.</li>
582 <li>SLAP parsing: In order to parse Simple Line Access Protocol
583 services (SLAP), instance documents are analyzed quite as for SSAP. In
584 this case, however, the comparison is done with the full utype specified
585 in SLAP as the services are more compliant than SSAP ones; utypes are
586 compared ignoring case.</li>
588 <li>Photometry Services parsing: Same as before &#8212; direct case insensitive
589 string comparison.</li>
591 <li> Spectral DM files in XML parsing: Case insensitive comparison with
592 utypes defined in Spectrum DM document.</li>
593 </ul>
595 <p>In summary, VOSpec uses utypes in case insensitive string comparison.
596 There is no evaluation of schema URLs, utype parsing, navigation or other
597 advanced utype features.</p>
598 </div> <!-- subsubsection VOSpec -->
600 <div class="section">
601 <h4><a id="app-topcat" shape="rect"><span
602 class="secnum">2.3.5. </span>TOPCAT/STILTS</a></h4>
604 <p>TOPCAT (written by Mark Taylor) <a href="#ref_topcat">[TOPCAT]</a>
605 distinguishes between three types of UType usage:</p>
607 <ul>
608 <li>Semantically aware usage of terms in the existing UType vocabulary/ies</li>
609 <li>Semantically unaware manipulation of UType strings</li>
610 <li>Places where utypes could/might/should be used but are not</li>
611 </ul>
614 <div class="section">
615 <h5><a id="app-topcat-semaware">Semantically aware usage(s)</a></h5>
617 <p>The SSA "Access.Reference" utype is used to identify an initial guess
618 for the spectrum URL column whose contents will be passed to spectrum
619 viewers via SAMP when a View Spectrum activation action is selected.
620 When looking for the right column Utype, any prefix is ignored,
621 and a UType which endsWith(":Access.Reference") is preferred,
622 otherwise any one which endsWith("Access.Reference") is used.</p>
623 </div> <!-- app-topcat-semaware -->
625 <div class="section">
626 <h5><a id="app-topcat-semunaware">Semantically unaware usages</a></h5>
629 <p>Utypes are read/written in various places by the table I/O layer.
630 Utypes are part of STIL's internal table model, and so UType values
631 which are associated with columns are read in and recorded from
632 table formats which support utypes, and the utypes are propagated
633 to output tables if the output format supports that. True support
634 for utypes is only provided in VOTable, but STIL has an internal
635 convention of using TUTYPnnn header cards for FITS tables analogous to
636 the FITS serialization of the spectral data model. In the
637 case of a UType which is too long to fit in a FITS header
638 (>68 characters) the UType is not propagated to the output
639 (it is lost).</p>
641 <p>Utypes are displayed, and can be added/edited, in the TOPCAT GUI
642 for table columns and parameters.</p>
644 <p>One use of utypes propagated in this way is to address
645 table columns and parameters in algebraic
646 expressions using the following syntax:</p>
648 <blockquote>
649 The string "utype$" followed by the text of a UType identifying
650 the required value. Any punctuation (such as ".", ":", "-") in the
651 UType should be replaced with a "_" (since these symbols cannot
652 appear in identifiers). The first matching column, or if there is
653 none the first matching parameter value is returned. UType matching
654 is case-insensitive.
655 </blockquote>
657 <p>So for instance a column with the UType obscore:Target.Name
658 can be addressed using the expression "utype$obscore_target_name"
659 as an alternative to using the column name.</p>
661 <p>taplint (the TAP service validator) checks that utypes match between
662 TAP_SCHEMA and the /tables endpoint. It also checks that utypes are correct
663 for tables declaring themselves ObsCore.</p>
665 <p>The SAMP MType spectrum.load.ssa-generic requires all UCDs and utypes
666 to be bundled up as name/value pairs in the "meta" map. The
667 documentation at
668 <a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/SampMTypes#spectrum_load_ssa_generic
669 ">http://wiki.ivoa.net/twiki/bin/view/IVOA/SampMTypes#spectrum_load_ssa_generic</a>
670 says:</p>
671 <blockquote>
672 meta (map):
673 Additional metadata describing the spectral data found at
674 the URL. Key->Value pairs represent either utypes or UCDs as
675 defined or used in some version of the SSA specification or its
676 predecessors. Example map keys are Access.Format (SSA 1.0 MIME
677 type Utype) or VOX:Spectrum_Format (pre-1.0 SSA MIME type UCD). It
678 is up to the recipient to make sense of these and, for instance,
679 deal with the possibility that given expected keys are present
680 or that apparently contradictory information is presented. Most
681 existing SSA-aware spectrum viewing clients already contain this
682 functionality.
683 </blockquote>
685 <p>TOPCAT duly grabs these from table
686 columns and passes them on to spectrum viewers.</p>
688 <p>Finally, TOPCAT uses utypes internally when saving session state into
689 a VOTable. This uses private utypes in the topcat_session namespace:</p>
691 <ul>
692 <li>topcat_session:isTopcatModel</li>
693 <li>topcat_session:saveVersion</li>
694 <li>topcat_session:label</li>
695 <li>topcat_session:columnIndices</li>
696 <li>topcat_session:columnVisibilities</li>
697 <li>topcat_session:broadcastRows</li>
698 <li>topcat_session:rowSubsetFlags</li>
699 </ul>
700 <p>These are not intended to be comprehensible to anybody but the TOPCAT
701 application itself.</p>
703 </div> <!-- app-topcat-semunaware -->
705 <div class="section">
706 <h5><a id="app-topcat-nonusage">Non-usages</a></h5>
708 <p>STILTS does not allow you to set/read utypes for columns/parameters
709 from the command line, though it does allow you to do that for UCDs.
710 Probably, it should do it for utypes.</p>
712 <p>STILTS/TOPCAT allows you to do multiple SSA (and SIA) positional
713 searches in the same way as multiple cone searches. As a non-essential
714 part of this, it attempts to find the actual sky position of the returned
715 spectrum &#8212; if it can do that it can report on how far away the spectrum
716 was from the request, and also figure out which is the closest match
717 in the event that there are more than one within the requested radius.
718 So it wants to work out RA and Dec from an SSA response, though if it
719 fails to do it, the multi-SSA still works.
720 It does <strong>not</strong> use utypes for this. Here is the comment from the code:</p>
721 <pre>
722 // Could work harder here (and for getDecIndex); the correct thing
723 // to do for SSA 1.04 would be to look for the column with
724 // utype ssa:Char.SpatialAxis.Coverage.Location.Value, and interpret
725 // this in conjunction with other STC-like columns to make sense
726 // of it as an ICRS position. Two problems here: 1 - STC; 2 - the
727 // spatialaxis.coverage column looks like a 2-element vector (at
728 // least in some SSA results), so it can't have a column index.
729 // Would need to redefine ConeSearcher interface so it gets
730 // something more flexible than a column interface, or in the
731 // performSearch method rejig the table so that it contained some
732 // new columns with ICRS RA &amp; Dec. Since I suspect SSA from
733 // ttools is going to be rather niche functionality, I don't think
734 // it's worth the effort just now.
735 </pre>
736 <p>Ad-hoc regex pattern matching on the column name is used instead.</p>
737 </div> <!-- app-topcat-nonusage -->
738 </div> <!-- subsubsection app-topcat -->
740 <div class="section">
741 <h4><a id="app-saada" shape="rect"><span
742 class="secnum">2.3.6. </span>Saada</a></h4>
744 <p>The principle of Saada <a href="#ref_saada">[SAADA]</a> is to
745 automatically ingest data files in a database. The built-in database
746 schema is flexible enough to allow users to load data without doing
747 any mapping. The consequence is that, by default, the database only
748 contains metadata found in input files. That is enough to build a
749 searchable repository, but not to build VO compliant services. For
750 that, native metadata must be enriched with quantities which are not
751 necessarily in data files: namely UCDs, units, utypes and
752 descriptions. These quantities can be set in metadata by a simple
753 drag &amp; drop (see Fig. 2). That is very relevant for UCDs and units
754 which can be used to query data (e.g. [phys.veloc] > 1000 [km/s]).
755 Utypes can also be mapped that way but this operation remains out of
756 the scope of any data model.</p>
758 <div class="figure">
759 <img src="utypemapping.png" alt="Saada utype assignment" style="max-width:1145px" align="center"/>
760 <p class="figurecaption"><strong>Figure 2:</strong> UType mapping in Saada</p>
761 </div> <!-- figure -->
763 <p>Another tool allows mapping a model on a dataset.
764 Saada hosts inner VO model descriptions (just ObsCore right now) and DM fields can be mapped on real data.
765 The mapper shown in Fig. 3 binds DM fields with arithmetic operations on database columns.
766 The resulting mapping expressions are used by the Saada VO interface
767 to format the query results in a way compliant with the DM supported
768 by a given service. Utypes are used here to identify DM fields. They
769 are considered as simple strings without regards on their inner
770 structure.</p>
772 <div class="figure">
773 <img src="dmMapping.png" style="max-width:739px" alt="Saada data model mapping" align="center"/>
774 <p class="figurecaption"><strong>Figure 3:</strong> DM mapping in Saada</p>
775 </div> <!-- figure -->
777 <p>In the Saada query engine constrains can be expressed with utypes, quite
778 in analogy with UCDs.</p>
780 </div> <!-- subsubsection app-saada -->
782 <div class="subsubsection">
783 <h4><a id="app-iris" shape="rect"><span
784 class="secnum">2.3.7. </span>Iris</a></h4>
786 <p>Iris <a href="#ref_iris">[IRIS]</a> is designed on a stack of
787 abstraction layers around a common framework that allows easy
788 extensibility via plugins. This is realized by SEDLib which provides:</p>
790 <ul>
791 <li>basic SED I/O capabilities for VOTable and FITS serializations</li>
792 <li>SEDs and Segments as first class objects, with a relatively low-level library</li>
793 </ul>
795 <p>The library implements the Spectrum 1.03 Data Model and it is used
796 by components up in the framework layers ladder to abstract the
797 components themselves from the details of the serialization. In
798 particular, SEDLib implements the Data Model described by the XML
799 schema, which is not equivalent to the UML diagrams in the Spectrum 1.03 document, but is more suited to a concrete implementation.</p>
801 <p>Utypes are used to map the Spectra/SED VOTable metadata to the DM
802 implemented by SEDLib. All the UTyped values are made available by
803 SEDLib in a Sed class instance. Thus, users can browse all the metadata
804 in a more consistent way: all the values that refer to the same concept
805 (i.e. utypes without the prefix are the same) are displayed in the same
806 column in the metadata browser, and users can build boolean expressions
807 to filter their data. Also, all the components (either native or from
808 third party plugins) can programmatically access, as input/output, all
809 the values in the original file, thus adding science capabilities to
810 Iris.</p>
812 <p>The utypes prefix ("namespace") is ignored when comparing utypes,
813 but it is used (as "spec:") when writing out the files. Note that, in
814 accordance with Spectrum 1.1, only utypes with the spec prefix are
815 interpreted as part of the Spectrum DM, even though Spectrum 1.1
816 imports classes from the CharDM (prefix char), which in turn imports
817 STC classes (prefix stc). As a result, even though the classes, in
818 most cases, are the same, stc: and char: utypes are not interpreted,
819 unless the unprefixed utypes were the same; this is never the case for
820 Spectrum 1.1, because the *:Spectrum.* pattern that spoils the blind
821 string comparison.</p>
823 <p>Utypes are used in conjunction with UCDs for discriminating between
824 different spectral quantities and perform consistency checks. For
825 instance, when a segment’s FluxAxis represents a quantity that can’t be
826 converted to the quantities of the other segments in a SED, an exception
827 is thrown when one tries to add that segment to the SED.</p>
829 <p>Some services (notably NED) add some utypes for tagging metadata
830 related to the provenance of the data (e.g. the bibcode reference to
831 the paper whence the data has been drawn). This information is
832 available in SEDLib, but in order to be used (e.g. by plugins
833 dedicated to those services) they must be accessed using the utypes
834 string. In compliance with the assumption that utypes should not be
835 parsed, and in the absence of a proper extensibility specification, the
836 use of this metadata is naïve. Nonetheless, custom metadata is shown to
837 the user and can be used for filtering purposes.</p>
839 <p>Several changes will need to be made when Iris is updated to the
840 Spectral 2.0 DM: the UType namespace will change and all the Spectrum
841 1.1 utypes will be replicated with a different prefix: "sdm". All the
842 utypes in Spectrum 1.1 will be changed by removing the Spectrum string.</p>
844 </div> <!-- subsubsection app-iris -->
846 </div> <!-- subsection Applications -->
849 <div class="section"><h3><a id="reg" shape="rect"/><span class="secnum">2.4. </span>Registry</h3>
851 <p>The VODataService 1.1 <a href="#ref_vods">[VODS]</a> standard allows
852 utypes on schemas, tables, columns, and foreign keys (this is analogous to
853 TAP_SCHEMA; cf. section <span class="xref">dal</span>). The UType element
854 is defined to be of type xs:token.</p>
856 <p>Comments in the XML schema indicate that from the point of view
857 of VODataService, a UType on a schema is
858 "an identifier for a concept in a data model that the data in
859 this schema as a whole represent". Utypes on a foreign key are defined
860 as "an identifier
861 for a concept in a data model that the association enabled by this key
862 represents", on tables as "an identifier for a concept in a data model
863 that the data in this table represent". In each case, VODataService
864 states that the "format defined in the VOTable standard is highly
865 recommended."</p>
867 <p>No means of associating prefixes with URIs or providing further
868 structure is given. Nothing is said on case normalization.</p>
871 <p>A working draft for the relational registry 2 <a
872 href="#ref_ridraft">[REGTAP]</a> employs utypes to</p>
873 <ul>
874 <li>link the VOResource data model as defined by the collection of the
875 related XML schema documents with columns in a set of database
876 tables</li>
877 <li>allow a representation of (fairly simple) VOResource extensions
878 without having to explicitly model all aspects of them.</li>
879 </ul>
881 <p>Generating utypes for the RegTAP columns and tables is done via XSLT
882 that operates on XSD (the XSLT will fail for certain authoring ways that
883 do not occur in VOResource). Conceptually, 1:1 relationships are
884 represented by concatenating the name of the root type and the
885 attribute names in an XPath-like fashion, whereas for other
886 relationships, a referring utype (as for 1:1 relationships) and a utype
887 for the elements of the collection is generated.</p>
889 <p>To avoid having to redefine the table structure for every VOResource
890 extension newly defined, RegTAP has a table mapping pairs of resource IVORN
891 and UType to string values. The utypes are computed as above; the
892 computability is convenient since it avoids the requirement for authors
893 of VOResource extensions to manually define utypes.</p>
895 <p>RegTAP requires lowercasing utypes on ingestion to ensure that
896 case-insensitive matching is possible although ADQL has no native operator
897 reliably doing case-insensitive string comparisons. In other words,
898 RegTAP
899 assumes that utypes are case-insensitive.</p>
900 </div> <!-- subsection reg -->
903 <div class="section"><h3><a id="sem" shape="rect"/><span class="secnum">2.5. </span>Semantics</h3>
905 <p>The current VOUnits proposed recommendation mentions utypes as a tool to express "the
906 nature of the concept" and offer UCDs as an alternative tool; in this way
907 each quantity in a model would be "described with a UCD or UType, value
908 and VOUnit". As to what a "concept" might be, it suggests as an
909 example that utypes could in this way identify a
910 "quantity MJD [...] seen as a concept" (rather than trying to shoehorn
911 the time scale into a unit string).</p>
913 </div> <!-- subsection sem -->
916 <div class="section"><h3><a id="voe" shape="rect"/><span class="secnum">2.6. </span>VOEvent</h3>
918 <p>TimeSeries representation to identify concepts in TimeSeries DM.
919 This works rather as discussed above for VOTables.</p>
921 </div> <!-- subsection voe -->
923 <div class="section">
924 <h3 id="gws">Grid and Web Services</h3>
925 <p>The specifications put forward by the Grid and Web Services Working Group
926 make no use or mention of utypes in any of its specifications.</p>
927 </div> <!-- subsection gws -->
928 </div> <!-- section current usages -->
930 <div class="section">
931 <h2><a id="assessment" shape="rect"/>Assessment</h2>
933 <p>The following is a redacted collection of critique that was raised to
934 or within the Utypes Tiger Team. That a given point is discussed here
935 does not necessarily mean all Tiger Team members agree that a given
936 issue is serious or is an issue at all, even where no concrete source is
937 indicated.</p>
939 <p>Probably the most common complaint is that the definition of utypes
940 has been at least bewildering, which lead to one and the same thing
941 being referred to by several utypes. Part of this results from evolving
942 or unclear standards; as an example, spec:Target.Name,
943 spec:Spectrum.Target.Name and sdm:Target.Name were, are, or will be
944 designations for something that has not changed in the underlying data
945 models.</p>
947 <p>Partly as a consequence of this, most services using utypes are
948 non-compliant to some degree <a href="#ref_ssastate">[SSASTATE]</a>,
949 which again gave client implementors a hard time and lead to a variety
950 of practices of suffix and/or infix matching, typically not even
951 consistently applied even within one code base.</p>
953 <p>There has also been an expectation that when, e.g., both Obscore and
954 Spectral talk about, say, the DID assigned by a publisher, the utype
955 used by both should be identical, either with or without the prefix.
956 Against that has been raised that utypes are not concept labels as UCDs
957 but something linked to a concrete data model. With data models
958 different, the utypes should be different, too.</p>
960 <p>On the other hand, developers voiced a demand for consistent markup
961 of classes wherever they turn up; for instance, within certain versions
962 of the spectral data model, accuracy can be modeled as a single class
963 with a eight attributes. There are, however, more than a hundred utypes
964 matching <code>spec:*.Accuracy.*</code>, all eventually mapping
965 to these eighte attributes, which is considered wasteful by some.</p>
967 <p>Directly connected to the syntax of utypes is an uncertainty whether
968 the "prefix" is significant when comparing utypes or must, rather, be
969 ignored. It appears the intention of, e.g., the authors of SSAP and the
970 spectral data model has been that comparisons would in general ignore
971 the prefix, while the STC-in-VOTable note quite strongly indicates that
972 usual clients should never have to dissect the utype string. Also,
973 while the notion that utypes are to be compared ignoring case is at
974 least very widespread, discussions about specific spellings repeatedly
975 came up, confusing implementors.</p>
977 <p>There has also been debate on whether plain sequences of utype-value
978 pairs should be able to represent more complex data structures, e.g.,
979 ordered sequences or sequences of complex objects. This lead to
980 proposed syntaxes like foo.bar.n, foo.bar[n], and foo.bar[n].quux. At
981 least Aladin still understands some utypes formed like this, but it
982 seems the notion of coding complex instance structure in this way
983 never really caught on.</p>
985 <p>Against the proposal to annotate VOTable FIELDs using FIELDrefs from
986 GROUPs, some implementors objected the usage of GROUP and the ample
987 referencing required an application to memorize a fairly large number of
988 things.</p>
990 <p>Another topic of concern is the applicability of the utypes mechanism
991 to FITS files; a suggestion on how this might work was made in the
992 context of the spectral data model (see above). Against this it was
993 argued that for values encoded in the FITS header, an arbitrary 8-char
994 keyword must be mapped to a utype, where the term "arbitrary" here means
995 that there is no algorithmic mapping between data model roles and FITS
996 keywords. In the concrete example of the SDM, the relationship between
997 VOTable utypes and FITS keywords is also degenerate, because in
998 VOTables, some fields can have different values in, e.g., the Data and
999 Char section, while in FITS some Char fields are inherited from
1000 Data.</p>
1002 <p>A consequence of the ad-hoc nature of relating header keywords and
1003 data model elements is that a
1004 trivial round-tripping of compliant files by model unaware programs
1005 spoils the compliance of the file itself. For example, if the user uses
1006 TOPCAT to discover a SED from the NED SED service, and then saves it as
1007 a FITS, the file is not compliant anymore. A related problem turns up when a
1008 compliant FITS spectrum is saved to VOTable by a model-unaware
1009 application. Note that the information loss depends on whether
1010 certain piece of metadata is contained in a column or in a parameter
1011 inside the header. For columns, the TUTYPn convention allows utypes to
1012 be linked to columns, but this is not possible for header keywords.</p>
1014 </div> <!-- section assessement -->
1017 <div class="section-nonum"><h2><a id="changes" shape="rect"/><span class="secnum"/>Changes from Previous Versions</h2>
1019 <div class="section-nonum">
1020 <h3><a id="changes-1.0">Changes from version 1.0</a></h3>
1021 <ul>
1022 <li>Expanded coverage on Spectral and ObsCore DMs</li>
1023 <li>Extracted assements from the report part to a special section.</li>
1024 </ul>
1025 </div> <!-- changes-1.0 -->
1026 </div> <!-- changes -->
1030 <div class="section-nonum"><h2><a id="references" shape="rect"/><span class="secnum"/>References</h2>
1032 <ul class="references">
1033 <li id="ref_ssastate">[SSASTATE], Demleitner, M.; Castro-Neves, M., 2012: <a href="http://docs.g-vo.org/talks/2012-urbana-ssapstate.pdf">SSAP Seen From A 2012 Client</a>, Talk given at the 2012 Urbana Interop</li>
1034 <li id="ref_votstc">[VOTSTC], Demleitner, M, et al, 2010: <a href="http://www.ivoa.net/Documents/Notes/VOTableSTC/">Referencing STC in VOTable</a>, Version , 2.0, IVOA Note</li>
1035 <li id="ref_ridraft">[REGTAP], Demleitner, M, et al, 2013: <a
1036 href="http://docs.g-vo.org/ridraft">IVOA Registry Relational Schema</a>,
1037 Registry WG Working Draft 5 March 2013</li>
1038 <li id="ref_vourp">[VOURP], Laurent Bourges, Gerard Lemson, <a href="http://code.google.com/p/vo-urp/">http://code.google.com/p/vo-urp/</a></li>
1039 <li id="ref_UTypes">[UTYPES], Mireille Louys, Omar Laurino (eds), 2012: <a href="http://wiki.ivoa.net/internal/IVOA/Utypes/WD-Utypes-0.7-20120523.pdf" shape="rect">UTypes: a standard for
1040 > serializing Data models instances</a>, Version 0.7, IVOA Working Draft</li>
1041 <li id="ref_SpecDM">[SpecDM], Jonathan McDowell, Doug Tody (eds), 2011: <a href="http://www.ivoa.net/Documents/latest/SpecDM.html" shape="rect">SpecDM</a>, Version 1.1, IVOA Recommendation</li>
1042 <li id="ref_STC">[STC], Arnold Rots (eds), 2007: <a href="http://www.ivoa.net/Documents/latest/STC.html" shape="rect">STC</a>, Version 1.33, IVOA Recommendation</li>
1043 <li id="ref_splat">[SPLAT], Peter Draper, <a
1044 href="http://star-www.dur.ac.uk/~pdraper/splat/splat-vo/">http://star-www.dur.ac.uk/~pdraper/splat/splat-vo/</a></li>
1045 <li id="ref_aladin">[ALADIN], Pierre Fernique, <a href="http://aladin.u-strasbg.fr">http://aladin.u-strasbg.fr</a></li>
1046 <li id="ref_ObsCore">[ObsCore], Doug Tody, Alberto Micol, Daniel
1047 Durand, Mireille Louys (eds), 2011: <a href="http://www.ivoa.net/Documents/latest/ObsCore.html" shape="rect">ObsCore</a>, Version 1.0, IVOA Recommendation</li>
1048 <li id="ref_photnote">[PHOTNOTE], Derriere, S., 2010:
1049 <a
1050 href="http://www.ivoa.net/internal/IVOA/PhotometryDataModel/NOTE-PPDMDesc-0.1-20101202.pdf">Providing
1051 Photometric Data Measurements Description in VOTables</a>, Version 0.1,
1052 IVOA Draft Note.</li>
1053 </ul>
1055 </div> <!-- references -->
1057 <div class="appendix">
1058 <h2><a id="aladin-utypes">Appendix A:
1059 Specific UType usage in Aladin</a></h2>
1061 <p>Here is a list of all utypes that Aladin interprets as of late 2012:</p>
1063 <ol>
1064 <li>For finding and interpreting the coordinate columns.
1065 <ul>
1066 <li>stc:AstroCoords</li>
1067 <li>stc:AstroCoordSystem</li>
1068 <li>stc:CatalogEntryLocation</li>
1069 <li>stc:AstroCoords.coord_system_id
1070 or stc:AstroCoords.coord_sys_id</li>
1071 <li>stc:AstroCoordSystem.href
1072 or stc:AstroCoordSystem.SpaceFrame.CoordRefFrame
1073 </li>
1074 <li>stc:AstroCoords.Position2D.Value2.C1</li>
1075 <li>stc:AstroCoords.Position2D.Value2.C2</li>
1076 <li>stc:AstroCoords.SpaceFrame.Epoch
1077 or stc:AstroCoords.Position2D.Epoch</li>
1078 <li>stc:AstroCoordSystem.SpaceFrame.CoordRefFrame.Equinox
1079 </li>
1080 </ul>
1081 </li>
1082 <li>For recognizing data content (VOTable signature):
1083 <ul>
1084 <li>ssa:Access.Reference (=&gt; ignorecase test)</li>
1085 <li>dal:footprint.geom.id</li>
1086 <li>dal:fov</li>
1087 <li>dal:footprint.geom</li>
1088 <li>ivoa:characterization/[ucd=pos]/coverage/support
1089 </li>
1090 </ul></li>
1091 <li>For interpreting STC regions:
1092 <ul>
1093 <li>stc:AstroCoordArea/Region/reg:Polygon/Vertex/Position[1]
1094 or stc:AstroCoordArea.Polygon.Vertex.Position.C1 (=&gt;
1095 ignorecase test)
1096 </li>
1097 <li>stc:AstroCoordArea/Region/reg:Polygon/Vertex/Position[2]
1098 stc:AstroCoordArea.Polygon.Vertex.Position.C2 (=&gt;
1099 ignorecase test)</li>
1100 <li>stc:AstroCoordArea/Region/reg:Box/Center[1]</li>
1101 <li>stc:AstroCoordArea/Region/reg:Box/Center[2]</li>
1102 <li>stc:AstroCoordArea/Region/reg:Box/Size[1]</li>
1103 <li>stc:AstroCoordArea/Region/reg:Box/Size[2]</li>
1104 <li>stc:AstroCoordArea/Region/reg:Sector/Center[1]
1105 or stc:AstroCoordArea.Circle.Center.C1</li>
1106 <li>stc:AstroCoordArea/Region/reg:Sector/Center[2]
1107 or stc:AstroCoordArea.Circle.Center.C2</li>
1108 <li>stc:AstroCoordArea/Region/reg:Circle/radius</li>
1109 <li>stc:AstroCoordArea.Circle.radius</li>
1110 <li>stc:AstroCoordArea/Region/reg:Sector/angle1</li>
1111 <li>stc:AstroCoordArea/Region/reg:Sector/angle2</li>
1112 <li>app:footprint.render.overlay.string.content</li>
1113 <li>dal:footprint.geom.segment.shape (=&gt; ignorecase test)</li>
1114 <li>app:footprint.render.overlay.string (=&gt; ignorecase test)</li>
1115 </ul></li>
1116 <li>For interpreting DAL SIAP response:
1117 <ul>
1118 <li>dal:SimpleQueryResponse</li>
1119 <li>dal:QueryResponseExtensions</li>
1120 <li>Observation.DataID.Collection</li>
1121 <li>Observation/DataCollection
1122 or Observation/ivoa:Characterization (deprecated)
1123 </li>
1124 <li>Observation.Provenance.DataViewsAndAccess"
1125 or Observation/DataViewsAndAccess (deprecated)</li>
1126 <li>Observation/Provenance/Processing/Composition</li>
1127 <li>ivoa:Characterization[ucd=pos]/Coverage/Location</li>
1128 <li>ivoa:Characterization[ucd=pos]/Coverage/Bounds/min</li>
1129 <li>ivoa:Characterization[ucd=pos]/Coverage/Bounds/max</li>
1130 <li>Observation.DataID.DatasetID
1131 or Observation/Identifier (deprecated)</li>
1132 <li>stc:AstroCoordSystem.CoordFrame.Cart2DRefFrame.Transform2.PosAngle</li>
1133 <li>Char.SpatialAxis.Coverage.Location.Value</li>
1134 </ul></li>
1135 <li>For interpreting DAL SSA response:
1136 <ul>
1137 <li>Dataset.DataModel</li>
1138 <li>Dataset.Length</li>
1139 <li>Access.Reference</li>
1140 <li>DataID.Title</li>
1141 </ul></li>
1142 </ol>
1144 </div> <!-- appendixA -->
1146 </div><!-- class="body" -->
1147 </body></html>
1148 <!-- vi: enc=utf-8:sw=2:et:sta
1149 -->

ViewVC Help
Powered by ViewVC 1.1.26