/[volute]/trunk/projects/registry/VODataService/VODataService.tex
ViewVC logotype

Diff of /trunk/projects/registry/VODataService/VODataService.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 5498 by msdemlei, Fri Oct 26 15:41:13 2018 UTC revision 5499 by msdemlei, Tue Jun 11 10:49:36 2019 UTC
# Line 113  Line 113 
113    
114  The XML Schemas of VODataService as well as VOResource and its other  The XML Schemas of VODataService as well as VOResource and its other
115  extensions are  extensions are
116  available from the IVOA document  available from the IVOA schema
117  repository\footnote{\url{http://www.ivoa.net/xml}} at any time.  repository\footnote{\url{http://www.ivoa.net/xml}} at any time.
118  Parts of the schema appear within the main sections of this document;  Parts of the schema appear within the main sections of this document;
119  however, documentation nodes have been left out for the sake of brevity.  however, documentation nodes have been left out for the sake of brevity.
# Line 122  Line 122 
122  repository, the version in the schema repository is authoritative.  repository, the version in the schema repository is authoritative.
123    
124  References to specific elements and types defined in the VOResource  References to specific elements and types defined in the VOResource
125  schema include the namespaces prefix \xmlel{vr} as in  schema include the namespace prefix \xmlel{vr} as in
126  \xmlel{vr:Resource} (a type defined in the VOResource schema).  \xmlel{vr:Resource} (a type defined in the VOResource schema).
127    
128  \section{Introduction}  \section{Introduction}
# Line 165  Line 165 
165  the fundamental types and structures extended here.  the fundamental types and structures extended here.
166  \item[STC, v1.33 \citep{2007ivoa.spec.1030R}] The deprecated mechanism  \item[STC, v1.33 \citep{2007ivoa.spec.1030R}] The deprecated mechanism
167  for declaring coverage through STCResourceProfile still uses concepts  for declaring coverage through STCResourceProfile still uses concepts
168  from verion 1 of the IVOA data model for Space-Time Coordinates.  The  from version 1 of the IVOA data model for Space-Time Coordinates.  The
169  updated mechanism has no such dependence any more.  updated mechanism has no such dependence any more.
170  \end{description}  \end{description}
171    
# Line 243  Line 243 
243  system barycenter, so this use case does \emph{not} immediately enable  system barycenter, so this use case does \emph{not} immediately enable
244  the discovery of, say, H$\alpha$ images of remote galaxies.  Redshift  the discovery of, say, H$\alpha$ images of remote galaxies.  Redshift
245  correction has to be applied by the client based on knowledge about the  correction has to be applied by the client based on knowledge about the
246  object(s) investigated.\todo{Also, we don't do solar system well  object(s) investigated.
 spatially.  Mention this here?  Fix it now?}  
247    
248  \paragraph{Find all ObsCore services publishing data taken at the  \paragraph{Find all ObsCore services publishing data taken at the
249  Telescope X.} This use case could be satisfied in version 1.1 through  Telescope X.} This use case could be satisfied in version 1.1 through
250  the use of \xmlel{vs:DataCollection} records and relationships to the  the use of \xmlel{vs:DataCollection} records and relationships to the
251  respective TAP services.  However, this scheme led to error-prone query  respective TAP services.  However, this scheme led to error-prone query
252  patterns, and few such data collections were actually registered; see  patterns, and few such data collections were actually registered; see
253  the IVOA Note on Discovering Data Collections \citep{note:DataCollect} for  the IVOA Note on discovering data collections \citep{2019ivoa.rept.0520D} for
254  details.  To better support the scheme proposed there, version 1.2 adds  details.  To better support the scheme proposed there, version 1.2 adds
255  the \xmlel{vs:DataResource} and \xmlel{vs:CatalogResource} types  the \xmlel{vs:DataResource} and \xmlel{vs:CatalogResource} types
256  that identify a resource as data-like but  that identify a resource as data-like but
# Line 432  Line 431 
431  the physical coverage of a resource on the sky (or on spherical bodies),  the physical coverage of a resource on the sky (or on spherical bodies),
432  in time, and in the energy of the messenger particle.  In addition, the  in time, and in the energy of the messenger particle.  In addition, the
433  element should contain a rough indication of the messenger type  element should contain a rough indication of the messenger type
434  (``Optical''), and it can contain a link to a footprint service and an  (``Optical''), and it can contain a link to a footprint endpoint and an
435  indication of the spatial resolution within a service.  indication of the spatial resolution within a service.
436    
437  VODataService has several classes for the declaration of the tabular  VODataService has several classes for the declaration of the tabular
# Line 453  Line 452 
452  main resource metadata is not enough to discover the table -- as is  main resource metadata is not enough to discover the table -- as is
453  fairly typical when a TAP service contains multiple unrelated tables --,  fairly typical when a TAP service contains multiple unrelated tables --,
454  data providers should define separate records for them as described in  data providers should define separate records for them as described in
455  the Note on Discovering Data Collections.  sect.~\ref{sect:discoverdata}.
456    
457  VODataService further defines a specialized interface type  VODataService further defines a specialized interface type
458  (inheriting from \xmlel{vr:Interface}) called  (inheriting from \xmlel{vr:Interface}) called
# Line 495  Line 494 
494  resource does not naturally admit a relational structure.  The classical  resource does not naturally admit a relational structure.  The classical
495  example for this would be a collection of files on an FTP server.  CatalogX,  example for this would be a collection of files on an FTP server.  CatalogX,
496  on the other hand, has an associated tableset.  That does not mean that  on the other hand, has an associated tableset.  That does not mean that
497  it is limited to what is conventionally thought as a ``catalog'',  it is limited to what is conventionally thought of as a ``catalogue'',
498  i.e., a table of data on astronomical objects.  On the  i.e., a table of data on astronomical objects.  On the
499  contrary, CatalogX should also be used for collections of images,  contrary, CatalogX should also be used for collections of images,
500  spectra, time series, etc, as long as their metadata is sufficiently  spectra, time series, etc, as long as their metadata is sufficiently
# Line 503  Line 502 
502  SIAP, SSAP) certainly satisfies that requirement.  SIAP, SSAP) certainly satisfies that requirement.
503    
504  The horizontal distinction (XResource vs.~XService) is somewhat more  The horizontal distinction (XResource vs.~XService) is somewhat more
505  subtle, as the content model of XResource and XService are identical.  subtle and will be discussed in sect.~\ref{sect:discoverdata}.
 Choose XResource when the resource is mainly accessible as part of  
 another service; the classical example would be a table (or schema) in a  
 TAP service or a collection of images or spectra within an ObsTAP  
 service.  These should then have mainly auxiliary capabilities (where  
 a capability with a \xmlel{vr:WebBrowser}-typed interface to, say, an  
 form-based access point does not preclude the use of XResource).    
 Choose XService when  
 there is a 1:1 relationship between the publishing service and the  
 published data, or if the service publishes multiple data collections  
 registered in separate XResource records.  
   
506    
507  Two further resource classes defined VODataService 1.1,  Two further resource classes defined VODataService 1.1,
508  \xmlel{vs:DataCollection} and \xmlel{vs:StandardSTC},  \xmlel{vs:DataCollection} and \xmlel{vs:StandardSTC},
# Line 524  Line 512 
512  disappeared from the VO by version 1.3 of this specification, their  disappeared from the VO by version 1.3 of this specification, their
513  type declarations may be removed from the schema.  type declarations may be removed from the schema.
514    
515    \subsubsection{Discovering Data Within Other Services}
516    
517    The content models of CatalogResource and CatalogService are identical.
518    To understand why the two classes are present nevertheless, a short
519    historical excurse is in order.  A full treatment of this is found in
520    the IVOA Endorsed Note on discovering data collections within services
521    \citep{2019ivoa.rept.0520D}, hereafter referred to as DDC.
522    
523    In the early VO, there was almost throughout a $1:1$ relationship between
524    data collections and services.  For instance, a catalogue of variable
525    stars had a single cone search interface, and the spectra from a given
526    spectrograph had a single SSA interface.  This is the model reflected by
527    the CatalogService class, and it was, by and large, sufficient for
528    IVOA's ``simple'' protocols (SCS, SIAP, SSAP, SLAP), although even these
529    protocols have facilities for multi-collection services.
530    
531    With the advent of services very naturally publishing what clearly
532    are multiple different resources -- TAP, with its multiple tables, and
533    Obscore building on top of it are the prime examples --, this model
534    proved inadequate; furthermore, publishers increasingly offered data
535    through multiple interfaces: An object catalogue now quite typically is
536    published as both a cone search service and within a TAP service; an
537    image collection could have both SIAP and Obscore interfaces.
538    
539    Thus, the relationship between data collections and services gradually
540    became $n:m$.  With this came the realisation that two classes of
541    discovery need to be supported; for all-VO queries, validation, and the
542    like, an enumeration of all \emph{services} (``give me all SSAP
543    services\dots'') needs to be performed.  For data discovery (``Where are
544    images from instrument X of object Y?''), a selection over all
545    \emph{collections} needs to be made.
546    
547    The solution eventually adopted for these problems are auxiliary
548    capabilities as introduced in DDC.  They provide stubs merely
549    identifying an access protocol -- at the same time identifying the
550    capability as an auxiliary one --  and access URLs, delegating all
551    further service metadata to a separate record, linked to the original
552    resource through an \emph{isServedBy} relationship.
553    
554    Thus, CatalogService-typed records should be used
555    
556    \begin{itemize}
557    \item when a service serves a single data collection, in which case the
558    metadata on the record describes the data collection (e.g., ``These are
559    observations of\dots'').
560    \item for a service serving multiple data collections, in which case the
561    metadata on the record  describes the service (e.g., ``This is the TAP
562    service of\dots''').
563    \end{itemize}
564    
565    CatalogResource-typed records should be used for resources that only
566    have auxiliary capabilities.
567    
568    Here is a sketch of a resource record of a table within a TAP service::
569    
570    \begin{lstlisting}[language=XML,basicstyle=\footnotesize]
571    <ri:Resource
572      xsi:type="vs:CatalogResource"
573      <title>Sample Table</title>
574      <identifier>ivo://example/sample</identifier>
575      <curation>...</curation>
576      <content> ...
577        <relationship>
578          <relationshipType>IsServedBy</relationshipType>
579          <relatedResource ivo-id="ivo://example/tap"
580            >Example TAP service</relatedResource>
581        </relationship>
582      </content>
583      <capability standardID="ivo://ivoa.net/std/TAP#aux">
584        <interface role="std" xsi:type="vs:ParamHTTP">
585          <accessURL use="base"
586            >http://example.org/svcs/tap</accessURL>
587        </interface>
588     </capability>
589      <coverage>...</coverage>
590      <tableset>
591        <schema>
592          <name>someschema</name>
593          <table>
594            <name>someschema.sample</name>...
595            ...
596          </table>
597        </schema>
598      </tableset>
599    </ri:Resource>
600    \end{lstlisting}
601    
602    A complete example can be found in DDC.
603    
604    Note that it is legal to add auxiliary capabilities to CatalogService
605    records as well.  The classical example could be a cone search service
606    serving a single catalogue that is also queriable within a larger TAP
607    service.
608    
609    Analogous considerations would apply to DataResource versus DataService,
610    although at this point no obvious use cases have been identified;
611    DataResource was included mainly for symmetry with CatalogResource.
612    
613  \section{The VODataService Metadata}  \section{The VODataService Metadata}
614  \label{sect:metadata}  \label{sect:metadata}

Legend:
Removed from v.5498  
changed lines
  Added in v.5499

msdemlei@ari.uni-heidelberg.de
ViewVC Help
Powered by ViewVC 1.1.26