# [Volute] r4921 - trunk/projects/time-domain/time-series/note

Volute commit messages volutecommits at g-vo.org
Mon Apr 16 15:24:18 CEST 2018

Author: francois
Date: Mon Apr 16 15:24:17 2018
New Revision: 4921

Log:
adding GAPS examaple and change TAPSchema to vodataservice tablesets

Modified:
trunk/projects/time-domain/time-series/note/TSSerializationNote.pdf
trunk/projects/time-domain/time-series/note/TSSerializationNote.tex
trunk/projects/time-domain/time-series/note/appendixFrancois.tex
trunk/projects/time-domain/time-series/note/francois.tex
trunk/projects/time-domain/time-series/note/laurent.tex
trunk/projects/time-domain/time-series/note/mireille-td.tex

Modified: trunk/projects/time-domain/time-series/note/TSSerializationNote.pdf
==============================================================================
Binary file (source and/or target). No diff available.

Modified: trunk/projects/time-domain/time-series/note/TSSerializationNote.tex
==============================================================================
--- trunk/projects/time-domain/time-series/note/TSSerializationNote.tex	Sun Apr 15 00:46:37 2018	(r4920)
+++ trunk/projects/time-domain/time-series/note/TSSerializationNote.tex	Mon Apr 16 15:24:17 2018	(r4921)
@@ -152,7 +152,7 @@

%\input{appendix1}
-%\input{appendixFrancois}
+\input{appendixFrancois}

\bibliography{TSSerializationNote.bib}

==============================================================================
@@ -5,8 +5,8 @@
\subsection{Definition}
Time Series can be defined in a very large sense as a collection of any kind of data over time for a particular source (e.~g. star, binary, QSO) or part of a source (e.~g. sun spots), independent on the type of data (images, light-curves, radial velocity, polarisation estates or degrees, positions, number of sunspots, densities,...), the duration of the observation or the cadence.

-Independent on the type of data we can sketch Time Series data as shown in Fig.~\ref{fig:time-series}. Time Series data is composed of a set of observations (n\_observations = 3 in this example), each with a different exposure or integration time (t\_exp). Although in some cases the cadance or time spam between each observation (delta\_t) is fixed, in the general case it can be different and we can therefore define a minimum and a maximum value (delta\_t\_min, delta\_t\_max). Each observation has it's own time stamp (t\_i) with a given precision or resolution (t\_resolution). As can be seen from this figure the duration of the observation can be defined in different ways: a) as the total integration or exposure time, i.~e. the sum of all the exposure times: t\_exp\_total = $\sum$t\_exp; or b) as the time spam between the beginning and the end of the observations: t\_exp\_total = t\_max - time\_min). Note that in the case that the exposure time is constant for all the observ!
ations th
en t\_exp\_total = n\_observations $\times$t\_exp. The situation can be more complicated, for instance during the observation there could be clouds and we therefore pause the exposure for a while and resume once the cloud has passed or we might want to remove parts of the observation due to artefacts in the data. In any case these values can be taken as approximative of the minimum and the maximum value this specific field can have.
-The most relevant fields of Time Series data are summarized in Table~\ref{tab:fields}.
+Independent on the type of data we can sketch Time Series data as shown in Fig.~\ref{fig:time-series}. Time Series data is composed of a set of observations (n\_observations = 3 in this example), each with a different exposure or integration time (t\_exp). Although in some cases the cadance or time span between each observation (delta\_t) is fixed, in the general case it can be different and we can therefore define a minimum and a maximum value (delta\_t\_min, delta\_t\_max). Each observation has it's own time stamp (t\_i) with a given precision or resolution (t\_resolution). As can be seen from this figure the duration of the observation can be defined in different ways: a) as the total integration or exposure time, i.~e. the sum of all the exposure times: t\_exp\_total = $\sum$t\_exp; or b) as the time spam between the beginning and the end of the observations: t\_exp\_total = t\_max - time\_min). Note that in the case that the exposure time is constant for all the observ!
ations th
en t\_exp\_total = n\_observations $\times$t\_exp. The situation can be more complicated, for instance during the observation there could be clouds and we therefore pause the exposure for a while and resume once the cloud has passed or we might want to remove parts of the observation due to artefacts in the data. In any case these values can be taken as approximative of the minimum and the maximum value this specific field can have.
+The most relevant fields of Time Series metadata are summarized in Table~\ref{tab:fields}.

\begin{figure}
\begin{center}
@@ -17,7 +17,7 @@

\begin{table}[th]
\begin{center}
-  \caption{Time Series data fields.}\label{tab:fields}
\begin{tabular}{p{0.35\textwidth}p{0.64\textwidth}}
\sptablerule
\textbf{Field}  & \textbf{Explanation}                        \\\sptablerule
@@ -68,7 +68,7 @@
\end{center}
\end{table}

-As highlighted by the different science uces cases described in \url{http://wiki.ivoa.net/twiki/bin/view/IVOA/CSPTimeSeries}, there are astrophysical phenomenae that vary in different timescales and to study the different physical underlying mechanims a user might need to collect and analyse data from different missions and of different nature.
+As highlighted by the different science use cases described in \url{http://wiki.ivoa.net/twiki/bin/view/IVOA/CSPTimeSeries}, there are astrophysical phenomenae that vary in different timescales and hence, in order to study the different physical underlying mechanims a user might need to collect and analyse data from different missions and of different nature.
Answering all the possible science cases is a difficult task. We would therefore like to keep a practical approach to the problem, solving the simplest cases in a first step and allowing having incremental solutions for more complex systems at later stages.

Looking at the different science cases we simplify the questions to two:
@@ -76,7 +76,7 @@
\item \emph{Have these two missions observed this object within these two dates?}
\item \emph{Is it possible to discover long/short term variability within the data?}
\end{enumerate}
-To answer the first question a user needs to be sure that dates are comparable, that is time has to be brought into a common time frame. To answer the second question we need to keep track of the minimum and maximum time spam. We aim in a first step to answer these fundamental questions and, later on we will move to answer the specific science cases, which focus of the nature of the Time Series data, giving priority to lightcurves which represent the mayority of the cases, while having in mind a wider approach.
+To answer the first question a user needs to be sure that dates are comparable, that is time has to be brought into a common time frame. To answer the second question we need to keep track of the minimum and maximum time span. We aim in a first step to answer these fundamental questions and, later on we will move to answer the specific science cases, which focus of the nature of the Time Series data, giving priority to lightcurves which represent the majority of the cases, while having in mind a wider approach.

\subsection{Using a common time frame}
To compare datasets from different missions or archives a common representation of time is needed. In order to do so we propose to map time into a pivot format. Following \cite{rots2015} and \cite{std:STC} we propose a set of minimum metadata to be added for serializations of Time Series (see Table~\ref{tab:metadata}).

Modified: trunk/projects/time-domain/time-series/note/appendixFrancois.tex
==============================================================================
--- trunk/projects/time-domain/time-series/note/appendixFrancois.tex	Sun Apr 15 00:46:37 2018	(r4920)
+++ trunk/projects/time-domain/time-series/note/appendixFrancois.tex	Mon Apr 16 15:24:17 2018	(r4921)
@@ -1,324 +1,14 @@
-\section{VODataservice tabular mapping of TimeSeries}
-\begin{small}
-\begin{lstlisting}[language=XML, caption= TAP schema in xml]
+\section{VODataservice tableset mapping of TimeSeries}
+
+This appendix points to three vodatservice "tableset" descriptions.
+
+The first xml document corresponds to example 1 of full-utype serialisation. It contains the table definitions for the TimeSeries metadata and
+the absolutely minimal content for the data table with two column definitions.
+
+The second xml-document corresponds to example 2. Beside the same metadata table definitions ias in document 1 it containsi more column description, because this TimeSeries is a multiband TimeSeries with the additional complexity of small shift in time with respect to the main TimeInstant for each band.
+
+The third xml-document corresponds to example 3 of full-type serialisation. The data table is very complex and most of the dependant measurements definitions have to be refined using ucds.
+
+TimeSeries projects in the VO will present very different flavors of the model, expressed as one specific tableset

-<?xml version="1.0" encoding="UTF-8"?>
-<vosi:tableset xmlns:vosi="http://www.ivoa.net/xml/VOSITables/v1.0" xmlns:vod="http://www.ivoa.net/xml/VODataService/v1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ivoa.net/xml/VODataService/v1.1 http://www.ivoa.net/xml/VODataService/v1.1 http://www.ivoa.net/xml/VOSITables/v1.0 http://vo.ari.uni-heidelberg.de/docs/schemata/VOSITables-v1.0.xsd">
-<schema>
-	<name>VizieRSimpleTimeSeries</name>
-	<description>TimeSeries model schema restriction to Sipmlle Vizer case</description>
-	<table type="output">
-		<name>TimleSeries</name>
-		<description>instances of Entity class</description>
-		<column>
-			<name>productType</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<utype>ts:TimeSeries.dataProductType</utype>
-		</column>
-		<column>
-			<name>calibLevel</name>
-			<dataType xsi:type="vod:TAPType">INTEGER</dataType>
-			<utype>ts:TimeSeries.calibLevel</utype>
-		</column>
-		<column>
-			<name>pubDID</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<utype>ts:Observation.observationID</utype>
-		</column>
-		<column>
-			<name>creator</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<utype>ts:TimeSeries.DataID.creatorDID</utype>
-		</column>
-		<column>
-			<name>contributor</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<utype>ts:TimeSeries.DataID.contributor</utype>
-		</column>
-		<column>
-			<name>Target</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<utype>ts:Observation.Target.name</utype>
-		</column>
-		<foreignKey>
-			<targetTable>characterisation</targetTable>
-			<fkColumn>
-				<fromColumn>pubDID</fromColumn>
-				<targetColumn>pubDID</targetColumn>
-			</fkColumn>
-		</foreignKey>
-		<foreignKey>
-			<targetTable>coordsys</targetTable>
-			<fkColumn>
-				<fromColumn>pubDID</fromColumn>
-				<targetColumn>pubDID</targetColumn>
-			</fkColumn>
-		</foreignKey>
-		<foreignKey>
-			<targetTable>TimeSeriesData</targetTable>
-			<fkColumn>
-				<fromColumn>pubDID</fromColumn>
-				<targetColumn>pubDID</targetColumn>
-			</fkColumn>
-		</foreignKey>
-	</table>
-	<table type="output">
-		<name>characterisation</name>
-		<description>instances of Entity Description class</description>
-		<column>
-			<name>pubDID</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<utype>ts:Observation.observationID</utype>
-		</column>
-		<column>
-			<name>SpatLocationRA</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>pos.eq.ra</ucd>
-			<utype>cha:Char.SpatialAxis.Location.Coord.SpatialValue2D[0]</utype>
-		</column>
-		<column>
-			<name>SpatLocationDec</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>pos.eq.dec</ucd>
-			<utype>cha:Char.SpatialAxis.Location.Coord.SpatialValue2D[1]</utype>
-		</column>
-		<column>
-			<name>SpatBoundsSizeRA</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>pos.eq.ra;stat.length</ucd>
-			<utype>cha:Char.SpatialAxis.Bounds.CharBox.Size2[0]</utype>
-		</column>
-		<column>
-			<name>SpatBoundsSizeDEC</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>pos.eq.dec;stat.length</ucd>
-			<utype>cha:Char.SpatialAxis.Bounds.CharBox.Size2[1]</utype>
-		</column>
-		<column>
-                       <name>t_min</name>
-                       <ucd>time.start</ucd>
-                       <unit>d</unit>
-                       <utype>ts:Char.TimeAxis.Coverage.bounds.StartTime</utype>
-                       <dataType xsi:type="vod:TAPType">REAL</dataType>
-                </column>
-		<column>
-                      <name>t_max</name>
-                      <ucd>time.stop</ucd>
-                      <unit>d</unit>
-                      <utype>ts:Char.TimeAxis.Coverage.bounds.StopTime</utype>
-                      <dataType xsi:type="vod:TAPType">REAL</dataType>
-               </column>
-               <column>
-                      <name>t_mean</name>
-                      <ucd>time</ucd>
-                      <unit>d</unit>
-                      <utype>ts:Char.TimeAxis.Coverage.location.TimeInstant</utype>
-                     <dataType xsi:type="vod:TAPType">REAL</dataType>
-               </column>
-               <column>
-                      <name>t_exp_time</name>
-                      <ucd>time.duration</ucd>
-                      <unit>d</unit>
-                      <utype>ts:Char.TimeAxis.Coverage.supportExtent</utype>
-                      <dataType xsi:type="vod:TAPType">REAL</dataType>
-                </column>
-                <column>
-                      <name>t_resolution</name>
-                      <ucd>time.resolution</ucd>
-                      <unit>d</unit>
-                      <utype>ts:Char.TimeAxis.resolutionRefVal</utype>
-                      <dataType xsi:type="vod:TAPType">REAL</dataType>
-                </column>
-                <column>
-                      <name>delta_t_min</name>
-                      <ucd>time</ucd>
-                      <unit>d</unit>
-                      <utype>ts:Char.TimeAxis.sampling.bounds.SamplingPrecision.TimeStart</utype>
-                      <dataType xsi:type="vod:TAPType">REAL</dataType>
-                </column>
-                <column>
-                      <name>delta_t_max</name>
-                      <ucd>time</ucd>
-                      <unit>d</unit>
-                      <utype>ts:Char.TimeAxis.sampling.bounds.SamplingPrecision.TimeStop</utype>
-                      <dataType xsi:type="vod:TAPType">REAL</dataType>
-                </column>
-                <column>
-                      <name>em_min</name>
-                      <ucd>em.wl;stat.min</ucd>
-                      <unit>d</unit>
-                      <utype>ts:Char.TimeAxis.Coverage.bounds.Limits.LoLimit</utype>
-                      <dataType xsi:type="vod:TAPType">REAL</dataType>
-                </column>
-                <column>
-                      <name>em_max</name>
-                      <ucd>em.wl;stat.max</ucd>
-                      <unit>d</unit>
-                      <utype>ts:Char.TimeAxis.Coverage.bounds.Limits.HiLimit</utype>
-                      <dataType xsi:type="vod:TAPType">REAL</dataType>
-                </column>
-	</table>
-	<table type="output">
-		<name>coordsys</name>
-		<description>instances of Coordinate systems and Photometry filter </description>
-                <column>
-			<name>pubDID</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<utype>ts:Observation.observationID</utype>
-		</column>
-		<column>
-			<name>TimeScale</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<ucd>time.scale</ucd>
-			<utype>coord:coordsys.TimeFrame.TimeScale</utype>
-		</column>
-		<column>
-			<name>refpositionT</name>
-			<dataType xsi:type="vod:TAPType" arraysize="2">DOUBLE</dataType>
-			<ucd>pos.eq</ucd>
-			<utype>coord:coordsys.TimeFrame.refPosition</utype>
-		</column>
-		<column>
-			<name>SpaceRefFrame</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<ucd>pos.frame</ucd>
-			<utype>coord:coordsys.SpaceFrame.spaceRefFrame</utype>
-		</column>
-		<column>
-			<name>refPositionS</name>
-			<dataType xsi:type="vod:TAPType" arraysize="2">DOUBLE</dataType>
-			<ucd>pos.eq</ucd>
-			<utype>coord:coordsys.SpaceFrame.refPosition</utype>
-		</column>
-		<column>
-			<name>wavelength1</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>em.wl</ucd>
-			<utype>photdm:PhotometryFilter.SpectralAxis.Coverage.Location.Value</utype>
-		</column>
-		<column>
-			<name>filter1</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<ucd>instr.filter</ucd>
-			<utype>photdm:PhotometryFilter.identifier</utype>
-		</column>
-		<column>
-			<name>wavelength2</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>em.wl</ucd>
-			<utype>photdm:PhotometryFilter.SpectralAxis.Coverage.Location.Value</utype>
-		</column>
-		<column>
-			<name>filter2</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<ucd>instr.filter</ucd>
-			<utype>photdm:PhotometryFilter.identifier</utype>
-		</column>
-		<column>
-			<name>wavelength3</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>em.wl</ucd>
-			<utype>photdm:PhotometryFilter.SpectralAxis.Coverage.Location.Value</utype>
-		</column>
-		<column>
-			<name>filter3</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<ucd>instr.filter</ucd>
-			<utype>photdm:PhotometryFilter.identifier</utype>
-		</column>
-		<column>
-			<name>wavelength4</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>em.wl</ucd>
-			<utype>photdm:PhotometryFilter.SpectralAxis.Coverage.Location.Value</utype>
-		</column>
-		<column>
-			<name>filter4</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<ucd>instr.filter</ucd>
-			<utype>photdm:PhotometryFilter.identifier</utype>
-		</column>
-		<column>
-			<name>wavelength5</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>em.wl</ucd>
-			<utype>photdm:PhotometryFilter.SpectralAxis.Coverage.Location.Value</utype>
-		</column>
-		<column>
-			<name>filter5</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<ucd>instr.filter</ucd>
-			<utype>photdm:PhotometryFilter.identifier</utype>
-		</column>
-	</table>
-	<table type="output">
-		<name>coordsys</name>
-		<description>instances of Coordinate systems and Photometry filter </description>
-                <column>
-			<name>pubDID</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<utype>ts:Observation.observationID</utype>
-		</column>
-		<column>
-			<name>TimeScale</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<ucd>time.scale</ucd>
-			<utype>coord:coordsys.TimeFrame.TimeScale</utype>
-		</column>
-		<column>
-			<name>refpositionT</name>
-			<dataType xsi:type="vod:TAPType" arraysize="2">DOUBLE</dataType>
-			<ucd>pos.eq</ucd>
-			<utype>coord:coordsys.TimeFrame.refPosition</utype>
-		</column>
-		<column>
-			<name>SpaceRefFrame</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<ucd>pos.frame</ucd>
-			<utype>coord:coordsys.SpaceFrame.spaceRefFrame</utype>
-		</column>
-		<column>
-			<name>refPositionS</name>
-			<dataType xsi:type="vod:TAPType" arraysize="2">DOUBLE</dataType>
-			<ucd>pos.eq</ucd>
-			<utype>coord:coordsys.SpaceFrame.refPosition</utype>
-		</column>
-		<column>
-			<name>wavelength</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>em.wl</ucd>
-			<utype>photdm:PhotometryFilter.SpectralAxis.Coverage.Location.Value</utype>
-		</column>
-		<column>
-			<name>filter</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<ucd>instr.filter</ucd>
-			<utype>photdm:PhotometryFilter.identifier</utype>
-		</column>
-	</table>
-	<table type="output">
-		<name>TimeSeriesData</name>
-		<description>instanceof TimeSeries Data Class</description>
-		<column>
-			<name>pubDID</name>
-			<dataType xsi:type="vod:TAPType">VARCHAR</dataType>
-			<utype>ts:Observation.observationID</utype>
-		</column>
-		<column>
-			<name>JD</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>time;obs.exposure</ucd>
-			<utype>ts:TimeSeriesData.NDPoint.TimeObservable.TimeMeasure.MJD</utype>
-		</column>
-		<column>
-			<name>MAGV</name>
-			<dataType xsi:type="vod:TAPType">DOUBLE</dataType>
-			<ucd>phot.flux</ucd>
-			<utype>ts:TimeSeriesData.NDPoint.dependantObservedObject.CoordMeasure.PhotometryPoint</utype>
-		</column>
-	</table>
-</schema>
-</vosi:tableset>
-\end{lstlisting}
-\end{small}

Modified: trunk/projects/time-domain/time-series/note/francois.tex
==============================================================================
--- trunk/projects/time-domain/time-series/note/francois.tex	Sun Apr 15 00:46:37 2018	(r4920)
+++ trunk/projects/time-domain/time-series/note/francois.tex	Mon Apr 16 15:24:17 2018	(r4921)
@@ -1,9 +1,9 @@
\subsection{Full utype serialisation}

In this approach, a relational view of the TimeSeries described above is provided. Hierarchies of classes showing 1 to 1 relationships are grouped in one single table. Table x shows the list of tables used to map the model with the full set of their columns metadata ( utype, datatype, ucd, unit and xtype).
-The VODataservice "table" representation of this set of tables is given in Appendix.
+The VODataservice "tableset" representation of this set of tables is described in Appendix.

-The structure is made of 4 "tables" number which seems to be a compromise to separate very differents groups of classes without havng too much of them.
+The structure is made of 4 "tables" number which seems to be a compromise to separate very differents groups of classes without having too much of them.

The main "table" is the data table where the actual values of the independant variable (Time stamps) and of the "one to many" varying variables are stored.

@@ -11,13 +11,13 @@

\begin{itemize}
\item Dataset, curation and dataid classes attributes. This is directly derived from similar concepts in ObsCore and Dataset metadata model.
-\item Characterization describes where and how the the dataset is situated in the physical parameter space; most of the columns there should be redondant with what is in Obscore Char.
+\item Characterization describes where and how the dataset is situated in the physical parameter space; most of the columns there should be redondant with what is in Obscore Char.
\item Coordsys table. This table mainly serializes stc and gathers the coordinate frames (time, space, spectral) used in the TimeSeries as well as the different photometric filter descriptions, assimilated to "flux frames".
\end{itemize}

-Utypes are built by concatenating class and attributes names following a path from a top element to the actual considered leave. They don't desigante a class atrribute per se but a role of the attribute value with respet to the full model.
+Utypes are built by concatenating class and attributes names following a path from a top element to the actual considered leave. They don't designate a class atrribute per se but a role of the attribute value with respet to the full model.

-The table in appendix is an absolute reference for the utypes definition and should be reproduced in the timeSeries model specification.
+Table x and its vodaitaservice tableset expressions  are an absolute reference for the utypes definition and should be reproduced in the timeSeries model specification.

"Tables" mentionned here and described in the Appendix are not required to be serialized as TABLE elements in VOTable. In the case there is only one single TimeSeries in the VOTable document, "generic metadata tables" have only one single instance. They can be serialized as groups and their columns as PARAMS instead of using TABLES with one single row.

@@ -26,20 +26,23 @@
http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/standardized\_votables/\\
/francois/SDSS\_J080434.20+510349.2\_VizieR\_complete\_utypes.xml \\
\end{small}
-This TimeSeries is a light curve for a single SDSS object and his provided as full Catalog in VizieR. It has one single dependant variable : V magnitude.
+This TimeSeries is a light curve for a single SDSS object and is provided as full Catalog in VizieR. It has one single dependant variable : V magnitude.

-Of course most of the  use cases will be much more complex.
+Obviously most of the  use cases will be more complex,
+as in the two following examples

Example 2
is an excerpt of table 3 of the VizieR catalog provided by Shenavrin and coworkers in 2011 (Shenavrin et al, Astronomicheskii Zhurnal, 2011, Vol. 88, No. 1, pp. 34-85.) where the rows present a basic time with a Time Shift for each photometric band.
-. It has a main time as independant variable and several magnitudes in different  bands for the same individual exposure. The exact measurement time is slightly varying according to the band (due to a shift of time for changing the filter) in such a way that several secondary times are given for each main TimeStamp as well.\\
+ It presents a main time as independant variable and several magnitudes in different  bands for the same individual exposure. The exact measurement time is slightly varying according to the band (due to a shift of time for changing the filter) in such a way that several secondary times are given for each main TimeStamp as well.\\
\begin{small}
(http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/standardized\_votables/\\
francois/BetaLyr\_Vizier\_complete\_utypes.xml) \\
\end{small}

-In example 3 where exoplanet data are provided (GASP project) some columns provide flux or radial velocity measurements which have a specific utype in an IVOA model (stc or phot). Some other don't have because the definition of the quantity is outside the scope of STC or photometric datamodel. In that case a generic "meausrement" utype (ts:TimeSeriesData.NDPoint.dependantObservedObject.CoordMeasure.coord) is given and the flavor can be precised with help of the ucd.
+In example 3 where exoplanet data are provided (GAPS project) some columns provide flux or radial velocity measurements which have a specific utype in an IVOA model (stc or phot). Some other don't have because the definition of the quantity is outside the scope of STC or photometric datamodel. In that case a generic "measurement" utype (ts:TimeSeriesData.NDPoint.dependantObservedObject.CoordMeasure.coord) is given and the flavor can be precised with help of the ucd.
+In some other cases the column contains an error on some of these measurements. In that case the utype is set to :
+"

\begin{small}
(http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/standardized\_votables/\\

Modified: trunk/projects/time-domain/time-series/note/laurent.tex
==============================================================================
--- trunk/projects/time-domain/time-series/note/laurent.tex	Sun Apr 15 00:46:37 2018	(r4920)
+++ trunk/projects/time-domain/time-series/note/laurent.tex	Mon Apr 16 15:24:17 2018	(r4921)
@@ -1,8 +1,11 @@
\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.
+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.
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}
@@ -19,7 +22,7 @@
\item VO-DML workflow --
\begin{itemize}
\item Obscure and chatty mapping syntax
-\item Coupling bewteen 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
+\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}

@@ -32,7 +35,7 @@
\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 sample of time domain data.

-The <VODML> block keeps split in 3 sections as shown below.
+The <VODML> block keeps splitting in 3 sections as shown below.

\begin{table}[th]
\begin{center}
@@ -62,7 +65,7 @@
\sptablerule
<VALUE> & Model leaf. Either points to a <PARAM> or a <FIELD> or it has its own value like a literal  \\ \sptablerule
<INSTANCE> & Denotes a class. An <INSTANCE> is a tuple of elements which can be either  <VALUE>, <INSTANCE> or <COLLECTION>  \\ \sptablerule
-   <COLLECTION> & Denotes a list or an array.  A collection can contain  be either  <VALUE>, <INSTANCE> or <COLLECTION> \\\sptablerule
+   <COLLECTION> & Denotes a list or an array.  A collection can contain   either  <VALUE>, <INSTANCE> or <COLLECTION> \\\sptablerule

\end{tabular}
\normalsize
@@ -141,7 +144,7 @@

\subsubsection{Workflow}
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 onj this occasion but possibly reusable as seeds for further developments.
+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 <VODML> block with unresolved references. The tool supports directives specifying which classes must be used in replacement of the abstract ones. The <VODML> block must be inserted by hand in the VOtable to be annotated. It must be split in multiple <TEMPLATES> if data are spread out on muliple tables. The references to actual <FIELD> and <PARAM> must also be set by hand.
@@ -151,7 +154,7 @@
\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 no need to adapt the client code to specific data collection as long as they are are not too much exotic.
+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.

Modified: trunk/projects/time-domain/time-series/note/mireille-td.tex
==============================================================================
--- trunk/projects/time-domain/time-series/note/mireille-td.tex	Sun Apr 15 00:46:37 2018	(r4920)
+++ trunk/projects/time-domain/time-series/note/mireille-td.tex	Mon Apr 16 15:24:17 2018	(r4921)
@@ -1,2 +1,2 @@
\subsection{Mireille}
-This  section presents the Mireille's model
\ No newline at end of file
+This  section presents  Mireille's model