[Volute] r3546 - trunk/projects/registry/discovercollections

Volute commit messages volutecommits at g-vo.org
Wed Oct 26 18:05:46 CEST 2016


Author: msdemlei
Date: Tue Sep 13 19:54:39 2016
New Revision: 3546

Log:
discovercollections: moved SIA 2.0 aux cap id here from SimpleDALRegExt.

Modified:
   trunk/projects/registry/discovercollections/discovercollections.tex

Modified: trunk/projects/registry/discovercollections/discovercollections.tex
==============================================================================
--- trunk/projects/registry/discovercollections/discovercollections.tex	Mon Sep 12 23:17:22 2016	(r3545)
+++ trunk/projects/registry/discovercollections/discovercollections.tex	Tue Sep 13 19:54:39 2016	(r3546)
@@ -69,13 +69,6 @@
 
 \subsection{The Problem Setting}
 
-% Two Micron All-Sky Survey (2MASS) 
-% Simple Spectral Access (SSA)
-% ÉLODIE spectrograph, ?? - Haute-Provence Observatory until c.1995
-% https://en.wikipedia.org/wiki/ELODIE_spectrograph
-% Baranne et al (1996) http://adsabs.harvard.edu/full/1996A%26AS..119..373B
-% Back/Acronym something like: Échelle l’Observation Des Intérieurs stellaires et des Exoplanètes (?)
-
 In early VO services, there was generally a one-to-one relationship between a
 data service and a data collection -- a cone search service exposing the
 2MASS (Two Micron All-Sky Survey) point source catalogue, or an Simple Spectral Access service (SSA) for the spectra of
@@ -85,13 +78,6 @@
 the Registry data model still provides the necessary building blocks (in
 particular through \vorent{Relationship}).
 
-% \newcommand{\vorent}[1]{\specialterm{vorent}{#1}}
-% http://www.ivoa.net/documents/REC/ReR/VOResource-20080222.html#d:Relationship
-% http://www.ivoa.net/documents/REC/ResMetadata/RM-20070302.html
-% http://vizier.u-strasbg.fr/viz-bin/VizieR
-% http://tapvizier.u-strasbg.fr/adql/
-% Table Access Protocol (TAP)
-
 With the widespread adoption of standards like TAP \citep{std:TAP} and
 Obscore \citep{std:obscore}, more and more services expose a large
 number of different data collections.  VizieR's TAP
@@ -102,19 +88,12 @@
 but no link is made to the TAP service that opens them up for complex
 queries.
 
-% Canadian Astronomy Data Centre
-% UH8K: University of Havard 8192x8192 pixel CCD 
-% http://www.cfht.hawaii.edu/Instruments/Imaging/UH8k/
-
 CADC's Obscore table\footnote{\nolinkurl{ivo://cadc.nrc.ca/tap}}
 contains data sets from approximately one hundred instruments.  A VO user might
 reasonably expect  that when interrogating the registry for
 services publishing data originating from, say, the UH8K Mosaic Camera
 or from SCUBA-2, they should see CADC's Obscore service.
 
-% Submillimetre Common-User Bolometer Array-2
-% https://en.wikipedia.org/wiki/Submillimetre_Common-User_Bolometer_Array#SCUBA-2
-
 The problem of the mismatch between service records and data collection
 records not only occurs for TAP services.  For instance, an image
 service collecting various observations of gravitationally lensed
@@ -124,10 +103,6 @@
 with four different data collection creators.  Each of these collections
 should be discoverable independently of each other.
 
-% http://esavo.esa.int/registry/result.jsp?searchMethod=GetResource&identifier=ivo://ivoa.net/std/SIA
-% SIAP: Simple Image Access Protocol (SIAP)
-% inconsistently just Simple Image Access (SIA)
-
 The class of problems just outlined is referred to as the ``data
 discovery'' use case in the following.  In short: How can the Registry
 support discovering the VizieR tables, the data collections that
@@ -305,7 +280,7 @@
 expressed as a relationship between capabilities.  The current
 VOResource model, however, does not allow declaring such a relationship.
 It does allow, however, relationships between full resources.  While in
-the future it might be desirable to allow relationships between between
+the future it might be desirable to allow relationships between 
 capabilities (see below), we believe for the moment service-to-service
 relationships are sufficient for the purpose of linking auxiliary and
 main capabilities.
@@ -400,7 +375,7 @@
 If the query should additionally constrain the protocol version on the
 capability, the standard id pattern would be
 
-$$\hbox{\texttt{ivo://ivoa.net/std/example\#cap-\%1\%}.}$$
+$$\hbox{\texttt{ivo://ivoa.net/std/example#cap-%1%}.}$$
 \end{bigdescription}
 
 
@@ -507,7 +482,7 @@
 In order to offer an immediate solution for the outlined problem, we
 propose to form auxiliary identifiers for legacy standard ids by just
 appending an \texttt{aux} fragment identifier.  While this practice is
-questionable because the StandardsRegExt records of the respective
+questionable because the Stan\-dards\-Reg\-Ext records of the respective
 standards do not have \xmlel{StandardKey}\,-typed elements with the
 corresponding ids and thus the identifiers, strictly speaking, do not
 resolve, and VO practice is to only define resource record terms in the
@@ -520,6 +495,7 @@
 \begin{itemize}
 \item \nolinkurl{ivo://ivoa.net/std/conesearch#aux} (SCS 1.03)
 \item \nolinkurl{ivo://ivoa.net/std/sia#aux} (SIAP 1.0)
+\item \nolinkurl{ivo://ivoa.net/std/sia#query-aux-2.0} (SIAP 2.0)
 \item \nolinkurl{ivo://ivoa.net/std/ssa#aux} (SSA 1.*)
 \item \nolinkurl{ivo://ivoa.net/std/tap#aux} (TAP 1.0)
 \end{itemize}


More information about the Volutecommits mailing list