/[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 5186 by msdemlei, Tue Oct 23 13:53:16 2018 UTC revision 5187 by msdemlei, Wed Oct 24 14:00:42 2018 UTC
# Line 241  Line 241 
241  patterns, and few such data collections were actually registered; see  patterns, and few such data collections were actually registered; see
242  the IVOA Note on Discovering Data Collections \citep{note:DataCollect} for  the IVOA Note on Discovering Data Collections \citep{note:DataCollect} for
243  details.  To better support the scheme proposed there, version 1.2 adds  details.  To better support the scheme proposed there, version 1.2 adds
244  the \xmlel{vs:TODOTODO} type that identifies a resource as data-like but  the \xmlel{vs:DataResource} and \xmlel{vs:CatalogResource} types
245    that identify a resource as data-like but
246  allows the addition of various capabilities to the record (which  allows the addition of various capabilities to the record (which
247  \xmlel{vs:DataCollection} did not).  An analogous use case would be  \xmlel{vs:DataCollection} did not).  An analogous use case would be
248  ``Find all TAP services publishing tables from Gaia DR2''.\todo{I need a  ``Find all TAP services publishing tables from Gaia DR2''.
 name for these resource types.  Desperately.}  
249    
250  \paragraph{Find a large-scale survey of sources between 20 and 40 GHz.}  \paragraph{Find a large-scale survey of sources between 20 and 40 GHz.}
251  While the spectral constraint is easily satisfied by the new coverage  While the spectral constraint is easily satisfied by the new coverage
# Line 406  Line 406 
406  \label{sect:summ}  \label{sect:summ}
407    
408    
409  The VODataService extension defines four new types of resources.  Two inherit  VODataService defines several resource types and some auxiliary classes
410  directly from \xmlel{vr:Resource}:  necessary to describe resources of these new types.
411    
412    \subsubsection{Auxiliary Classes}
413    
414  \begin{bigdescription}  The VODataService type \xmlel{vs:Coverage} allows the declaration of
415  \item[\xmlel{vs:DataCollection}]  the physical coverage of a resource on the sky (or on spherical bodies),
416  This resource was used in version 1.1 of this standard to define simple  in time, and in the energy of the messenger particle.  In addition, the
417  collections of data, perhaps available through ftp services or offline.  element should contain a rough indication of the messenger type
418  It might still be used as such, although the utility of such a  (``Optical''), and it can contain a link to a footprint service and an
419  registration is questioinable at present.  With the Endorsed Note on  indication of the spatial resolution within a service.
420  discovering data collections \citep{note:DataCollect}, a more capabable type for  
421  reigstering data collections independent of services is necessary, and  VODataService has several classes for the declaration of the tabular
422  in general it is desirable to attach actionable properties (i.e.,  structure underlying a service; this can be the tables in a TAP service,
423  capabilities) to resource records.  Therefore, version 1.2 of  or it can relate to the data structure returned by the service.  A
424  VODataService deprecates \xmlel{vs:DataCollection} for use with data  \xmlel{vs:TableSet} consists of one or more (possibly anonymous)
425  available online.  Use \xmlel{vs:TODOTODO} instead, with auxiliary  \xmlel{vs:TableSchema} instances.  These have some very basic metadata
426  capabilities if available through IVOA standard services, or with a  (name, title, description, utype) and otherwise contain \xmlel{vs:Table}
427  basic capability having a WebBrowser interface if only nonstandard  instances.  These again have simple metadata, but mainly give column
428  access modes are supported.  metadata (including UCDs and units) in \xmlel{vs:TableParam}-typed
429          elements.  These are the basis for enabling discovery queries like
430    ``find all resources having redshifts and far infrared fluxes''.
431  \item[\xmlel{vs:StandardSTC}]  
432  This resource type was intended to declare standard combinations of  Note that table and schema metadata is deliberately shallow.  If the
433  STC 1 reference frames and other coordinate metadata.  It is no longer  main resource metadata is not enough to discover the table -- as is
434  in use and retained only for compatibility.  It may be removed in a  fairly typical when a TAP service contains multiple unrelated tables --,
435  later version of VODataService version 1.  data providers should define separate records for them as described in
436  \end{bigdescription}  the Note on Discovering Data Collections.
   
 The other two resource types represent specialized services:  
   
   
 \begin{bigdescription}  
 \item[\xmlel{vs:DataService}]  
 Inheriting from \xmlel{vr:Service}, this type is for  
        services that access astronomical data.  It adds the ability to  
        describe the data's coverage of the  
        sky, frequency, and time.  
   
 \item[\xmlel{vs:CatalogService}]  
 Inheriting from \xmlel{vs:DataService}, this type  
        specifically refers to a service that accesses tabular data.  
        In addition to the coverage information, this type adds the  
        ability to describe the tables and their columns.  This is  
        intended for describing services that support the ``simple'' IVOA  
        data access layer protocols such as Simple Image Access  
         and Simple Cone Search.  
 \end{bigdescription}  
   
   
 In general, \xmlel{coverage} refers to  
 the extent that data samples the measurement range of the sky (space),  
 frequency, and time.  The coverage metadata (encoded via the  
 \xmlel{vs:Coverage} type) has two parts.  The first part  
 allows a full STC profile description in space, time, and energy.  
 The second part  
 captures key coverage metadata defined in the IVOA Resource Metadata  
 standard \citep{2007ivoa.spec.0302H}.  The RM-derived coverage elements can  
 be considered summarizing metadata for many of the details that  
 \emph{may} appear within the STC description, and enables simpler  
 searching of high-level coverage information.  
   
   
   
   
 Table descriptions appear within a single \xmlel{tableset}  
 element.  This element can in turn can contain one or more  
 \xmlel{schema} element in which each schema  
 represents a set of logically related tables.  It is not required that  
 that the schema grouping match the underlying database's  
 \emph{catalogs} or \emph{schemas}, though it may.  In some cases,  
 such as when describing the table that is returned from an SIA  
 service, the terms \emph{catalog} and \emph{schema} may have  
 little relevance; in this case, the table can be considered part of a  
 sole ``default'' schema.    
   
   
   
 For each table in a schema, one can describe each of the columns,  
 providing such information as its name, type, UCD,  
 units, and a textual description.  Providing this information makes it  
 possible to select a resource based on the kind data contained in its  
 tables.    
437    
438    VODataService defines specialized interface type
   
 Finally, the VODataService defines specialized interface type  
439  (inheriting from \xmlel{vr:Interface}) called  (inheriting from \xmlel{vr:Interface}) called
440  \xmlel{vs:ParamHTTP}.  This type is used to describe the commonly  \xmlel{vs:ParamHTTP}.  This type is used to describe the commonly
441  used interface that is invoked over HTTP as either a GET or a POST  used interface that is invoked over HTTP as either a GET or a POST
442  in which the arguments are encoded as  in which the arguments are encoded as
443  \emph{name=value} pairs.  In addition to the access URL, it can  \emph{name=value} pairs.  Such interface declarations should
 include not only the mime-type of the returned response, it can also  
444  enumerate the input arguments that are supported by the service  enumerate the input arguments that are supported by the service
445  implementation.  Much like table columns, one can indicate for each  implementation; this is particularly useful in the generation of simple
446  argument the name, the UCD, the data type, the units, whether it is  user interfaces from VOSI capabilities responses.
447  required, and a textual description of the argument.  Note that this does  
448  not capture any interdependencies between arguments.  For example, it  To be able to express the types of table columns and service arguments
449  cannot indicate if one argument only makes sense in the presence of  alike, VODataService defines several type systems.  All of these are
450  another argument.    basically just enumerations of type names, possibly with some additional
451    metadata like VOTable-style array sizes.  In new resource records, only
452    \xmlel{vs:SimpleDataType} (for ParamHTTP interface parameters) and
453    \xmlel{vs:VOTableType} (for table columns) should be used.
454    
455    \subsubsection{VODataService Resource Classes}
456    
457    \begin{figure}
458    \includegraphics{resclasses.pdf}
459    \caption{The four major resource classes in VODataService and their
460    derivation tree}
461    \label{fig:rescls}
462    \end{figure}
463    
464    While no common VO service discovery pattern relies on the type  of the
465    resource,\footnote{Of course, in non-service discovery (e.g., authorities
466    or standards), resource types are important.} resources should
467    nevertheless choose an appropriate type for their resources.  At the
468    very least, this helps in Registry maintenance.
469    
470    VODataService provides four major resource classes; their derivation
471    tree is shown in Fig.~\ref{fig:rescls}.  The vertical distinction in
472    that figure reflects whether a resource has an associated tableset
473    (DataX vs.~CatalogX); you would typically use the DataX types when a
474    resource does not naturally admit a relational structure.  The classical
475    example for this would be a couple of files on an FTP server.  CatalogX,
476    on the other hand, has an associated tableset.  That does not mean that
477    it is limited to what is conventionally thought as a ``catalogue'',
478    i.e., a collection of metadata on astronomical objects.  On the
479    contrary, CatalogX should also be used for collection of images,
480    spectra, time series, etc, as long as their metadata is sufficiently
481    structured.  Accessibility through IVOA standard protocols (ObsCore,
482    SIAP, SSAP) certainly satisfies that requirement.
483    
484    The horizontal distinction (XResource vs.~XService) is somewhat more
485    subtle, as the content model of XResource and XService are identical.
486    Choose XResource when the resource is mainly accessible as part of
487    another service; the classical example would be a table (or schema) in a
488    TAP service or a collection of images or spectra within an ObsTAP
489    service.  These should then have mainly auxiliary capabilities (where
490    a capability with a \xmlel{vr:WebBrowser}-typed interface to, say, an
491    form-based access point would certainly not hurt).  Choose XService when
492    there is a 1:1 relationship between the publishing service and the
493    published data.
494    
495    
496    Two further resource classes in VODataService are deprecated in version
497    1.2.  
498    
499    \xmlel{vs:DataCollection} was used in version 1.1 of this standard to
500    define simple collections of data, much like CatalogResource in the
501    current version.  It did not admit capabilities, though, and since the
502    addition of capabilities would essentially have a CatalogService clone
503    with a different child sequence, it was decided to abandon rather than
504    repair it.
505    
506    \xmlel{vs:StandardSTC} was intended to declare standard combinations of
507    STC 1 reference frames and other coordinate metadata.  Since STC 1
508    coverage declaration is itself deprecated, so is \xmlel{vs:StandardSTC}.
509    
510    Resource record authors are requested to migrate or discard resource
511    records using the deprecated types.  If all such records have
512    disappeared from the VO by version 1.3 of this specification, we may
513    remove the type declarations from the schema.
514    
515    
516  \section{The VODataService Metadata}  \section{The VODataService Metadata}
# Line 520  Line 526 
526  \subsection{Resource Type Extensions}  \subsection{Resource Type Extensions}
527  \label{sect:resext}  \label{sect:resext}
528    
529  \subsubsection{DataCollection}  \subsubsection{DataResource}
530  \label{sect:datacollection}  \label{sect:DataResource}
   
   
 A \emph{data collection}, which is describable with the  
 \xmlel{vs:DataCollection} resource type, is a logical  
 group of data comprising one or more accessible  
 datasets.  A collection can contain any combination of images,  
 spectra, catalogs, time-series, or other data.  (In contrast, we talk  
 about a \emph{dataset} as being a set of digitally-encoded  
 data that is normally accessible as a single unit -- e.g., a file.)  
   
   
   
 The \xmlel{vs:DataCollection} type adds seven additional metadata  
 elements beyond the core VOResource metadata:  
   
 % GENERATED: !schemadoc VODataService-v1.2.xsd DataCollection  
 \begin{generated}  
 \begingroup  
         \renewcommand*\descriptionlabel[1]{%  
         \hbox to 5.5em{\emph{#1}\hfil}}\vspace{2ex}\noindent\textbf{\xmlel{vs:DataCollection} Type Schema Documentation}  
   
 \noindent{\small  
            A logical grouping of data which, in general, is composed of one  
            or more accessible datasets.  A collection can contain any  
            combination of images, spectra, catalogs, or other data.    
          \par}  
   
 \noindent{\small  
            (A dataset is a collection of digitally-encoded data that  
            is normally accessible as a single unit, e.g., a file.)  
          \par}  
   
 \vspace{1ex}\noindent\textbf{\xmlel{vs:DataCollection} Type Schema Definition}  
   
 \begin{lstlisting}[language=XML,basicstyle=\footnotesize]  
 <xs:complexType name="DataCollection" >  
   <xs:complexContent >  
     <xs:extension base="vr:Resource" >  
       <xs:sequence >  
         <xs:element name="facility" type="vr:ResourceName" minOccurs="0"  
                   maxOccurs="unbounded" />  
         <xs:element name="instrument" type="vr:ResourceName" minOccurs="0"  
                   maxOccurs="unbounded" />  
         <xs:element name="rights" type="vr:Rights" minOccurs="0"  
                   maxOccurs="unbounded" />  
         <xs:element name="format" type="vs:Format" minOccurs="0"  
                   maxOccurs="unbounded" />  
         <xs:element name="coverage" type="vs:Coverage" minOccurs="0" />  
         <xs:element name="tableset" type="vs:TableSet" minOccurs="0" >  
           <xs:unique name="DataCollection-schemaName" >  
             <xs:selector xpath="schema" />  
             <xs:field xpath="name" />  
           </xs:unique>  
           <xs:unique name="DataCollection-tableName" >  
             <xs:selector xpath="schema/table" />  
             <xs:field xpath="name" />  
           </xs:unique>  
         </xs:element>  
         <xs:element name="accessURL" type="vr:AccessURL" minOccurs="0" />  
       </xs:sequence>  
     </xs:extension>  
   </xs:complexContent>  
 </xs:complexType>  
 \end{lstlisting}  
   
 \vspace{0.5ex}\noindent\textbf{\xmlel{vs:DataCollection} Extension Metadata Elements}  
   
 \begingroup\small\begin{bigdescription}\item[Element \xmlel{facility}]  
 \begin{description}  
 \item[Type] string with ID attribute: vr:ResourceName  
 \item[Meaning]  
                      the observatory or facility used to collect the data  
                      contained or managed by this resource.    
                     
 \item[Occurrence] optional; multiple occurrences allowed.  
   
 \end{description}  
 \item[Element \xmlel{instrument}]  
 \begin{description}  
 \item[Type] string with ID attribute: vr:ResourceName  
 \item[Meaning]  
                      the Instrument used to collect the data contain or  
                      managed by a resource.    
                     
 \item[Occurrence] optional; multiple occurrences allowed.  
   
 \end{description}  
 \item[Element \xmlel{rights}]  
 \begin{description}  
 \item[Type] composite: \xmlel{vr:Rights}  
 \item[Meaning]  
                       Information about rights held in and over the resource.  
                       
 \item[Occurrence] optional; multiple occurrences allowed.  
 \item[Comment]  
                       This should be repeated for all Rights values that apply.  
                       
   
 \end{description}  
 \item[Element \xmlel{format}]  
 \begin{description}  
 \item[Type] a string with optional attributes  
 \item[Meaning]  
                       The physical or digital manifestation of the information  
                       supported by a resource.  
                       
 \item[Occurrence] optional; multiple occurrences allowed.  
 \item[Comment]  
                       This should use RFC 2046 media (“MIME”) types for  
                       network-retrievable, digital data.    
                       Non-RFC 2046 values could be used for media that cannot  
                       be retrieved over the network.  
                       
   
 \end{description}  
 \item[Element \xmlel{coverage}]  
 \begin{description}  
 \item[Type] composite: \xmlel{vs:Coverage}  
 \item[Meaning]  
                      Extent of the content of the resource over space, time,  
                      and frequency.  
                     
 \item[Occurrence] optional  
   
 \end{description}  
 \item[Element \xmlel{tableset}]  
 \begin{description}  
 \item[Type] composite: \xmlel{vs:TableSet}  
 \item[Meaning]  
                      A description of the tables that are part of this  
                      collection.  
                     
 \item[Occurrence] optional  
 \item[Comment]  
                      Each schema name and each table name must be  
                      unique within this tableset.  
                     
   
 \end{description}  
 \item[Element \xmlel{accessURL}]  
 \begin{description}  
 \item[Type] composite: \xmlel{vr:AccessURL}  
 \item[Meaning]  
                      The URL that can be used to download the data contained in  
                      this data collection.  
                     
 \item[Occurrence] optional  
   
 \end{description}  
   
   
 \end{bigdescription}\endgroup  
   
 \endgroup  
 \end{generated}  
   
 % /GENERATED  
   
 The definition of the \xmlel{tableset} element forces certain  
 names within its description to be unique; these constraints are explained  
 further in section~\ref{sect:unique}.  
   
   
   
 The attributes \xmlel{facility}, \xmlel{instrument}, \xmlel{rights},  
 and \xmlel{accessURL} are re-used from  
 the core VOResource schema, sharing the same syntax and similar  
 semantics.  In particular, the meanings of \xmlel{facility}  
 and \xmlel{instrument} in the context of  
 \xmlel{vs:DataCollection} are different from that in  
 \xmlel{vr:Organisation} only in that in the former type, they refer  
 to the origin of the data.  
531    
532    The \xmlel{vs:DataResource} resource type is for describing a
533    resource containing generic astronomical data without a dominating
534    tabular structure.  An example might be a largely unstructured archive
535    of various observations.  Resources that have structured metadata tables
536    (like most VO services) or are tabular in nature (like usual
537    astronomical catalogs) should use \xmlel{vs:CatalogResource}.
538    
539    The type is built on top of \xmlel{vr:Service}, so they can have
540    capabilities.  For \xmlel{vs:DataResource}, only auxiliary capabilities
541    (e.g., TAP services giving access to the table) or plain capabilities
542    with \xmlel{vr:WebBrowser} interfaces should be given.  Resources with a
543    primary access mode dedicated to the resource should use
544    \xmlel{vs:DataService}-typed resources.
545    
   
 The \xmlel{vs:Format} type is used for  
 providing a value to the \xmlel{format} element:  
   
   
 % GENERATED: !schemadoc VODataService-v1.2.xsd Format  
 \begin{generated}  
 \begingroup  
         \renewcommand*\descriptionlabel[1]{%  
         \hbox to 5.5em{\emph{#1}\hfil}}\vspace{1ex}\noindent\textbf{\xmlel{vs:Format} Type Schema Definition}  
   
 \begin{lstlisting}[language=XML,basicstyle=\footnotesize]  
 <xs:complexType name="Format" >  
   <xs:simpleContent >  
     <xs:extension base="xs:token" >  
       <xs:attribute name="isMIMEType" type="xs:boolean" default="false" />  
     </xs:extension>  
   </xs:simpleContent>  
 </xs:complexType>  
 \end{lstlisting}  
   
 \vspace{0.5ex}\noindent\textbf{\xmlel{vs:Format} Attributes}  
   
 \begingroup\small\begin{bigdescription}  
 \item[isMIMEType]  
 \begin{description}  
 \item[Type] boolean (true/false): xs:boolean  
 \item[Meaning]  
                  If true, the content of the element is an RFC  
                  2046-compliant media time.  
                 
 \item[Occurrence] optional  
 false  
 \end{description}  
   
   
 \end{bigdescription}\endgroup  
   
 \endgroup  
 \end{generated}  
   
 % /GENERATED  
   
   
 The \xmlel{isMIMEType} attribute  
 provides a flag to indicate if the value represents an actual  
 MIME-type: if it is, this attribute should be explicitly set to  
 \texttt{true}.  
   
   
   
   
 See section~\ref{sect:table} for a specification of  
 the \xmlel{vs:TableSet} type for describing tables.    
   
   
   
 \subsubsection{DataService}  
   
   
 The \xmlel{vs:DataService} resource type is for describing a  
 service that provides access to astronomical data.  This service adds  
546  to the core VOResource service metadata the ability to associate an  to the core VOResource service metadata the ability to associate an
547  observing facility and/or instrument with the data as well as describe  observing facility and/or instrument with the data as well as describe
548  the coordinate coverage of data via its child \xmlel{coverage}  the coordinate coverage of data via its child \xmlel{coverage}
549  element.  Note that while these elements are all optional, a resource  element.  Note that while these elements are all optional, a resource
550  of this type still implies access to astronomical data.  of this type still implies access to astronomical data.
551    
552    % GENERATED: !schemadoc VODataService-v1.2.xsd DataResource
553    % /GENERATED
554    
555  % GENERATED: !schemadoc VODataService-v1.2.xsd DataService  \subsubsection{DataService}
 \begin{generated}  
 \begingroup  
         \renewcommand*\descriptionlabel[1]{%  
         \hbox to 5.5em{\emph{#1}\hfil}}\vspace{2ex}\noindent\textbf{\xmlel{vs:DataService} Type Schema Documentation}  
   
 \noindent{\small  
            A service for accessing astronomical data  
          \par}  
   
 \vspace{1ex}\noindent\textbf{\xmlel{vs:DataService} Type Schema Definition}  
   
 \begin{lstlisting}[language=XML,basicstyle=\footnotesize]  
 <xs:complexType name="DataService" >  
   <xs:complexContent >  
     <xs:extension base="vr:Service" >  
       <xs:sequence >  
         <xs:element name="facility" type="vr:ResourceName" minOccurs="0"  
                   maxOccurs="unbounded" />  
         <xs:element name="instrument" type="vr:ResourceName" minOccurs="0"  
                   maxOccurs="unbounded" />  
         <xs:element name="coverage" type="vs:Coverage" minOccurs="0" />  
       </xs:sequence>  
     </xs:extension>  
   </xs:complexContent>  
 </xs:complexType>  
 \end{lstlisting}  
   
 \vspace{0.5ex}\noindent\textbf{\xmlel{vs:DataService} Extension Metadata Elements}  
   
 \begingroup\small\begin{bigdescription}\item[Element \xmlel{facility}]  
 \begin{description}  
 \item[Type] string with ID attribute: vr:ResourceName  
 \item[Meaning]  
                      the observatory or facility used to collect the data  
                      contained or managed by this resource.    
                     
 \item[Occurrence] optional; multiple occurrences allowed.  
   
 \end{description}  
 \item[Element \xmlel{instrument}]  
 \begin{description}  
 \item[Type] string with ID attribute: vr:ResourceName  
 \item[Meaning]  
                      the Instrument used to collect the data contain or  
                      managed by a resource.    
                     
 \item[Occurrence] optional; multiple occurrences allowed.  
   
 \end{description}  
 \item[Element \xmlel{coverage}]  
 \begin{description}  
 \item[Type] composite: \xmlel{vs:Coverage}  
 \item[Meaning]  
                      Extent of the content of the resource over space, time,  
                      and frequency.  
                     
 \item[Occurrence] optional  
   
 \end{description}  
556    
557    The \xmlel{vs:DataService} resource type has the same content model as
558    \xmlel{vs:DataResource}.  It should be used instead of
559    \xmlel{vs:DataResource} when the resource's capabilties give
560    access to (essentially) only the resource's data, as for instance an
561    ``SSAP service for the XY instrument'', of for a service giving access
562    to multiple resources; in this latter case, make the resource-level
563    metadata should pertain to the service itself rather than any specific
564    data collection served by it.
565    
566  \end{bigdescription}\endgroup  Note that whenever the service operates on clearly definable tabular
567    data, the \xmlel{vs:CatalogService} resource type should be used in
568    preference to \xmlel{vs:DataService}.
569    
570  \endgroup  For DataService's content model, refer to sect.~\ref{sect:DataResource}.
 \end{generated}  
571    
 % /GENERATED  
572    
 The use and meaning of the \xmlel{facility} and  
 \xmlel{instrument} elements are the same as for  
 \xmlel{vs:DataCollection}.  
573    
574    
575    \subsubsection{CatalogResource}
576    \label{sect:CatalogResource}
577    
 \subsubsection{CatalogService}  
 \label{sect:catalogservice}  
578    
579    The \xmlel{vs:CatalogResource} resource type is for describing a
580    resource containing astronomical data or metadata in a set of one or
581    more tables.  It extends \xmlel{vs:DataResource} and thus has metadata
582    on coverage and the facilities and instruments that produced the
583    resource.  In addition to \xmlel{vs:DataResource}, this type allows the
584    declaration of the metadata of the table(s) underlying the data or
585    delivered by it in a tableset element.
586    
587  The \xmlel{vs:CatalogService} resource type is for describing a  As with \xmlel{vs:DataResource}, this type should only be used if all
588  service that interacts with astronomical data through one or more  capabilities declared in the resource are either auxiliary or
589  specified tables.  Because it extends the \xmlel{vs:DataService}  nonstandard.  Use \xmlel{vs:CatalogService} instead.
 type, a catalog service can have a coverage description as well.  The  
 tabular data may optionally be described via a  
 \xmlel{tableset} element.  
590    
591    This is the type that should be used for publishing data collections
592    according to the IVOA Note on Discovering Data Collections
593    \citep{note:DataCollect}.
594    
595    
596  % GENERATED: !schemadoc VODataService-v1.2.xsd CatalogService  % GENERATED: !schemadoc VODataService-v1.2.xsd CatalogResource
597  \begin{generated}  \begin{generated}
598  \begingroup  \begingroup
599          \renewcommand*\descriptionlabel[1]{%          \renewcommand*\descriptionlabel[1]{%
# Line 917  Line 657 
657    
658  % /GENERATED  % /GENERATED
659    
660  The definition of \xmlel{tableset} element forces certain  
661  names within its description to be unique; these constraints are explained  \subsubsection{CatalogService}
662  further in section~\ref{sect:unique}.  
663    The \xmlel{vs:CatalogResource} resource type is for describing a
664    service publishing astronomical data or metadata based on tabular
665    representations.  Its relationship is as between \xmlel{vs:DataResource}
666    and \xmlel{vs:DataService}: Use \xmlel{vs:CatalogService} when either
667    the resource's capabilties are exclusive to the resource described by
668    the resource-level metadata (``SSAP service for the XY instrument'') or
669    if the service publishes multiple other CatalogResources; in that latter
670    case, again, the resource-level metadata should not refer to any
671    specific data collection contained.
672    
673    This is the type that should be used for typical, one-resource VO
674    services.
675    
676    For CatalogService's content model, refer to
677    sect.~\ref{sect:CatalogResource}.
678    
679  \subsection{Coverage}  \subsection{Coverage}
680  \label{sect:cover}  \label{sect:cover}
681    
682    
683    
684    \subsubsection{DataCollection}
685    \label{sect:datacollection}
686    
687    The \xmlel{vs:DataCollection} type is deprecated and should no longer be
688    used in new resource records.  Existing \xmlel{vs:DataCollection}-typed
689    records should be migrated to \xmlel{vs:DataResource} or
690    \xmlel{vs:CatalogResource} as appropriate.  The \xmlel{accessURL} child
691    of \xmlel{vs:DataCollection} (which is not part of any of the new
692    classes) should be replaced by a plain capability with a
693    \xmlel{vr:WebBrowser}-typed interface.
694    
695    
696    \subsubsection{StandardSTC}
697    
698    The \xmlel{vs:StandardSTC} type is deprecated and should no longer be
699    used in new resource records.  Since the XML serialisation of the STC 1
700    data model was never promoted to an IVOA recommendation, there also is
701    no properly standardised way of creating such records.
702    
703    \subsection{Coverage in Space, Time, and Spectrum}
704    
705  The \xmlel{vs:Coverage} type summarily describes how the data served is  The \xmlel{vs:Coverage} type summarily describes how the data served is
706  distributed on the  distributed on the
707  sky, in energy, and in time.  For the energy coverage, there is a  sky, in energy, and in time.  For the energy coverage, there is a
# Line 1185  Line 963 
963    
964  % /GENERATED  % /GENERATED
965    
966    
967    
968  \subsection{Tabular Data}  \subsection{Tabular Data}
969  \label{sect:table}  \label{sect:table}
970    
# Line 2754  Line 2534 
2534  \subsection{Changes from REC-1.1}  \subsection{Changes from REC-1.1}
2535    
2536  \begin{itemize}  \begin{itemize}
2537  \item Deprecating STCResourceProfile and replacing it with  \item Deprecated STCResourceProfile and replaced it with
2538  \xmlel{spatial}, \xmlel{temporal}, and \xmlel{spectral} elements.  \xmlel{spatial}, \xmlel{temporal}, and \xmlel{spectral} elements.
2539  \item Adding an nrows element to \xmlel{vs:Table}.  \item Introduced new DataResource and CatalogResource resource types
2540  \item Requiring inclusion of quotes for delimited identifiers in a  and wove them into the inheritance hierarchy to CatalogService; these
2541    are to be used for ``dependent'' resources.
2542    \item Deprecated DataCollection and StandardSTC (which are no longer
2543    needed).
2544    \item Added an nrows element to \xmlel{vs:Table}.
2545    \item Required inclusion of quotes for delimited identifiers in a
2546  SQL context.  SQL context.
2547  \item DataType/@arraysize no longer defaults to 1, and the  \item DataType/@arraysize no longer defaults to 1, and the
2548  interpretation of arraysize=1 as a scalar is withdrawn.  Use empty  interpretation of arraysize=1 as a scalar is withdrawn.  Use empty
2549  arraysize for scalars now.  arraysize for scalars now.
2550  \item Deprecating TAPType.  \item Deprecated TAPType.
2551  \item Ported source to \ivoatex.  \item Ported source to \ivoatex.
2552  \end{itemize}  \end{itemize}
2553    

Legend:
Removed from v.5186  
changed lines
  Added in v.5187

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