In the file SDSS we adopted the simplest model mapping technic we could imagine. 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 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 to generate exact FIELD attributes dynamycally in the query phases.