/[volute]/trunk/projects/utypes/current-usage/utypes-usage.html
ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 2123 - (show annotations)
Mon Apr 22 12:38:03 2013 UTC (8 years, 6 months ago) by volute@g-vo.org
File MIME type: text/html
File size: 52497 byte(s)
current usage: extracted most assessment-like material to a chapter of its own
(and added some gripes of my own).


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"/>
7
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"/>
12
13 <style type="text/css" xml:space="preserve">
14
15 code {
16 font-weight: bold;
17 font-family: monospace
18 }
19
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 }
29
30 div.admonition:before {
31 content: 'Note';
32 font-weight: bold;
33 }
34
35 body {
36 counter-reset: section;
37 counter-reset: toc_section;
38 }
39
40 .figurecaption {
41 margin-bottom: 4ex;
42 }
43
44 .figure img {
45 position: relative;
46 width: 100%;
47 }
48
49 p.caption {
50 font-style: italic;
51 }
52
53 .redax {
54 background-color: #FFFF90;
55 font-style: italic;
56 }
57
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>
106
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>
110
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/>
136
137 <h2>Abstract</h2>
138
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>
147
148 <h2>Status of this Document</h2>
149
150 <p id="statusdecl"></p>
151
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>
156
157 <h2 class="prologue-heading-western">Acknowledgments</h2>
158
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>
162
163
164 <h2>Contents</h2>
165 <?toc?>
166
167 </div><!-- class="head" -->
168
169 <div class="body">
170
171 <div class="section"><h2><a id="introduction" shape="rect"/><span class="secnum">1. </span>Introduction</h2>
172
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>
183
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 -->
189
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>
201
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>
214
215 </div> <!-- section introduction -->
216
217 <div class="section"><h2><a id="currentusages" shape="rect"/><span
218 class="secnum">2. </span>Current usages</h2>
219
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>
230
231 <div class="section"><h3><a id="dm" shape="rect"/><span
232 class="secnum">2.1. </span>Data Models</h3>
233
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>
237
238 <div class="section"><h4><a id="definition" shape="rect"/><span
239 class="secnum">2.1.1. </span>Definition</h4>
240
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>
252
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>
255
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>
269
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>
276
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>
284
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>
290
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>
300
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>
306
307
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>
315
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>
323
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>
341
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>
349
350 </div>
351 <div class="section"><h4><a id="inheritance" shape="rect"/><span
352 class="secnum">2.1.2. </span>Inheritance</h4>
353
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>
360
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>
367
368 <p>Note, however, that the top level use of Spectrum from the Spectrum
369 DM must be denoted using the "spec:" namespace.</p>
370
371 </div>
372 <div class="section"><h4><a id="extensibility" shape="rect"/><span
373 class="secnum">2.1.3. </span>Extensibility</h4>
374
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>
384
385
386 </div> <!-- subsection dm -->
387
388
389 <div class="section"><h3><a id="dal" shape="rect"/><span
390 class="secnum">2.2. </span>Data Access Layer</h3>
391
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>
401
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>
413
414 <p>UTypes are also case-insensitive.</p>
415
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>
419
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>
430
431 </div>
432 <div class="section"><h3><a id="apps" shape="rect"><span
433 class="secnum">2.3. </span>Applications</a></h3>
434
435 <div class="section"><h4><a id="app-votable" shape="rect"/><span
436 class="secnum">2.3.1. </span>VOTable</h4>
437
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>
446
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>
456
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>
467
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>
474
475 <p>A short example for an STC metadata declaration might be:</p>
476
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>
490
491 <p>Adoption of <a href="#ref_votstc">[VOTSTC]</a> has been moderate so far.</p>
492
493 </div> <!-- subsubsection app-votable -->
494
495 <div class="section">
496 <h4><a id="app-splat">SPLAT</a></h4>
497
498 <p>The SSAP client SPLAT (written by Peter Draper and Margarida Castro Neves)
499 <a href="#ref_vosplat">[SPLAT]</a> uses UTypes in serveral ways.</p>
500
501 <p>When processing an SSA response, it tries to locate the columns
502 interesting to it using UTypes. The approach may be illustrated by a
503 comment in the code that states:</p>
504
505 <blockquote>The choices
506 are controlled by a series of regular expressions that can be extended as
507 needed, or by looking for the standard set of UTypes defined by the IVOA
508 Spectral Data Model (1.0).</blockquote>
509
510 <p>&#8212; which is supposed to mean that, when UType
511 matching fails, some heuristics are applied to guess based on column names. The
512 UType match here is case insensitive, and to dodge the confusing specifications
513 on the first few elements of a utype,
514 SPLAT matches what might be described as suffix patterns. Among
515 the UType patterns matched in this way are: access.reference, access.format,
516 target.name, char.spectralaxis.name, char.fluxaxis.unit, and the
517 like.</p>
518
519 <p>Within a spectrum deemed compliant to the Spectral Data Model,
520 SPLAT tries to locate flux and
521 spectral axes as well as errors and units of those using UTypes. Again, the
522 match is case insensitive and employs suffix rules.</p>
523
524 <p>When processing a spectrum in VOTable format, SPLAT searches for TABLE
525 elements with a UType "sed:Segment" to extract the corresponding data. This
526 search is case sensitive, and a full match is required; the
527 specification that inspired that behaviour has not made it to IVOA REC
528 yet.</p>
529 </div> <!-- subsubsection app-splat -->
530
531 <div class="section">
532 <h4><a id="app-aladin" shape="rect"><span
533 class="secnum">2.3.3. </span>Aladin</a></h4>
534 <p>Aladin (written by Pierre Fernique and others) <a href="#ref_aladin">[ALADIN]</a> employs UTypes for:</p>
535
536 <ul>
537 <li>Finding and interpreting coordinate columns</li>
538 <li>Recognizing data content (VOTable signature)</li>
539 <li>Interpreting STC regions</li>
540 <li>Interpreting DAL SIA responses</li>
541 <li>Interpreting DAL SSA responses</li>
542 </ul>
543
544 <p>The full list of UTypes required for each task is given in <a
545 href="#appendixa">Appendix A</a>.</p>
546
547 </div> <!-- subsubsection app-aladin -->
548
549 <div class="section">
550 <h4><a id="app-vospec" shape="rect"><span
551 class="secnum">2.3.4. </span>VOSpec</a></h4>
552
553 <p>VOSpec (written by Juan Gonzalez) <a href="#ref_vospec">[VOSpec]</a> uses UTypes for:</p>
554
555 <ul>
556 <li>SSAP parsing: UTypes are identified by direct string comparison of
557 fragments with the documented UTypes, i.e., after converting the UType
558 found in the table to upper case, a check is made whether this UType
559 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
560 done in some cases to cope with severely non-compliant services.</li>
561
562 <li>SLAP parsing: In order to parse Simple Line Access Protocol
563 services (SLAP), instance documents are analyzed quite as for SSAP. In
564 this case, however, the comparison is done with the full utype specified
565 in SLAP as the services are more compliant than SSAP ones; utypes are
566 compared ignoring case.</li>
567
568 <li>Photometry Services parsing: Same as before &#8212; direct case insensitive
569 string comparison.</li>
570
571 <li> Spectral DM files in XML parsing: Case insensitive comparison with
572 UTypes defined in Spectrum DM document.</li>
573 </ul>
574
575 <p>In summary, VOSpec uses utypes in case insensitive string comparison.
576 There is no evaluation of schema URLs, utype parsing, navigation or other
577 advanced utype features.</p>
578 </div> <!-- subsubsection VOSpec -->
579
580 <div class="section">
581 <h4><a id="app-topcat" shape="rect"><span
582 class="secnum">2.3.5. </span>TOPCAT/STILTS</a></h4>
583
584 <p>TOPCAT (written by Mark Taylor) <a href="#ref_topcat">[TOPCAT]</a>
585 distinguishes between three types of UType usage:</p>
586
587 <ul>
588 <li>Semantically aware usage of terms in the existing UType vocabulary/ies</li>
589 <li>Semantically unaware manipulation of UType strings</li>
590 <li>Places where UTypes could/might/should be used UTypes but are not</li>
591 </ul>
592
593
594 <div class="section">
595 <h5><a id="app-topcat-semaware">Semantically aware usage(s)</a></h5>
596
597 <p>The SSA "Access.Reference" utype is used to identify an initial guess
598 for the spectrum URL column whose contents will be passed to spectrum
599 viewers via SAMP when a View Spectrum activation action is selected.
600 When looking for the right column Utype, any prefix is ignored,
601 and a UType which endsWith(":Access.Reference") is preferred,
602 otherwise any one which endsWith("Access.Reference") is used.</p>
603 </div> <!-- app-topcat-semaware -->
604
605 <div class="section">
606 <h5><a id="app-topcat-semunaware">Semantically unaware usages</a></h5>
607
608
609 <p>UTypes are read/written in various places by the table I/O layer.
610 UTypes are part of STIL's internal table model, and so UType values
611 which are associated with columns are read in and recorded from
612 table formats which support UTypes, and the UTypes are propagated
613 to output tables if the output format supports that. True support
614 for UTypes is only provided in VOTable, but STIL has an internal
615 convention of using TUTYPnnn header cards for FITS tables analogous to
616 the FITS serialization of the spectral data model. In the
617 case of a UType which is too long to fit in a FITS header
618 (>68 characters) the UType is not propagated to the output
619 (it is lost).</p>
620
621 <p>UTypes are displayed, and can be added/edited, in the TOPCAT GUI
622 for table columns and parameters.</p>
623
624 <p>One use of utypes propagated in this way is to address
625 table columns and parameters in algebraic
626 expressions using the following syntax:</p>
627
628 <blockquote>
629 The string "utype$" followed by the text of a UType identifying
630 the required value. Any punctuation (such as ".", ":", "-") in the
631 UType should be replaced with a "_" (since these symbols cannot
632 appear in identifiers). The first matching column, or if there is
633 none the first matching parameter value is returned. UType matching
634 is case-insensitive.
635 </blockquote>
636
637 <p>So for instance a column with the UType obscore:Target.Name
638 can be addressed using the expression "utype$obscore_target_name"
639 as an alternative to using the column name.</p>
640
641 <p>taplint (the TAP service validator) checks that UTypes match between
642 TAP_SCHEMA and the /tables endpoint. It also checks that UTypes are correct
643 for tables declaring themselves ObsCore.</p>
644
645 <p>The SAMP MType spectrum.load.ssa-generic requires all UCDs and UTypes
646 to be bundled up as name/value pairs in the "meta" map. The
647 documentation at
648 <a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/SampMTypes#spectrum_load_ssa_generic
649 ">http://wiki.ivoa.net/twiki/bin/view/IVOA/SampMTypes#spectrum_load_ssa_generic</a>
650 says:</p>
651 <blockquote>
652 meta (map):
653 Additional metadata describing the spectral data found at
654 the URL. Key->Value pairs represent either UTypes or UCDs as
655 defined or used in some version of the SSA specification or its
656 predecessors. Example map keys are Access.Format (SSA 1.0 MIME
657 type Utype) or VOX:Spectrum_Format (pre-1.0 SSA MIME type UCD). It
658 is up to the recipient to make sense of these and, for instance,
659 deal with the possibility that given expected keys are present
660 or that apparently contradictory information is presented. Most
661 existing SSA-aware spectrum viewing clients already contain this
662 functionality.
663 </blockquote>
664
665 <p>TOPCAT duly grabs these from table
666 columns and passes them on to spectrum viewers.</p>
667
668 <p>Finally, TOPCAT uses utypes internally when saving session state into
669 a VOTable. This uses private utypes in the topcat_session namespace:</p>
670
671 <ul>
672 <li>topcat_session:isTopcatModel</li>
673 <li>topcat_session:saveVersion</li>
674 <li>topcat_session:label</li>
675 <li>topcat_session:columnIndices</li>
676 <li>topcat_session:columnVisibilities</li>
677 <li>topcat_session:broadcastRows</li>
678 <li>topcat_session:rowSubsetFlags</li>
679 </ul>
680 <p>These are not intended to be comprehensible to anybody but the TOPCAT
681 application itself.</p>
682
683 </div> <!-- app-topcat-semunaware -->
684
685 <div class="section">
686 <h5><a id="app-topcat-nonusage">Non-usages</a></h5>
687
688 <p>STILTS does not allow you to set/read UTypes for columns/parameters
689 from the command line, though it does allow you to do that for UCDs.
690 Probably, it should do it for UTypes.</p>
691
692 <p>STILTS/TOPCAT allows you to do multiple SSA (and SIA) positional
693 searches in the same way as multiple cone searches. As a non-essential
694 part of this, it attempts to find the actual sky position of the returned
695 spectrum &#8212; if it can do that it can report on how far away the spectrum
696 was from the request, and also figure out which is the closest match
697 in the event that there are more than one within the requested radius.
698 So it wants to work out RA and Dec from an SSA response, though if it
699 fails to do it, the multi-SSA still works.
700 It does <strong>not</strong> use UTypes for this. Here is the comment from the code:</p>
701 <pre>
702 // Could work harder here (and for getDecIndex); the correct thing
703 // to do for SSA 1.04 would be to look for the column with
704 // utype ssa:Char.SpatialAxis.Coverage.Location.Value, and interpret
705 // this in conjunction with other STC-like columns to make sense
706 // of it as an ICRS position. Two problems here: 1 - STC; 2 - the
707 // spatialaxis.coverage column looks like a 2-element vector (at
708 // least in some SSA results), so it can't have a column index.
709 // Would need to redefine ConeSearcher interface so it gets
710 // something more flexible than a column interface, or in the
711 // performSearch method rejig the table so that it contained some
712 // new columns with ICRS RA &amp; Dec. Since I suspect SSA from
713 // ttools is going to be rather niche functionality, I don't think
714 // it's worth the effort just now.
715 </pre>
716 <p>Ad-hoc regex pattern matching on the column name is used instead.</p>
717 </div> <!-- app-topcat-nonusage -->
718 </div> <!-- subsubsection app-topcat -->
719
720 <div class="section">
721 <h4><a id="app-saada" shape="rect"><span
722 class="secnum">2.3.6. </span>Saada</a></h4>
723
724 <p>The principle of Saada <a href="#ref_saada">[SAADA]</a> is to
725 automatically ingest data files in a database. The built-in database
726 schema is flexible enough to allow users to load data without doing
727 any mapping. The consequence is that, by default, the database only
728 contains metadata found in input files. That is enough to build a
729 searchable repository, but not to build VO compliant services. For
730 that, native metadata must be enriched with quantities which are not
731 necessarily in data files: namely UCDs, units, UTypes and
732 descriptions. These quantities can be set in metadata by a simple
733 drag &amp; drop (see Fig. 2). That is very relevant for UCDs and units
734 which can be used to query data (e.g. [phys.veloc] > 1000 [km/s]).
735 UTypes can also be mapped that way but this operation remains out of
736 the scope of any data model.</p>
737
738 <div class="figure">
739 <img src="utypemapping.png" alt="" width="40%" align="center"/>
740 <p class="figurecaption"><strong>Figure 2:</strong> UType mapping in Saada</p>
741 </div> <!-- figure -->
742
743 <p>Another tool allows mapping a model on a dataset.
744 Saada hosts inner VO model descriptions (just ObsCore right now) and DM fields can be mapped on real data.
745 The mapper shown in Fig. 3 binds DM fields with arithmetic operations on database columns.
746 The resulting mapping expressions are used by the Saada VO interface
747 to format the query results in a way compliant with the DM supported
748 by a given service. UTypes are used here to identify DM fields. They
749 are considered as simple strings without regards on their inner
750 structure.</p>
751
752 <div class="figure">
753 <img src="dmMapping.png" alt="" width="40%" align="center"/>
754 <p class="figurecaption"><strong>Figure 3:</strong> DM mapping in Saada</p>
755 </div> <!-- figure -->
756
757 <p>Note that the Saada query engine is also enable to process constrains expressed with UTypes as it does with UCDs.</p>
758
759 </div> <!-- subsubsection app-saada -->
760
761 <div class="subsubsection">
762 <h4><a id="app-iris" shape="rect"><span
763 class="secnum">2.3.7. </span>Iris</a></h4>
764
765 <p>Iris <a href="#ref_iris">[IRIS]</a> is designed on a stack of
766 abstraction layers around a common framework that allows easy
767 extensibility via plugins. This is realized by SEDLib which provides:</p>
768
769 <ul>
770 <li>basic SED I/O capabilities for VOTable and FITS serializations</li>
771 <li>SEDs and Segments as first class objects, with a relatively low-level library</li>
772 </ul>
773
774 <p>The library implements the Spectrum 1.03 Data Model and it is used
775 by components up in the framework layers ladder to abstract the
776 components themselves from the details of the serialization. In
777 particular, SEDLib implements the Data Model described by the XML
778 schema, which is not equivalent to the UML diagrams in the Spectrum 1.03 document, but is more suited to a concrete implementation.</p>
779
780 <p>UTypes are used to map the Spectra/SED VOTable metadata to the DM
781 implemented by SEDLib. All the UTyped values are made available by
782 SEDLib in a Sed class instance. Thus, users can browse all the metadata
783 in a more consistent way: all the values that refer to the same concept
784 (i.e. UTypes without the prefix are the same) are displayed in the same
785 column in the metadata browser, and users can build boolean expressions
786 to filter their data. Also, all the components (either native or from
787 third party plugins) can programmatically access, as input/output, all
788 the values in the original file, thus adding science capabilities to
789 Iris.</p>
790
791 <p>The UTypes prefix ("namespace") is ignored when comparing UTypes,
792 but it is used (as "spec:") when writing out the files. Note that, in
793 accordance with Spectrum 1.1, only UTypes with the spec prefix are
794 interpreted as part of the Spectrum DM, even though Spectrum 1.1
795 imports classes from the CharDM (prefix char), which in turn imports
796 STC classes (prefix stc). As a result, even though the classes, in
797 most cases, are the same, stc: and char: UTypes are not interpreted,
798 unless the unprefixed UTypes were the same; this is never the case for
799 Spectrum 1.1, because the *:Spectrum.* pattern that spoils the blind
800 string comparison.</p>
801
802 <p>Utypes are used in conjunction with UCDs for discriminating between
803 different spectral quantities and perform consistency checks. For
804 instance, when a segment’s FluxAxis represents a quantity that can’t be
805 converted to the quantities of the other segments in a SED, an exception
806 is thrown when one tries to add that segment to the SED.</p>
807
808 <p>Some services (notably NED) add some UTypes for tagging metadata
809 related to the provenance of the data (e.g. the bibcode reference to
810 the paper whence the data has been drawn). This information is
811 available in SEDLib, but in order to be used (e.g. by plugins
812 dedicated to those services) they must be accessed using the UTypes
813 string. In compliance with the assumption that UTypes should not be
814 parsed, and in the absence of a proper extensibility specification, the
815 use of this metadata is naïve. Nonetheless, custom metadata is shown to
816 the user and can be used for filtering purposes.</p>
817
818 <p>Several changes will need to be made when Iris is updated to the
819 Spectral 2.0 DM: the UType namespace will change and all the Spectrum
820 1.1 UTypes will be replicated with a different prefix: "sdm". All the
821 UTypes in Spectrum 1.1 will be changed by removing the Spectrum string.</p>
822
823 </div> <!-- subsubsection app-iris -->
824
825 </div> <!-- subsection Applications -->
826
827
828 <div class="section"><h3><a id="reg" shape="rect"/><span class="secnum">2.4. </span>Registry</h3>
829
830 <p>The VODataService 1.1 <a href="#ref_vods">[VODS]</a> standard allows
831 UTypes on schemas, tables, columns, and foreign keys (this is analogous to
832 TAP_SCHEMA; cf. section <span class="xref">dal</span>). The UType element
833 is defined to be of type xs:token.</p>
834
835 <p>Comments in the XML schema indicate that from the point of view
836 of VODataService, a UType on a schema is
837 "an identifier for a concept in a data model that the data in
838 this schema as a whole represent". UTypes on a foreign key are defined
839 as "an identifier
840 for a concept in a data model that the association enabled by this key
841 represents", on tables as "an identifier for a concept in a data model
842 that the data in this table represent". In each case, VODataService
843 states that the "format defined in the VOTable standard is highly
844 recommended."</p>
845
846 <p>No means of associating prefixes with URIs or providing further
847 structure is given. Nothing is said on case normalization.</p>
848
849
850 <p>A working draft for the relational registry 2 <a
851 href="#ref_ridraft">[REGTAP]</a> employs UTypes to</p>
852 <ul>
853 <li>link the VOResource data model as defined by the collection of the
854 related XML schema documents with columns in a set of database
855 tables</li>
856 <li>allow a representation of (fairly simple) VOResource extensions
857 without having to explicitly model all aspects of them.</li>
858 </ul>
859
860 <p>Generating UTypes for the RegTAP columns and tables is done via XSLT
861 that operates on XSD (the XSLT will fail for certain authoring ways that
862 do not occur in VOResource). Conceptually, 1:1 relationships are
863 represented by concatenating the name of the root type and the
864 attribute names in an XPath-like fashion, whereas for other
865 relationships, a referring utype (as for 1:1 relationships) and a utype
866 for the elements of the collection is generated.</p>
867
868 <p>To avoid having to redefine the table structure for every VOResource
869 extension newly defined, RegTAP has a table mapping pairs of resource IVORN
870 and UType to string values. The UTypes are computed as above; the
871 computability is convenient since it avoids the requirement for authors
872 of VOResource extensions to manually define UTypes.</p>
873
874 <p>RegTAP requires lowercasing UTypes on ingestion to ensure that
875 case-insensitive matching is possible although ADQL has no native operator
876 reliably doing case-insensitive string comparisons. In other words,
877 RegTAP
878 assumes that UTypes are case-insensitive.</p>
879 </div> <!-- subsection reg -->
880
881
882 <div class="section"><h3><a id="sem" shape="rect"/><span class="secnum">2.5. </span>Semantics</h3>
883
884 <p>The current VOUnits proposed recommendation mentions UTypes as a tool to express "the
885 nature of the concept" and offer UCDs as an alternative tool; in this way
886 each quantity in a model would be "described with a UCD or UType, value
887 and VOUnit". As to what a "concept" might be, it suggests as an
888 example that utypes could in this way identify a
889 "quantity MJD [...] seen as a concept" (rather than trying to shoehorn
890 the time scale into a unit string).</p>
891
892 </div> <!-- subsection sem -->
893
894
895 <div class="section"><h3><a id="voe" shape="rect"/><span class="secnum">2.6. </span>VOEvent</h3>
896
897 <p>TimeSeries representation to identify concepts in TimeSeries DM.
898 This works rather as discussed above for VOTables.</p>
899
900 </div> <!-- subsection voe -->
901
902 <div class="section">
903 <h3 id="gws">Grid and Web Services</h3>
904 <p>The specifications put forward by the Grid and Web Services Working Group
905 make no use or mention of UTypes in any of its specifications.</p>
906 </div> <!-- subsection gws -->
907 </div> <!-- section current usages -->
908
909 <div class="section">
910 <h2><a id="assessment" shape="rect"/>Assessment</h2>
911
912 <p>The following is a redacted collection of critique that was raised to
913 or within the Utypes Tiger Team. That a given point is discussed here
914 does not necessarily mean all Tiger Team members agree that a given
915 issue is serious or is an issue at all, even where no concrete source is
916 indicated.</p>
917
918 <p>Probably the most common complaint is that the definition of utypes
919 has been at least bewildering, which lead to one and the same thing
920 being referred to by several utypes. Part of this results from evolving
921 or unclear standards; as an example, spec:Target.Name,
922 spec:Spectrum.Target.Name and sdm:Target.Name were, are, or will be
923 designations for something that has not changed in the underlying data
924 models.</p>
925
926 <p>Partly as a consequence of this, most services using utypes are
927 non-compliant to some degree <a href="#ref_ssastate">[SSASTATE]</a>,
928 which again gave client implementors a hard time and lead to a variety
929 of practices of suffix and/or infix matching, typically not even
930 consistently applied even within one code base.</p>
931
932 <p>There has also been an expectation that when, e.g., both Obscore and
933 Spectral talk about, say, the DID assigned by a publisher, the utype
934 used by both should be identical, either with or without the prefix.
935 Against that has been raised that utypes are not concept labels as UCDs
936 but something linked to a concrete data model. With data models
937 different, the utypes should be different, too.</p>
938
939 <p>On the other hand, developers voiced a demand for consistent markup
940 of classes wherever they turn up; for instance, within certain versions
941 of the spectral data model, accuracy can be modeled as a single class
942 with a eight attributes. There are, however, more than a hundred utypes
943 matching <code>spec:*.Accuracy.*</code>, all eventually mapping
944 to these eighte attributes, which is considered wasteful by some.</p>
945
946 <p>Directly connected to the syntax of utypes is an uncertainty whether
947 the "prefix" is significant when comparing utypes or must, rather, be
948 ignored. It appears the intention of, e.g., the authors of SSAP and the
949 spectral data model has been that comparisons would in general ignore
950 the prefix, while the STC-in-VOTable note quite strongly indicates that
951 usual clients should never have to dissect the utype string. Also,
952 while the notion that utypes are to be compared ignoring case is at
953 least very widespread, discussions about specific spellings repeatedly
954 came up, confusing implementors.</p>
955
956 <p>There has also been debate on whether plain sequences of utype-value
957 pairs should be able to represent more complex data structures, e.g.,
958 ordered sequences or sequences of complex objects. This lead to
959 proposed syntaxes like foo.bar.n, foo.bar[n], and foo.bar[n].quux. At
960 least Aladin still understands some utypes formed like this, but it
961 seems the notion of coding complex instance structure in this way
962 never really caught on.</p>
963
964 <p>Against the proposal to annotate VOTable FIELDs using FIELDrefs from
965 GROUPs, some implementors objected the usage of GROUP and the ample
966 referencing required an application to memorize a fairly large number of
967 things.</p>
968
969 <p>Another topic of concern is the applicability of the utypes mechanism
970 to FITS files; a suggestion on how this might work was made in the
971 context of the spectral data model (see above). Against this it was
972 argued that for values encoded in the FITS header, an arbitrary 8-char
973 keyword must be mapped to a utype, where the term "arbitrary" here means
974 that there is no algorithmic mapping between data model roles and FITS
975 keywords. In the concrete example of the SDM, the relationship between
976 VOTable UTypes and FITS keywords is also degenerate, because in
977 VOTables, some fields can have different values in, e.g., the Data and
978 Char section, while in FITS some Char fields are inherited from
979 Data.</p>
980
981 <p>A consequence of the ad-hoc nature of relating header keywords and
982 data model elements is that a
983 trivial round-tripping of compliant files by model unaware programs
984 spoils the compliance of the file itself. For example, if the user uses
985 TOPCAT to discover a SED from the NED SED service, and then saves it as
986 a FITS, the file is not compliant anymore. A related problem turns up when a
987 compliant FITS spectrum is saved to VOTable by a model-unaware
988 application. Note that the information loss depends on whether
989 certain piece of metadata is contained in a column or in a parameter
990 inside the header. For columns, the TUTYPn convention allows UTypes to
991 be linked to columns, but this is not possible for header keywords.</p>
992
993 </div> <!-- section assessement -->
994
995
996 <div class="section-nonum"><h2><a id="changes" shape="rect"/><span class="secnum"/>Changes from Previous Versions</h2>
997
998 <div class="section-nonum">
999 <h3><a id="changes-1.0">Changes from version 1.0</a></h3>
1000 <ul>
1001 <li>Expanded coverage on Spectral and ObsCore DMs</li>
1002 <li>Extracted assements from the report part to a special section.</li>
1003 </ul>
1004 </div> <!-- changes-1.0 -->
1005 </div> <!-- changes -->
1006
1007
1008
1009 <div class="section-nonum"><h2><a id="references" shape="rect"/><span class="secnum"/>References</h2>
1010
1011 <ul class="references">
1012 <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>
1013 <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>
1014 <li id="ref_ridraft">[REGTAP], Demleitner, M, et al, 2013: <a
1015 href="http://docs.g-vo.org/ridraft">IVOA Registry Relational Schema</a>,
1016 Registry WG Working Draft 5 March 2013</li>
1017 <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>
1018 <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
1019 > serializing Data models instances</a>, Version 0.7, IVOA Working Draft</li>
1020 <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>
1021 <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>
1022 <li id="ref_splat">[SPLAT], Peter Draper, <a
1023 href="http://star-www.dur.ac.uk/~pdraper/splat/splat-vo/">http://star-www.dur.ac.uk/~pdraper/splat/splat-vo/</a></li>
1024 <li id="ref_aladin">[ALADIN], Pierre Fernique, <a href="http://aladin.u-strasbg.fr">http://aladin.u-strasbg.fr</a></li>
1025 <li id="ref_ObsCore">[ObsCore], Doug Tody, Alberto Micol, Daniel
1026 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>
1027 </ul>
1028
1029 </div> <!-- references -->
1030
1031 <div class="appendix"><h2><a id="appendixA" shape="rect"/>Appendix A:
1032 Specific UType usage in Aladin</h2>
1033
1034 <p>Here is a list of all UTypes that Aladin interprets as of late 2012:</p>
1035
1036 <ol>
1037 <li>For finding and interpreting the coordinate columns.
1038 <ul>
1039 <li>stc:AstroCoords</li>
1040 <li>stc:AstroCoordSystem</li>
1041 <li>stc:CatalogEntryLocation</li>
1042 <li>stc:AstroCoords.coord_system_id
1043 or stc:AstroCoords.coord_sys_id</li>
1044 <li>stc:AstroCoordSystem.href
1045 or stc:AstroCoordSystem.SpaceFrame.CoordRefFrame
1046 </li>
1047 <li>stc:AstroCoords.Position2D.Value2.C1</li>
1048 <li>stc:AstroCoords.Position2D.Value2.C2</li>
1049 <li>stc:AstroCoords.SpaceFrame.Epoch
1050 or stc:AstroCoords.Position2D.Epoch</li>
1051 <li>stc:AstroCoordSystem.SpaceFrame.CoordRefFrame.Equinox
1052 </li>
1053 </ul>
1054 </li>
1055 <li>For recognizing data content (VOTable signature):
1056 <ul>
1057 <li>ssa:Access.Reference (=&gt; ignorecase test)</li>
1058 <li>dal:footprint.geom.id</li>
1059 <li>dal:fov</li>
1060 <li>dal:footprint.geom</li>
1061 <li>ivoa:characterization/[ucd=pos]/coverage/support
1062 </li>
1063 </ul></li>
1064 <li>For interpreting STC regions:
1065 <ul>
1066 <li>stc:AstroCoordArea/Region/reg:Polygon/Vertex/Position[1]
1067 or stc:AstroCoordArea.Polygon.Vertex.Position.C1 (=&gt;
1068 ignorecase test)
1069 </li>
1070 <li>stc:AstroCoordArea/Region/reg:Polygon/Vertex/Position[2]
1071 stc:AstroCoordArea.Polygon.Vertex.Position.C2 (=&gt;
1072 ignorecase test)</li>
1073 <li>stc:AstroCoordArea/Region/reg:Box/Center[1]</li>
1074 <li>stc:AstroCoordArea/Region/reg:Box/Center[2]</li>
1075 <li>stc:AstroCoordArea/Region/reg:Box/Size[1]</li>
1076 <li>stc:AstroCoordArea/Region/reg:Box/Size[2]</li>
1077 <li>stc:AstroCoordArea/Region/reg:Sector/Center[1]
1078 or stc:AstroCoordArea.Circle.Center.C1</li>
1079 <li>stc:AstroCoordArea/Region/reg:Sector/Center[2]
1080 or stc:AstroCoordArea.Circle.Center.C2</li>
1081 <li>stc:AstroCoordArea/Region/reg:Circle/radius</li>
1082 <li>stc:AstroCoordArea.Circle.radius</li>
1083 <li>stc:AstroCoordArea/Region/reg:Sector/angle1</li>
1084 <li>stc:AstroCoordArea/Region/reg:Sector/angle2</li>
1085 <li>app:footprint.render.overlay.string.content</li>
1086 <li>dal:footprint.geom.segment.shape (=&gt; ignorecase test)</li>
1087 <li>app:footprint.render.overlay.string (=&gt; ignorecase test)</li>
1088 </ul></li>
1089 <li>For interpreting DAL SIAP response:
1090 <ul>
1091 <li>dal:SimpleQueryResponse</li>
1092 <li>dal:QueryResponseExtensions</li>
1093 <li>Observation.DataID.Collection</li>
1094 <li>Observation/DataCollection
1095 or Observation/ivoa:Characterization (deprecated)
1096 </li>
1097 <li>Observation.Provenance.DataViewsAndAccess"
1098 or Observation/DataViewsAndAccess (deprecated)</li>
1099 <li>Observation/Provenance/Processing/Composition</li>
1100 <li>ivoa:Characterization[ucd=pos]/Coverage/Location</li>
1101 <li>ivoa:Characterization[ucd=pos]/Coverage/Bounds/min</li>
1102 <li>ivoa:Characterization[ucd=pos]/Coverage/Bounds/max</li>
1103 <li>Observation.DataID.DatasetID
1104 or Observation/Identifier (deprecated)</li>
1105 <li>stc:AstroCoordSystem.CoordFrame.Cart2DRefFrame.Transform2.PosAngle</li>
1106 <li>Char.SpatialAxis.Coverage.Location.Value</li>
1107 </ul></li>
1108 <li>For interpreting DAL SSA response:
1109 <ul>
1110 <li>Dataset.DataModel</li>
1111 <li>Dataset.Length</li>
1112 <li>Access.Reference</li>
1113 <li>DataID.Title</li>
1114 </ul></li>
1115 </ol>
1116
1117 </div> <!-- appendixA -->
1118
1119 </div><!-- class="body" -->
1120 </body></html>
1121 <!-- vi: enc=utf-8:sw=2:et:sta
1122 -->

msdemlei@ari.uni-heidelberg.de
ViewVC Help
Powered by ViewVC 1.1.26