\documentclass[11pt,a4paper]{ivoa}
\input tthdefs

\SVN$Rev$
\SVN$Date$
\SVN$URL$

\usepackage{listings}
\lstloadlanguages{XML,SQL}
\lstset{flexiblecolumns=true,numberstyle=\small,showstringspaces=False,
  identifierstyle=\texttt,defaultdialect=[latex]tex,language=tex,
  basicstyle=\footnotesize}

\definecolor{rtcolor}{rgb}{0.15,0.4,0.3}
\definecolor{tapcolor}{rgb}{0.4,0.1,0.1}

\newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
\newcommand{\tapent}[1]{\texttt{\color{tapcolor} #1}}

\title{A Roadmap for Space-Time Discovery in the VO Registry}

\ivoagroup{Registry}

\author[http://www.ivoa.net/twiki/bin/view/IVOA/MarkusDemleitner]{Demleitner, M.}

\editor{Demleitner, M.}

% \previousversion[????URL????]{????Funny Label????}
\previousversion{This is the first public release}
       

\begin{document}
\begin{abstract}
In VODataService 1.1, the footprint of resources in space, time, and the
electromagnetic spectrum (the ``coverage'') is defined using STC-X.
Takeup of this mechanism has been low, and searchable registry
interfaces have, by and large, not made use of it.  With MOCs, the
Virtual Observatory now has a technology that allows efficient handling
of spatial footprints.  This note lays out a way to develop
the Registry ecosystem to accomodate them and to replace STC-X in the
representation of resource coverage on the time and spectral axes as
well.
\end{abstract}



\section{Introduction}

Many important use cases for the Registry in the Virtual Observatory
(VO) involve matching a region of interest in space, time, and spectrum
with the regions covered by the registered resources.  Examples include:

\begin{itemize}
\item Where can I find data in the near infrared for sources within
two degrees of the Galactic center?
\item Where can I find photometry on the southern sky for the first half
of the 20$^{\rm th}$ century?
\item Where can I find X-ray spectra for objects in the Large Magellanic
Cloud?
\end{itemize}

To enable such use cases in the VO Registry, searchable registries must
contain coverage (``STC'', space-time coordinates) information.  In
VODataService 1.1 \citep{2010ivoa.spec.1202P}, the intent was to
represent such information mainly in STC-X \xmlel{ResourceProfile}
elements.  As of January 2018, only about 1000~resources out of the
18000~resources in the Registry 
contain a \xmlel{ResourceProfile}, and of those, the
overwhelming majority declare essentially trivial metadata (full
sky without explicit limits on time and wavelength).

Standard searchable registries have, so far, not actually exposed this
information; in particular, RegTAP \citep{2014ivoa.spec.1208D} has
dropped an attempt to add tables for STC coverage early on in the
standardisation effort, mainly over disputes about how spatial coverage
should be modeled.  Prototype implementations of these early efforts
existed, but were largely not used.  The fact that coverage information
was available for less than 10\% (for the space axes, much less for the
other axes) of the VO's resources certainly contributed to the perceived
lack of usefulness.

On the side of registries trying to process VODataService~1.1 coverage
information, dealing with the STC-X embedded within
the resource records was made difficult by the large feature set of
STC-X, where coverages could be provided in a myriad of reference
frames and shapes that needed to be unified to standard systems before
they could meaningfully be searched.  Additionally, STC-X itself never
reached the Recommendation status, so supporting coverage in the
Registry meant implementing against a non-standard.

Meanwhile, \citet{2014ivoa.spec.0602F} have introduced MOCs, a powerful
technology for representing spatial coverage information. It is
successfully employed in several custom services, as well as, for instance,
through the Aladin 10 \citep{talk:aladin10} VO client software.  
Numerous resource records already provide
MOC-based information on their spatial coverage by giving a
\xmlel{footprint} (also defined in VODataService 1.1) element in their
resource records.  When harvesting the URLs
transmitted in this way in addition to in-record STC-X coverage
information, about 70\% of all resource records in the VO get spatial
coverage information.

The solution of giving a footprint URL, however, is still unsatisfactory
because

\begin{enumerate}
\item No temporal and only very rough spectral coverage is available.
\item Searchable registries have to harvest the MOCs in a separate step,
which means many extra requests in addition OAI-PMH-based harvesting; 
in practical experience, a significant number of these extra requests
fail for a wide variety of reasons.
This further complicates the operation of searchable registries.
\item Hence, the validity of a resource record with a footprint
effectively depends on two
artefacts: the resource record itself and the MOC referenced.
\item The updating architecture based on OAI-PMH is bypassed, leading to
significant extra logic in maintaining up-to-date coverage information.
\end{enumerate}

In this note we propose a modification of the VODataService schema (in
section~\ref{sect:xmlschema}) and an extension to RegTAP (in
section~\ref{sect:tableschema}) that will facilitate VO-wide,
standards-based dissemination and interrogation of STC coverage.
Based on this, we enumerate several questions that need to be answered
in the upcoming standardisation process,
and a roadmap for the next steps in
section~\ref{sect:roadmap}.  We conclude with some remarks on the
current implementation status.

\section{Extending the VODataService Schema}
\label{sect:xmlschema}

\subsection{Axes Modeled as Floating Point Intervals}

We propose to model time and spectral coverage as a union of simple
intervals over the real numbers.  To avoid burdening the searchable
registries with error-prone transformations
-- that often enough are actually impossible without
information not conveyed within the registry records --, 
we fix reference systems and units.  

Specifically, times are assumed to be given in Barycentric Dynamical Time (TDB) 
at the solar
system barycenter.  They must be specified as Modified Julian Dates.  
For now, we do not forsee
discovery use cases that require a temporal resolution significantly below 
one hour.  Hence, resource record authors are encouraged to pad their
actual temporal coverage such that differences in time scales (of the
order of 10s of seconds) or reference positions (of the order of minutes between
ground-based observatories and the barycenter) do not matter.

Following common VO practice, spectral limits must be given in meters of
vacuum wavelength for the solar system barycenter.  Again, discovery use
cases on a level where the difference between reference frames of
ground-based observatories versus the solar system barycenter matters
are not forseen, and resource record authors are advised to pad their
intervals on that level.

\subsection{Spatial Coverage}

Spatial coverage is conveyed as a MOC.  To enable easy embedding into
resource records written in VOResource (i.e., XML), 
we represent MOCs in the ASCII convention
proposed in the MOC specification \citep{2014ivoa.spec.0602F}.  This
representation is not normative so far, but it is in fairly wide use,
and its proper standardisation should be a minor matter as part of the work
proposed here.

The MOCs are to be understood in ICRS.  It is forseen that future
extensions to this will allow
non-celestial frames (see also Sect.~\ref{sect:questions}).  In
VOResource, this will probably be effected using an attribute to the
coverage element.  Whatever the eventual decision, spatial coverage
without further annotation should always be understood as being given in
the ICRS.

An important characteristic of MOCs
is the order of the smallest scale (the ``MOC resolution''). 
Higher orders yield more faithful
representations of the actual coverage, but also lead to a possibly
significant increase of the size of the serialised MOC.
We suggest a ``typical resolution'' of the Registry of
about a degree.  If the resources in the Registry were uniformly
distributed, that resolution would mean a selectivity of roughly 1:50000
(since there are roughly 50000 different patches with a diameter of a
degree on the sky), which seems sufficient.

This translates into the recommendation to have MOCs within resource
records at orders between 5 and 7.  In a standard, this should be given
as a recommendation, not as a requirement.  Resources that really only
cover a few compact sources could and probably should use higher
resolutions.

At least within the 1.x series of VODataService, we additionally have to
keep the \xmlel{footprint} element.  It has been used to convey
URLs of coverage MOCs in FITS serialisation for a while now, and some
searchable Registries 
already harvest and interpret such footprints. 

Although, as argued above, we do not believe \xmlel{footprint} is a well-scaling
and general solution to the problem at hand, it is perfectly conceivable 
that sepcialised applications or services
want to harvest or otherwise use high-resolution MOCs.  Hence,
continued support for what the \xmlel{footprint} element does is
probably desirable
even in the presence of the inline coverage declaration in VOResource.

To distinguish MOC-based footprints from those giving footprints in
other formats -- there have footprint services returning STC-S strings,
for instance --, services
supplying high-resolution MOCs on an extra endpoint should add an
\xmlel{ivo-id} attribute valued
$$\hbox{\verb|ivo://ivoa.net/std/moc|}$$
to their footprint elements.

On the timeframe of VODataService 2.0, we suggest migrating the
declaration of footprint-type services to regular
capabilities.

\subsection{A VOResource Example}

With the proposed VODataService schema (version tag
1.11), a full coverage element could look like this:

\begin{lstlisting}[language=XML,basicstyle=\footnotesize]
<coverage>
  <spatial>
    4/2068 
    5/8263,8268-8269
    6/33045-33047,33049,33051,33069,33080-33081,
    33083,33104-33106,33112,33124-33126,33128-33130
  </spatial>
  <temporal>51845.1 52262.2</temporal>
  <spectral>3e-07 1.1e-06</spectral>
  <footprint ivo-id="ivo://ivoa.net/std/moc"
    >http://dc.zah.uni-heidelberg.de/cdfspect/q/ssa/coverage</footprint>
  <waveband>Optical</waveband>
</coverage>
\end{lstlisting}

\subsection{Schema Changes}

The changes to the VODataService schema necessary to implement the
proposed scheme are limited to the \xmlel{vs:Coverage}
type.  For a rough, first-order approximation to the new schema one can
add the following elements before the current STCResourceProfile-typed
child:

\begin{lstlisting}[language=XML,basicstyle=\footnotesize]
        <xs:element name="spatial" type="xs:string" 
               minOccurs="0">
            <xs:annotation>
               <xs:documentation>
                  An ASCII-serialised MOC defining the spatial coverage 
                  of the resource.
               </xs:documentation>
               <xs:documentation>
                  The MOC is to be understood in the ICRS reference frame.
                  Resources should give the coverage at least to order 6
                  (a resolution of about one degree).  The order should be
                  chosen so as to keep the resulting MOC smaller than a few
                  dozens of kB.  If desired, a more precise MOC can be provided
                  on a dedicated endpoint declared in the footprint element.
               </xs:documentation>
            </xs:annotation>
         </xs:element>

<!-- TODO: make a FloatPair or FloatInterval or whatever type -->
         <xs:element name="temporal" type="xs:string" minOccurs="0"
               maxOccurs="unbounded">
            <xs:annotation>
               <xs:documentation>
                  A pair of lower, upper limits of a time interval 
                  for which the resource offers data.
               </xs:documentation>
               <xs:documentation>
                  This is written as for VOTable tabledata (i.e., 
                  white-separated C-style floating point literals).
                  The limits must be given as MJD.  While they
                  are not intended to be precise, they are to be understood
                  in TDB for the solar system barycenter.  The total coverage
                  of the resource is the union of all such intervals.
               </xs:documentation>
            </xs:annotation>
         </xs:element>

         <xs:element name="spectral" type="xs:string" minOccurs="0"
               maxOccurs="unbounded">
            <xs:annotation>
               <xs:documentation>
                  A pair of lower, upper limits of a spectral interval 
                  for which the resource offers data.
               </xs:documentation>
               <xs:documentation>
                  This is written as for VOTable tabledata (i.e., 
                  white-separated C-style floating point literals).
                  The limits must be given in meters of vacuum wavelength,
                  e.g., 655e-9 658e-9.  While the limits are not intended 
                  to be precise, they are to be understood for the
                  solar system barycenter.
               </xs:documentation>
            </xs:annotation>
         </xs:element>
\end{lstlisting}

While we probably do not want to include schema validation for ASCII
MOCs, the floating-point intervals can easily be validated using XML schema.

A draft VODataService 1.2 schema (version attribute on the root element:
1.11) that includes these elements is part of
this note and can be obtained from the IVOA document
repository\footnote{\auxiliaryurl{VODataService-v1.2.xsd}}.

\section{STC coverage in RegTAP}
\label{sect:tableschema}

The mapping of the proposed VOResource extension to a relational model
is fairly straightforward.  Given the forseeable data and query patterns, any
denormalisation does not seem warranted.  The interval-valued axes thus map
to tables that can have multiple rows per ivoid.

Since essentially arbitrary geometric operations between the spatial
coverages and other ADQL-defined geometries are allowed, explicit
support for MOCs or at least rather similar spatial representations is
required in the database.  Beta-level support for representing MOCs is
available in recent releases of pgsphere \citep{soft:pgsphere}.

\subsection{Relational Mapping}

These considerations yield the following three tables:

\paragraph{Table rr.stc\_temporal}  All columns in this table should be
indexed.  The \verb|ivoid| column should be an explicit foreign key into
\verb|rr.resource|.  It is recommended to query this table using the
\verb|ivo_interval_overlaps| user defined function.

% GENERATED: maketable.sh rr.stc_temporal

\begin{inlinetable}
\small
\begin{tabular}{p{0.28\textwidth}p{0.2\textwidth}p{0.66\textwidth}}
\sptablerule
\multicolumn{3}{l}{\textit{Column names, utypes, datatypes, and descriptions for the \rtent{rr.stc\_temporal} table}}\\
\sptablerule
ivoid\hfil\break
\makebox[0pt][l]{\scriptsize\ttfamily xpath:/identifier}&
\footnotesize string&
The parent resource.\\
time\_start\hfil\break
\makebox[0pt][l]{\scriptsize\ttfamily stc:AstroCoordArea.TimeInterval.StartTime}&
\footnotesize real&
Lower limit of a time interval covered by the resource.\\
time\_end\hfil\break
\makebox[0pt][l]{\scriptsize\ttfamily stc:AstroCoordArea.TimeInterval.EndTime}&
\footnotesize real&
Upper limit of a time interval covered by the resource.\\

\sptablerule
\end{tabular}
\end{inlinetable}


% /GENERATED

\paragraph{Table rr.stc\_spectral} All columns in this table should be
indexed.  The \verb|ivoid| column should be an explicit foreign key into
\verb|rr.resource|.  It is recommended to query this table using the
\verb|ivo_interval_overlaps| user defined function.


% GENERATED: maketable.sh rr.stc_spectral

\begin{inlinetable}
\small
\begin{tabular}{p{0.28\textwidth}p{0.2\textwidth}p{0.66\textwidth}}
\sptablerule
\multicolumn{3}{l}{\textit{Column names, utypes, datatypes, and descriptions for the \rtent{rr.stc\_spectral} table}}\\
\sptablerule
ivoid\hfil\break
\makebox[0pt][l]{\scriptsize\ttfamily xpath:/identifier}&
\footnotesize string&
The parent resource.\\
wavelength\_start\hfil\break
\makebox[0pt][l]{\scriptsize\ttfamily stc:AstroCoordArea.SpectralInterval.LoLimit}&
\footnotesize real&
Lower limit of a vacuum wavelength interval covered by the resource (for the solar system barycenter).\\
wavelength\_end\hfil\break
\makebox[0pt][l]{\scriptsize\ttfamily stc:AstroCoordArea.SpectralInterval.HiLimit}&
\footnotesize real&
Upper limit of a vacuum wavelength interval covered by the resource (for the solar system barycenter).\\

\sptablerule
\end{tabular}
\end{inlinetable}


% /GENERATED


\paragraph{Table rr.stc\_spatial} All columns in this table should be
indexed.  The \verb|coverage| is given as having a type \texttt{string}
in the following table, but it is to be understood as a geometry
suitable for the common ADQL geometry operators and operands (CONTAINS,
INTERSECTS, CIRCLE, POLYGON, etc).  Details on the serialisation of this
column on output should be given by a future version of the IVOA DALI
standard \citep{2017ivoa.spec.0517D}.

The column \verb|ref_system_name| is present for extensability and must
always be NULL (meaning ICRS BARYCENTER coordinates).  Non-ICRS
coverages are not yet supported.  Still, clients must constrain any query
against coverage with \verb|ref_system_name IS NULL| to avoid false
positives later.  Non-ICRS systems will be denoted by strings drawn from
a controlled vocabulary that is yet to be defined.

% GENERATED: maketable.sh rr.stc_spatial

\begin{inlinetable}
\small
\begin{tabular}{p{0.28\textwidth}p{0.2\textwidth}p{0.66\textwidth}}
\sptablerule
\multicolumn{3}{l}{\textit{Column names, utypes, datatypes, and descriptions for the \rtent{rr.stc\_spatial} table}}\\
\sptablerule
ivoid\hfil\break
\makebox[0pt][l]{\scriptsize\ttfamily xpath:/identifier}&
\footnotesize string&
The parent resource.\\
coverage\hfil\break
\makebox[0pt][l]{\scriptsize\ttfamily }&
\footnotesize string&
A geometry representing the area a resource contains data for; this should be tight at least with a resolution of degrees.\\
ref\_system\_name\hfil\break
\makebox[0pt][l]{\scriptsize\ttfamily }&
\footnotesize string&
The reference frame coverage is written in. This is currently reserved and fixed to NULL. Clients should always add a constraint to NULL for this to avoid matching non-celestial services later.\\

\sptablerule
\end{tabular}
\end{inlinetable}


% /GENERATED

\subsection{A user-defined function}

\def\NUMERIC{\hbox{ NUMERIC}}

In order to facilitate robust query patterns, searchable registries that
host these tables must also provide a user defined function
\begin{eqnarray*}
\hbox{\verb|ivo_interval_overlaps|}&(l_1\NUMERIC, h_1\NUMERIC,\\
&l_2\NUMERIC, h_2\NUMERIC)
\end{eqnarray*}
that returns 1 if the intervals $[\,l_1:h_1]$ and 
$[\,l_2:h_2]$ overlap and 0 otherwise.  This is defined to be equivalent
to the expression $$h_1\geq l_2\hbox{ and }h_2\geq l_1$$ with the
conventional boolean mapping of 1 as True and 0 as False.


\subsection{Relationship to RegTAP}
\label{sect:relationship}

This extension could become part of RegTAP 1.2; this would in effect mean
making it mandatory for all RegTAP searchable registries.  In the
interest of maximal interoperability and least surprise to clients this
would probably be the most desirable way forward, although it would mean
requiring rather extensive support for geometric operations in the
backend database of all RegTAP services.

An alternative to globally requiring the three tables would be to
make them optional;
the presence of the \verb|TAP_SCHEMA| (and tablesets) would let clients
determine support for the coverage tables (and potentially discovery
supporting searchable registries).

A last possibility would be to define the three tables in a separate
standard and define an extra data model, to be used independently in
discovery.


\subsection{Sample Queries}

Here are RegTAP queries
fulfilling the use cases mentioned in the introduction using the three
proposed tables.  We only select
ivoids in the following examples -- the actual discovery of interface
URLs or other pieces of resource metadata proceeds as normal in RegTAP.


\begin{enumerate}
\item Where can I find data in the near infrared for sources withing
two degrees of the Galactic center?

\begin{lstlisting}[language=SQL]
SELECT ivoid
FROM stc_spatial
NATURAL JOIN stc_spectral
WHERE
	1=INTERSECTS(
		CIRCLE('', 266.5 -29., 2),
		coverage)
	AND ref_system_name IS NULL
	AND ivo_interval_overlaps(
		wavelength_start, wavelength_end,
		4e-6, 8e-7)
\end{lstlisting}

\item Where can I find photometry on the southern sky for the first half
of the 20$^{\rm th}$ century?

\begin{lstlisting}[language=SQL]
SELECT ivoid
FROM rr.stc_spatial
NATURAL JOIN rr.stc_temporal
NATURAL JOIN rr.table_columns
WHERE
	1=INTERSECTS(
		CIRCLE('', 0, -90, 90),
		coverage)
	AND ref_system_name IS NULL
	AND ivo_interval_overlaps(
		time_start, time_end,
		15000, 34000)
	AND ucd LIKE 'phot.mag%'
\end{lstlisting}

\item Where can I find X-ray data for the center of the Large Magellanic
Cloud?

\begin{lstlisting}[language=SQL]
SELECT ivoid
FROM rr.stc_spatial
NATURAL JOIN rr.stc_temporal
WHERE
	1=CONTAINS(
		POINT('', 80.9, -69.8),
		coverage)
	AND ref_system_name IS NULL
	AND ivo_interval_overlaps(
		wavelength_start, wavelength_end,
		1e-8, 1e-11)
\end{lstlisting}

\end{enumerate}

Note that as of early 2018, the prototype at
\url{http://dc.g-vo.org/tap} cannot
yet intersect circles and MOCs.  Hence, the first two queries do not yet
work on that service as they are given here; use the pattern from query
three for experiments.


\section{A Roadmap}
\label{sect:roadmap}

\subsection{Questions to be Discussed}
\label{sect:questions}

\paragraph{Should we include further axes?}  The STC-X
\xmlel{ResourceProfile} element allows the definition of coverage in
redshift space.  We could not identify clear discovery cases that would
require distance information, although ``resources on nearby stars'' or
``resources on distant galaxy clusters'' might count.  However, to satisfy the
first one, redshifts will not work as a proxy for distance,
whereas using physical distances on a cosmological scale involves
prescribing models and thus is at least not optimal for the second one.  
It is not clear whether a model for distance
information in astronomy exists that enables sufficiently many discovery
scenarios and still admits simple query patterns.

\paragraph{Open intervals?} While open intervals probably have no actual
place in spectral coverage, for live instruments that keep adding data
it might be interesting to declare a half-open interval with no upper
limit in time.  It seems doubtful that the additional effort in
specifying this (and in making sure \verb|ivo_interval_overlaps| behaves
correctly) when operators can just put in an upper limit sufficiently
far in the future.

\paragraph{Other reference systems?}  We currently require all
spatial coordinates to be in the ICRS.  This obviously is not enough
whenever objects move fast against the ICRS, as for instance for solar
system objects and, in particular, their surface (or cloud-top) features.  To
enable future extensions to cover these domains, a column
\verb|ref_system_name| must currently always be filled with
\texttt{NULL} on the service side, and clients must always constrain
coverage queries with a \verb|ref_system_name IS NULL| condition.

Is this enough to cover forseeable and plausible use cases?  Should we
write \verb|'ICRS'| rather than \texttt{NULL} already, and then perhaps
already define some system names we already have resources for?  Given
it will be present in almost all STC queries, should we have a less
verbose name than \verb|ref_system_name|?

\paragraph{Non-electromagnetic coverage?} With the advent of neutrino
and gravitational wave observatories, the location in the electromagnetic
spectrum does not necessarily characterise observations any more even
for conventional celestial observations.  The diversity even increases
when observations of charged primary particles are included.  Should the
VO Registry enable metadata discovery for such resources?  If so, how?
We remark that moving to energy instead of wavelength in the declaration
of spectral coverage could already go a long way here.

\paragraph{MOC representation in VOTables} This draft suggests MOCs
should be serialised to the (currently non-standard) ASCII form when
they appear in VOResource documents.  Below, we propose to follow this
practice when packing MOCs into VOTable cells.  The current standard
representation, on the other hand, is essentially an array of integers
(plus some metadata that is not actually necessary for decoding).  It would be
almost trivial to port this convention to VOTables.  Doing so might
yield some space savings when using binary coding as well as more
straightforward parsing at the expense of generally less compact
representations in TABLEDATA and less human readability.


\subsection{Next Steps}

Obviously, the most important task at hand is to gain implementation
experience, which in particular means getting data providers to add STC
coverage information to their records as soon as possible.  Clients will
probably not start using the mechanisms proposed here if they have to
expect to lose more than half of their recall by using STC constraints;
but in order to assess the completeness of our use cases, as much
experience with client usage patterns as possible should be gathered
before casting the standards in stone.

The following standards and pieces of infrastructure need to be touched:

\paragraph{Software support for MOCs in pgsphere} Current betas of
pgsphere know how to match points against MOCs.  To avoid surprising
behaviour, MOCs should behave in ADQL like POLYGONs and CIRCLEs, in
particular in INTERSECTS and OVERLAPS, ideally also in AREA, CENTROID
and DISTANCE (though the latter are perhaps not quite as central for
RegTAP).  This is currently being worked on in Heidelberg.

\paragraph{VODataService 1.2} The addition to the VODataService schema
will necessitate a new version of the VODataService standard.  Several
other minor updates to VODataService need to be undertaken anyway, 
in particular in
order to improve alignment with VOSI.  Work on this should start within
the Registry WG after VOResource 1.1 has passed the standards process.

\paragraph{Standardising ASCII MOCs}  If MOCs are indeed to be
represented in VODataService instance documents, it is highly desirable
to standardise a representation beyond FITS\footnote{It would, of
course, be possible to include base64-encoded FITS bytestreams in the
XML documents.  While this might be marginally acceptable in VOResource
documents, it seems the overhead of encoding large amounts of
whitespaces and null bytes is excessive
when many MOCs are serialised into VOTables with a MOC-valued
column.}.  As the current MOC specification already proposes a usable
ASCII serialisation, this could happen in a very minor update to the
MOC specification, but see the next paragraph.

\paragraph{Defining MOC representation in VOTable cells}  For
visualisation and possibly more advanced filtering, it is highly
desirable that clients can use the \verb|coverage| column of
\verb|stc_spatial| in select clauses.  This means that we need a
representation of MOCs at least in VOTables.  The ASCII serialisation
proposed in the MOC specification would suffice, but for unambiguous
identification of MOC literals, a VOTable \xmlel{xtype} needs to be
defined.  This would probably require a new version of DALI.  For
standardisation convenience, this update to DALI could then also provide
the normative text for the ASCII serialisation of the MOCs themselves.

This option needs to be weighed against the alternative as discussed in
Sect.~\ref{sect:questions}: Using arrays of NUNIQs analogous to the
current FITS-based MOC serialisation.

\paragraph{Updating RegTAP}  As discussed in
sect.~\ref{sect:relationship}, the new RegTAP tables would preferably
come in an update to RegTAP.  This work would be done during late WD
phases of VODataService 1.2.


\section{Implementation Status}

The implementation status is discussed separately for publishing
registries (i.e., adding STC coverage information to resource records),
searchable registries (i.e., protocol-level support for STC-based
discovery), and user interfaces (i.e., client software that lets its
users enter STC constraints).

\subsection{Publishing Registries}

The scheme proposed here is implemented by DaCHS
\citep{2014A_C.....7...27D} on the side of resource record production.
The operator-visible interface to declaring (and, within limits,
computing) coverage is discussed in the ``Coverage Metadata`` chapter of
DaCHS' reference
documentation\footnote{\url{http://docs.g-vo.org/DaCHS/ref.html}}.

Those resources from GAVO's Heidelberg data center having data
corresponding to physical STC locations (which largely excludes theory
and infrastructures services) have coverage declarations as proposed
here and publish them through the data center's OAI-PMH endpoint.  To
find example records, look for resources with an authority
\texttt{org.gavo.dc} in the VO Registry.  

This translates into 85, 65, and 56 resources with new-style spatial,
temporal, and spectral coverage, respectively, as of 2018-01-31.

\subsection{Searchable Registries}

The extensions to VODataService (parsing) and RegTAP (ingesting)
described here are implemented by the GAVO RegTAP
network\footnote{accessible through \url{http://reg.g-vo.org/tap}}.  The
Paris and Potsdam mirrors only contain coverage information from within
the resource records (STC-X and as proposed here), which translates into
1063, 79, and 67 coverage records in space, time, and spectrum on
2018-01-31.

The Heidelberg RegTAP
mirror\footnote{\href{http://dc.g-vo.org/tap}{http://dc.g-vo.org/tap}}
additionally harvests the contents of \xmlel{footprint} into
the \verb|stc_spatial| table.  This gives 13408 spatial footprints out
of 19494 resources (again, as of 2018-01-31), which should suffice for
experiments, in particular given that there is by definition no STC
coverage for resources like authorities, registries, standards or
theoretical services.

\subsection{Clients}

No known client exposes an interface built on the RegTAP tables
discussed here.

Aladin 10's registry interface \citep{talk:aladin10}, however,
illustrates the power of global resource discovery based on spatial
constraints.  It uses a metadata scheme very similar to the one proposed
here.

\appendix
\section{Changes from Previous Versions}

No previous versions yet.  
% these would be subsections "Changes from v. WD-..."
% Use itemize environments.


\bibliography{ivoatex/ivoabib,ivoatex/docrepo,local}


\end{document}
