From ec1ce5124670ce5672dedb908aef0d510172a63e Mon Sep 17 00:00:00 2001 From: Patrick Dowler Date: Fri, 18 Sep 2026 12:15:22 -0700 Subject: [PATCH 1/2] start WD-ObsCore-1.2 comment out data model section and create new sections to establish doc structure add some TODO items for content that should move --- Makefile | 6 +++--- ObsCore.tex | 25 ++++++++++++++++++++++++- 2 files changed, 27 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index b5470a3..c1456b6 100644 --- a/Makefile +++ b/Makefile @@ -5,13 +5,13 @@ DOCNAME = ObsCore # count up; you probably do not want to bother with versions <1.0 -DOCVERSION = 1.1 +DOCVERSION = 1.2 # Publication date, ISO format; update manually for "releases" -DOCDATE = 2017-05-09 +DOCDATE = 2026-09-18 # What is it you're writing: NOTE, WD, PR, REC, PEN, or EN -DOCTYPE = REC +DOCTYPE = WD # An e-mail address of the person doing the submission to the document # repository (can be empty until a make upload is being made) diff --git a/ObsCore.tex b/ObsCore.tex index a688105..c487ca1 100644 --- a/ObsCore.tex +++ b/ObsCore.tex @@ -285,6 +285,7 @@ \subsection{The goal of this effort} %Fig.~\ref{fig:archdiag} shows the role this document plays within the %IVOA architecture \citep{2021ivoa.spec.1101D}. +\iffalse % temporarily hide data model section \section[Observation Core Components Data Model]{Observation Core Components Data Model} \label{sec:core-components}This section highlights and describes the core components of the Observation data model, synthetized today in the Dataset Metadata DM specification. The term ``core components'' is meant to refer to those @@ -583,8 +584,18 @@ \subsubsection{File Content and Format} analysis. See section \ref{bkm:Ref289893457} for more details and implementation requirements. +\fi % temporarily hide data model section + +\section{ObsCore Table Model} + +ObsCore defines a simple set of core attributes to be included in a single table. This table structure can be +implemented in various services. + +TODO: move core specification content from next section here \section{Implementation of ObsCore in a TAP Service} +TODO: TAP-specific details here + \label{sec:obstap-impl}The ObsCore model must be implemented within Table Access Protocol (TAP) services such that all valid queries can be executed unchanged on any service that implements the model. Additional optional or provider-defined columns are permitted (see section \ref{bkm:Ref421295535}) so long as all mandatory columns are @@ -983,7 +994,19 @@ \subsection{Additional Columns} as optional. ObsTAP compliant services will support all columns defined as mandatory and possibly some of the optional ones. Queries built up using additional columns defined specifically for a given archive might not be portable. -\section{Registering an ObsTAP Service} +\section{ObsCore Extensions} +The ObsCore table includes common metadata attributes that are applicable to a wide range of astronomical data. +Additional details that are not common enough to be included in core may be defined as extensions that support +data discovery use cases for specific kinds of data. + +TODO: extension mechanism + +\section{Registering ObsCore and Extension Tables} +TODO: write this section following current practice and remove the next section. + +\section{OBSOLETE: Registering an ObsTAP Service} +TODO: remove when previous section makes it obsolete + \label{sec:obstap-register}The standard identifier for this version of the ObsCore model now follows the IVOA Identifiers v2.0 specification \citep{2016ivoa.spec.0523D} and should be ivo://ivoa.net/std/ObsCore\#core-1.1 From 22f7ced3c78bbd3980d50aa678b7fb035dd3fabc Mon Sep 17 00:00:00 2001 From: Patrick Dowler Date: Fri, 25 Sep 2026 08:49:02 -0700 Subject: [PATCH 2/2] moved core field descriptions to table model section moved ObsCore Extensions section up --- ObsCore.tex | 178 ++++++++++++++++++++++++++-------------------------- 1 file changed, 88 insertions(+), 90 deletions(-) diff --git a/ObsCore.tex b/ObsCore.tex index c487ca1..4607274 100644 --- a/ObsCore.tex +++ b/ObsCore.tex @@ -591,89 +591,6 @@ \section{ObsCore Table Model} ObsCore defines a simple set of core attributes to be included in a single table. This table structure can be implemented in various services. -TODO: move core specification content from next section here - -\section{Implementation of ObsCore in a TAP Service} -TODO: TAP-specific details here - -\label{sec:obstap-impl}The ObsCore model must be implemented within Table Access Protocol (TAP) services such that all -valid queries can be executed unchanged on any service that implements the model. Additional optional or -provider-defined columns are permitted (see section \ref{bkm:Ref421295535}) so long as all mandatory columns are -provided. The protocol does not specify any specific ordering of fields in the query response so long as the mandatory -parameters are present in the output stream. - -Here we specify an explicit mapping of the model to relational database tables; in the context of TAP this means we are -specifying the logical tables as described in the TAP\_SCHEMA (the TAP-required database schema where the tables and -columns exposed by the service are described). This does not necessarily imply that the underlying database will have -the identical structure (what is exposed through TAP could be, for example, a database view of the underlying database -tables), but in most cases the relationship between TAP\_SCHEMA description and the underlying tables is -straightforward. - -%\begin{table}[h] -%\begin{center} -\begin{tabularx}{\textwidth}{|p{0.2\textwidth}|p{0.2\textwidth}|p{0.4\textwidth}|} -\hline -schema\_name & table\_name & Description\\\hline -ivoa & ivoa.ObsCore & ObsCore 1.1\\\hline -\caption{TAP\_SCHEMA.tables for implementation of the ObsCore model.} -\label{tab:3} -\end{tabularx} -%\end{center} -%\end{table} - -%\begin{table}[h] -%\begin{center} -\begin{tabularx}{\textwidth}{|p{0.18\textwidth}|p{0.25\textwidth}|p{0.22\textwidth}|p{0.07\textwidth}|p{0.14\textwidth}|} -\hline -table\_name & column\_name & data type & units & Constraint\\\hline -ivoa.ObsCore & dataproduct\_type & adql:VARCHAR & & \\\hline -ivoa.ObsCore & calib\_level & adql:INTEGER & & not null\\\hline -ivoa.ObsCore & obs\_collection & adql:VARCHAR & & not null\\\hline -ivoa.ObsCore & obs\_id & adql:VARCHAR & & not null\\\hline -ivoa.ObsCore & obs\_publisher\_did & adql:VARCHAR & & not null\\\hline -ivoa.ObsCore & access\_url & adql:CLOB & & \\\hline -ivoa.ObsCore & access\_format & adql:VARCHAR & & \\\hline -ivoa.ObsCore & access\_estsize & adql:BIGINT & kbyte & \\\hline -ivoa.ObsCore & target\_name & adql:VARCHAR & & \\\hline -ivoa.ObsCore & s\_ra & adql:DOUBLE & deg & \\\hline -ivoa.ObsCore & s\_dec & adql:DOUBLE & deg & \\\hline -ivoa.ObsCore & s\_fov & adql:DOUBLE & deg & \\\hline -ivoa.ObsCore & s\_region & adql:REGION & & \\\hline -ivoa.ObsCore & s\_resolution & adql:DOUBLE & arcsec & \\\hline -ivoa.ObsCore & s\_xel1 & adql:BIGINT & & \\\hline -ivoa.ObsCore & s\_xel2 & adql:BIGINT & & \\\hline -ivoa.ObsCore & t\_min & adql:DOUBLE & d & \\\hline -ivoa.ObsCore & t\_max & adql:DOUBLE & d & \\\hline -ivoa.ObsCore & t\_exptime & adql:DOUBLE & s & \\\hline -ivoa.ObsCore & t\_resolution & adql:DOUBLE & s & \\\hline -ivoa.ObsCore & t\_xel & adql:BIGINT & & \\\hline -ivoa.ObsCore & em\_min & adql:DOUBLE & m & \\\hline -ivoa.ObsCore & em\_max & adql:DOUBLE & m & \\\hline -ivoa.ObsCore & em\_res\_power & adql:DOUBLE & & \\\hline -ivoa.ObsCore & em\_xel & adql:BIGINT & & \\\hline -ivoa.ObsCore & o\_ucd & adql:VARCHAR & & \\\hline -ivoa.ObsCore & pol\_states & adql:VARCHAR & & \\\hline -ivoa.ObsCore & pol\_xel & adql:BIGINT & & \\\hline -ivoa.ObsCore & facility\_name & adql:VARCHAR & & \\\hline -ivoa.ObsCore & instrument\_name & adql:VARCHAR & & \\\hline -\caption{List of the minimal set of data model fields to -implement for an ObsTAP service. See tables of Appendix C for the full description of the TAP\_SCHEMA.columns table.} -\label{tab:4} -\end{tabularx} -%\end{center} -%\end{table} -%\vspace{0.3cm} - -Table \ref{tab:3} and Table \ref{tab:4} provide the primary information needed to describe the ObsCore model in terms of TAP\_SCHEMA tables -and columns. - -The ``datatype'' column values should follow the TAP standard specification and are bound to the TAP specification -version used to implement the model. Here what is shown applies for TAP v1.0. - -The content of the ``constraint'' column specified in Table \ref{tab:4} above is not part of the TAP\_SCHEMA.columns description, -but is required by the ObsCore model and specified here to make this clear to implementers. Additional standard -content for the individual columns is specified below. - \subsection{Data Product Type (dataproduct\_type)} The dataproduct\_type column contains a simple string value describing the primary nature of the data product. It should assume one of these string values: image, cube, spectrum, sed, timeseries, visibility, event or measurements. @@ -984,6 +901,94 @@ \subsection{Axes lengths (s\_xel1, s\_xel2, em\_xel, t\_xel, pol\_xel)} for instance, these attributes should be set to -1. The number of elements in such lists is a different property and should be represented in the NDCube DM which tackles sparse data sets. +\section{ObsCore Extensions} +The ObsCore table includes common metadata attributes that are applicable to a wide range of astronomical data. +Additional details that are not common enough to be included in core may be defined as extensions that support +data discovery use cases for specific kinds of data. + +TODO: extension mechanism + +\section{Implementation of ObsCore in a TAP Service} +TODO: TAP-specific details here + +\label{sec:obstap-impl}The ObsCore model must be implemented within Table Access Protocol (TAP) services such that all +valid queries can be executed unchanged on any service that implements the model. Additional optional or +provider-defined columns are permitted (see section \ref{bkm:Ref421295535}) so long as all mandatory columns are +provided. The protocol does not specify any specific ordering of fields in the query response so long as the mandatory +parameters are present in the output stream. + +Here we specify an explicit mapping of the model to relational database tables; in the context of TAP this means we are +specifying the logical tables as described in the TAP\_SCHEMA (the TAP-required database schema where the tables and +columns exposed by the service are described). This does not necessarily imply that the underlying database will have +the identical structure (what is exposed through TAP could be, for example, a database view of the underlying database +tables), but in most cases the relationship between TAP\_SCHEMA description and the underlying tables is +straightforward. + +%\begin{table}[h] +%\begin{center} +\begin{tabularx}{\textwidth}{|p{0.2\textwidth}|p{0.2\textwidth}|p{0.4\textwidth}|} +\hline +schema\_name & table\_name & Description\\\hline +ivoa & ivoa.ObsCore & ObsCore 1.1\\\hline +\caption{TAP\_SCHEMA.tables for implementation of the ObsCore model.} +\label{tab:3} +\end{tabularx} +%\end{center} +%\end{table} + +%\begin{table}[h] +%\begin{center} +\begin{tabularx}{\textwidth}{|p{0.18\textwidth}|p{0.25\textwidth}|p{0.22\textwidth}|p{0.07\textwidth}|p{0.14\textwidth}|} +\hline +table\_name & column\_name & data type & units & Constraint\\\hline +ivoa.ObsCore & dataproduct\_type & adql:VARCHAR & & \\\hline +ivoa.ObsCore & calib\_level & adql:INTEGER & & not null\\\hline +ivoa.ObsCore & obs\_collection & adql:VARCHAR & & not null\\\hline +ivoa.ObsCore & obs\_id & adql:VARCHAR & & not null\\\hline +ivoa.ObsCore & obs\_publisher\_did & adql:VARCHAR & & not null\\\hline +ivoa.ObsCore & access\_url & adql:CLOB & & \\\hline +ivoa.ObsCore & access\_format & adql:VARCHAR & & \\\hline +ivoa.ObsCore & access\_estsize & adql:BIGINT & kbyte & \\\hline +ivoa.ObsCore & target\_name & adql:VARCHAR & & \\\hline +ivoa.ObsCore & s\_ra & adql:DOUBLE & deg & \\\hline +ivoa.ObsCore & s\_dec & adql:DOUBLE & deg & \\\hline +ivoa.ObsCore & s\_fov & adql:DOUBLE & deg & \\\hline +ivoa.ObsCore & s\_region & adql:REGION & & \\\hline +ivoa.ObsCore & s\_resolution & adql:DOUBLE & arcsec & \\\hline +ivoa.ObsCore & s\_xel1 & adql:BIGINT & & \\\hline +ivoa.ObsCore & s\_xel2 & adql:BIGINT & & \\\hline +ivoa.ObsCore & t\_min & adql:DOUBLE & d & \\\hline +ivoa.ObsCore & t\_max & adql:DOUBLE & d & \\\hline +ivoa.ObsCore & t\_exptime & adql:DOUBLE & s & \\\hline +ivoa.ObsCore & t\_resolution & adql:DOUBLE & s & \\\hline +ivoa.ObsCore & t\_xel & adql:BIGINT & & \\\hline +ivoa.ObsCore & em\_min & adql:DOUBLE & m & \\\hline +ivoa.ObsCore & em\_max & adql:DOUBLE & m & \\\hline +ivoa.ObsCore & em\_res\_power & adql:DOUBLE & & \\\hline +ivoa.ObsCore & em\_xel & adql:BIGINT & & \\\hline +ivoa.ObsCore & o\_ucd & adql:VARCHAR & & \\\hline +ivoa.ObsCore & pol\_states & adql:VARCHAR & & \\\hline +ivoa.ObsCore & pol\_xel & adql:BIGINT & & \\\hline +ivoa.ObsCore & facility\_name & adql:VARCHAR & & \\\hline +ivoa.ObsCore & instrument\_name & adql:VARCHAR & & \\\hline +\caption{List of the minimal set of data model fields to +implement for an ObsTAP service. See tables of Appendix C for the full description of the TAP\_SCHEMA.columns table.} +\label{tab:4} +\end{tabularx} +%\end{center} +%\end{table} +%\vspace{0.3cm} + +Table \ref{tab:3} and Table \ref{tab:4} provide the primary information needed to describe the ObsCore model in terms of TAP\_SCHEMA tables +and columns. + +The ``datatype'' column values should follow the TAP standard specification and are bound to the TAP specification +version used to implement the model. Here what is shown applies for TAP v1.0. + +The content of the ``constraint'' column specified in Table \ref{tab:4} above is not part of the TAP\_SCHEMA.columns description, +but is required by the ObsCore model and specified here to make this clear to implementers. Additional standard +content for the individual columns is specified below. + \subsection{Additional Columns} \label{bkm:Ref421295535}\label{bkm:Ref421297012}Service providers may include additional columns in the ivoa.ObsCore table to expose additional metadata. These columns must be described in the TAP\_SCHEMA.columns table and in the output @@ -994,13 +999,6 @@ \subsection{Additional Columns} as optional. ObsTAP compliant services will support all columns defined as mandatory and possibly some of the optional ones. Queries built up using additional columns defined specifically for a given archive might not be portable. -\section{ObsCore Extensions} -The ObsCore table includes common metadata attributes that are applicable to a wide range of astronomical data. -Additional details that are not common enough to be included in core may be defined as extensions that support -data discovery use cases for specific kinds of data. - -TODO: extension mechanism - \section{Registering ObsCore and Extension Tables} TODO: write this section following current practice and remove the next section.