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

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