\subsection{Laurent's approach} The VO-DML workflow is 2 folds : 1) The model serialization in a \textit{model.vo-dml.xml} file (REC process currently close to complete) 2) the data mapping. This last step consists in an XML bloc on the top of the VOTAble acting as a bridge between the model and the data so that a client can easily build model instances by exploring that mapping bloc (see previous section). The VO-DML concepts are endorsed by the community but the mapping syntax may appear as too complex making both data annotation process and VOTable parsing difficult. \begin{itemize} \item VO-DML workflow ++ \begin{itemize} \item Enable to map any modelling feature \item Mapping block independent from the VOTable content \begin{itemize} \item No dependency with the VOTable schema \item Easiness to join data taken out from different tables \item Easy to skip for clients not model aware \end{itemize} \end{itemize} \item VO-DML workflow -- \begin{itemize} \item Obscure and chatty mapping syntax \item Coupling between the mapping leaves and the VOTable data structure. For instance, the mapping has to be changed when a value is moved from a PARAM to a FIELD \end{itemize} \end{itemize} The present section explores a possible simplification of the mapping syntax relying on the strengths of the VO-DML workflow while targeting an easier job for both data providers and data consumers. The syntax baseline is designed to provide general-purpose clients (e.g. Aladin, JS widget \dots) with nothing more than what they need, considering that more advanced clients could retrieve in any case any model features within the model itself. This simplification might also improve the reliability of the data annotation process. This is not a complete proposal, but a proof of concept validated against TD data. \subsubsection{Mapping Syntax} \paragraph{Basics} The design of this mapping syntax being not complete; we just describe here the outlines of this simplification and the features we need to map the present data sample. As describe in the previous section, the block is split in 3 sections. \begin{table}[th] \begin{center} \scriptsize \caption{Main mapping elements.}\label{tab:mapping_elements} \begin{tabular}{rl} \sptablerule & References to all referenced models (models + imports) \\ & Not implemented here \\ & One template per table \\ \sptablerule \end{tabular} \normalsize \end{center} % \textbf{Note:} $^1$For SSO or moving objects coordinates might not be enough or relevant. \end{table} Each template refers to a particular table and contains the mapping of the classes hosted by that table. The mapping is based on the 3 concepts necessary to describe a hierarchy of classes: \smallskip \begin{table}[th] \begin{center} \scriptsize \caption{Mapping element roles.}\label{tab:mapping_elements} \begin{tabular}{rp{0.75\textwidth}l} \sptablerule & Model leaf. Either points to a or a or contains its own value for literals \\ \sptablerule & Denotes a class. An is a tuple of elements which can be either , or \\ \sptablerule & Denotes a list or an array. A collection can contain either , or \\\sptablerule \end{tabular} \normalsize \end{center} % \textbf{Note:} $^1$For SSO or moving objects coordinates might not be enough or relevant. \end{table} Each one of these elements supports some attributes wich can be mandatory (mand.) or optional (opt). It has be be noted that some attributes such as units or formats are not described here as well as the foreign key mechanism. \begin{table}[th] \begin{center} \scriptsize \caption{Mapping element attributes.}\label{tab:mapping_elements} \begin{tabular}{cp{1cm}cp{1cm}cp{1cm}cp{1cm}cp{1cm}cp{1cm}cp{1cm}cp{1cm}} \sptablerule Attribute: & \textbf{@dmrole} & \textbf{@dmtype} & \textbf{@ref} & \textbf{@tableref} & \textbf{@size} & \textbf{@value} \\ \sptablerule & mand. & none & mand. if no @value & none & none & mand. if no @ref \\ \sptablerule & mand. & opt. & none & opt. & none & none \\ \sptablerule & none & none & none & none & opt & none \\ \sptablerule \end{tabular} \normalsize \end{center} % \textbf{Note:} $^1$For SSO or moving objects coordinates might not be enough or relevant. \end{table} \paragraph{ element} The @dmrole attribute is the one set in the VO-DML model. Other VO-DML attributes (e.g. @dmtype) can be retrieved in the VO-DML file from the location of the element and from its @dmrole. \begin{itemize} \item If a element has a @ref attribute but no @value, its value is taken out from the refered element of the table refered by the current . The client must first search in the , and then in the . The value of a element located out of a block and pointing onto a is set with the values read the first table row. \item If a element has a @value attribute but no @ref, the value of @value is taken. \item If a element has both @value and @ref, the client must first resolve @ref and then @value. \end{itemize} \paragraph{ element} The @dmrole attribute is the one set in the VO-DML model. \begin{itemize} \item An without @dmtype attribute matches the type set in the VO-DML file. Otherwise, @dmtype can specify a subtype of the dmtype read in the model. This feature is used to support abstract classes. \item An with a @tableref is mapped in the designated by @tableref and having the same @dmrole. \end{itemize} \paragraph{ element} The @dmrole attribute is the one set in the VO-DML model. All sub-elements must have the same @dmtype. The number of elements in a collection is specified the @size attribute. \begin{itemize} \item A without @size attribute contains one instance of each element mapped (see example below) \tiny \begin{lstlisting}[language=xml] ..... ..... \end{lstlisting} \normalsize \item A with a @size attribute contains as many instances of the mapped elements as requested by @size. To be consistant, when @size is set, must have one unique child containing only one mapped entity. \tiny \begin{lstlisting}[language=xml] ..... \end{lstlisting} \normalsize If @size equals to * or -1, the collection is populated as long as data are available. For instance, this is the case when the maps photometric points which are read row per row in the table. \end{itemize} \subsubsection{Workflow (to be updated)} The model used for these serializations, designed with Modelio 3.5, has been presented at (ref ivoa). This serialization has also been tested with SparseCube but the outcomes are less advanced. This demonstrator used for the serialization of the data sample relies on 2 specific Python tools developed on this occasion but possibly reusable as seeds for further developments. \begin{itemize} \item \textit{transform.py} reads a VO-DML model and genererates a single block with unresolved references. The tool supports directives specifying which classes must be used in replacement of the abstract ones. The block must be inserted by hand in the VOtable to be annotated. It must be split in multiple if data are spread out on muliple tables. The references to actual and must also be set by hand. \item \textit{transform.py} is a basic client which plots the annotated timeseries. The key point is that \textit{transform.py} is able, to some extent, to read any VOTable mapped with the model. \end{itemize} \subsubsection{Conclusions and Prospects} This approach confirms the power and versatility of the VO-DML workflow since it doesn't use any feature external to the VO-DML ecosystem. The main outcome is that clients knowing a model are able by construction to read VOTables annotated with that model. There is no need to adapt the client code to specific data collection as long as they are are not too much exotic. The added value of the light syntax sketched here is that the same outcomes can be reached with more compact and more readable annotations. This opens the way for light clients such as JavaScript widgets which could have difficulties to process hundreds of XML lines each time they have to parse a VOTable.