ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1820 - (show annotations)
Thu Sep 20 14:18:27 2012 UTC (9 years, 1 month ago) by gerard.lemson
File MIME type: text/html
File size: 27190 byte(s)
UPdate to section on simulation data model specifics.
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"/>
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"/>
14 <style type="text/css" xml:space="preserve">
16 code {
17 font-weight: bold;
18 font-family: monospace
19 }
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 }
31 div.admonition:before {
32 content: 'Note';
33 font-weight: bold;
34 }
36 body {
37 counter-reset: section;
38 counter-reset: toc_section;
39 }
41 .figurecaption {
42 margin-bottom: 4ex;
43 }
45 .figure img {
46 position: relative;
47 width: 100%;
48 }
50 p.caption {
51 font-style: italic;
52 }
54 .redax {
55 background-color: #FFFF90;
56 font-style: italic;
57 }
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>
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>
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/>
138 <h2>Abstract</h2>
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>
145 <h2>Status of this Document</h2>
147 <p id="statusdecl"></p>
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>
154 <h2 class="prologue-heading-western">Acknowledgments</h2>
156 <p>This document has been developed with support from ...</p>
159 <h2>Contents</h2>
160 <?toc?>
162 </div><!-- class="head" -->
164 <div class="body">
166 <div class="section"><h2><a id="introduction" shape="rect"/><span class="secnum">1. </span>Introduction</h2>
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>
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 -->
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 to assess the impact
194 of proposed solutions on current practices.
195 This document aims to provide such a summary. </p>
197 </div> <!-- section introduction -->
199 <div class="section"><h2><a id="currentusages" shape="rect"/><span
200 class="secnum">2. </span>Current usages</h2>
202 <p>The current usages and practices regarding UTypes may be presented
203 in several ways, e.g., by specification (VOTable, ObsCore, etc.) or by
204 application (TOPCAT, IRIS, etc.). One useful perspective is to
205 consider UTypes from an IVOA Working Group standpoint, i.e., their
206 usages within specific subdomains of VO activity, which is the
207 approach we have taken in this summary. </p>
209 <div class="section"><h3><a id="dm" shape="rect"/><span
210 class="secnum">2.1. </span>Data Models</h3>
212 <p>Unsurprisingly the bulk of usages and practices of usage arise in
213 the various data models defined by the DM Working Group, with most
214 defining UTypes in tables using different conventions.</p>
218 <div class="section"><h4><a id="definition" shape="rect"/><span
219 class="secnum">2.1.1. </span>Definition</h4>
221 <p>The Spectrum DM 1.1 <a href="#ref_spec1.1">[Spectrum1.1]</a>
222 defines a UType as a standard identifier for a data model
223 field. They are case-insensitive and of the form "a.b.c.d" where "the dots
224 indicate a 'has-a' hierarchy with the leftmost element being the
225 containing model and the rightmost element being the lowest level
226 element referred to". Although there are similarities with XPath,
227 it is stressed that the UType does not indicate the exact position of
228 an element in an instance but is merely a label for a data model
229 field. Note, however, that unique UTypes within a group in a VOTable
230 serialization of a Spectrum "can be used to infer the data-model structure".</p>
232 <p>An enumeration syntax is also suggested for multiple instances of
233 the same UType: "Data.FluxAxis.Quality.n" where n is an integer.</p>
235 <p>The Photometry DM 1.0 <a href="#ref_phot1.0">[PHOT]</a> defines
236 its UTypes "following the IVOA rules applied for other IVOA data
237 models and derived from a simplified XML schema." The form of a
238 UType is now "ns:a.b.c.d" where the element before the colon - 'ns'
239 - identifies the data model being used.</p>
241 <p>The ObsCore DM 1.0 <a href="#ref_obsccore1.0">[OBSCORE]</a>
242 defines a convention that UTypes created from the UML ObsCore model
243 follow a Camel case syntax with "attributes of a class starting with
244 a lower case letter."</p>
246 <p>The Characterisation DM 1.0 <a href="#ref_char1.0">[CHAR]</a>
247 specifies that "UTypes are built from the XML schema representation
248 of the model which already enforces a hierarchical structure" using
249 the "a.b.c.d" form. The constructed string is "based on instance
250 variable paths in the object-oriented data model." The difference
251 between this and an XPath approach is that a UType may use
252 "constrained element (or attribute) values in its path".</p>
254 <p>The Simulation DM 1.0 <a href="#ref_simdm1.0">[SIM]</a> states
255 that a UType is a "pointer into a data model" and that it "should
256 allow one to uniquely identify a concept in a data model". It notes
257 that it has become common practice for IVOA data models to provide a
258 list of UTypes that they are defining. It then specifies a set of
259 rules for deriving UTypes directly from a UML data model rather than
260 as a separate process:</p>
262 <pre>
263 UType := [model-UType | package-UType | class-UType |
264 attribute-UType | collection-UType |
265 reference-UType | container-UType
266 model-UType := &lt;model-name>
267 package-UType := model-UType ":/" package-hierarchy
268 package-hierarchy := &lt;package-name> ["/" &lt;package-name>]*
269 class-UType := package-UType "/" &lt;class-name>
270 attribute-UType := class-UType "." attribute
271 attribute := [primitive-attr | struct-attr]
272 primitive-attr := &lt;attribute-name>
273 struct-attr := &lt;attribute-name> "." attribute
274 collection-UType := class-UType "." &lt;collection-name>
275 reference-UType := class-UType "." &lt;reference-name>
276 container-UType := class-UType "." "CONTAINER"
277 identifier-UType := class-UType "." "ID"
278 </pre>
281 </div>
282 <div class="section"><h4><a id="inheritance" shape="rect"/><span
283 class="secnum">2.1.2. </span>Inheritance</h4>
285 <p>The Spectrum DM 1.1 implies that when data models are inherited,
286 UTypes with the same form except for the leftmost element
287 (identifying the model) are equivalent: "we say that SSA inherits
288 the Spectrum model, so that 'SSA.' UTypes overlap with the Spectrum
289 ones.". An unnoted consequence of this is that the same concept
290 across data models must have the same 'b.c.d' identifier.</p>
292 <p>The Photometry DM seems to take this even further by using the
293 "Access class defined in ObsTAP and inherited from SSA" but tacking
294 it onto "PhotometryFilter.transmissionCurve",
295 viz. PhotometryFilter.transmissionCurve.Access.*. This implies that
296 field names must be unique across data models.
297 </p>
299 <p>Note, however, that the top level use of Spectrum from the Spectrum
300 DM must be denoted using the "spec:" namespace.</p>
302 </div>
303 <div class="section"><h4><a id="extensibility" shape="rect"/><span
304 class="secnum">2.1.3. </span>Extensibility</h4>
306 <p>Although not actually laid out in standards documents, discussion within
307 the IVOA has frequently addressed user-extensability of data models and,
308 by extension, UTypes. A simple example of how this should work is
309 NED SEDs that use <code>FluxAxis.Published.Value</code>, which is
310 supposed to be related to the standard
311 standard FluxAxis element.
312 Unique field names across all data models would solve part of this
313 problem.</p>
314 </div>
316 <div class="section">
317 <h4><a id="simdm" shape="rect">Simulation Data Model Specifics</a></h4>
319 <p>The Simulation Data Model (SimDM) interprets UTypes as pointers into a data model.
320 It does not state that that is what they should be.
321 The UTYPEs in SimDM are generated <i>and</i>used. The
322 <a href="http://ivoa.net/Documents/SimDM/20120503/html/SimDM.html">HTML document
323 with the detailed
324 documentation</a> of the data model has the list of UTypes at the end. But in
325 particular each concept defined there has an anchor built from the UType.
326 Therefore <a href="http://ivoa.net/Documents/SimDM/20120503/html/SimDM.html#SimDM:/resource/experiment/Simulation.appliedPhysics">http://ivoa.net/Documents/SimDM/20120503/html/SimDM.html#SimDM:/resource/experiment/Simulation.appliedPhysics</a>
327 , built from (HTML doc location)+'#'+UTYPE
328 will lead one directly to the documentation for the corresponding concept in
329 the HTML doc.</p>
331 <p>NB The same concept is also reachable by attaching an opaque identifier to the root
332 URL, e.g.
333 http://ivoa.net/Documents/SimDM/20120503/html/SimDM.html#_14_0_8e0028f_12028
334 19509828_742596_1632.
335 This URL is also a pointer into the data model and could be seen as an
336 alternative, non-human readable UType.
337 This is in line with the definition of UTypes that Norman Gray has been
338 arguing for [REF needed].</p>
340 <p>The HTML doc and most of the other documents accompanying the data
341 model (see section 6.1 in the
342 <a href="http://www.ivoa.net/Documents/SimDM/20120503/REC-SimulationDataModel-1.00-20120503.pdf">Simulation Data Model REC</a>)
343 have been generated from what we have started calling the ".vo-urp
344 representation" of the data model. This representation (formerly called "intermediate representation") can be found in
345 <a href="http://ivoa.net/Documents/SimDM/20120503/uml/SimDM_INTERMEDIATE.xml"
346 >http://ivoa.net/Documents/SimDM/20120503/uml/SimDM_INTERMEDIATE.xml</a>.
347 That document itself was generated from the XMI representation of the UML
348 model created using MagicDraw CE 12.1, but could be written by hand if need
349 be. It defines the data model concepts formally, in machine readable XML, and amongst
350 others associates the UType and identifier (the xmiid attribute) to each
351 concept.</p>
353 <p>The generation of the documents is performed using the VO-URP framework/tool
354 developed by Laurent Bourges and Gerard Lemson, see
355 <a href="http://code.google.com/p/vo-urp/">http://code.google.com/p/vo-urp/</a>. This tool has some other UType-related
356 features.
357 For example VO-URP can also build a web application giving access to a
358 relational database containing instances of the SimDM model. See
359 <a href="http://galformod.mpa-garching.mpg.de/dev/SimDM-browser"
360 >http://galformod.mpa-garching.mpg.de/dev/SimDM-browser</a>
361 for a prototype with not too much data inside.
362 This web app contains an SQL query interface that has TAP metadata
363 describing the schema
364 (<a href="http://galformod.mpa-garching.mpg.de/dev/SimDM-browser/Query.do">http://galformod.mpa-garching.mpg.de/dev/SimDM-browser/Query.do</a>).</p>
366 <p>The tables and columns in the metadata have been assigned the UType of the
367 class/attribute/reference they represent in the RDB representation of the
368 model. As the relational schema is a faithful(1-1) representation of the
369 data model (including inheritance!), the interpretation of UTypes is without
370 problems, even for tables.</p>
372 <p>Note that it is the meta-model for the .vo-urp representation (currently
373 represented as a UML profile as well as an XML schema) that defines the
374 modeling concepts used in the UTYPE "grammar" that is used to generate UTYPE-s and
375 taken over by Mireille Louys in the old UTYPE WD. Also all the mappings we use in
376 our generation pipeline, such as our OR mapping from .vo-urp to RDM, our
377 mapping from .vo-urp to XSD, our mapping from .vo-urp to Java etc, are all
378 defined at the meta-model level.
379 Without such a meta-model, acting as the common language by
380 which we express our data models, it will be difficult to formalize such data
381 model mappings, or formalizing what is meant by "pointing into a data model".</p>
383 <p>It would be good to consider, whatever we decide UTYPE-s are going to be, whether for
384 interoperability we need to have such a common language in which we express
385 our data models. This could be one of the results of the UTYPEs effort.
386 To show that this is all not revolutionary stuff, consider the <a href="http://www.omg.org/mof/">Meta Object Facility (MPF) spec of the Object
387 Management Group</a> which uses this approach, and which is used in the
388 Eclipse Modeling Framework.</p>
389 </div> <!-- subsubsection simdb -->
391 </div> <!-- subsection dm -->
394 <div class="section"><h3><a id="dal" shape="rect"/><span
395 class="secnum">2.2. </span>Data Access Layer</h3>
397 <p>SSA 1.1 <a href="#ref_ssa">[SSA]</a> defines UTypes as "pointers to
398 data model elements" and a mechanism
399 to "flatten a hierarchical data model so that all fields are
400 represented by fixed strings in a flat namespace." It notes,
401 however, that "if a data model becomes complex enough this will no
402 longer be possible." A mechanism is described for having multiple
403 equal UTypes in the same file, e.g., when serializing multiple
404 instances of a component data model as a VOTable.</p>
406 <p>Although nothing is explicitly said about UTypes being parsable,
407 this is certainly implied by the pseudo-grammar defined with a UType
408 being constructed using "embedded period characters to delimit the
409 fields of the UType". UTypes are defined within a single namespace
410 identifying the data model with the form "(component-name).(field-name)"
411 and are unique only within the context of the specified data model.
412 However, a convention is also described whereby concepts that are
413 common to both the Spectrum DM and the SSA query response do not
414 require the "spectrum." identifier when used in the SSA query
415 response; hence "Spectrum.Target.Name" and "Target.Name" are
416 equivalent in this particular context. </p>
418 <p>UTypes are also case-insensitive.</p>
420 <p>A 2011 survey of UType practices in SSA response documents showed rather
421 inconsistent results <a href="#ref_ssastate">[SSASTATE]</a>.</p>
423 <p>In <a href="#ref_tap">TAP</a>, UTypes enter as columns in TAP_SCHEMA.
424 They can be assigned to schemas, tables, columns, and foreign keys (this is analogous
425 to VODataService; cf. Registry). UTypes for columns are already used by
426 Obscore. No further details are given on the content of the columns
427 containing UTypes by the TAP specification, but obviously at least these
428 particular UTypes will have to work as simple, and presumably opaque,
429 strings if they are to be useful in SQL queries.</p>
431 </div>
432 <div class="section"><h3><a id="apps" shape="rect"/><span
433 class="secnum">2.3. </span>Applications</h3>
435 <p>UTypes were introduced as an attribute of many VOTable elements in
436 VOTable 1.1 <a href="#ref_votable1.1">[VOT1.1]</a> (FIELD, PARAM,
437 FIELDref, PARAMref, RESOURCE, TABLE, and GROUP) as an identifier for
438 something in an external data model. They should have the form
439 "datamodel_identifier:role_identifier". Although the schema defines
440 UType to have a non-namespaced value, the VOTable REC recommends to
441 use "the xmlns convention which specifies the URI of the data model
442 cited", referring to an example along the lines of:</p>
443 <pre xml:space="preserve"> &lt;VOTABLE
444 version="1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
445 xmlns="http://www.ivoa.net/xml/VOTable/v1.2"
446 xmlns:stc="http://www.ivoa.net/xml/STC/v1.30" > ... &lt;FIELD
447 name="RA" ID="col1" ucd="pos.eq.ra;meta.main" ref="J2000"
448 UType="stc:AstroCoords.Position2D.Value2.C1" datatype="float"
449 width="6" precision="2" unit="deg"/> ... </pre>
451 <p>The IVOA Note "Referencing STC in VOTable" <a
452 href="#ref_votstc">[VOTSTC]</a> suggests embedding space-time coordinate
453 metadata in VOTables by means of references to FIELDs and PARAMs. These
454 references are kept in GROUPs with a defined UType. Each group should
455 define the data model used via a specific &lt;prefix&gt;DataModel.URI
456 UType (which entails that the data model name is significant and
457 role_identifiers from different data models do not mean the same thing).
458 Abusing XML namespace declaration for the purpose of binding data model
459 names to URIs is explicitely discouraged.</p>
461 <p>The UTypes themselves are defined essentially through XPaths into
462 STC-X instance documents, although child element and attribute names are
463 treated analogously (i.e., <code>&lt;elem attr="bla"/&gt;</code> and
464 <code>&lt;elem&gt;&lt;attr&gt;bla&lt;/attr&gt;&lt;/elem&gt;</code> are
465 not distinguished), and some special rules apply to deal with the substitution
466 groups of STC-X.</p>
468 <p>Adoption of "Referencing STC in VOTable" has been moderate so far.</p>
470 </div>
473 <div class="section"><h3><a id="reg" shape="rect"/><span class="secnum">2.4. </span>Registry</h3>
475 <p>The VODataService 1.1 <a href="#ref_vods">[VODS]</a> standard allows
476 UTypes on schemas, tables, columns, and foreign keys (this is analogous to
477 TAP_SCHEMA; cf. section <span class="xref">dal</span>). The UType element
478 is defined to be of type xs:token.</p>
480 <p>Comments in the XML schema indicate that from the point of view
481 of VODataService, a UType on a schema is
482 "an identifier for a concept in a data model that the data in
483 this schema as a whole represent". UTypes on a foreign key are defined
484 as "an identifier
485 for a concept in a data model that the association enabled by this key
486 represents", on tables as "an identifier for a concept in a data model
487 that the data in this table represent". In each case, VODataService
488 states that the "format defined in the VOTable standard is highly
489 recommended."</p>
491 <p>No means of associating prefixes with URIs or providing further
492 structure is given. Nothing is said on case normalization.</p>
495 <p>An internal working draft for Registry Interfaces 2 <a
496 href="#ref_ri2">[RI2]</a> employs UTypes to</p>
497 <ol>
498 <li>link the VOResource data model as defined by the collection of the
499 related XML schema documents with columns in a set of database
500 tables</li>
501 <li>allow a representation of (fairly simple) VOResource extensions
502 without having to explicitely model all aspects of them.</li>
503 </ol>
505 <p>Generating UTypes for the RI2 columns and tables is done via XSLT
506 that operates on XSD (the XSLT will fail for certain authoring ways that
507 do not occur in VOResource), but conceptually follows the model of
508 <a href="#ref_votstc">[VOTSTC]</a>, where UTypes are (relative) XPaths.
509 For VOResource case, RI2 allows three roots (Resource, Capability, and
510 Interface).</p>
512 <p>To avoid having to redefine the table structure for every VOResource
513 extension newly defined, RI2 has a table mapping pairs of resource IVORN
514 and UType to string values. The UTypes are computed as above; the
515 computability is convenient since it avoids the requirement for authors
516 of VOResource extensions to manually define UTypes.</p>
518 <p>RI2 requires lowercasing UTypes on ingestion to ensure that
519 case-insensitive matching is possible although ADQL has no operator
520 reliably doing case-insensitive string comparisons. In other words, RI2
521 assumes that UTypes are case insensitive.</p>
522 </div> <!-- subsection reg -->
525 <div class="section"><h3><a id="sem" shape="rect"/><span class="secnum">2.5. </span>Semantics</h3>
527 Used in VOUnits to tie quantity with concept.
529 </div> <!-- subsection sem -->
532 <div class="section"><h3><a id="voe" shape="rect"/><span class="secnum">2.6. </span>VOEvent</h3>
534 TimeSeries representation to identify concepts in TimeSeries DM.
536 </div> <!-- subsection voe -->
538 <div class="section">
539 <h3 id="gws">Grid and Web Services</h3>
540 <p>The specifications put forward by the Grid and Web Services Working Group
541 make no use or mention of UTypes in any of its specifications.</p>
542 </div> <!-- subsection gws -->
543 </div> <!-- section current usages -->
545 <div class="section"><h2><a id="conflicts" shape="rect"/><span class="secnum">3. </span>Conflicts</h2>
547 <p>The previous section clearly demonstrates that there are a number
548 of conflicting usage practices within the IVOA regarding UTypes.</p>
549 <ul>
550 <li>Syntax: ns:a.b.c.d vs. a.b.c.d</li>
551 <li>Case-insensitive vs. Camel case</li>
552 <li>Uniqueness vs. non-uniqueness of a, b, c, d across data models</li>
553 <li>Parsable (pointer) vs. non-parsable (label)</li>
554 <li>Where to give a data model URI: xmlns? prefix:DataModel.URI? Not at all?</li>
555 </ul>
557 </div> <!-- section conflicts -->
560 <div class="section-nonum"><h2><a id="changes" shape="rect"/><span class="secnum"/>Changes from Previous Versions</h2>
562 </div> <!-- changes -->
566 <div class="section-nonum"><h2><a id="references" shape="rect"/><span class="secnum"/>References</h2>
568 <ul class="references">
569 <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>
570 <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>
571 <li id="ref_votstc">[RI2], Demleitner, M, et al, 2012: <a
572 href="http://docs.g-vo.org/ridraft">Registry Interfaces Version 2</a>,
573 Registry WG Internal Working Draft</li>
574 <li id="ref_UTypes">[UTypes], Mireille Louys, ... (eds), 2008: <a href="http://www.ivoa.net/Documents/latest/UTypes.html" shape="rect">UTypes</a>, Version 0.4, IVOA Working Draft</li>
575 <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>
576 <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>
577 <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>
578 </ul>
580 </div> <!-- references -->
581 </div><!-- class="body" -->
582 </body></html>
583 <!-- vi: enc=utf-8:sw=2:et:sta
584 -->

ViewVC Help
Powered by ViewVC 1.1.26