1. Utypes for Model Referencing
A data model can be seen as a structure (class) containing elements (attributes)
These elements can be mapped into a qualified name that is called a utype.
Examples:
Target.Name
TimeAxis.numBins
AstroCoords.Time.TimeInstant.ISOTime

2. Name space in Utypes
A qualified utype may be ambiguous (exist in several data models  use name space:
cha: for Characterisation (dedicated note)
spec: for Spectrum data model
stc: proposed for Space-Time coordinates (proposal of a STC-U complementary to STC-X and STC-S)
Examples:
cha:TimeAxis.numBins
stc:AstroCoords.Time.TimeInstant.ISOTime

3. prefix:element.element.element...
Utype syntax
prefix:element.element.element...
namespace-type prefix
dot-separated list of the elements in the hierarchy of the data model
to be agreed across IVOA WGs (was in preparation by JMD)

4. Utypes as URI ?
Extend name space conventions to utypes? Proposed by N. Gray in an IVOA note
Pros: fully accurate, versioning available, may link to documentation, shared semantics...
Cons: potential proliferation of private models?
Example:
xmlns:cha=”
utype=”cha:TimeAxis.numBins”
may find documentation from

5. Utypes vs UCDs Example of a value named NAXIS1:
as a ucd: instr.fov;instr.pixel -- or maybe just a number !
as a utype: fits:main.NAXIS1 is the parameter which gives the dimension along the X-axis as described by the FITS data-model
complementary

6. Utypes in the VO Was created for the DAL needs Used in SSA
Used by Characterisation
Could be used in ADQL/VOQL

7. Utypes in VOTable
The tabular material serialized as a VOTable may contain in its fields (columns) any kind of data
it is impossible to import into a VOTable document all XML structures related to all data models developed by the VO
VOTable document therefore refers to data models without including them

8. Utypes in VOTable1.1
in VOTable schema: utype is a non-mandatory attribute of any RESOURCE TABLE FIELD PARAM GROUP
is an acceptable attribute wherever the ucd accepted
contrary to the ucd, gives exact meaning
ucd = broad semantics, typically used for data mining
utype = detailed semantics, refers to a data model
is only useful in relation with a data model
with URI linking ?

9. Utypes role in VOTable supplies an accurate meaning to applications
especially important for quantities (parameters and/or fields) which exact meaning is crucial
systems of coordinates for spatial correlations: celestial, terrestrial, solar, ... (connection with STC)
time definitions for time series (connection with STC)
photometric systems & filters
more generally any parameter part of a model, simulation...

10. VOTable-STC Connection
STC is an essential component to precise the conventions of dates, locations, coordinate systems – now an IVOA Recommendation
is of interest in most VO components
in VOTable: replaces (and deprecates) the COOSYS convention

11. VOTable-STC connection
Among the different scenarios proposed, the preference makes use of GROUPs of parameters
it was decided to write an IVOA note dedicated to the VOTable-STC connection
 preliminary version circulated, finally close to an agreement
Will be included in VOTable1.2

12. Coordinate components
2 classes are required (STC nomenclature):
the coordinate system = AstroCoordSystem which will generally refer to standard systems
the actual coordinates = AstroCoord
More generic CooSys and Coords may be used for non-astronomical coordinate frame.

13. Detailed Coordinate Definition
Done in 2 groups:
coordinate system group with attributes
utype=”stc:AstroCoordSystem”
ID=”mySysID” for referencing
coordinate group
utype=”stc:AstroCoords”
ref=”mySysID” refers the coordinate system group
ID=”myCoords” for referencing
Actual coordinate values are stored in FIELDs

14. Coordinate components
Defined in FIELD with attributes:
ref=”myCoords”
utype=”stc:AstroCoords.type.rep.comp”
type = Position2D | Position3D | Time
rep = Value2 | Value3 | TimeInstant
comp = C1 | C2 | C3 | ISOTime | MJDTime
... plus other attributes ucd, datatype, width, precision ...

15. ID/ref <GROUP utype=”AstroCoordSystem” ID=”myFrame” >
<PARAM name=”STC_ID”
utype=”stc:AstroCoordSystem.ID”
value=”UTC_ICRS_TOPO” ... />
...
</GROUP>
ID/ref
<GROUP ref=”myFrame”
ID=”myCoords” utype="AstroCoords">
<PARAM name=”epoch”
utype=”stc:AstroCoords.SpaceFrame.
epoch” value=” ” ... />
...
</GROUP>
CoordSystem
includes
sub-groups
for time,
space,
redshift...

16. ID/ref <GROUP utype=”AstroCoords” ref=”myFrame” ID=”myCoords” >
<PARAM name=”epoch”
utype=”stc:AstroCoords.
SpaceFrame.epoch”
value=” ” ... />
...
</GROUP>
ID/ref
<FIELD name=”RA” ref="myCoords"
utype=”AstroCoords.Position2D.Value2.C1”
... />

17. Examples Example 1: excerpt of the Hipparcos Catalog
Example 2: Ephemerid of a comet
(see the note_stc.html document)

20. Relations between tables (1)
One VOTable document may contain several tables, meaning tables logically grouped.
In the relational model, relations between tables are specified via the concept of keys
basic key definitions: primary key (non-null, unique) and foreign key (must exist as primary in the related table)
A simple solution: GROUPs

21. Relations between tables (2)
<GROUP name=”primaryKey”>
<FIELDref ref=”ClusterName”>
<FIELDref ref=”GalaxyName”>
</GROUP>
...
<FIELD ID=”ClusterName” .../>
<FIELD ID=”GalaxyName” .../>

22. Relations between tables (3)
<GROUP name=”foreignKey” ref=”mainTable”>
<FIELDref ref=”ClusterName”>
<FIELDref ref=”GalaxyName”>
</GROUP>
...
<FIELD ID=”ClusterName” .../>
<FIELD ID=”GalaxyName” .../>

23. Relations between tables (4)
Other possible interesting details:
order of the data, e.g. with
<GROUP name=”order” >
<PARAM name=”sequence” value=”increasing”>
<FIELDref ref=”ClusterName”>
<FIELDref ref=”GalaxyName”>
</GROUP>

24. Relations between tables (5)
not yet decided: what is better:
just a <GROUP> with a specific name ?
prefer the definition of some “relational” data model and refer to these groups with utypes ?
to be included in VOTable1.2 ?

25. Future of VOTable After VOTable 1.2 To keep as a Working Group ?
Need maintenance ? Volunteers ?