Skip to content

Commit

Permalink
Fix typos
Browse files Browse the repository at this point in the history
  • Loading branch information
gmantele committed Jan 5, 2024
1 parent c3bd04c commit bbdc9ee
Showing 1 changed file with 18 additions and 17 deletions.
35 changes: 18 additions & 17 deletions DataLinkImp.tex
Original file line number Diff line number Diff line change
Expand Up @@ -64,11 +64,11 @@ \section{Introduction}
via one service to related data products, and web services
that can act upon the data.

The {\em links\/} web service capability is a web service capability
The \blinks web service capability is a web service capability
for drilling
down from a discovered data item such as a dataset identifier, a source in a cata-
log or any other data item. In the first case (typically an IVOA publisher
dataset identifier) iit allows to find details about the data files that can be
down from a discovered data item such as a dataset identifier, a source in a
catalog or any other data item. In the first case (typically an IVOA publisher
dataset identifier) it allows to find details about the data files that can be
downloaded, alternate representations of the data that are available, and
services that can act upon the data (usually without having to download
the entire dataset). In the latter cases it allows to associate metadata, images,
Expand All @@ -83,37 +83,38 @@ \section{Introduction}


The current document is an implementation note for \blinks endpoint recognition in various contexts.
We reviewing three methods by which DataLink documents can be associated to resource entries in service responses and suggest possible choices according to the context.
We are reviewing three methods by which DataLink documents can be associated to resource entries in service responses and suggest possible choices according to the context.

\section{DataLink and SIAP-2.0 or ObsTAP services}

SIAP-2.0 \citep{2015ivoa.spec.1223D} services are queriable by setting contraints on the four "axes" of the data (2D-space, spectral, time and polarization) and their properties. Other archive metadata or data details are also queriable (target, collection, facilities, etc...). ObsTAP services are TAP services delivering the ivoa.Obscore table queriable via ADQL. The successfull response is a VOTable containing a mandatory result TABLE and optional service descriptor resource(s).

\subsection{DataLink discovery via format and reference columns}
The result table describes the dataset characterization on the different axes and give additional operative features. The various columns are mapped from the ObsCore-1.1 data model (reference). The accessReference and AccessFormat fields give different solutions to reach the dataset for download or access. This can be done in two ways:
The result table describes the dataset characterization on the different axes and give additional operative features. The various columns are mapped from the ObsCore-1.1 data model (reference). The \verb|accessReference| and \verb|AccessFormat| fields give different solutions to reach the dataset for download or access. This can be done in two ways:
\begin{itemize}
\item The data discovery step has yielded a result with the AccessFormat value (media type) : application/x-votable+xml;content=datalink
To the client, this indicates that what is given in the access reference (e.g., the access\_url column in ObsTAP or SIAP-2.0) is a datalink document (see below for DataLink functionalities).
\item The data discovery step has yielded a result with the \verb|AccessFormat| value (media type) :
\verb|application/x-votable+xml;content=datalink|
To the client, this indicates that what is given in the access reference (e.g. the \verb|access_url| column in ObsTAP or SIAP-2.0) is a DataLink document (see below for DataLink functionalities).
\item In case the media type is different, the access reference is a direct link to the dataset download.
\end{itemize}

\subsection{SIAP-2.0, ObsTAP and service descriptors}
To enable additional Datalink functionalities, SIAP-2.0 or ObsTAP services can then add a service descriptor in the query response that indicates the availability of a Datalink service accompanying the DAL service. It references one (or more) field(s) from the DAL response.
To enable additional DataLink functionalities, SIAP-2.0 or ObsTAP services can then add a service descriptor in the query response that indicates the availability of a DataLink service accompanying the DAL service. It references one (or more) field(s) from the DAL response.

This is explained in detail in DataLink specification, section 4.2. The net result is that DataLink-enabled clients can find ancillary data and use associated services for data access or processing by virtue of being able to retrieve Datalink documents.
This is explained in detail in DataLink specification, section 4.2. The net result is that DataLink-enabled clients can find ancillary data and use associated services for data access or processing by virtue of being able to retrieve DataLink documents.

The service descriptor embedded in an ObsTAP query response is allowed because ObsTAP is a peculiar TAP service and TAP allows the TAP response to contain additional resources in addition to the "results" one (See section 2.9 of TAP-1.0 specification). Hence the inclusion of a service descriptor service is valid.


\section{DataLink in the context of other dataset discovery methods}
Datasets can also be discovered in various other ways. Dataset "discovery" is defined as the discovery of the ivoa publisher\_did of a dataset in standard services or by the ad hoc discovery of "obsids" in combination with the a priori knowledge of a DataLink service "aware" of these obsids.
Datasets can also be discovered in various other ways. Dataset "discovery" is defined as the discovery of the IVOA \verb|publisher_did| of a dataset in standard services or by the ad hoc discovery of "obsids" in combination with the a priori knowledge of a DataLink service "aware" of these obsids.

Beside the most standard and modern discovery path via ObsTAP/SIAP-2.0, the following alternative scenarii are possible:
\begin{itemize}
\item The discovery can be done via an SIAP-1.0 or an SSA service. A DataLink service descriptor should have been added to the Service query response to allow further guiding to additional resources
\item The discovery can be done via a paper in a journal implementing publication of datasets associated with articles. The editor should describe or implement a DataLink service (eg via a service descriptor valid for the journal) for further usage and access to download, DataAcces, metadata resources.
\item The discovery can be done via an SIAP-1.0 or an SSA service. A DataLink service descriptor should have been added to the service query response to allow further guiding to additional resources
\item The discovery can be done via a paper in a journal implementing publication of datasets associated with articles. The editor should describe or implement a DataLink service (eg via a service descriptor valid for the journal) for further usage and access to download DataAccess metadata resources.
\item Logs of observations are dataset descriptions belonging to the catalog category. They can be exposed in the VO using ConeSearch or TAP. They are in general not consistent with the ObsCore model. However they allow some kind of "dataset discovery". A Service descriptor can be added to the VOTable containing the log file.
\item HiPS is an IVOA standard for a global and hierarchical allsky access to pixel and catalogue data (reference HIPS). HiPS cells contain ids for original dataset which have been processed to build the Healpix maps. HiPS metadata file allows to generate a specific VOTable record for each cell of the HiPS collection including a "progenitor" url. This can be a new way to discover datasets and start a DataLink session to find out additional associated resources.
\item HiPS is an IVOA standard for a global and hierarchical allsky access to pixel and catalogue data (reference HIPS). HiPS cells contain ids for original dataset which have been processed to build the Healpix maps. HiPS metadata file allows to generate a specific VOTable record for each cell of the HiPS collection including a "progenitor" URL. This can be a new way to discover datasets and start a DataLink session to find out additional associated resources.
\end{itemize}

\section{DataLink outside Data discovery context}
Expand All @@ -134,13 +135,13 @@ \section{DataLink outside Data discovery context}
\end{itemize}
We could also attach links to entities in an IVOA provenance metadata service response.
\section{Various recognition solutions for use cases introduced in section 3 and 4}
In such contexts, the links ressource URL attached to a record may be given in various ways:
In such contexts, the \blinks resource URL attached to a record may be given in various ways:
\begin{itemize}
\item It may be deduced from an "identifier" given by one of the main table FIELD. In that case it is easy to attach a service descriptor to the main VOTable containing the measurements.
\item It may be given directly in one of the FIELD of the table (let's say the name of this FIELD is "bla"). In that case we may still have two different situations.
\begin{itemize}
\item If the FIELD "bla" contains URL driving different contents from row to row, it is a good idea to use an "Obscore"-like solution, consisting in addding the utype "Access.reference" to FIELD bla, and to add a "foo" column with utype "Access.format" to tell the client what is the nature of the retrieved resource (\{links\} resource or whatever other media type).
\item If the FIELD "bla" contains always an URL to the \{links\} resource (or whatever media type) without any change from row to row, it is recommendedd to use a LINK element inside the FIELD "bla" to qualify the url as described in DataLink specification, section 5.
\item If the FIELD "bla" contains URL driving different contents from row to row, it is a good idea to use an "Obscore"-like solution, consisting in addding the utype \verb|Access.reference| to FIELD "bla", and to add a "foo" column with utype \verb|Access.format| to tell the client what is the nature of the retrieved resource (\{links\} resource or whatever other media type).
\item If the FIELD "bla" contains always an URL to the \{links\} resource (or whatever media type) without any change from row to row, it is recommended to use a LINK element inside the FIELD "bla" to qualify the URL as described in DataLink specification, section 5.
\end{itemize}
\end{itemize}

Expand Down

1 comment on commit bbdc9ee

@Bonnarel
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Good fixes

Please sign in to comment.