\subsection{Marks's approach}
\label{subsec:approach-mark}

For this study, we generated annotation for the 2 sample files according to the current VO-DML Mapping Syntax proposal \cite{gl:mapping}.
Annotation was generated to both the current Cube model and the toy Time Series model described in Section~\ref{subsec:model-mark}.
The files themselves may be found at the following URL:
\begin{small}
http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/standardized\_votables/MarkCD/
\end{small}

\subsubsection{Sample Files}

In the text below we will focus on the annotation to the Time Series model as that is the focus of this study.
\begin{enumerate}
\item \textbf{BetaLyr\_Vizier}
    Example file annotated as multiple SimpleTimeSeries data product instances, 
    one per photometric band.

    The structure is:
    \begin{itemize}
    \item 1-instance of ObsDataset
    \item 5-instances of SimpleTimeSeries data products, one for each band (J,K,L,M,N)
    \item 5-TSPoint templates, each with 1-Time + 1-Observable (Mag with Error )
    \end{itemize}

    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
    segment to provide these singular elements as PARAMs.  This results in 
    very straight-forward annotation and VOTable.

\item \textbf{GaiaSample3Tables}
    Example file annotated to the toy TimeSeries model, using the current Mapping syntax proposal, as multiple SimpleTimeSeries data products.
    \begin{itemize}
    \item  0-instances of ObsDataset
    \item  3-instances of SimpleTimeSeries data product
    \item  3-instances of TSPoint with 3 Observables each (1-Time + 1-Flux\_w\_error + 1-Mag)
    \end{itemize}

    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.

    There is no DatasetMetadata included.
    
    For annotation purposes, I needed to make the following changes.
    \begin{itemize}
    \item Changed VOTABLE tag to version 1.4 to validate against vo-dml schema
    \item Added IDs to TABLE elements to reference in vo-dml annotation
    \item Added IDs to PARAM elements for Filter metadata
    \end{itemize}
    
\end{enumerate}

\subsubsection{Mapping Syntax}

The syntax used is fully documented in the VO-DML Mapping document~\cite{gl:mapping}.  It is important to note that this syntax was designed to satisfy a broad set of use cases and essential requirements identified by the community.  Any syntax being considered by the community for application, should be evaluated against these requirements to ensure that it will meet the needs of the community.

The document fully describes the syntax, so we will not go into detail here.  The key structural components are:
\begin{itemize}
\item <VODML> - primary element, all annotation is isolated from the VOTable serialization.
\item <MODEL> - identifies which vo-dml compliant models are represented in the serialization
\item <GLOBALS> - instances which are global in nature. (eg: Frames, Dataset Metadata)
\item <TEMPLATES> - defines multiple instances by iterating over entries in the template target (rows of a TABLE)
\item <INSTANCE> - defines a particular instance of a structured object (TimeFrame, SimpleTimeSeries, etc) identified by the vodml-id of the object type (coords:domain.time.TimeFrame, ts:SimpleTimeSeries)
\end{itemize}

This syntax provides severval benefits over the earlier utype convention, or any utype based annotation syntax, such as:
\begin{itemize}
\item Isolating the annotation from the VOTable elements allows data providers to retain their native serialization.
  \begin{itemize}
  \item is an additive change to current serialization thread
  \item allows native code to continue functioning
  \end{itemize}
\item Protects against model changes
  \begin{itemize}
  \item if a model changes, say elements move from one group to another (which has happened), data providers do not need to change the VOTable GROUP content, just update the annotation section.
  \end{itemize}
\item Allows reuse of elements
  \begin{itemize}
  \item a single PARAM value=TOPOCENTER can be used for all Frame.refPosition roles.
  \item a single FIELD name='time', can provide the time measure for multiple SimpleTimeSeries instances.
  \end{itemize}
\item Clear association of an instance to a role
  \begin{itemize}
  \item The syntax directly associates an instance to the role it plays in the parent object; ds:Target.position is instance of meas:Position
  \item The same INSTANCE may serve multiple roles. eg: a single Organization instance may serve as both ds:DataID.curator and ds:Curation.publisher 
  \end{itemize}
\item Allows annotation to multiple models, or versions thereof.
  \begin{itemize}
  \item Providers can annotate the same VOTable content as a SparseCube AND SimpleTimeSeries (for example).
  \item Providers can annotate the same VOTable content to multiple versions of the same model, allowing for smoother transitions by clients.
  \end{itemize}
\item Allows clients to 'discover' content it understands.
  \begin{itemize}
  \item since any modeled instance ALWAYS has the same vodml-id, client applications can find and work with content that it understands.  The common example is a generic plotting package can find instances containing the roles 'meas:CoordMeasure.coord' and 'meas:CoordMeasure.error' to plot these data without knowing that they reside in a SparseCube, TimeSeries, or other data product.
  \end{itemize}
\end{itemize}
These limitations of the utype annotation approach were the primary drivers for the VO-DML Mapping project.