TimeSeries model and serializations:

./model:
   Toy timeseries model based off current models ( Dataset, Cube, Coords, Meas ).
   The model extends Cube model elements to facilitate the modeling of a wide 
   variety of TimeSeries flavors.

   There are multiple ways the TimeSeries model could be derived from Cube.
   The details will depend on a thorough review of the full set of use cases
   and requirements.  This toy model focuses on representing the SimpleTimeSeries
   as a fairly direct extension of SparseCube... with the addition of requiring
   a 'timeAxis'.  The cube component elements are designed to facilitate the 
   definition of other TimeSeries described in the CSPTimeseries document, but
   are not heavily considered here at this point.

     TSPoint: Element type for SimpleTimeSeries product.
       This class basically represents F(t); something as function of time, 
       where time is a measured value.
       All entities in the Point are measured values.

     SimpleTimeSeries: DataProduct for time series of observed quantities
       Expected to handle "Group A" case of CSPTimeseries document

     NOTE:
       The example files (BetaLyr, ) appear to match the "Groups of light curves"
       category. In the example serializations, we simply include multiple 
       instances of the SimpleTimeSeries data product.  If a DataProduct 
       specification for this category is required, it would be a simple 
       extension of cube:DataProduct with a list of references to SimpleTimeSeries
       or possibly a base <TimeSeriesDP>.
        

Sample Files:
  NOTE: 
    Files annotated as a Cube only use elements from the current vo-dml compliant
    models (ds, cube, coords, meas).  As such, there are elements which cannot 
    be mapped in the annotation.  My impression is that this is one of the goals
    of this exercise.. see which concepts are missing from current models.

    Files annotated to the toy TimeSeries model have access to additional objects
    which allow the incorporation of those elements into the annotation.
      + LuminosityMeasure:
          This class would most likely be modeled in the Spectral Data Model.
          This representation is one prototyped for a Source model, it accomodates
          Flux and Magnitude measures, and provides access to the Photometry
          filter metadata (modeled in PhotDM).  Rather than a rigorous modeling
          of this relation, we add a stub object PhotProv to collect the relevant
          metadata.

  BetaLyr_Vizier
    The use of FIELD elements to store metadata (eg: ObsDataset metadata ) 
    presents a challenge for proper annotation.  Being in FIELDs, they must be
    annotated within a TEMPLATE element, which may have multiple instances.
    This forces the INSTANCES to identify a particular instance via the 
    ORM PRIMARYKEY/FOREIGNKEY elements.

    For a model which specifies that there should only be 1 instance of that 
    type, this is quite a lot of overhead.  This annotation shows that the 
    syntax can accommodate the structure, but in practical application, it 
    is probably easier for both client and provider to re-cast the VOTable
    segement to provide these singular elements as PARAMs.  This results in 
    very straight-forward annotation and VOTable.

    BetaLyr_Vizier_cube.xml
      Example file annotated with current vo-dml Mapping syntax according to the 
      Cube model as a SparseCube.
        1-instance of ObsDataset
        1-instances of SparseCube data product
        1-NDPoint template with 10 Observables 
  
    BetaLyr_Vizier_ts.xml
      Example file annotated with current vo-dml Mapping syntax according to the 
      toy TimeSeries model as multiple SimpleTimeSeries data product instances, 
      one per photometric band.
      The structure is:
        1-instance of ObsDataset
        5-instances of SimpleTimeSeries data products (J,K,L,M,N bands)
        5-TSPoint templates with 1-Time + 1-Observable (Mag w/ Error ) each

  GaiaSample3Tables
    This appears to be a straight forward representation of 3 SimpleTimeSeries
    data products, each serialized in their own TABLE.  In this example, the
    filter metadata is constant for each table, so we've annotated them as 
    individual instances which are referred to by the LuminosityMeasures 
    within the TEMPLATE.

    As far as I can see.. there is no DatasetMetadata included.
    
    For annotation purposes, I needed to make the following changes.
    * Changed VOTABLE tag to version 1.4 to validate against vo-dml schema
    * Added IDs to TABLE elements to reference in vo-dml annotation
    * Added IDs to PARAM elements for Filter metadata
    
    GaiaSample3Tables_cube.vot
      Example file annotated with current vo-dml Mapping syntax according to the 
      Cube model as a SparseCube.
        0 - instances of ObsDataset
        3 - instances of SparseCube data product
        3 - instances of NDPoint with 3 Observables each 
             (1-Time + 1-Flux_w_error + 1-Mag)

      NOTE: It is very straight forward to annotate the file in this way.
      However, I believe it would be very difficult to annotate as 
        1 - SparseCube
        1 - NDPoint template with 9 Observables
      since there would not be a single table TEMPLATE containing the 
      full NDPoint content.


    GaiaSample3Tables_ts.vot
      Example file annotated with current vo-dml Mapping syntax according to the 
      toy TimeSeries model as multiple SimpleTimeSeries data products.
        0 - instances of ObsDataset
        3 - instances of SparseCube data product
        3 - instances of NDPoint with 3 Observables each 
             (1-Time + 1-Flux_w_error + 1-Mag)