ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

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

1 <?xml version="1.0" encoding="UTF-8"?><!-- this source is meant to be processed with Paul Harrison's
2 ivoadoc toolkit, see somewhere at http://code.google.com/p/volute/ -->
3 <!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="#d2e927"><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 <p>Similar approaches combining GROUP, PARAM, and FIELDref elements have
488 been tried by <a href="#ref_photnote">[PHOTNOTE]</a> for photometry. In
489 a related effort, prototype services have even combined utypes from
490 different data models in one such GROUP; at the time of writing, CDS'
491 VizieR service returns VOTable fragments like</p>
493 <pre xml:space="preserve">
494 &lt;GROUP ID="gsed" name="_sed" ucd="phot" utype="spec:PhotometryPoint"&gt;
495 &lt;DESCRIPTION&gt;The SED group is made of 4 columns: mean frequency, flux,
496 flux error, and filter designation&lt;/DESCRIPTION&gt;
497 &lt;FIELDref ref="sed_freq"
498 utype="photdm:PhotometryFilter.SpectralAxis.Coverage.Location.Value"/&gt;
499 &lt;FIELDref ref="sed_flux" utype="spec:PhotometryPoint"/&gt;
500 &lt;FIELDref ref="sed_eflux" utype="spec:PhotometryPointError"/&gt;
501 &lt;FIELDref ref="sed_filter"
502 utype="photdm:PhotometryFilter.identifier"/&gt;
503 &lt;/GROUP&gt;
504 </pre>
507 </div> <!-- subsubsection app-votable -->
509 <div class="section"><h4><a id="app-splat"><span class="secnum">2.3.2. </span>SPLAT</a></h4>
511 <p>The SSAP client SPLAT (written by Peter Draper and Margarida Castro Neves)
512 <a href="#ref_vosplat">[SPLAT]</a> uses utypes in serveral ways.</p>
514 <p>When processing an SSA response, it tries to locate the columns
515 interesting to it using utypes. The approach may be illustrated by a
516 comment in the code that states:</p>
518 <blockquote>The choices
519 are controlled by a series of regular expressions that can be extended as
520 needed, or by looking for the standard set of utypes defined by the IVOA
521 Spectral Data Model (1.0).</blockquote>
523 <p>— which is supposed to mean that, when UType
524 matching fails, some heuristics are applied to guess based on column names. The
525 UType match here is case insensitive, and to dodge the confusing specifications
526 on the first few elements of a utype,
527 SPLAT matches what might be described as suffix patterns. Among
528 the UType patterns matched in this way are: access.reference, access.format,
529 target.name, char.spectralaxis.name, char.fluxaxis.unit, and the
530 like.</p>
532 <p>Within a spectrum deemed compliant to the Spectral Data Model,
533 SPLAT tries to locate flux and
534 spectral axes as well as errors and units of those using utypes. Again, the
535 match is case insensitive and employs suffix rules.</p>
537 <p>When processing a spectrum in VOTable format, SPLAT searches for TABLE
538 elements with a UType "sed:Segment" to extract the corresponding data. This
539 search is case sensitive, and a full match is required; the
540 specification that inspired that behaviour has not made it to IVOA REC
541 yet.</p>
542 </div> <!-- subsubsection app-splat -->
544 <div class="section"><h4><a id="app-aladin" shape="rect"><span class="secnum">2.3.3. </span>Aladin</a></h4>
545 <p>Aladin (written by Pierre Fernique and others) <a href="#ref_aladin">[ALADIN]</a> employs utypes for:</p>
547 <ul>
548 <li>Finding and interpreting coordinate columns</li>
549 <li>Recognizing data content (VOTable signature)</li>
550 <li>Interpreting STC regions</li>
551 <li>Interpreting DAL SIA responses</li>
552 <li>Interpreting DAL SSA responses</li>
553 </ul>
555 <p>The full list of utypes required for each task is given in
556 <a href="#aladin-utypes">appendix A</a>.</p>
558 </div> <!-- subsubsection app-aladin -->
560 <div class="section"><h4><a id="app-vospec" shape="rect"><span class="secnum">2.3.4. </span>VOSpec</a></h4>
562 <p>VOSpec (written by Juan Gonzalez) <a href="#ref_vospec">[VOSpec]</a> uses utypes for:</p>
564 <ul>
565 <li>SSAP parsing: utypes are identified by direct string comparison of
566 fragments with the documented utypes, i.e., after converting the UType
567 found in the table to upper case, a check is made whether this UType
568 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
569 done in some cases to cope with severely non-compliant services.</li>
571 <li>SLAP parsing: In order to parse Simple Line Access Protocol
572 services (SLAP), instance documents are analyzed quite as for SSAP. In
573 this case, however, the comparison is done with the full utype specified
574 in SLAP as the services are more compliant than SSAP ones; utypes are
575 compared ignoring case.</li>
577 <li>Photometry Services parsing: Same as before — direct case insensitive
578 string comparison.</li>
580 <li> Spectral DM files in XML parsing: Case insensitive comparison with
581 utypes defined in Spectrum DM document.</li>
582 </ul>
584 <p>In summary, VOSpec uses utypes in case insensitive string comparison.
585 There is no evaluation of schema URLs, utype parsing, navigation or other
586 advanced utype features.</p>
587 </div> <!-- subsubsection VOSpec -->
589 <div class="section"><h4><a id="app-topcat" shape="rect"><span class="secnum">2.3.5. </span>TOPCAT/STILTS</a></h4>
591 <p>TOPCAT (written by Mark Taylor) <a href="#ref_topcat">[TOPCAT]</a>
592 distinguishes between three types of UType usage:</p>
594 <ul>
595 <li>Semantically aware usage of terms in the existing UType vocabulary/ies</li>
596 <li>Semantically unaware manipulation of UType strings</li>
597 <li>Places where utypes could/might/should be used but are not</li>
598 </ul>
601 <div class="section"><h4><a id="app-topcat-semaware"><span class="secnum"> </span>Semantically aware usage(s)</a></h4>
603 <p>The SSA "Access.Reference" utype is used to identify an initial guess
604 for the spectrum URL column whose contents will be passed to spectrum
605 viewers via SAMP when a View Spectrum activation action is selected.
606 When looking for the right column Utype, any prefix is ignored,
607 and a UType which endsWith(":Access.Reference") is preferred,
608 otherwise any one which endsWith("Access.Reference") is used.</p>
609 </div> <!-- app-topcat-semaware -->
611 <div class="section"><h4><a id="app-topcat-semunaware"><span class="secnum"> </span>Semantically unaware usages</a></h4>
614 <p>Utypes are read/written in various places by the table I/O layer.
615 Utypes are part of STIL's internal table model, and so UType values
616 which are associated with columns are read in and recorded from
617 table formats which support utypes, and the utypes are propagated
618 to output tables if the output format supports that. True support
619 for utypes is only provided in VOTable, but STIL has an internal
620 convention of using TUTYPnnn header cards for FITS tables analogous to
621 the FITS serialization of the spectral data model. In the
622 case of a UType which is too long to fit in a FITS header
623 (&gt;68 characters) the UType is not propagated to the output
624 (it is lost).</p>
626 <p>Utypes are displayed, and can be added/edited, in the TOPCAT GUI
627 for table columns and parameters.</p>
629 <p>One use of utypes propagated in this way is to address
630 table columns and parameters in algebraic
631 expressions using the following syntax:</p>
633 <blockquote>
634 The string "utype$" followed by the text of a UType identifying
635 the required value. Any punctuation (such as ".", ":", "-") in the
636 UType should be replaced with a "_" (since these symbols cannot
637 appear in identifiers). The first matching column, or if there is
638 none the first matching parameter value is returned. UType matching
639 is case-insensitive.
640 </blockquote>
642 <p>So for instance a column with the UType obscore:Target.Name
643 can be addressed using the expression "utype$obscore_target_name"
644 as an alternative to using the column name.</p>
646 <p>taplint (the TAP service validator) checks that utypes match between
647 TAP_SCHEMA and the /tables endpoint. It also checks that utypes are correct
648 for tables declaring themselves ObsCore.</p>
650 <p>The SAMP MType spectrum.load.ssa-generic requires all UCDs and utypes
651 to be bundled up as name/value pairs in the "meta" map. The
652 documentation at
653 <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>
654 says:</p>
655 <blockquote>
656 meta (map):
657 Additional metadata describing the spectral data found at
658 the URL. Key-&gt;Value pairs represent either utypes or UCDs as
659 defined or used in some version of the SSA specification or its
660 predecessors. Example map keys are Access.Format (SSA 1.0 MIME
661 type Utype) or VOX:Spectrum_Format (pre-1.0 SSA MIME type UCD). It
662 is up to the recipient to make sense of these and, for instance,
663 deal with the possibility that given expected keys are present
664 or that apparently contradictory information is presented. Most
665 existing SSA-aware spectrum viewing clients already contain this
666 functionality.
667 </blockquote>
669 <p>TOPCAT duly grabs these from table
670 columns and passes them on to spectrum viewers.</p>
672 <p>Finally, TOPCAT uses utypes internally when saving session state into
673 a VOTable. This uses private utypes in the topcat_session namespace:</p>
675 <ul>
676 <li>topcat_session:isTopcatModel</li>
677 <li>topcat_session:saveVersion</li>
678 <li>topcat_session:label</li>
679 <li>topcat_session:columnIndices</li>
680 <li>topcat_session:columnVisibilities</li>
681 <li>topcat_session:broadcastRows</li>
682 <li>topcat_session:rowSubsetFlags</li>
683 </ul>
684 <p>These are not intended to be comprehensible to anybody but the TOPCAT
685 application itself.</p>
687 </div> <!-- app-topcat-semunaware -->
689 <div class="section"><h4><a id="app-topcat-nonusage"><span class="secnum"> </span>Non-usages</a></h4>
691 <p>STILTS does not allow you to set/read utypes for columns/parameters
692 from the command line, though it does allow you to do that for UCDs.
693 Probably, it should do it for utypes.</p>
695 <p>STILTS/TOPCAT allows you to do multiple SSA (and SIA) positional
696 searches in the same way as multiple cone searches. As a non-essential
697 part of this, it attempts to find the actual sky position of the returned
698 spectrum — if it can do that it can report on how far away the spectrum
699 was from the request, and also figure out which is the closest match
700 in the event that there are more than one within the requested radius.
701 So it wants to work out RA and Dec from an SSA response, though if it
702 fails to do it, the multi-SSA still works.
703 It does <strong>not</strong> use utypes for this. Here is the comment from the code:</p>
704 <pre>
705 // Could work harder here (and for getDecIndex); the correct thing
706 // to do for SSA 1.04 would be to look for the column with
707 // utype ssa:Char.SpatialAxis.Coverage.Location.Value, and interpret
708 // this in conjunction with other STC-like columns to make sense
709 // of it as an ICRS position. Two problems here: 1 - STC; 2 - the
710 // spatialaxis.coverage column looks like a 2-element vector (at
711 // least in some SSA results), so it can't have a column index.
712 // Would need to redefine ConeSearcher interface so it gets
713 // something more flexible than a column interface, or in the
714 // performSearch method rejig the table so that it contained some
715 // new columns with ICRS RA &amp; Dec. Since I suspect SSA from
716 // ttools is going to be rather niche functionality, I don't think
717 // it's worth the effort just now.
718 </pre>
719 <p>Ad-hoc regex pattern matching on the column name is used instead.</p>
720 </div> <!-- app-topcat-nonusage -->
721 </div> <!-- subsubsection app-topcat -->
723 <div class="section"><h4><a id="app-saada" shape="rect"><span class="secnum">2.3.6. </span>Saada</a></h4>
725 <p>The principle of Saada <a href="#ref_saada">[SAADA]</a> is to
726 automatically ingest data files in a database. The built-in database
727 schema is flexible enough to allow users to load data without doing
728 any mapping. The consequence is that, by default, the database only
729 contains metadata found in input files. That is enough to build a
730 searchable repository, but not to build VO compliant services. For
731 that, native metadata must be enriched with quantities which are not
732 necessarily in data files: namely UCDs, units, utypes and
733 descriptions. These quantities can be set in metadata by a simple
734 drag &amp; drop (see Fig. 2). That is very relevant for UCDs and units
735 which can be used to query data (e.g. [phys.veloc] &gt; 1000 [km/s]).
736 Utypes can also be mapped that way but this operation remains out of
737 the scope of any data model.</p>
739 <div class="figure">
740 <img src="utypemapping.png" alt="Saada utype assignment" style="max-width:1145px" align="center"/>
741 <p class="figurecaption"><strong>Figure 2:</strong> UType mapping in Saada</p>
742 </div> <!-- figure -->
744 <p>Another tool allows mapping a model on a dataset.
745 Saada hosts inner VO model descriptions (just ObsCore right now) and DM fields can be mapped on real data.
746 The mapper shown in Fig. 3 binds DM fields with arithmetic operations on database columns.
747 The resulting mapping expressions are used by the Saada VO interface
748 to format the query results in a way compliant with the DM supported
749 by a given service. Utypes are used here to identify DM fields. They
750 are considered as simple strings without regards on their inner
751 structure.</p>
753 <div class="figure">
754 <img src="dmMapping.png" style="max-width:739px" alt="Saada data model mapping" align="center"/>
755 <p class="figurecaption"><strong>Figure 3:</strong> DM mapping in Saada</p>
756 </div> <!-- figure -->
758 <p>In the Saada query engine constrains can be expressed with utypes, quite
759 in analogy with UCDs.</p>
761 </div> <!-- subsubsection app-saada -->
763 <div class="subsubsection">
764 <h4><a id="app-iris" shape="rect"><span class="secnum">2.3.7. </span>Iris</a></h4>
766 <p>Iris <a href="#ref_iris">[IRIS]</a> is designed on a stack of
767 abstraction layers around a common framework that allows easy
768 extensibility via plugins. This is realized by SEDLib which provides:</p>
770 <ul>
771 <li>basic SED I/O capabilities for VOTable and FITS serializations</li>
772 <li>SEDs and Segments as first class objects, with a relatively low-level library</li>
773 </ul>
775 <p>The library implements the Spectrum 1.03 Data Model and it is used
776 by components up in the framework layers ladder to abstract the
777 components themselves from the details of the serialization. In
778 particular, SEDLib implements the Data Model described by the XML
779 schema, which is not equivalent to the UML diagrams in the Spectrum 1.03 document, but is more suited to a concrete implementation.</p>
781 <p>Utypes are used to map the Spectra/SED VOTable metadata to the DM
782 implemented by SEDLib. All the UTyped values are made available by
783 SEDLib in a Sed class instance. Thus, users can browse all the metadata
784 in a more consistent way: all the values that refer to the same concept
785 (i.e. utypes without the prefix are the same) are displayed in the same
786 column in the metadata browser, and users can build boolean expressions
787 to filter their data. Also, all the components (either native or from
788 third party plugins) can programmatically access, as input/output, all
789 the values in the original file, thus adding science capabilities to
790 Iris.</p>
792 <p>The utypes prefix ("namespace") is ignored when comparing utypes,
793 but it is used (as "spec:") when writing out the files. Note that, in
794 accordance with Spectrum 1.1, only utypes with the spec prefix are
795 interpreted as part of the Spectrum DM, even though Spectrum 1.1
796 imports classes from the CharDM (prefix char), which in turn imports
797 STC classes (prefix stc). As a result, even though the classes, in
798 most cases, are the same, stc: and char: utypes are not interpreted,
799 unless the unprefixed utypes were the same; this is never the case for
800 Spectrum 1.1, because the *:Spectrum.* pattern that spoils the blind
801 string comparison.</p>
803 <p>Utypes are used in conjunction with UCDs for discriminating between
804 different spectral quantities and perform consistency checks. For
805 instance, when a segment’s FluxAxis represents a quantity that can’t be
806 converted to the quantities of the other segments in a SED, an exception
807 is thrown when one tries to add that segment to the SED.</p>
809 <p>Some services (notably NED) add some utypes for tagging metadata
810 related to the provenance of the data (e.g. the bibcode reference to
811 the paper whence the data has been drawn). This information is
812 available in SEDLib, but in order to be used (e.g. by plugins
813 dedicated to those services) they must be accessed using the utypes
814 string. In compliance with the assumption that utypes should not be
815 parsed, and in the absence of a proper extensibility specification, the
816 use of this metadata is naïve. Nonetheless, custom metadata is shown to
817 the user and can be used for filtering purposes.</p>
819 <p>Several changes will need to be made when Iris is updated to the
820 Spectral 2.0 DM: the UType namespace will change and all the Spectrum
821 1.1 utypes will be replicated with a different prefix: "sdm". All the
822 utypes in Spectrum 1.1 will be changed by removing the Spectrum string.</p>
824 </div> <!-- subsubsection app-iris -->
826 </div> <!-- subsection Applications -->
829 <div class="section"><h3><a id="reg" shape="rect"><span class="secnum">2.4. </span>Registry</a></h3>
831 <p>The VODataService 1.1 <a href="#ref_vods">[VODS]</a> standard allows
832 utypes on schemas, tables, columns, and foreign keys (this is analogous to
833 TAP_SCHEMA; cf. section <span class="xref"><a href="#dal">2.2</a></span>). The UType element
834 is defined to be of type xs:token.</p>
836 <p>Comments in the XML schema indicate that from the point of view
837 of VODataService, a UType on a schema is
838 "an identifier for a concept in a data model that the data in
839 this schema as a whole represent". Utypes on a foreign key are defined
840 as "an identifier
841 for a concept in a data model that the association enabled by this key
842 represents", on tables as "an identifier for a concept in a data model
843 that the data in this table represent". In each case, VODataService
844 states that the "format defined in the VOTable standard is highly
845 recommended."</p>
847 <p>No means of associating prefixes with URIs or providing further
848 structure is given. Nothing is said on case normalization.</p>
851 <p>A working draft for the relational registry 2 <a 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>
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>
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>
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 -->
882 <div class="section"><h3><a id="sem" shape="rect"><span class="secnum">2.5. </span>Semantics</a></h3>
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>
892 </div> <!-- subsection sem -->
895 <div class="section"><h3><a id="voe" shape="rect"><span class="secnum">2.6. </span>VOEvent</a></h3>
897 <p>TimeSeries representation to identify concepts in TimeSeries DM.
898 This works rather as discussed above for VOTables.</p>
900 </div> <!-- subsection voe -->
902 <div class="section"><h3><a id="d2e927"><span class="secnum">2.7. </span>Grid and Web Services</a></h3>
903 <p>The specifications put forward by the Grid and Web Services Working Group
904 make no use or mention of utypes in any of its specifications.</p>
905 </div> <!-- subsection gws -->
906 </div> <!-- section current usages -->
908 <div class="section"><h2><a id="assessment" shape="rect"><span class="secnum">3. </span>Assessment</a></h2>
910 <p>The following is a redacted collection of critique that was raised to
911 or within the Utypes Tiger Team. That a given point is discussed here
912 does not necessarily mean all Tiger Team members agree that a given
913 issue is serious or is an issue at all, even where no concrete source is
914 indicated.</p>
916 <p>Probably the most common complaint is that the definition of utypes
917 has been at least bewildering, which lead to one and the same thing
918 being referred to by several utypes. Part of this results from evolving
919 or unclear standards; as an example, spec:Target.Name,
920 spec:Spectrum.Target.Name and sdm:Target.Name were, are, or will be
921 designations for something that has not changed in the underlying data
922 models.</p>
924 <p>Partly as a consequence of this, most services using utypes are
925 non-compliant to some degree <a href="#ref_ssastate">[SSASTATE]</a>,
926 which again gave client implementors a hard time and lead to a variety
927 of practices of suffix and/or infix matching, typically not even
928 consistently applied even within one code base.</p>
930 <p>There has also been an expectation that when, e.g., both Obscore and
931 Spectral talk about, say, the DID assigned by a publisher, the utype
932 used by both should be identical, either with or without the prefix.
933 Against that has been raised that utypes are not concept labels as UCDs
934 but something linked to a concrete data model. With data models
935 different, the utypes should be different, too.</p>
937 <p>On the other hand, developers voiced a demand for consistent markup
938 of classes wherever they turn up; for instance, within certain versions
939 of the spectral data model, accuracy can be modeled as a single class
940 with a eight attributes. There are, however, more than a hundred utypes
941 matching <code>spec:*.Accuracy.*</code>, all eventually mapping
942 to these eighte attributes, which is considered wasteful by some.</p>
944 <p>Directly connected to the syntax of utypes is an uncertainty whether
945 the "prefix" is significant when comparing utypes or must, rather, be
946 ignored. It appears the intention of, e.g., the authors of SSAP and the
947 spectral data model has been that comparisons would in general ignore
948 the prefix, while the STC-in-VOTable note quite strongly indicates that
949 usual clients should never have to dissect the utype string. Also,
950 while the notion that utypes are to be compared ignoring case is at
951 least very widespread, discussions about specific spellings repeatedly
952 came up, confusing implementors.</p>
954 <p>There has also been debate on whether plain sequences of utype-value
955 pairs should be able to represent more complex data structures, e.g.,
956 ordered sequences or sequences of complex objects. This lead to
957 proposed syntaxes like foo.bar.n, foo.bar[n], and foo.bar[n].quux. At
958 least Aladin still understands some utypes formed like this, but it
959 seems the notion of coding complex instance structure in this way
960 never really caught on.</p>
962 <p>Against the proposal to annotate VOTable FIELDs using FIELDrefs from
963 GROUPs, some implementors objected the usage of GROUP and the ample
964 referencing required an application to memorize a fairly large number of
965 things.</p>
967 <p>Another topic of concern is the applicability of the utypes mechanism
968 to FITS files; a suggestion on how this might work was made in the
969 context of the spectral data model (see above). Against this it was
970 argued that for values encoded in the FITS header, an arbitrary 8-char
971 keyword must be mapped to a utype, where the term "arbitrary" here means
972 that there is no algorithmic mapping between data model roles and FITS
973 keywords. In the concrete example of the SDM, the relationship between
974 VOTable utypes and FITS keywords is also degenerate, because in
975 VOTables, some fields can have different values in, e.g., the Data and
976 Char section, while in FITS some Char fields are inherited from
977 Data.</p>
979 <p>A consequence of the ad-hoc nature of relating header keywords and
980 data model elements is that a
981 trivial round-tripping of compliant files by model unaware programs
982 spoils the compliance of the file itself. For example, if the user uses
983 TOPCAT to discover a SED from the NED SED service, and then saves it as
984 a FITS, the file is not compliant anymore. A related problem turns up when a
985 compliant FITS spectrum is saved to VOTable by a model-unaware
986 application. Note that the information loss depends on whether
987 certain piece of metadata is contained in a column or in a parameter
988 inside the header. For columns, the TUTYPn convention allows utypes to
989 be linked to columns, but this is not possible for header keywords.</p>
991 </div> <!-- section assessement -->
994 <div class="section-nonum"><h2><a id="changes" shape="rect"><span class="secnum"/>Changes from Previous Versions</a></h2>
996 <div class="section-nonum"><h2><a id="changes-1.0"><span class="secnum"/>Changes from version 1.0</a></h2>
997 <ul>
998 <li>Expanded coverage on Spectral and ObsCore DMs</li>
999 <li>Extracted assements from the report part to a special section.</li>
1000 </ul>
1001 </div> <!-- changes-1.0 -->
1002 </div> <!-- changes -->
1006 <div class="section-nonum"><h2><a id="references" shape="rect"><span class="secnum"/>References</a></h2>
1008 <ul class="references">
1009 <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>
1010 <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>
1011 <li id="ref_ridraft">[REGTAP], Demleitner, M, et al, 2013: <a href="http://docs.g-vo.org/ridraft">IVOA Registry Relational Schema</a>,
1012 Registry WG Working Draft 5 March 2013</li>
1013 <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>
1014 <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
1015 &gt; serializing Data models instances</a>, Version 0.7, IVOA Working Draft</li>
1016 <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>
1017 <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>
1018 <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>
1019 <li id="ref_aladin">[ALADIN], Pierre Fernique, <a href="http://aladin.u-strasbg.fr">http://aladin.u-strasbg.fr</a></li>
1020 <li id="ref_ObsCore">[ObsCore], Doug Tody, Alberto Micol, Daniel
1021 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>
1022 <li id="ref_photnote">[PHOTNOTE], Derriere, S., 2010:
1023 <a href="http://www.ivoa.net/internal/IVOA/PhotometryDataModel/NOTE-PPDMDesc-0.1-20101202.pdf">Providing
1024 Photometric Data Measurements Description in VOTables</a>, Version 0.1,
1025 IVOA Draft Note.</li>
1026 </ul>
1028 </div> <!-- references -->
1030 <div class="appendix">
1031 <h2><a id="aladin-utypes">Appendix A:
1032 Specific UType usage in Aladin</a></h2>
1034 <p>Here is a list of all utypes that Aladin interprets as of late 2012:</p>
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>
1117 </div> <!-- appendixA -->
1119 </div><!-- class="body" -->
1120 </body></html><!-- vi: enc=utf-8:sw=2:et:sta
1121 -->


Name Value
svn:mime-type text/html

ViewVC Help
Powered by ViewVC 1.1.26