In the file BetaLyr_complete_utypes we adopted the simplest model mapping technic we could imagine.
Note, however that the BetaLyr use case is much more complex than the SDSS one. 
    First of all there are up to 5 fluxes on each row of the table
    Second, each line has 5 slightly different types.
    The choice has been made here to consider each line as a data point in the time series. In these conditions there is a single time column considered as an independant variable and all other times are part of the dependant variable which is made of plentyiofasurements. THis approach is conforted in looking the original paper (Shenavrin et al, Astronomicheskii Zhurnal, 2011, Vol. 88, No. 1, pp. 34–85.) where these raws present a basic time with a Time Shift for each photometric band.

As in SDSS The model classes are grouped in  4 different packages which are mapped into 4 different tables : one for generic Dataset metadata ( dataset direct attributes, dataID attributes and observation attributes), one for characterisation, one for coordinate system and Photometric filters features, and of course the data table. 

In order to build utypes for the data and metadata fields in these different tables, we start from the TimeSeries root class and follow the pathes until the leaves attributes. We concatenate the classes and attributes names until we reach the FIELD. This defines unambiguously utypes. They can include pieces from different models mainly the TimeSeries model and imported models such as characterisation, STC, photometry, etc...

In the Beta Lyr example several different FIELDS have identical utypes due to the multiphotometric aspect of the measurements. Refrence to photometriy filter definitions in the System definuition table.

    IN this approach the role  of a FIELD with respect to this IVOA models is defined entirely by the utype string and available at the FIELD level without any depndance from other FIELDS or VOTABLE structures. GROUPs of FIELDS are only there for facilitating reading.  This is the simplest method we can imagine in the case the TimeSeries provides for each Time Stamp a measurement consistent with one  STC or Photometry axis (or a combination of those).  We think that this way applications can infer a lot of feasible actions from the sole parsing of each FIELD attributes values.

     - This method will become more difficult to use if all or part of the measurements are represented by a new or non-IVOA model. 
     - It has been objected that the method may be unstable in the case of changes in the model affecting the names and attributes in the main TimeSeries model or in imported data models. This issue can be partially solved by attaching utypes permanently to columns in a TAP schema. That's why we provide a TAP schema for a given family of TimeSeries. 

       This TAP schema representation of the view of the model adapted to the data can be generated from catalog metadata when storing the TimeSeries initialy and may help tio generate exact FIELD attributes dynamycally in the query phases.