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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 2122 - (show annotations)
Mon Apr 22 08:53:36 2013 UTC (8 years, 6 months ago) by volute@g-vo.org
File MIME type: text/html
File size: 53844 byte(s)
current usage: a bit more on obscore.

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

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