ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 2124 - (show annotations)
Mon Apr 22 12:47:41 2013 UTC (8 years, 6 months ago) by volute@g-vo.org
File MIME type: text/html
File size: 56043 byte(s)
utypes usage: Normalized utype spelling to all-lowercase.

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


Name Value
svn:mime-type text/html

ViewVC Help
Powered by ViewVC 1.1.26