VODataService < IVOA

IVOA Web>IvoaResReg>VODataService (2013-04-10, RayPlante) (raw view)

<small>Jumps:  [[http://www.ivoa.net/forum/registry/][reg-dm mail archive]] :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10 
<br/> Meetings: InterOpNov2009Reg :: InterOpMay2009ResReg :: InterOpOct2008ResReg :: InterOpMay2008ResReg :: InterOpSep2007ResReg</small>

---+!! !VODataService

!VODataService is a XML Schema that extends the core !VOResource schema to describe data collections and services that provide access to data.  It forms the basis for extension schemas that describe support for standard IVOA protocols.  Work on this standard is complete as of version 1.1.

   $ Recommendation Document: [[http://www.ivoa.net/Documents/VODataService/][VODataService: a VOResource Schema Extension for Describing Collections and Services]] (2010 December 02)

   $ Recommended Schema: [[http://www.ivoa.net/xml/VODataService/VODataService-v1.1.xsd][VODataService-v1.1.xsd]] 

   $ Previous version (still in use in the IVOA):  [[http://www.ivoa.net/xml/VODataService/VODataService-v1.0.xsd][VODataService-v1.0.xsd]]

*Note:*  the documents, schemas, and samples are now available in an Subversion (SVN) repository at the [[http://volute.googlecode.com/][Volute site]] under *trunk/projects/registry/VODataService*.

---++++!! Table of Contents
%TOC%

---++ Features

!VODataService defines the follow extensions of the generic Resource type:
   * =DataCollection=:  describes a collection of data which can include a mix of images, catalogs, spectra and any other type of data.   A collection description may include a description of coverage on the sky and in time and frequency, and it may include a description of the component tabular data.
   * =DataService=:  This is an extension of the Service Resource type that represents a service that provides access to data.  One can describe the data's coverage on the sky and in time and frequency and its association with facilities and instruments.  
   * =CatalogService=:  This is an extension of the =DataService= type to describe a service that provides access to data, and specifically interacts with or returns information in a tabular form.  In addition to the =DataService= metadata, one may also describe the strucuture of the tables.  
   * =STCStandard=:  This resource extension is used to define standard coordinate systems using STC.

It also defines an extension of the generic Interface type:
   * =ParamHTTP=:  this describes a service interface in the form an HTTP Get URL and comprised of a base URL and a set of arguments made up of key=value parameters.  In this extension, it is possible to describe the input parameters supported by the service.

---++ Some samples 

---+++ Version 1.1 (proposed)

   * [[%ATTACHURL%/collection.xml][collection.xml]]
   * [[%ATTACHURL%/catalog.xml][catalog.xml]]
   * [[%ATTACHURL%/catalogservice.xml][catalogservice.xml]]
   * [[%ATTACHURL%/stc.xml][stc.xml]]
   * [[%ATTACHURL%/foreignkey.xml][foreignkey.xml]]

---+++ Version 1.0 (currently in use by IVOA registries)

   * [[%PUBURL%/%WEB%/RegUpgradeToV10/collection.xml][collection.xml]]
   * [[%PUBURL%/%WEB%/RegUpgradeToV10/catalog.xml][catalog.xml]]
   * [[%PUBURL%/%WEB%/RegUpgradeToV10/stc.xml][stc.xml]]

---++ Latest Changes in v1.1

This changes came from discussion at Nov 2009 interop:

<ul>
   <li> add <code>&lt;testQuery&gt;</code> to <code>vs:ParamHTTP</code> </li>
</ul>

These changes came from discussion at May 2009 interop and were incorporated into the current PR version:

<ul>
  <li> corrected errors in example in <a href="#intro">Introduction</a> </li>
  <li> added <code>&lt;description&gt;</code> and
       <code>&lt;utype&gt;</code> elements to the
       <code>vs:ForeignKey</code> type for consistency with TAP. </li>
  <li> changed type names <code>vs:TAP</code> to
       <code>vs:TAPType</code> and <code>vs:VOTable</code>
       <code>vs:VOTableType</code>. </li>
</ul>


---++ Previously Discussion of Proposed Changes

---+++ Accepted at May 2009 !InterOp

Following the discussion after InterOpOct2008ResReg in collaboration with the TAP team, the following changes were made:

   * The ==&lt;dataType&gt;== element for column descriptions now requires an ==xsi:type== attribute to indicate which set of standard names the data type name drawn from.  There are two sets defined: ==vs:TAP== (containing the TAP data types) and ==vs:VOTable== (containing the VOTable types suppported before).

   * Foreign keys can optionally be described via ==&lt;foreignKey&gt;== elements within a ==&lt;table&gt;==.  The ==vs:ForeignKey== type allows one to pair up columns from the current table with columns in another table.

---+++ Proposed Changes

   $ Editor's Note: All of the proposed changes below were accepted

These changes follows on discussion of changes from InterOpSep2007ResReg and InterOpMay2008ResReg and is recorded in part below under [[#Previous_Discussion_of_Proposed_Changes]["Previous Discussion of Proposed Changes" below]].  This proposed version attempts to incorporate feedback on the last proposal.  Here is a summary of the changes:

<ol>
   <li>  The RM !RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a =&lt;regionOfRegard&gt;= child element of =&lt;coverage&gt;=.  This make searching on this data much simpler.  

   <li>  The descriptions of tables is done via a single =tableset= element which contains a list of =schema= elements.  
  %BR% %BR% The =schema= element aggregates a set of logically related tables with no implied relationship to database catalogs or schemas.  It responds to several issues regarding the hierarchical organization of the table descriptions:
      *  This model reflects the TAP data model
      *  "catalog" is an overloaded term, with different connotations in astronomy and database technology.
      *  To make searching more straight forward, it is considered important that all =table= elements are addressable via a single simple XPath location (e.g. tableset/schema/table).
      *  The introduction of =schema= does not address the issue of backward compatibility with VODataService v1.0 in which the =CatalogService= resource type lists tables at _two levels higher_--i.e. there are no =tableset= and =schema= levels.  This proposal takes the position that the table set organization is more important than this backward compatibility.  Consequently, it would be helpful to users to migrate uses of v1.0 to v1.1 as broadly and quickly as possible. 

   <li> =schema/name= and =schema/table/name= elements are required and must be unique.  %BR% %BR% NVO portal applications discovered that it is important to have unique ways of identifying tables.

   <li> =schema/table/name= should include database catalog and/or schema qualifiers as applicable.    %BR% %BR%  This allows the name to be plugged directly into an ADQL query without further construction from separately tagged schema and catalog names.  A dot-delimiting syntax for the name would allow for parsing out the catalog and schema if is desired, though in most cases, this will not be necessary.

   <li> the =TableService= is dropped.    %BR% %BR%  This proposal posits that this is unnecessarily redundant with =CatalogService=.  There are currently no =TableService= resources registered, suggesting there is little need to distinguish between a service with coverage one without (noting that =coverage= is optional).  

   <li> the =function= and =join= elements are *dropped* from the last proposal    %BR% %BR% 
      * There was the prudent suggestion (by DougTody and supported by others) that these need further prototyping before we lock them into a schema that would be difficult to revise later.  (!McGlynn noted a similar join feature in HEASARC services that proved not to be useful in practice.)  Instead extension mechanisms will provide a way to add these in the future. 

   <li> Table description extension mechanisms: =xsi:type= and extended types.  %BR% %BR%  Richer descriptions of tables will be enabled in two ways:
      * an =xsi:type= attribute can added to =&lt;tableset&gt;=, =&lt;schema&gt;=, and/or =&lt;table&gt;= to allow additional elements to be added.  (Note you can pretty much do this anywhere in a VOResource document.)
      * the =&lt;dataType&gt;= elements feature optional attributes, =extendedType= and =extendedSchema= to indicate a column or parameter has an extended type.  When present, the element value is the type to assume if the extended type is not recognized or supported.  

   <li> the =&lt;table&gt;= element's attribute =role= has been changed to =type=; added documentation for the recognized values for "base_table" and "view".

   <li> optional =utype= elements are added to =&lt;schema&gt;=, =&lt;table&gt;=, and =&lt;column&gt;= elements.

   <li> an optional =flag= child element has been added to the =column= element. Able to appear multiple times per column, they are used to mark traits such as "indexed" or "nullable".
</ol>


---+++ Proposed Changes

These changes were proposed in Cambridge and were motivated by recent development work on the Simple Spectral Access (SSA) Protocol.  The presentation here reflects the feedback provided during the Registry Working Group Session in Cambridge.

   1.  Add an optional =&lt;testArgs&gt;= to the =ParamHTTP= Interface type
      * Definition: a formatted set of arguments that, when applied to the access URL, can be used to test the service.
      * this mechanism is useful regardless of whether the service complies with a standard or not.  
      * the format is a string such that when concatonated after the access URL, it produces a legal URL.  
      * the arguments should be chosen such that the resulting query returns a legal, non-empty result.  
   1.  Add an optional =&lt;rights&gt;= element to the =DataService= Resource type.  *DROPPED*
      * *This proposal has been dropped.*  When proposed, this was thought to be missing from =DataService=; however, it is included in the definition of the more general =Service= Resource type.
   1.  Add an optional =&lt;dataset&gt;= element to the =DataService=  and =DataCollection= Resource types.  *DROPPED*
      * provides a listing of Dataset identifiers that are available for use as input to the service
      * *This proposal is being dropped* as it does not address the original intended use of dataset IDs within SSA.

This change was motivated by recent work on TAP and VOSI.

   1 Add extra elements to describe use of tables and databases.
      * Extra types are !RelationalSchema, Function, !RelationalJoin.
      * Two possible schema: one with mandatory nesting table in schema in catalog; one with the structure partially flattened.
      * [[%ATTACHURL%/VODataService-v1.1-tables-proposal-1.xsd][XML schema with deeper nesting]]
      * [[%ATTACHURL%/VODataService-v1.1-tables-proposal-2.xsd][XML schema partially flattened]]
      * The flatter schema allows all resources that validated against VODataService 1.0 to validate against VODataService 1.1.









<br/>
<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->

Attachments

Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
html	PR-VODataService-1.1-20090903.html	r1	manage	198.2 K	2009-09-03 - 19:55	RayPlante	supports v1.1pr1
html	PR-VODataService-1.1-20100412.html	r1	manage	203.6 K	2010-04-14 - 15:45	RayPlante	post RFC revision submitted to doc repository
xsd	VODataService-v1.1pr1.xsd	r1	manage	50.0 K	2009-09-03 - 19:54	RayPlante	PR version
xsd	VODataService-v1.1pr2.xsd	r1	manage	50.9 K	2010-04-14 - 15:37	RayPlante	Post RFC revision
html	VODataService-v1.1pr3.html	r3 r2 r1	manage	204.1 K	2010-05-14 - 14:04	RayPlante	First Post-TCG revision
html	VODataService-v1.1pr4.html	r1	manage	205.4 K	2010-07-07 - 19:49	RayPlante	2nd post-TCG revsion (includes arch summary)
html	VODataService-v1.1wd.html	r17 r16 r15 r14 r13	manage	193.9 K	2009-05-08 - 15:54	RayPlante	for v1.1wd8 (updated version, author list)
xsd	VODataService-v1.1wd.xsd	r1	manage	40.9 K	2008-10-24 - 14:42	RayPlante	for v1.1wd3
xsd	VODataService-v1.1wd2.xsd	r1	manage	43.0 K	2008-10-23 - 15:44	RayPlante	v1.1wd2
xsd	VODataService-v1.1wd3.xsd	r1	manage	40.7 K	2008-10-24 - 14:47	RayPlante	for v1.1wd3
xsd	VODataService-v1.1wd4.xsd	r1	manage	44.4 K	2008-10-24 - 22:37	RayPlante	for v1.1wd4
xsd	VODataService-v1.1wd5.xsd	r1	manage	44.0 K	2008-10-28 - 09:27	RayPlante
xsd	VODataService-v1.1wd6.xsd	r1	manage	44.9 K	2008-11-11 - 21:38	RayPlante
xsd	VODataService-v1.1wd7.xsd	r1	manage	45.5 K	2008-11-14 - 20:59	RayPlante
xsd	VODataService-v1.1wd8.xsd	r1	manage	50.4 K	2009-05-07 - 15:44	RayPlante
xml	catalog.xml	r2 r1	manage	7.8 K	2009-09-03 - 20:06	RayPlante	for v1.1pr1
xml	catalogservice.xml	r5 r4 r3 r2 r1	manage	3.9 K	2009-09-03 - 20:06	RayPlante	for v1.1pr1
xml	collection.xml	r1	manage	4.5 K	2009-09-03 - 20:05	RayPlante	for v1.1pr1
xml	foreignkey.xml	r1	manage	3.7 K	2009-09-03 - 20:07	RayPlante	for v1.1pr1
xml	stc.xml	r2 r1	manage	2.1 K	2009-09-03 - 20:07	RayPlante	for v1.1pr1

Topic revision: r40 - 2013-04-10 - RayPlante

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema