Merge branch 'main' of https://github.com/ivoa-std/architecture

IVOAArchitecture.tex

@@ -1,5 +1,7 @@
 \documentclass[11pt,letter]{ivoa}
-\input tthdefs
+%\documentclass[11pt,letter]{ivoatex/ivoa}
+%\input tthdefs
+\input ivoatex/tthdefs
 
 \newcommand{\xtype}[1]{\texttt{#1}}
 
@@ -16,16 +18,19 @@
 
 \ivoagroup{Technical Coordination Group}
 
-\author{Patrick Dowler}
 \author{Janet Evans}
+\author{Marco Molinaro}
+\author{Patrick Dowler}
 \author{Christophe Arviset}
 \author{Severin Gaudet}
 \author{IVOA Technical Coordination Group}
 
-\editor{Patrick Dowler, Janet Evans}
+\editor{Janet Evans, Marco Molinaro}
 
+\previousversion{IVOAArchitecture-2.0-20211029}
 \previousversion{IVOAArchitecture-1.0-20101123}
 
+
 \begin{document}
 
 \begin{abstract}
@@ -208,7 +213,7 @@ \subsection{CDP}
 
 \subsection{GMS}
 
-The Group Membership Service (GMS, Proposed Recommendation) 
+The Group Membership Service (GMS) \citep{2022ivoa.spec.0222M}
 specification describes a service interface for determining 
 whether a user is a member of a group. Membership information can be used to protect access to 
 proprietary resources. When an authorization decision is needed (whether to grant or deny access 
@@ -250,7 +255,7 @@ \subsection{HiPS}
 
 \subsection{MOC}
 
-The Multi-Order Coverage Map (MOC) \citep{2019ivoa.spec.1007F} is a method to specify coverage as an arbitrary sky regions. 
+The Multi-Order Coverage Map (MOC) \citep{2022ivoa.spec.0727F} is a method to specify coverage as an arbitrary sky regions. 
 The goal is to be able to provide a very fast comparison mechanism between coverage maps. 
 The mechanism is based on the HEALPix sky tessellation algorithm. It is essentially a 
 simple way to map regions of the sky into hierarchically grouped predefined cells. 
@@ -306,7 +311,7 @@ \section{Semantics Standards}
 
 \subsection{Vocabularies}
 
-Vocabularies in the VO is a Recommendation for how to build and use
+Vocabularies in the VO \citep{2021ivoa.spec.0525D} describes how to build and use
 consensus vocabularies in the Virtual Observatory.  It supports both
 ``soft'' vocabularies based on the Simple Knowledge Organisation System
 SKOS and ``hard'' vocabularies based on RDF schema, where the latter
@@ -323,7 +328,7 @@ \subsection{Vocabularies}
 
 \subsection{VOUnits}
 
-VOUnits \citep{2014ivoa.spec.0523D} describes how to serialise unit strings within the Virtual
+VOUnits \citep{2023ivoa.spec.1215G} describes how to serialise unit strings within the Virtual
 Observatory, in particular (but by no means limited to) in the
 \xmlel{unit} attribute in VOTable.  It hence defines the atomic units,
 prefixes applicable, and the syntax of expressions using such prefixed
@@ -396,7 +401,7 @@ \subsection{VOResource}
 
 \subsection{VODataService}
 
-The VODataService \citep{2010ivoa.spec.1202P} standard makes discovery possible.  It is an encoding standard that enables one to 
+The VODataService \citep{2021ivoa.spec.1102D} standard makes discovery possible.  It is an encoding standard that enables one to 
 describe how the data underlying the resource covers the sky as well as their frequency and time. 
 VODataService also enables detailed descriptions of tables that include information useful to the 
 discovery of tabular data. 
@@ -429,7 +434,7 @@ \subsection{RegTAP}
 
 \subsection{SimpleDALRegExt}
 
-Describing Simple Data Access Services (SimpleDALRegExt) \citep{2017ivoa.spec.0530P} 
+Describing Simple Data Access Services (SimpleDALRegExt) \citep{2022ivoa.spec.0222D} 
 is part of the registry standards that make discovery of Simple DAL services 
 possible (e.g., SIAP, SCS, SSAP, SLAP).  SimpleDALRegExt refers to an encoding standard for a 
 specialized extension of the IVOA Resource Metadata that is useful for describing VO Simple DAL 
@@ -492,6 +497,11 @@ \subsection{VO-DML}
 side effect allows the creation and use of standards compliant data models outside of the 
 IVOA standards context. 
 
+\subsection{MIVOT} 
+
+The Model Instances in VOTables (MIVOT) \citep{2023ivoa.spec.0620M} defines a syntax to map VOTable data to any model serizalized in VO-DML. The annotation operates as a bridge between the data and the model. It associates the column/param metadata from the VOTable to the data model elements (class, attributes, types, etc.) of a standardized IVOA data model, expressed in the Virtual Observatory Data Modeling Language (here after VO-DML). It also brings up VOTable data or metadata that were possibly missing in the table metadata. The data model elements are grouped in an independent annotation block complying with the MIVOT XML syntax. This annotation block is added as an extra resource element at the top of the VOTable result resource. The MIVOT syntax allows to describe a data structure as a hierarchy of classes. It is also able to represent relations and composition between them.It can also build up data model objects by aggregating instances from different tables of the VOTable. Missing metadata can also be provided using MIVOT, for instance by completing coordinate system description, or by providing curation tracing. The annotation block is made of re-usable bricks that facilitate the development of tools on both client and server sides. The adopted design does not alter the original VOTable content. The backward compatibility is preserved thanks to the limited impact of the annotations on legacy clients.
+
+
 \subsection{CharDM} 
 
 The Characterisation Data Model (CharDM) \citep{2008ivoa.spec.0325L} defines the high level metadata necessary to describe the 
@@ -527,7 +537,7 @@ \subsection{ObsCoreDM}
 
 \subsection{PhotDM}
 
-The Photometry Data Model (PhotDM) \citep{2013ivoa.spec.1005S} describes photometry filters, photometric systems, magnitude 
+The Photometry Data Model (PhotDM) \citep{2022ivoa.spec.1101S} describes photometry filters, photometric systems, magnitude 
 systems, zero points and its interrelation with the other IVOA data models through a 
 simple data model. Particular attention is given necessarily to optical photometry where 
 specifications of magnitude systems and photometric zero points are required to convert 
@@ -569,7 +579,7 @@ \subsection{SSLDM}
 
 \subsection{SpectralDM}
 
-The Spectral Data Model \citep{2007ivoa.spec.1029M} describes the structure of spectrophotometric datasets with spectral and 
+The Spectral Data Model \citep{2023ivoa.spec.1215C} describes the structure of spectrophotometric datasets with spectral and 
 temporal coordinates and associated metadata. This data model may be used to represent spectra, 
 time series data, segments of SED (Spectral Energy Distributions) and other spectral or temporal 
 associations. 
@@ -604,18 +614,18 @@ \subsection{STC}
 STC and certain other parts of the Data Model. Two serializations are discussed: XML (STC-X) and
 ascii string (STC-S); the former is an integral part of the model.
 
-\subsection{Coords}
+\subsection{Coordinates}
 
-The Coordinates Data Model (Proposed Recommendation) 
+The Coordinates Data Model \citep{2022ivoa.specQ1004R} 
 covers the following concepts: description of single and multi-dimensional 
 coordinate space and coordinates within that space, cordinate frames providing metadata describing the 
 origin and orientation of the coordinate space, the definition of simple domain-specific coordinate
 types for the most common use cases, and description of the coordinate systems domain space. This
 model is a refactored subset of the original STC data model.
 
-\subsection{Meas}
+\subsection{Measurements}
 
-The Measurements Data Model (Proposed Recommendation)
+The Measurements Data Model \citep{2022ivoa.spec.1004R} 
 covers the description of measured or determined astronomical data 
 to enable the association of the determined ``value'' with corresponding errors. In this model, 
 the ``value'' is given by the various coordinate types of the coordinates data model plus a 
@@ -669,7 +679,7 @@ \section{Data Access Standards}
 
 \subsection{ADQL}
 
-The Astronomical Data Query Language (ADQL) \citep{2008ivoa.spec.1030O} has been developed based on SQL92. This document 
+The Astronomical Data Query Language (ADQL) \citep{2023ivoa.spec.1215M} has been developed based on SQL92. This document 
 describes the subset of the SQL grammar supported for querying relational tablesets within the VO. Special restrictions and 
 extensions to SQL92 have been defined in order to support generic and astronomy 
 specific operations. 
@@ -694,7 +704,7 @@ \subsection{DALI}
 
 \subsection{DataLink}
 
-The DataLink \citep{2015ivoa.spec.0617D} API specification describes the linking of data discovery metadata to  
+The DataLink \citep{2023ivoa.spec.1215B} API specification describes the linking of data discovery metadata to  
 the data itself, further detailed metadata, related resources, and to services that perform 
 operations on the data. The web service capability supports a drill-down into the details 
 of a specific dataset and provides a set of links to the dataset file(s) and related resources. 
@@ -783,6 +793,7 @@ \subsection{SODA}
 
 \subsection{TAP}
 \label{dal:tap}
+\label{epn:tap}
 
 The Table Access Protocol (TAP) \citep{2019ivoa.spec.0927D} defines a service protocol for accessing general table data, 
 including astronomical catalogs as well as general database tables. Access is provided 
@@ -796,6 +807,11 @@ \subsection{TAP}
 cross-matching capabilities are possible by orchestrating a distributed query across 
 multiple TAP services. 
 
+\subsection{EPN-TAP}
+
+The EPN-TAP protocol  \citep{2022ivoa.spec.0822E} defines a service protocol for describing and accessing data related to the study of the Solar System in general, including observational, modeled, and experimental data. It consists of 1) the usual TAP mechanism; 2) the EPNcore metadata dictionary; 3) a set of rules defining table structure and parameter usage. EPN-TAP relies on the TAP  standard ({Sec.~\ref{epn:tap}) with no modification. All EPN-TAP services are accessible through standard TAP clients.
+
+
 \subsection{VTP}
 
 The VOEvent Transport Protocol (VTP) \citep{2017ivoa.spec.0320S} formalizes a TCP-based protocol for VOEvent transportation 
@@ -869,6 +885,8 @@ \section{Acronym Lookup Table}
         {Data Access Layer Interface - common components standard} \\
         {DataLink} &
         {Data Link - linking metadata to data standard} \\
+       {EPN-TAP} &
+       {Solar System Table access protocol} \\
         {GMS} &
         {Group Membership Service - standard} \\
         {HiPS} &
@@ -879,6 +897,8 @@ \section{Acronym Lookup Table}
         {International Virtual Observatory Alliance} \\
         {Meas} &
         {Measurements - astronomical measurements standard} \\
+        {MIVOT} &
+        {MIVOT - model instances in VO tables} \\
         {MOC} &
         {Multi-Order Coverage - metadata standard} \\
         {ObsCoreDM} &

Makefile

@@ -6,13 +6,13 @@
 DOCNAME = IVOAArchitecture
 
 # count up; you probably do not want to bother with versions <1.0
-DOCVERSION = 2.0
+DOCVERSION = 2.1
 
 # Publication date, ISO format; update manually for "releases"
-DOCDATE = 2021-10-29
+DOCDATE = 2024-09-10
 
 # What is it you're writing: NOTE, WD, PR, or REC
-DOCTYPE = EN
+DOCTYPE = NOTE
 
 # Source files for the TeX document (but the main file must always
 # be called $(DOCNAME).tex

archdiag-full.xml

@@ -58,43 +58,43 @@ of the various sections) to have the box centered.
 	<rec name="DALI" x="310" y="290" w="33"/>
 	<rec name="ADQL" x="250" y="160" w="37"/>
 
-    <rec name="ConeSearch" x="665.5" y="155" w="69"/>
+        <rec name="ConeSearch" x="665.5" y="155" w="69"/>
 	<rec name="SSAP" x="682" y="180" w="36"/>
 	<rec name="SLAP" x="682.5" y="205" w="35"/>
 	<rec name="SIAP" x="683.5" y="230" w="33"/>
-    <rec name="TAP" x="686" y="255" w="28"/>
-    <prerec name="ObjVisSAP" x="667" y="330" w="66"/>
+        <rec name="TAP" x="686" y="255" w="28"/>
+        <prerec name="ObjObsSAP" x="667" y="330" w="66"/>
 	<rec name="SimDAL" x="676" y="355" w="48"/>
 	<rec name="VTP" x="684" y="380" w="30.5"/>
 	<rec name="DataLink" x="628" y="405" w="53"/>
 	<rec name="SODA" x="681" y="430" w="38"/>
 	<rec name="ObsCore" x="619" y="180" w="52"/>
-	<prerec name="EPN-TAP" x="617.5" y="205" w="55"/>
+	<rec name="EPN-TAP" x="617.5" y="205" w="55"/>
 	<rec name="ObsLocTAP" x="612" y="230" w="66"/>
 
 	<!-- Data Models: x=430..580, y=250..400 -->
 	<prerec name="VODML-Map" x="440" y="355" w="72"/>
 	<rec name="VODML" x="512" y="195" w="46"/>
 	<rec name="SimDM" x="473" y="230" w="44"/>
-	<rec name="STC" x="580" y="255" w="30"/>
 	<rec name="CharDM" x="470.5" y="255" w="49"/>
 	<rec name="SSLDM" x="572.5" y="280" w="45"/>
 	<rec name="SpectralDM" x="461.5" y="280" w="67"/>
 	<rec name="PhotDM" x="571" y="305" w="48"/>
-	<prerec name="Meas" x="456" y="305" w="35"/>
-	<prerec name="Coords" x="501" y="305" w="44"/>
+	<rec name="Meas" x="456" y="305" w="35"/>
+	<rec name="Coords" x="501" y="305" w="44"/>
 	<prerec name="Transform" x="465" y="330" w="60"/>
 	<prerec name="DatasetDM" x="490" y="380" w="65"/>
 	<prerec name="CubeDM" x="497" y="405" w="51"/>
 	<rec name="ProvDM" x="571" y="330" w="48"/>
+	<rec name="MIVOT" x="500" y="430"  w="46"/>	
 
 	<!-- GWS: all over the place -->
 	<rec name="PDL" x="430" y="380" w="33"/>
 	<rec name="SSO" x="450" y="115" w="31"/>
 	<rec name="VOSpace" x="173" y="455" w="54"/>
 	<rec name="CDP" x="500" y="115" w="31"/>
 	<rec name="UWS" x="633.5" y="460" w="33"/>
-	<prerec name="GMS" x="534" y="460" w="32"/>
+	<rec name="GMS" x="534" y="460" w="32"/>
 	<rec name="VOSI" x="568" y="435" w="34"/>
 
 	<!-- Semantics: x=160..250 y=250..400 -->