Apps review

.github/workflows/preview.yml

@@ -18,7 +18,7 @@ on:
     branches:
       - master
       - wd-v1.0
-      - draft-0.1
+      - apps-review
       - pr-1.0
 
 jobs:

.gitignore

@@ -59,4 +59,4 @@ pom.xml.tag
 
 trash/*
 exercise*
-test-date
+test-date/*

doc/MANGO.tex

@@ -207,8 +207,9 @@ \subsection{Requirements}
 
     \item Multi-columns quantities
        \begin{itemize}[noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt]
-          \item MANGO must be able to provide an accurate description of properties which attributes are spread 
-                out on multiple columns (e.g. positions, errors).
+          \item	MANGO needs to provide accurate description of multi-attribute properties (e.g. positions, errors).
+				Whether these are stored in separate columns and need to be linked back is an implementation detail
+				that it’s being taken care by MIVOT. 
           \item MANGO must be able to describe errors with the most common shapes (symmetric values, correlation 
                 or covariance matrices, ellipses), all with different confidence levels. 
                 Such complex quantities cannot be reconstructed from simple field descriptions, but with a model
@@ -225,11 +226,12 @@ \subsection{Requirements}
 
     \item Connection of quantities : 
        \begin{itemize}[noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt]
-           \item MANGO must be able to setup links between different properties of the same table. 
+           \item MANGO must be able to setup links between different properties of the same MANGO object. 
                  This can be relevant for instance for attaching detection likelihoods with source positions
                  or to tag properties with timestamps.
-           \item MANGO must be able to link MANGO instances to each other, allowing for instance to connect one 
-                 source with all of its detections.
+           \item MANGO must be able to link different objects. For example,
+		         it should be possible to connect sources with their detections,
+				 with both being represented as separate MANGO objects.
         \end{itemize}   
 \end{itemize}
 
@@ -325,37 +327,28 @@ \subsubsection{Property Identification}
 
 \subsubsection{MANGO and MIVOT: 2 Strategies for Structuring Tabular Data}
 
-MANGO is primarily used to organise tabular data provided by TAP services \citep{2019ivoa.spec.0927D} 
-other DAL nodes (one of the reference implementation is based on a Vizier SCS).
-To achieve this, table rows must be linked to the model using MIVOT annotations.
-We propose two strategies for establishing this mapping:
-\begin{itemize}[noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt]
-    \item Single Object per Row: Each table row is treated as a single object, a \texttt{MangoObject} instance.
-          with its properties grouped within a container or dock.
-    \item Scattered Independent Quantities: Each table row is considered as a collection of independent quantities.
-\end{itemize}
-\hfill \break
-
-MIVOT annotations support both approaches:
+MANGO is used to represent catalogue data which are typically provided in tabular
+form by TAP services \citep{2019ivoa.spec.0927D} 
+or other DAL nodes (one of the reference implementation is based on a Vizier SCS).
+The linking between MANGO instances and table row elements is provided by MIVOT annotations.
+There are two possible strategies for establishing this mapping:
 
 \begin{itemize}[noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt]
-    \item MANGO as a Global View: This configuration enables full utilisation of the 
-          model's features. Properties can be interconnected, data rows can be identified
-          and treated as individual entities (MANGO objects) that can be linked together to describe,
-          for example, sources with their detections or orbiting systems.
-          This approach allows for serialisation formats like XML or JSON, which often require
-          a unique root.
-          However, the annotation process might be slightly more complex due to additional class levels.
-    \item MANGO as a Sparse Parameter View: In this simpler approach, the data mapping is a
-          flat set of independent objects. Clients can iterate through these objects and process
+    \item \textit{MANGO as a Global View}: Each table row is treated as a single object,
+	      a \texttt{MangoObject} instance. 
+		  Modelled quantities are then grouped within a container, the MANGO property dock. 
+		  This approach makes full use of the model's features.
+		  Properties can be linked together to describe entities, such as sources and their detections,
+		  or orbiting systems.
+		  This approach allows serialisation formats such as XML or JSON, which require a unique root.
+    \item \textit{MANGO as a Sparse Parameter View}: Each table row is treated as a flat set of independent
+	      model components (the MANGO properties).
+          Clients can iterate through these objects and process
           the entities of interest individually.
-          It's important to note that such a client could also handle data mapped to the full MANGO schema.
-          The annotation process might be less complex on the server side.
 \end{itemize}
 
-This document does not favour one approach over the other.
-The decision ultimately rests with the data providers.
-However, both options are based on the full-featured MANGO model.
+This standard does not favour one approach over the other.
+The decision ultimately rests with the implementers.
 
 %\input{model.tex}
 \input{model_toc.tex}

doc/Makefile

@@ -7,7 +7,7 @@ DOCNAME = MANGO
 DOCVERSION = 1.0
 
 # Publication date, ISO format; update manually for "releases"
-DOCDATE = 2025-08-07
+DOCDATE = 2025-12-18
 
 # What is it you're writing: NOTE, WD, PR, REC, PEN, or EN
 DOCTYPE = PR

doc/ivoatexmeta.tex

@@ -1,7 +1,7 @@
 % GENERATED FILE -- edit this in the Makefile
 \newcommand{\ivoaDocversion}{1.0}
-\newcommand{\ivoaDocdate}{2025-08-07}
-\newcommand{\ivoaDocdatecode}{20250807}
+\newcommand{\ivoaDocdate}{2025-12-18}
+\newcommand{\ivoaDocdatecode}{20251218}
 \newcommand{\ivoaDoctype}{PR}
 \newcommand{\ivoaDocname}{MANGO}
 \renewcommand{\ivoaBaseURL}{https://www.ivoa.net/documents/MANGO}

doc/model.tex

@@ -34,7 +34,7 @@ \section{Model: mango }
   %\end{center}
   %\end{figure}
 
-  The purpose of MANGO, which stands for MO-del for AN-notating G-eneric O-objects, is to add an upper level of description to the tabular data of query responses. It allows metadata to be extended, complex quantities to be reconstructed from column values, and properties to be linked. It also allows to specify the origin af the data.
+  The purpose of MANGO is to provide a higher level of description for multi-attribute properties. When used with MIVOT annotations, it enables tabular data to be represented as structured objects. This enables the metadata representation to be improved and complex quantities to be reconstructed from column values. Modelled properties can be linked to each other. MANGO also enables the origin of the data to be specified.
 
   \subsection{AssociatedMangoObject}
   \label{sect:AssociatedMangoObject}
@@ -166,7 +166,7 @@ \section{Model: mango }
       \textbf{vodml-id: DateTime.dateTime} \newline
       \textbf{type: \hyperref[sect:ivoa]{ivoa:datetime}} \newline
       \textbf{multiplicity: 1} \newline
-      The timestamp value is always given as a string. The way to process this string is given by the representation mode. It can represent an ISO date or a real value (e.g. for MJD mjd timestamps).
+      Data type for timestamps and their representation. Timestamps are modeled by a single value and a representation mode. There is no time scale associated with \texttt{mango:DateTime}. The scale is either imposed by the representation mode or defined by the time coordinate system relevant for the host object,
 
   \subsection{EpochPosition}
 
@@ -184,13 +184,13 @@ \section{Model: mango }
       \textbf{vodml-id: EpochPosition.longitude} \newline
       \textbf{type: \hyperref[sect:ivoa]{ivoa:RealQuantity}} \newline
       \textbf{multiplicity: 1} \newline
-      This parameter is a clone of the \texttt{coords:LonLatPoint.lat} component of \texttt{meas:Position} but applied to the \texttt{mango:EpochPosition} context. It matches the description given by \texttt{coords} data model: The longitude of the Point, as a Quantity with angular units (see \texttt{coords:LonLatPoint.lon}.
+      This parameter corresponds to the longitude as described by the \texttt{coords} data model: \textit{The longitude of the Point, as a Quantity with angular units} (see \texttt{coords:LonLatPoint.lon}). It is a clone of the \texttt{coords:LonLatPoint.lon} component of \texttt{meas:Position} but applied to the \texttt{mango:EpochPosition} context.
 
     \subsubsection{EpochPosition.latitude}
       \textbf{vodml-id: EpochPosition.latitude} \newline
       \textbf{type: \hyperref[sect:ivoa]{ivoa:RealQuantity}} \newline
       \textbf{multiplicity: 1} \newline
-      This parameter is a clone of the \texttt{coords:LonLatPoint.lat} component of \texttt{meas:Position} but applied to the \texttt{mango:EpochPosition} context. It matches the description given by \texttt{coords} data model: The latitude of the Point, as a Quantity with angular units (see \texttt{coords:LonLatPoint.lon}).
+      This parameter corresponds to the latitude as described by the \texttt{coords} data model: \textit{The latitude of the Point, as a Quantity with angular units} (see \texttt{coords:LonLatPoint.lat}). It is a clone of the \texttt{coords:LonLatPoint.lat} component of \texttt{meas:Position} but applied to the \texttt{mango:EpochPosition} context. It matches the description given by \texttt{coords} data model:
 
     \subsubsection{EpochPosition.parallax}
       \textbf{vodml-id: EpochPosition.parallax} \newline
@@ -202,28 +202,28 @@ \section{Model: mango }
       \textbf{vodml-id: EpochPosition.radialVelocity} \newline
       \textbf{type: \hyperref[sect:ivoa]{ivoa:RealQuantity}} \newline
       \textbf{multiplicity: 1} \newline
-      This parameter is a clone of the \texttt{coords:Coords.point} component of \texttt{meas:Velocity} but applied to the \texttt{mango:EpochPosition} context. It matches the description given by the \texttt{coords} data model: The measured Velocity along of the radial axis (see \texttt{meas:Velocity.coord} in \cite{2022ivoa.spec.1004R}).
+      This parameter corresponds to the radial velocity as described by the \texttt{coords} data model: \textit{The measured Velocity along of the radial axis } (see \texttt{meas:Velocity.coord} in \cite{2022ivoa.spec.1004R}). It is a clone of the \texttt{coords:Coords.point} component of \texttt{meas:Velocity} but applied to the \texttt{mango:EpochPosition} context.
 
     \subsubsection{EpochPosition.pmLongitude}
       \textbf{vodml-id: EpochPosition.pmLongitude} \newline
       \textbf{type: \hyperref[sect:ivoa]{ivoa:RealQuantity}} \newline
       \textbf{multiplicity: 1} \newline
-      This parameter is a clone of the \texttt{coords:LonLatPoint.lon} component of \texttt{meas:ProperMotion} but applied to the \texttt{mango:EpochPosition} context. It matches the description given by \texttt{coords} data model: Velocity along the longitude axis in angular distance per unit time (see \texttt{meas:ProperMotion.coord}).
+      This parameter corresponds to the proper motion longitude as described by the \texttt{coords} data model: \textit{Velocity along the longitude axis in angular distance per unit time} (see \texttt{meas:ProperMotion.coord}). It is a clone of the \texttt{coords:LonLatPoint.lon} component of \texttt{meas:ProperMotion} but applied to the \texttt{mango:EpochPosition} context.
 
     \subsubsection{EpochPosition.pmLatitude}
       \textbf{vodml-id: EpochPosition.pmLatitude} \newline
       \textbf{type: \hyperref[sect:ivoa]{ivoa:RealQuantity}} \newline
       \textbf{multiplicity: 1} \newline
-      This parameter is a clone of the \texttt{coords:LonLatPoint.lat} component of \texttt{meas:ProperMotion} but applied to the \texttt{mango:EpochPosition} context. It matches the description given by \texttt{coords} data model: Velocity along the latitude axis in angular distance per unit time (see \texttt{meas:ProperMotion.coord}).
+      This parameter corresponds to the proper motion latitude as described by the \texttt{coords} data model: \textit{Velocity along the latitude axis in angular distance per unit time} (see \texttt{meas:ProperMotion.coord}). It is a clone of the \texttt{coords:LonLatPoint.lat} component of \texttt{meas:ProperMotion} but applied to the \texttt{mango:EpochPosition} context.
 
     \subsubsection{EpochPosition.obsDate}
       \textbf{vodml-id: EpochPosition.obsDate} \newline
       \textbf{type: \hyperref[sect:ivoa]{ivoa:datetime}} \newline
       \textbf{multiplicity: 1} \newline
       Observation date expressed within the common time system if present. This attribute, if set, supersedes the epoch possibly given with the spatial coordinate system (see the above). Figure \ref{datetime} shows up the hierarchy of the primitive types representing the observation dates.
 
-    \subsubsection{EpochPosition.pmCosLat\_applied}
-      \textbf{vodml-id: EpochPosition.pmCosLat\_applied} \newline
+    \subsubsection{EpochPosition.pmCosLatApplied}
+      \textbf{vodml-id: EpochPosition.pmCosLatApplied} \newline
       \textbf{type: \hyperref[sect:ivoa]{ivoa:boolean}} \newline
       \textbf{multiplicity: 1} \newline
       It is common, though not universal, practice to quote longitudinal proper motion pre-multiplied by cos(latitude) so that the magnitude of the quantity is not affected by its longitudinal position. We do not constrain the value to one form or the other in this model. Instead, this flag enables providers to convey whether or not the factor has been applied (see \texttt{meas:ProperMotion.cosLat\_applied})
@@ -430,16 +430,11 @@ \section{Model: mango }
   \label{sect:Property}
     Class holder for a \textit{flavor} of property’ ie: there should be a Property subclass for each \textit{flavor} of Property being hosted. The property types are not limited to “physical or calculated” (eg: flags, assigned labels) This class specifies both type and role of the property, and hosts the property instance itself.
 
-    \noindent \textbf{constraint} \newline
-    \indent    \textbf{detail: Property.One association at the time
- }\newline
-
-
     \subsubsection{Property.semantics}
       \textbf{vodml-id: Property.semantics} \newline
       \textbf{type: \hyperref[sect:VocabularyTerm]{mango:VocabularyTerm}} \newline
       \textbf{multiplicity: 0..1} \newline
-      Reference to a semantic concept giving the nature of the property or of the set made of the property and its associated properties. The semantics field contains a URI for a concept that describes the meaning of the property. This attribute is intended to be machine-readable and to assist automated link selection, presentation, and usage. The value is always interpreted as a URI; relative URIs (Berners-Lee and Fielding et al., 2005) are completed using the base URI of the core DataLink vocabulary, http://www.ivoa.net/rdf/datalink/core. Terms from this vocabulary must always be written as relative URIs. This means that for concepts from the core vocabulary, the value in the semantics fieldz always starts with a hash. (datalink1.1). The semantics concept applies to a single property or to the set made of the property and its associated properties (e.g. position and flag).
+      Reference to a semantic concept giving the nature of the property or of the set made of the property and its associated properties. The semantics field contains a URI for a concept that describes the meaning of the property. This attribute is intended to be machine-readable and to assist automated link selection, presentation, and usage. The value is always interpreted as a URI; relative URIs (Berners-Lee and Fielding et al., 2005) are completed using the base URI of the core DataLink vocabulary, \url{http://www.ivoa.net/rdf/datalink/core}. Terms from this vocabulary must always be written as relative URIs. This means that for concepts from the core vocabulary, the value in the semantics fields always starts with a hash. (datalink1.1). The semantics concept applies to a single property or to the set made of the property and its associated properties (e.g. position and flag).
 
     \subsubsection{Property.description}
       \textbf{vodml-id: Property.description} \newline
@@ -525,7 +520,7 @@ \section{Model: mango }
 
   \subsection{jd}
   \label{sect:jd}
-  Primitive type for observation dates expressed as a Julian Date (e.g. 25213).
+  Primitive type for observation dates expressed as a Julian Date (e.g. 2460895.1).
 
   \subsection{FootprintSerialization}
   \label{sect:FootprintSerialization}