# [Volute] r3644 - trunk/projects/dal/SODA

Volute commit messages volutecommits at g-vo.org
Wed Oct 19 01:02:05 CEST 2016

Author: jdempsey
Date: Wed Oct 19 01:02:05 2016
New Revision: 3644

Log:
Correct spelling in a few places

Modified:
trunk/projects/dal/SODA/SODA.tex

Modified: trunk/projects/dal/SODA/SODA.tex
==============================================================================
--- trunk/projects/dal/SODA/SODA.tex	Tue Oct 18 22:03:03 2016	(r3643)
+++ trunk/projects/dal/SODA/SODA.tex	Wed Oct 19 01:02:05 2016	(r3644)
@@ -82,7 +82,7 @@
including the Virtual Observatory Support Interfaces (VOSI,
\citet{std:VOSI}) resources.

-Wthin the IVOA architecture, SODA servces could be found and used in
+Within the IVOA architecture, SODA services could be found and used in
several ways. First, a SODA service could be found in the IVOA Registry
and used directly. A description of a SODA service may be found along
with specific dataset metadata at either the data discovery phase using
@@ -97,7 +97,7 @@

\subsubsection{SODA Service in the Registry}

-Resources in the IVOA Registry may include SODA capabilites. In order to
+Resources in the IVOA Registry may include SODA capabilities. In order to
use such services, clients require prior knowledge of suitable
identifiers that are usable with a registered SODA service. This
scenario is described in more detail below in
@@ -108,7 +108,7 @@
In the simplest case, the identifiers found via data discovery can be
used directly with an associated SODA service. The query response (from
SIA or TAP) would include one or more DataLink service descriptor(s)
-that describe the available SODA capabilities. This scenario is descibed
+that describe the available SODA capabilities. This scenario is described
in detail in Section~\ref{sec:disc-soda}.

\subsubsection{SODA Service from DataLink}
@@ -379,7 +379,7 @@
Supported multiplicity may also differ between {sync} and {async} requests.

In general, services would support multi-valued parameters as they may be
-able to provide more efficent access to data files. Clients may attempt to use
+able to provide more efficient access to data files. Clients may attempt to use
multi-valued parameters, but must be prepared to fall back to multiple requests
if the service indicates this is not supported. A future version of
\citep{std:DataLink} should provide a mechanism to describe parameter
@@ -411,7 +411,7 @@
\subsubsection{CIRCLE}
\label{sec:CIRCLE}

-The CIRCLE patameter defines a spatial region using the \xtype{circle}
+The CIRCLE parameter defines a spatial region using the \xtype{circle}
xtype defined in DALI \citep{std:DALI}.

Example: a circle at (12,34) with radius 0.5:
@@ -536,7 +536,7 @@
The BAND parameter defines the energy interval(s) to be extracted from
the data using a floating point interval (\texttt{xtype="interval"}) as
defined in \citep{std:DALI}.  The value is an open or closed numeric
-interval with numeric values interpretted as wavelength(s) in metres. As
+interval with numeric values interpreted as wavelength(s) in metres. As
in DALI, open intervals use -Inf or +Inf as one limit.

\begin{itemize}
@@ -573,7 +573,7 @@
All energy values are expressed as barycentric wavelength in
meters. A future version of this specification may allow the
use of other reference systems (specifically the native
-system of ther data).
+system of their data).

The UCD \citep{std:UCD} describing the BAND parameter is \ucd{em.wl}.

@@ -720,7 +720,7 @@
\label{sec:integration}

Finding and using SODA services depends on several other standards;
-service providers can follow one or more stategies in integrating a
+service providers can follow one or more strategies in integrating a
range of standard and custom services with their SODA implementation.
Here we describe these strategies and show how to use the standards
together.
@@ -801,7 +801,7 @@
\subsection{SODA Service in the Registry}
\label{sec:reg-soda}

-Resources in the IVOA Registry may include SODA capabilites. However,
+Resources in the IVOA Registry may include SODA capabilities. However,
in order to
use such services, clients require prior knowledge of suitable
identifiers that are usable with a registered SODA service. As a result,
@@ -828,7 +828,7 @@

The declaration of the ID parameter will specify which column in the
data discovery response contains the  suitable identifier; although this
-is usually the obs\_publishder\_did from the ObsCore data model, this is
+is usually the obs\_publisher\_did from the ObsCore data model, this is
not required and the provider may have the ID parameter reference
another (possibly custom) column.

@@ -893,9 +893,9 @@
permitted, it is much more useful if the links response contains data- or
file-specific service descriptors that make use of the ability to
include metadata in the parameter descriptions. Thus, the provider will
-normally include one or more data-specific service descritors for each
+normally include one or more data-specific service descriptors for each
input ID, but scalability should not be a problem because clients
-nornally use a single or small number of ID(s) per invocation.
+normally use a single or small number of ID(s) per invocation.

A data-specific SODA sync service descriptor describing the standard
parameters (see~\ref{sec:parameters}) with plausible values:
@@ -1048,9 +1048,9 @@
a parameter is not supported.
\item Added section introducing the different usage scenarios for SODA
and how they can interact with other DAL capabilities. Moved the bulk of
-the nomative text to an integration section so that it follows the
+the normative text to an integration section so that it follows the
primary specification of SODA resources and parameters.
-\item re-organised so that UCDs for patameters are only specified once
+\item re-organised so that UCDs for parameters are only specified once
in the section on three-factor semantics.
\item Added CIRCLE AND POLYGON double array'' parameters. POS is
retained for consistency with SIA-2.0 query.


More information about the Volutecommits mailing list