/[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 5193 by msdemlei, Thu Oct 25 13:39:27 2018 UTC revision 5194 by msdemlei, Thu Oct 25 14:07:01 2018 UTC
# Line 535  Line 535 
535  in terms of the RM definition.    in terms of the RM definition.  
536    
537    
538  \subsection{Resource Type Extensions}  \subsection{VODataService Resource Types}
539  \label{sect:resext}  \label{sect:resext}
540    
541  \subsubsection{DataResource}  \subsubsection{DataResource}
# Line 806  Line 806 
806  The \xmlel{vs:Coverage} type summarily describes how the data served is  The \xmlel{vs:Coverage} type summarily describes how the data served is
807  distributed on the  distributed on the
808  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
809  qualitative classification in the \xmlel{waveband} \todo{Worry  also qualitative classification in the \xmlel{waveband} \todo{Worry
810  about non-EM messengers in waveband (use a vocabulary?)} element.  about non-EM messengers in waveband (use a vocabulary?)} element.
811    
812  Historically, the quantitative footprints were expected to be given in  Historically, the quantitative footprints were expected to be given in
813  the element of type \xmlel{stc:STCResourceProfile}.  As discussed in  the element of type \xmlel{stc:STCResourceProfile}.  As discussed in
814  \citet{note:regstc}, this expectation turned out to be erroneous,  \citet{note:regstc}, this expectation turned out to be erroneous,
815  and the underlying standard \citep{note:stcx} never proceeded to become  and the underlying standard, STC-X \citep{note:stcx}, never proceeded to become
816  a recommendation.  Hence, this version of VODataService deprecates the  a recommendation.  Hence, this version of VODataService deprecates the
817  use of \xmlel{STCResourceProfile}.  use of \xmlel{STCResourceProfile}.
818    
# Line 829  Line 829 
829  By default, the MOCs are to be interpreted in the ICRS.  It is forseen  By default, the MOCs are to be interpreted in the ICRS.  It is forseen
830  that future extensions \todo{We should really do this now -- proposals,  that future extensions \todo{We should really do this now -- proposals,
831  anyone?} to this will allow non-celestial frames (e.g., on planet  anyone?} to this will allow non-celestial frames (e.g., on planet
832  surfaces).  However, whenever a resource's coordinates can be expressed  surfaces).  However, the only celestial reference system allowed is
833  as ICRS (e.g., Galactic or Ecliptic coordinates of extrasolar objects),  ICRS.  If a resource's coordinates are natively in another frame (e.g.,
834  the coverage must be expressed in the ICRS.  Galactic or FK4 for some equinox), it is the resource record author's
835    responsibility to convert the spatial coverage into the ICRS.
836    
837  An important characteristic of MOCs is the order of the smallest scale  An important characteristic of MOCs is the order of the smallest scale
838  (the ``MOC resolution'').  Higher orders yield more faithful  (the ``MOC resolution'').  Higher orders yield more faithful
# Line 865  Line 866 
866    
867  Deviating from common VO practice (which currently fairly consistently  Deviating from common VO practice (which currently fairly consistently
868  uses wavelengths of elecromagnetic waves in vacuum), spectral limits are  uses wavelengths of elecromagnetic waves in vacuum), spectral limits are
869  given in Joules of particle energy.  This is intended to allow seamless  given in Joules of messenger energy.  This is intended to allow seamless
870  integration of non-electromagnetic messengers.  The reference position  integration of non-electromagnetic messengers.  The reference position
871  for the spectral axis is the solar system barycenter.  Again, discovery  for the spectral axis is the solar system barycenter.  Again, discovery
872  use cases on a level where the difference between reference frames of  use cases on a level where the difference between reference frames of
# Line 1073  Line 1074 
1074  The \xmlel{vs:TableSet} type can be used  The \xmlel{vs:TableSet} type can be used
1075  to describe a set of tables that are part of a single resource and can  to describe a set of tables that are part of a single resource and can
1076  be considered functionally all located at a single site.  While there is  be considered functionally all located at a single site.  While there is
1077  no expectation that the table set directly correspond to tabular service  no expectation that the table set directly corresponds to the responses
1078  responses, services should not include metadata for purely internal  of tabular services,
1079    services should not include metadata for purely internal
1080  tables.  tables.
1081    
1082    
# Line 1137  Line 1139 
1139    
1140    
1141  The \xmlel{vs:TableSchema} type collects  The \xmlel{vs:TableSchema} type collects
1142  tables together that are logically related.\todo{Better cater for the  tables together that are logically related.
1143  case that tables are outside of all schemas (see SIMBAD)}  For example, a single  For example, a single
1144  resource may provide access several major astronomical catalogs  resource may provide access several major astronomical catalogs
1145  (e.g. SDSS, 2MASS, and FIRST) from one site, enabling high-performance  (e.g. SDSS, 2MASS, and FIRST) from one site, enabling high-performance
1146  cross-correlations between them.  Each catalog can be described in a  cross-correlations between them.  Each catalog can be described in a
1147  separate \xmlel{schema} element, using the elements from  separate \xmlel{schema} element, using the elements from
1148  the \xmlel{vs:TableSchema} type.  the \xmlel{vs:TableSchema} type.\todo{Is is a good idea to use
1149    ``default'' as the NULL value?  Or should we rather have minOccurs 0 for
1150    title?}
1151    
1152    
1153    
# Line 1423  Line 1427 
1427  A foreign key description should only refer to tables described within  A foreign key description should only refer to tables described within
1428  the current table set.    the current table set.  
1429    
1430  When the tableset describes a set of TAP-accessible tables, the value of  When the table set describes a set of TAP-accessible tables, the value of
1431  a \xmlel{table}'s \xmlel{name} child must be in a form immediately  a \xmlel{table}'s \xmlel{name} child must be in a form immediately
1432  usable for use in ADQL or SQL queries. This corresponds to the analogous  usable for use in ADQL or SQL queries. This corresponds to the analogous
1433  requirement for \tapschema\ and is usually only a problem when delimited  requirement for \tapschema.  This means that all qualifications (schema,
1434  identifiers are used as table names on the relational side.  In that  catalog) must be present, but also that when delimited
1435  case, the quotes must be part of \xmlel{name}'s value, and the  identifiers are used as table names on the relational side,
1436    the quotes must be part of \xmlel{name}'s value, and the
1437  capitalisation used in the DDL must be preserved.  capitalisation used in the DDL must be preserved.
1438    
1439    
# Line 1448  Line 1453 
1453  \xmlel{vs:Catalog\-Ser\-vice} types  \xmlel{vs:Catalog\-Ser\-vice} types
1454  constrain certain names to be unique.  In particular, all schema names  constrain certain names to be unique.  In particular, all schema names
1455  within a \xmlel{tableset} element must be unique, and all  within a \xmlel{tableset} element must be unique, and all
1456  table names within a \xmlel{tableset} element must be  table names within a \xmlel{schema} element must be
1457  unique.  (A schema and table may share a common name, such as  unique.  (A schema and table may share a common name, such as
1458  ``default''.)  These constraints makes it possible to uniquely locate  ``default''.)  These constraints makes it possible to uniquely locate
1459  the description of a schema or table within a VOResource description.    the description of a schema or table within a VOResource description.  
1460    
   
 \begin{admonition}{Remark}  
 The uniqueness constraints for names  
 within table sets guarantee that when the following XPath queries are  
 applied to a \xmlel{tableset} element, zero or one node  
 only will be returned:  
   
 \begin{itemize}  
 \item\verb|schema[@name="default"]|  
 \item\verb|schema/table[@name="default"]|  
 \end{itemize}  
 \end{admonition}  
   
1461  Name uniqueness is only required when the table set description is  Name uniqueness is only required when the table set description is
1462  part of a VOResource description.  The name uniqueness rules  part of a VOResource description.  The name uniqueness rules
1463  \emph{should} also be applied to other uses of the  \emph{should} also be applied to other uses of the
# Line 2649  Line 2641 
2641  interpretation of arraysize=1 as a scalar is withdrawn.  Use empty  interpretation of arraysize=1 as a scalar is withdrawn.  Use empty
2642  arraysize for scalars now.  arraysize for scalars now.
2643  \item Deprecated TAPType.  \item Deprecated TAPType.
2644    \item No longer requiring unique table names within a tableset;
2645    uniquness is now required within a schema (actually, many services have
2646    been in violation of the old unique-within-tableset rule for a long time
2647    without operational difficulties).
2648  \item Ported source to \ivoatex.  \item Ported source to \ivoatex.
2649  \end{itemize}  \end{itemize}
2650    

Legend:
Removed from v.5193  
changed lines
  Added in v.5194

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