Utypes Tiger Team

Utypes Use Cases

• UC #1. Serialize DM instances into a file
• UC #2. Deserialize a DM instance from a file
• UC #3. Embed STC information into VOTables
  • UC #3.1. Embed STC information in FITS
• UC #4. Provide an abstract (de)serialization strategy that can work with any expressive enough file format. A client can instantiate an object equivalent to the object that was originally serialized
  • UC #4.1 Trivial roundtripping
• UC #5. Link columns in a relational model of the registry to VOResource schema elements
• UC #6. Tag metadata in a DAL query response
• UC #7. Render datasets/archives VO-compliant
• UC #8. Extensions of standard DMs
• UC #9. Support serialization of multiple instances of the same DM class
• UC #10. Standard, machine readable DM description
  • UC #10.1 Versioning of DM descriptions
  • UC #10.2 DM descriptions should express relationships between DMs (reuse, extensions)
• UC #11. Documentation of DM fields
• UC #12. Query archives by DM attribute (e.g. by observation’s target name)

Current Practices and Uses

Spectrum 1.1 REC, Quality Flags: FluxAxis.Quality.n, where n is an integer. (Parsable? Anyway this is gone in Spectral 2.0)

Photometry 1.0 PR, Access class: “we use the Access class defined in ObsTAP and inherited from SSA” -> PhotometryFilter.transmissionCurve.Access.*

Photometry 1.0 PR, Spectrum is imported using the spec namespace (notice the difference with the previous approach).

Namespace (in several DMs): the namespace must be parsed out of the Utype string… but then again which is the actual Utype string?

Extensibility (e.g. NED SED): FluxAxis.Published.Value: is this Utype by any chance related to the standard FluxAxis or to Target.Name? (How can I infer it?)

Introduced as an attribute for FIELD and PARAM in VOTable 1.2:

• Maps FIELD/PARAM to a DM attribute
• Encourages use of the XML namespace convention for avoiding name collisions
• Encourages use of the XML xmlns for linking to the DM
• Highlights the usefulness of utypes for space-time coordinates and provides an example

for STC

• Does not say anything about parsability

Redefined in SSA 1.1:

• The goal of utypes is to “flatten a hierarchical data model so that all fields are represented

by fixed strings in a flat namespace”

• They are introduced as “fixed” strings, but no explanation is given on the meaning of

“fixed”.

• “Of course, if a data model becomes complex enough this will no longer be possible”
• Introduces a serialization mechanism for multiple instances (multiple equal Utypes in the

same file), providing an example using serialization specific features, for VOTable.

• Does not say anything explicit about parsability, however…
• In others sections (e.g. query response metadata) other features are introduced:

Utype is built with the pseudo-grammar “<component-name>”.”<field-name>”

spec:Spectrum.Target.Name and ssa:Target.Name are the same thing.

• More information about utypes in Section 4.2.7 (Metadata Extension Mechanism)

Redefined in Spectrum 1.1, also introducing Data Model inheritance:

• Analogy with XPATH (‘.’ instead of ‘/’). “a.b.c.d”, dots indicate “has-a” relationship (3.5)
• ‘Data Model Field’ and ‘Utype’ interchangeable (3.5)
• “Other IVOA standards may use a different prefix instead of “Spectrum.” … This

represents Data Model inheritance.” (3.5)

• “the utypes can be used to infer the data model structure” (8.2)

Most DMs define utypes in tables, using different conventions

Utypes strings can change when DMs are reused. Also, the namespace changes globally for each DM (spec:Target.Name, ssa:Target.Name)

Utypes are only partially used in FITS serializations: they can be used for columns, not for parameters: in this case, an arbitrary 8 char string is provided by the DM document.

DMs do not define an “xmlns” link to the DM URI