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

Minutes of telecon 2012-08-21

Persons present: Omar, Markus, Gerard, Matthew, Patrick

Points discussed (not in temporal order):

Starting with a clean slate as far as the current working draft is concerned (while harvesting from the current text what's useful): None of the persons present object.

But: We'll have to first come up with a report that summarizes current usage of utypes (plus, when we have a better idea of where we want to go, the impact of any changes to current practice). Matthew volunteers to edit this report. Markus will help out.

Omar will be editor of the working draft, and we assume Mireille will also want to be part of the effort.

Omar will circulate a list of the use cases over the DM list; there's already something on this page (http://wiki.ivoa.net/twiki/bin/view/IVOA/UtypesTigerTeam), but it needs smoothing and elaboration. Documents will end up in volute.

We need to make explicit what are the prime use cases driving utypes. Not all of the ones on the wiki may be achieveable.

Attempts to define utypes: Are they "pointers into a data model instance", much like xpath points into a XML document? That much seems not very contentious. As far as this function is concerned, it is seen that inheritance and embedding are not very well dealt with now.

"I should be able to serialize and deserialize a data model instance in any way I want" using utypes (Matthew). But we obviously need to pose additional constraints on what the target formats need to be able to to (e.g., represent key-value pairs).

What formats do we actually care about? VOTable obviously, FITS probably (though some say people that want FITS won't care about data models), SAMP messages. JSON? No agreement. CSV doesn't have enough of a header to allow utype mapping, probably.

We've got about 8 weeks until the interop. What do we want to get done by then? We want the use cases in a form so TCG/plenary/whoever can decide which absolutely have to be covered, where we as Tiger Team provide comments/suggest priorities. We also must have the overview of where utypes are already used. Telecons every two weeks.