Difference: VODataService (1 vs. 40)

Revision 402013-04-10 - RayPlante

 
META TOPICPARENT name="IvoaResReg"
Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
Meetings: InterOpNov2009Reg :: InterOpMay2009ResReg :: InterOpOct2008ResReg :: InterOpMay2008ResReg :: InterOpSep2007ResReg

VODataService

Changed:
<
<
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. The Request For Comment period is finished; it is now under TCG review.
>
>
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.
 
Changed:
<
<
Proposed Recommendation Document (Post-TCG review draft)
VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 July 07; includes reference to IVOA architecture)
>
>
Recommendation Document
VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 December 02)
 
Changed:
<
<
Proposed Recommendation Document (TCG review version)
VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 April 12)
>
>
Recommended Schema
VODataService-v1.1.xsd
 
Changed:
<
<
Proposed Recommended Schema (TCG review version)
VODataService-v1.1.xsd (1.1pr2)
>
>
Previous version (still in use in the IVOA)
VODataService-v1.0.xsd
 
Deleted:
<
<
Schema Currently in use in the IVOA
VODataService-v1.0.xsd
 Note: the documents, schemas, and samples are now available in an Subversion (SVN) repository at the Volute site under trunk/projects/registry/VODataService.

Table of Contents

Features

VODataService defines the follow extensions of the generic Resource type:

Changed:
<
<
  • 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.
>
>
  • 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:
Changed:
<
<
  • 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.
>
>
  • 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)

Changed:
<
<
>
>
 

Version 1.0 (currently in use by IVOA registries)

Changed:
<
<
>
>
 

Latest Changes in v1.1

This changes came from discussion at Nov 2009 interop:

    Changed:
    <
    <
  • add <testQuery> to vs:ParamHTTP
  • >
    >
  • add <testQuery> to vs:ParamHTTP
  •  

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

    • corrected errors in example in Introduction
    • added <description> and
    Changed:
    <
    <
    <utype> elements to the vs:ForeignKey type for consistency with TAP.
    >
    >
    <utype> elements to the vs:ForeignKey type for consistency with TAP.
     
  • changed type names vs:TAP to
  • Changed:
    <
    <
    vs:TAPType and vs:VOTable vs:VOTableType.
    >
    >
    vs:TAPType and vs:VOTable vs:VOTableType.
     

    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:

    Changed:
    <
    <
    • The <dataType> 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).
    >
    >
    • The <dataType> 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).
     
    Changed:
    <
    <
    • Foreign keys can optionally be described via <foreignKey> elements within a <table>. The vs:ForeignKey type allows one to pair up columns from the current table with columns in another table.
    >
    >
    • Foreign keys can optionally be described via <foreignKey> elements within a <table>. The vs:ForeignKey type allows one to pair up columns from the current table with columns in another table.
     

    Proposed Changes

    Changed:
    <
    <
    Editor's Note
    All of the proposed changes below were accepted
    >
    >
    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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      Changed:
      <
      <
    1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.
    2. >
      >
    3. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.
    4.  
      Changed:
      <
      <
    5. The descriptions of tables is done via a single tableset element which contains a list of schema elements.
    6. >
      >
    7. The descriptions of tables is done via a single tableset element which contains a list of schema elements.
    8.  

      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:
      Changed:
      <
      <
        • 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.
      >
      >
        • 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.
       
      Changed:
      <
      <
    9. schema/name and schema/table/name elements are required and must be unique.

      NVO portal applications discovered that it is important to have unique ways of identifying tables.
    10. >
      >
    11. schema/name and schema/table/name elements are required and must be unique.

      NVO portal applications discovered that it is important to have unique ways of identifying tables.
    12.  
      Changed:
      <
      <
    13. schema/table/name should include database catalog and/or schema qualifiers as applicable.

      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.
    14. >
      >
    15. schema/table/name should include database catalog and/or schema qualifiers as applicable.

      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.
    16.  
      Changed:
      <
      <
    17. the TableService is dropped.

      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).
    18. >
      >
    19. the TableService is dropped.

      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).
    20.  
      Changed:
      <
      <
    21. the function and join elements are dropped from the last proposal

        • 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.
    22. >
      >
    23. the function and join elements are dropped from the last proposal

        • 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.
    24.  
      Changed:
      <
      <
    25. Table description extension mechanisms: xsi:type and extended types.

      Richer descriptions of tables will be enabled in two ways:
        • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
        • the <dataType> 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.
    26. >
      >
    27. Table description extension mechanisms: xsi:type and extended types.

      Richer descriptions of tables will be enabled in two ways:
        • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
        • the <dataType> 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.
    28.  
      Changed:
      <
      <
    29. the <table> element's attribute role has been changed to type; added documentation for the recognized values for "base_table" and "view".
    30. >
      >
    31. the <table> element's attribute role has been changed to type; added documentation for the recognized values for "base_table" and "view".
    32.  
      Changed:
      <
      <
    33. optional utype elements are added to <schema>, <table>, and <column> elements.
    34. >
      >
    35. optional utype elements are added to <schema>, <table>, and <column> elements.
    36.  
      Changed:
      <
      <
    37. 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".
    38. >
      >
    39. 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".
    40.  

      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.

      Changed:
      <
      <
      1. Add an optional <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.
      >
      >
      1. Add an optional <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.
      Changed:
      <
      <
      1. Add extra elements to describe use of tables and databases.
      >
      >
      1. Add extra elements to describe use of tables and databases.
       


      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="Post RFC revision" date="1271259459" name="VODataService-v1.1pr2.xsd" path="VODataService-v1.1pr2.xsd" size="52134" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="post RFC revision submitted to doc repository" date="1271259916" name="PR-VODataService-1.1-20100412.html" path="PR-VODataService-1.1-20100412.html" size="208495" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="First Post-TCG revision" date="1273845894" name="VODataService-v1.1pr3.html" path="VODataService-v1.1pr3.html" size="209036" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="2nd post-TCG revsion (includes arch summary)" date="1278532149" name="VODataService-v1.1pr4.html" path="VODataService-v1.1pr4.html" size="210377" user="RayPlante" version="1.1"

      Revision 392012-06-26 - root

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
      Meetings: InterOpNov2009Reg :: InterOpMay2009ResReg :: InterOpOct2008ResReg :: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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. The Request For Comment period is finished; it is now under TCG review.

      Proposed Recommendation Document (Post-TCG review draft)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 July 07; includes reference to IVOA architecture)

      Proposed Recommendation Document (TCG review version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 April 12)

      Proposed Recommended Schema (TCG review version)
      VODataService-v1.1.xsd (1.1pr2)

      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd

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

      Table of Contents

      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)

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

      This changes came from discussion at Nov 2009 interop:

      • add <testQuery> to vs:ParamHTTP

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

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. 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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="Post RFC revision" date="1271259459" name="VODataService-v1.1pr2.xsd" path="VODataService-v1.1pr2.xsd" size="52134" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="post RFC revision submitted to doc repository" date="1271259916" name="PR-VODataService-1.1-20100412.html" path="PR-VODataService-1.1-20100412.html" size="208495" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="First Post-TCG revision" date="1273845894" name="VODataService-v1.1pr3.html" path="VODataService-v1.1pr3.html" size="209036" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="2nd post-TCG revsion (includes arch summary)" date="1278532149" name="VODataService-v1.1pr4.html" path="VODataService-v1.1pr4.html" size="210377" user="RayPlante" version="1.1"

      Revision 382010-07-07 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
      Meetings: InterOpNov2009Reg :: InterOpMay2009ResReg :: InterOpOct2008ResReg :: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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. The Request For Comment period is finished; it is now under TCG review.

      Proposed Recommendation Document (Post-TCG review draft)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 July 07; includes reference to IVOA architecture)

      Proposed Recommendation Document (TCG review version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 April 12)

      Proposed Recommended Schema (TCG review version)
      VODataService-v1.1.xsd (1.1pr2)

      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd

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

      Table of Contents

      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)

      Added:
      >
      >
       

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

      This changes came from discussion at Nov 2009 interop:

      • add <testQuery> to vs:ParamHTTP

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

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. 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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="Post RFC revision" date="1271259459" name="VODataService-v1.1pr2.xsd" path="VODataService-v1.1pr2.xsd" size="52134" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="post RFC revision submitted to doc repository" date="1271259916" name="PR-VODataService-1.1-20100412.html" path="PR-VODataService-1.1-20100412.html" size="208495" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="First Post-TCG revision" date="1273845894" name="VODataService-v1.1pr3.html" path="VODataService-v1.1pr3.html" size="209036" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="2nd post-TCG revsion (includes arch summary)" date="1278532149" name="VODataService-v1.1pr4.html" path="VODataService-v1.1pr4.html" size="210377" user="RayPlante" version="1.1"

      Revision 372010-07-07 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
      Meetings: InterOpNov2009Reg :: InterOpMay2009ResReg :: InterOpOct2008ResReg :: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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. The Request For Comment period is finished; it is now under TCG review.

      Changed:
      <
      <
      Proposed Recommendation Document (Post-TCG review draft)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 May XX)
      >
      >
      Proposed Recommendation Document (Post-TCG review draft)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 July 07; includes reference to IVOA architecture)
       
      Proposed Recommendation Document (TCG review version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 April 12)

      Proposed Recommended Schema (TCG review version)
      VODataService-v1.1.xsd (1.1pr2)

      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd

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

      Table of Contents

      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)

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

      This changes came from discussion at Nov 2009 interop:

      • add <testQuery> to vs:ParamHTTP

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

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. 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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="Post RFC revision" date="1271259459" name="VODataService-v1.1pr2.xsd" path="VODataService-v1.1pr2.xsd" size="52134" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="post RFC revision submitted to doc repository" date="1271259916" name="PR-VODataService-1.1-20100412.html" path="PR-VODataService-1.1-20100412.html" size="208495" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="First Post-TCG revision" date="1273845894" name="VODataService-v1.1pr3.html" path="VODataService-v1.1pr3.html" size="209036" user="RayPlante" version="1.3"
      Added:
      >
      >
      META FILEATTACHMENT attr="" comment="2nd post-TCG revsion (includes arch summary)" date="1278532149" name="VODataService-v1.1pr4.html" path="VODataService-v1.1pr4.html" size="210377" user="RayPlante" version="1.1"
       

      Revision 362010-05-14 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
      Meetings: InterOpNov2009Reg :: InterOpMay2009ResReg :: InterOpOct2008ResReg :: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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. The Request For Comment period is finished; it is now under TCG review.

      Proposed Recommendation Document (Post-TCG review draft)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 May XX)

      Proposed Recommendation Document (TCG review version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 April 12)

      Proposed Recommended Schema (TCG review version)
      VODataService-v1.1.xsd (1.1pr2)

      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd

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

      Table of Contents

      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)

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

      This changes came from discussion at Nov 2009 interop:

      • add <testQuery> to vs:ParamHTTP

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

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. 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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="Post RFC revision" date="1271259459" name="VODataService-v1.1pr2.xsd" path="VODataService-v1.1pr2.xsd" size="52134" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="post RFC revision submitted to doc repository" date="1271259916" name="PR-VODataService-1.1-20100412.html" path="PR-VODataService-1.1-20100412.html" size="208495" user="RayPlante" version="1.1"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="First Post-TCG revision" date="1273837117" name="VODataService-v1.1pr3.html" path="VODataService-v1.1pr3.html" size="209042" user="RayPlante" version="1.2"
      >
      >
      META FILEATTACHMENT attr="" comment="First Post-TCG revision" date="1273845894" name="VODataService-v1.1pr3.html" path="VODataService-v1.1pr3.html" size="209036" user="RayPlante" version="1.3"
       

      Revision 352010-05-14 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
      Meetings: InterOpNov2009Reg :: InterOpMay2009ResReg :: InterOpOct2008ResReg :: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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. The Request For Comment period is finished; it is now under TCG review.

      Proposed Recommendation Document (Post-TCG review draft)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 May XX)

      Proposed Recommendation Document (TCG review version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 April 12)

      Proposed Recommended Schema (TCG review version)
      VODataService-v1.1.xsd (1.1pr2)

      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd

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

      Table of Contents

      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)

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

      This changes came from discussion at Nov 2009 interop:

      • add <testQuery> to vs:ParamHTTP

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

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. 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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="Post RFC revision" date="1271259459" name="VODataService-v1.1pr2.xsd" path="VODataService-v1.1pr2.xsd" size="52134" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="post RFC revision submitted to doc repository" date="1271259916" name="PR-VODataService-1.1-20100412.html" path="PR-VODataService-1.1-20100412.html" size="208495" user="RayPlante" version="1.1"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="First Post-TCG revision" date="1273835109" name="VODataService-v1.1pr3.html" path="VODataService-v1.1pr3.html" size="209041" user="RayPlante" version="1.1"
      >
      >
      META FILEATTACHMENT attr="" comment="First Post-TCG revision" date="1273837117" name="VODataService-v1.1pr3.html" path="VODataService-v1.1pr3.html" size="209042" user="RayPlante" version="1.2"
       

      Revision 342010-05-14 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
      Changed:
      <
      <

      Meetings: InterOpNov2009Reg :: InterOpMay2008ResReg :: InterOpSep2007ResReg
      >
      >

      Meetings: InterOpNov2009Reg :: InterOpMay2009ResReg :: InterOpOct2008ResReg :: InterOpMay2008ResReg :: InterOpSep2007ResReg
       

      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. The Request For Comment period is finished; it is now under TCG review.

      Added:
      >
      >
      Proposed Recommendation Document (Post-TCG review draft)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 May XX)
       
      Proposed Recommendation Document (TCG review version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 April 12)

      Proposed Recommended Schema (TCG review version)
      VODataService-v1.1.xsd (1.1pr2)

      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd

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

      Table of Contents

      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)

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

      This changes came from discussion at Nov 2009 interop:

      • add <testQuery> to vs:ParamHTTP

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

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. 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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="Post RFC revision" date="1271259459" name="VODataService-v1.1pr2.xsd" path="VODataService-v1.1pr2.xsd" size="52134" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="post RFC revision submitted to doc repository" date="1271259916" name="PR-VODataService-1.1-20100412.html" path="PR-VODataService-1.1-20100412.html" size="208495" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="First Post-TCG revision" date="1273835109" name="VODataService-v1.1pr3.html" path="VODataService-v1.1pr3.html" size="209041" user="RayPlante" version="1.1"

      Revision 332010-05-14 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
      Meetings: InterOpNov2009Reg :: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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. The Request For Comment period is finished; it is now under TCG review.

      Proposed Recommendation Document (TCG review version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 April 12)

      Proposed Recommended Schema (TCG review version)
      VODataService-v1.1.xsd (1.1pr2)

      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd

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

      Table of Contents

      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)

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

      This changes came from discussion at Nov 2009 interop:

      • add <testQuery> to vs:ParamHTTP

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

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. 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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="Post RFC revision" date="1271259459" name="VODataService-v1.1pr2.xsd" path="VODataService-v1.1pr2.xsd" size="52134" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="post RFC revision submitted to doc repository" date="1271259916" name="PR-VODataService-1.1-20100412.html" path="PR-VODataService-1.1-20100412.html" size="208495" user="RayPlante" version="1.1"
      Added:
      >
      >
      META FILEATTACHMENT attr="" comment="First Post-TCG revision" date="1273835109" name="VODataService-v1.1pr3.html" path="VODataService-v1.1pr3.html" size="209041" user="RayPlante" version="1.1"
       

      Revision 322010-04-15 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
      Changed:
      <
      <

      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg
      >
      >

      Meetings: InterOpNov2009Reg :: InterOpMay2008ResReg :: InterOpSep2007ResReg
       

      VODataService

      Changed:
      <
      <
      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.
      >
      >
      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. The Request For Comment period is finished; it is now under TCG review.
       
      Changed:
      <
      <
      Proposed Recommendation Document (TCG review version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 April 12)
      >
      >
      Proposed Recommendation Document (TCG review version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 April 12)
       
      Changed:
      <
      <
      Proposed Recommendation Document (RFC version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2009 Sept. 3)
      >
      >
      Proposed Recommended Schema (TCG review version)
      VODataService-v1.1.xsd (1.1pr2)
      Deleted:
      <
      <
      Proposed Recommended Schema (TCG review version)
      VODataService-v1.1.xsd (1.1pr2)

      Proposed Recommended Schema (RFC version)
      VODataService-v1.1.xsd (1.1pr1)
       
      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd

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

      Table of Contents

      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)

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

      This changes came from discussion at Nov 2009 interop:

      • add <testQuery> to vs:ParamHTTP

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

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. 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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="Post RFC revision" date="1271259459" name="VODataService-v1.1pr2.xsd" path="VODataService-v1.1pr2.xsd" size="52134" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="post RFC revision submitted to doc repository" date="1271259916" name="PR-VODataService-1.1-20100412.html" path="PR-VODataService-1.1-20100412.html" size="208495" user="RayPlante" version="1.1"

      Revision 312010-04-14 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Changed:
      <
      <
      Proposed Recommendation Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      >
      >
      Proposed Recommendation Document (TCG review version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2010 April 12)
       
      Changed:
      <
      <
      Proposed Recommended Schema
      VODataService-v1.1.xsd
      >
      >
      Proposed Recommendation Document (RFC version)
      VODataService: a VOResource Schema Extension for Describing Collections and Services (2009 Sept. 3)
       
      Added:
      >
      >
      Proposed Recommended Schema (TCG review version)
      VODataService-v1.1.xsd (1.1pr2)

      Proposed Recommended Schema (RFC version)
      VODataService-v1.1.xsd (1.1pr1)
       
      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd

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

      Table of Contents

      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)

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

      Added:
      >
      >
      This changes came from discussion at Nov 2009 interop:

      • add <testQuery> to vs:ParamHTTP
        These changes came from discussion at May 2009 interop and were incorporated into the current PR version:

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. 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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="Post RFC revision" date="1271259459" name="VODataService-v1.1pr2.xsd" path="VODataService-v1.1pr2.xsd" size="52134" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="post RFC revision submitted to doc repository" date="1271259916" name="PR-VODataService-1.1-20100412.html" path="PR-VODataService-1.1-20100412.html" size="208495" user="RayPlante" version="1.1"

      Revision 302010-04-14 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Proposed Recommendation Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services

      Proposed Recommended Schema
      VODataService-v1.1.xsd

      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd

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

      Table of Contents

      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)

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

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

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. 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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
      Added:
      >
      >
      META FILEATTACHMENT attr="" comment="Post RFC revision" date="1271259459" name="VODataService-v1.1pr2.xsd" path="VODataService-v1.1pr2.xsd" size="52134" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="post RFC revision submitted to doc repository" date="1271259916" name="PR-VODataService-1.1-20100412.html" path="PR-VODataService-1.1-20100412.html" size="208495" user="RayPlante" version="1.1"
       

      Revision 292009-09-23 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Changed:
      <
      <
      Internal Proposed Recommendation Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      >
      >
      Proposed Recommendation Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
       
      Changed:
      <
      <
      Internal Working Draft Schema
      VODataService-v1.1pr1.xsd
      >
      >
      Proposed Recommended Schema
      VODataService-v1.1.xsd
      Deleted:
      <
      <
      Working Draft Schema
      VODataService-v1.1.xsd
       
      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd

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

      Table of Contents

      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)

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

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

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. 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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"

      Revision 282009-09-03 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Changed:
      <
      <
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      >
      >
      Jumps: reg-dm mail archive :: IvoaResReg :: ResourceMetadata :: RegistryInterface :: VOResourceV10
       
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Changed:
      <
      <
      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress
      >
      >
      Internal Proposed Recommendation Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
       
      Changed:
      <
      <
      Internal Working Draft Schema
      VODataService-v1.1wd8.xsd
      >
      >
      Internal Working Draft Schema
      VODataService-v1.1pr1.xsd
       
      Added:
      >
      >
      Working Draft Schema
      VODataService-v1.1.xsd
       
      Changed:
      <
      <
      Working Draft Schema
      VODataService-v1.0.xsd
      >
      >
      Schema Currently in use in the IVOA
      VODataService-v1.0.xsd
       
      Changed:
      <
      <
      >
      >
      Note: the documents, schemas, and samples are now available in an Subversion (SVN) repository at the Volute site under trunk/projects/registry/VODataService.
       
      Added:
      >
      >

      Table of Contents

       

      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)

      Version 1.0 (currently in use by IVOA registries)

      Latest Changes in v1.1

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

      • corrected errors in example in Introduction
      • added <description> and <utype> elements to the vs:ForeignKey type for consistency with TAP.
      • changed type names vs:TAP to vs:TAPType and vs:VOTable vs:VOTableType.

      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 <dataType> 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 <foreignKey> elements within a <table>. The vs:ForeignKey type allows one to pair up columns from the current table with columns in another table.
      Changed:
      <
      <

      Previous Discussion of Proposed Changes

      >
      >

      Proposed Changes

       
      Deleted:
      <
      <

      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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".
      Changed:
      <
      <

      Proposed Changes

      >
      >

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008335" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
       
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd8" date="1241800309" name="catalogservice.xml" path="catalogservice.xml" size="3966" user="RayPlante" version="1.4"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008365" name="catalogservice.xml" path="catalogservice.xml" size="3978" user="RayPlante" version="1.5"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008397" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008441" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
       
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
      Added:
      >
      >
      META FILEATTACHMENT attr="" comment="PR version" date="1252007690" name="VODataService-v1.1pr1.xsd" path="VODataService-v1.1pr1.xsd" size="51205" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="supports v1.1pr1" date="1252007734" name="PR-VODataService-1.1-20090903.html" path="PR-VODataService-1.1-20090903.html" size="202941" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1pr1" date="1252008476" name="foreignkey.xml" path="foreignkey.xml" size="3772" user="RayPlante" version="1.1"
       

      Revision 272009-05-08 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd8.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Added:
      >
      >

      Latest Changes in v1.1

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

      • The <dataType> 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 <foreignKey> elements within a <table>. The vs:ForeignKey type allows one to pair up columns from the current table with columns in another table.

      Previous Discussion of Proposed Changes

       

      Proposed Changes

      Added:
      >
      >
      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" below. This proposed version attempts to incorporate feedback on the last proposal. Here is a summary of the changes:

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".
      Deleted:
      <
      <

      Previous Discussion of Proposed Changes

       

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd8" date="1241800309" name="catalogservice.xml" path="catalogservice.xml" size="3966" user="RayPlante" version="1.4"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"

      Revision 262009-05-08 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd8.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated date)" date="1241713880" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198337" user="RayPlante" version="1.16"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated version, author list)" date="1241798041" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198535" user="RayPlante" version="1.17"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"

      Revision 252009-05-07 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd8.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated date)" date="1241712075" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198337" user="RayPlante" version="1.15"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated date)" date="1241713880" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198337" user="RayPlante" version="1.16"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"

      Revision 242009-05-07 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress
      Changed:
      <
      <
      Internal Working Draft Schema
      VODataService-v1.1wd7.xsd
      >
      >
      Internal Working Draft Schema
      VODataService-v1.1wd8.xsd
       

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd8" date="1241711240" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198342" user="RayPlante" version="1.14"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd8 (updated date)" date="1241712075" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198337" user="RayPlante" version="1.15"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"

      Revision 232009-05-07 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd7.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226704406" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="170813" user="RayPlante" version="1.13"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd8" date="1241711240" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="198342" user="RayPlante" version="1.14"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
      Added:
      >
      >
      META FILEATTACHMENT attr="" comment="" date="1241711080" name="VODataService-v1.1wd8.xsd" path="VODataService-v1.1wd8.xsd" size="51609" user="RayPlante" version="1.1"
       

      Revision 222008-11-14 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd7.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226696035" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="116392" user="RayPlante" version="1.11"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226704406" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="170813" user="RayPlante" version="1.13"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"

      Revision 212008-11-14 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress
      Changed:
      <
      <
      Internal Working Draft Schema
      VODataService-v1.1wd5.xsd
      >
      >
      Internal Working Draft Schema
      VODataService-v1.1wd7.xsd
       

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226594111" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="108066" user="RayPlante" version="1.10"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226696035" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="116392" user="RayPlante" version="1.11"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      Added:
      >
      >
      META FILEATTACHMENT attr="" comment="" date="1226696347" name="VODataService-v1.1wd7.xsd" path="VODataService-v1.1wd7.xsd" size="46592" user="RayPlante" version="1.1"
       

      Revision 202008-11-13 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd5.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226585971" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="100692" user="RayPlante" version="1.9"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226594111" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="108066" user="RayPlante" version="1.10"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"

      Revision 192008-11-13 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd5.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226425481" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="86178" user="RayPlante" version="1.8"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226585971" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="100692" user="RayPlante" version="1.9"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"

      Revision 182008-11-11 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd5.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226425481" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="86178" user="RayPlante" version="1.8"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="" date="1226425517" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
      >
      >
      META FILEATTACHMENT attr="" comment="" date="1226439511" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
       

      Revision 172008-11-11 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd5.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226425481" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="86178" user="RayPlante" version="1.8"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1225186462" name="stc.xml" path="stc.xml" size="2126" user="RayPlante" version="1.1"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226437869" name="stc.xml" path="stc.xml" size="2152" user="RayPlante" version="1.2"
       
      META FILEATTACHMENT attr="" comment="" date="1226425517" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"

      Revision 162008-11-11 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd5.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
      Changed:
      <
      <
        • an xsi:type attribute can added to <tableset>, <schema>, and/or =<table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
      >
      >
        • an xsi:type attribute can added to <tableset>, <schema>, and/or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
       
        • the <dataType> 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.

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

    42. optional utype elements are added to <schema>, <table>, and <column> elements.

    43. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
    44. Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1226313676" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="64477" user="RayPlante" version="1.6"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd6" date="1226425481" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="86178" user="RayPlante" version="1.8"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1225186462" name="stc.xml" path="stc.xml" size="2126" user="RayPlante" version="1.1"
      Added:
      >
      >
      META FILEATTACHMENT attr="" comment="" date="1226425517" name="VODataService-v1.1wd6.xsd" path="VODataService-v1.1wd6.xsd" size="45936" user="RayPlante" version="1.1"
       

      Revision 152008-11-10 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd5.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or =<table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1226312292" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="61410" user="RayPlante" version="1.4"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1226313676" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="64477" user="RayPlante" version="1.6"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1225186462" name="stc.xml" path="stc.xml" size="2126" user="RayPlante" version="1.1"

      Revision 142008-11-10 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd5.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.

      2. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      3. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      4. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      5. the TableService is dropped.

        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).

      6. the function and join elements are dropped from the last proposal

          • 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.

      7. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or =<table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      9. optional utype elements are added to <schema>, <table>, and <column> elements.

      10. 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".

      Previous Discussion of Proposed Changes

      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 <testArgs> 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.
      2. Add an optional <rights> 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.
      3. Add an optional <dataset> 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.


      <--  
      -->

      META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      Changed:
      <
      <
      META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1225194810" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="51668" user="RayPlante" version="1.3"
      >
      >
      META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1226312292" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="61410" user="RayPlante" version="1.4"
       
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
      META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1225186462" name="stc.xml" path="stc.xml" size="2126" user="RayPlante" version="1.1"

      Revision 132008-10-28 - RayPlante

       
      META TOPICPARENT name="IvoaResReg"
      Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
      Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

      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.

      Internal Working Draft Document
      VODataService: a VOResource Schema Extension for Describing Collections and Services
      in progress

      Internal Working Draft Schema
      VODataService-v1.1wd5.xsd

      Working Draft Schema
      VODataService-v1.0.xsd

      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)

      Version 1.0 (currently in use by IVOA registries)

      Proposed Changes

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

        Added:
        >
        >
      1. The RM RegionOfRegard has been "pulled out" of the STC profile and can now be encoded explicitly via a <regionOfRegard> child element of <coverage>. This make searching on this data much simpler.
      2.  
      3. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

        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.

      4. schema/name and schema/table/name elements are required and must be unique.

        NVO portal applications discovered that it is important to have unique ways of identifying tables.

      5. schema/table/name should include database catalog and/or schema qualifiers as applicable.

        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.

      6. the TableService is dropped.

        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).

      7. the function and join elements are dropped from the last proposal

          • 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.

      8. Table description extension mechanisms: xsi:type and extended types.

        Richer descriptions of tables will be enabled in two ways:
          • an xsi:type attribute can added to <tableset>, <schema>, and/or =<table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          • the <dataType> 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.

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

      10. optional utype elements are added to <schema>, <table>, and <column> elements.

      11. 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".

        Previous Discussion of Proposed Changes

        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 <testArgs> 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.
        2. Add an optional <rights> 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.
        3. Add an optional <dataset> 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.


        <--  
        -->

        META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
        META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
        META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
        META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
        META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
        META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
      12. Changed:
        <
        <
        META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224859557" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="41938" user="RayPlante" version="1.2"
        >
        >
        META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1225194810" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="51668" user="RayPlante" version="1.3"
         
        META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
        META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
        META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
        META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
        META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1225186462" name="stc.xml" path="stc.xml" size="2126" user="RayPlante" version="1.1"

        Revision 122008-10-28 - RayPlante

         
        META TOPICPARENT name="IvoaResReg"
        Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
        Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

        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.

        Internal Working Draft Document
        VODataService: a VOResource Schema Extension for Describing Collections and Services
        in progress
        Changed:
        <
        <
        Internal Working Draft Schema
        VODataService-v1.1wd4.xsd
        >
        >
        Internal Working Draft Schema
        VODataService-v1.1wd5.xsd
         

        Working Draft Schema
        VODataService-v1.0.xsd

        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)

        Version 1.0 (currently in use by IVOA registries)

        Proposed Changes

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

        1. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

          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.

        2. schema/name and schema/table/name elements are required and must be unique.

          NVO portal applications discovered that it is important to have unique ways of identifying tables.

        3. schema/table/name should include database catalog and/or schema qualifiers as applicable.

          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.

        4. the TableService is dropped.

          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).

        5. the function and join elements are dropped from the last proposal

            • 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.

        6. Table description extension mechanisms: xsi:type and extended types.

          Richer descriptions of tables will be enabled in two ways:
            • an xsi:type attribute can added to <tableset>, <schema>, and/or =<table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
            • the <dataType> 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.

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

        8. optional utype elements are added to <schema>, <table>, and <column> elements.

        9. 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".

        Previous Discussion of Proposed Changes

        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 <testArgs> 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.
        2. Add an optional <rights> 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.
        3. Add an optional <dataset> 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.


        <--  
        -->

        META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
        META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
        META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
        META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
        META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
        META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
        META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224859557" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="41938" user="RayPlante" version="1.2"
        META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
        META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
        META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
        Added:
        >
        >
        META FILEATTACHMENT attr="" comment="" date="1225186060" name="VODataService-v1.1wd5.xsd" path="VODataService-v1.1wd5.xsd" size="45031" user="RayPlante" version="1.1"
        META FILEATTACHMENT attr="" comment="for v1.1wd5" date="1225186462" name="stc.xml" path="stc.xml" size="2126" user="RayPlante" version="1.1"
         

        Revision 112008-10-24 - RayPlante

         
        META TOPICPARENT name="IvoaResReg"
        Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
        Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

        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.

        Internal Working Draft Document
        VODataService: a VOResource Schema Extension for Describing Collections and Services
        in progress
        Changed:
        <
        <
        Internal Working Draft Schema
        VODataService-v1.1wd3.xsd
        >
        >
        Internal Working Draft Schema
        VODataService-v1.1wd4.xsd
         

        Working Draft Schema
        VODataService-v1.0.xsd

        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)

        Version 1.0 (currently in use by IVOA registries)

        Proposed Changes

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

          Changed:
          <
          <
        1. The descriptions of tables is done via the tableset element

          The tableset 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:
            • "catalog" is an overloaded term, with different connotations in astronomy and database technology; tableset replaces the catalog element in attempt to shed connotations from both domains. In contrast, the term "table set" has a direct connection to the jargon behind the development of TAP and is more directly appropos.
            • 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/table).
            • The introduction of tableset does not address the issue of backward compatibility with VODataService v1.0 in which the CatalogService resource type lists tables at one level higher--i.e. there is no tableset level. 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.
        2. >
          >
        3. The descriptions of tables is done via a single tableset element which contains a list of schema elements.

          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).
        4. Added:
          >
          >
            • 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.
           
          Changed:
          <
          <
        5. tableset/name and tableset/table/qualifiedName elements are required and must be unique.

          NVO portal applications discovered that it is important to have unique ways of identifying tables.
        6. >
          >
        7. schema/name and schema/table/name elements are required and must be unique.

          NVO portal applications discovered that it is important to have unique ways of identifying tables.
        8.  
          Changed:
          <
          <
        9. tableset/table/qualifiedName should include database catalog and/or schema qualifiers as applicable.

          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.
        10. >
          >
        11. schema/table/name should include database catalog and/or schema qualifiers as applicable.

          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.
        12.  
        13. the TableService is dropped.

          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).

        14. the function and join elements are dropped from the last proposal

            • 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.

        15. Table description extension mechanisms: xsi:type and extended types.

          Richer descriptions of tables will be enabled in two ways:
        16. Changed:
          <
          <
            • an xsi:type attribute can added to <tableset> or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
          >
          >
            • an xsi:type attribute can added to <tableset>, <schema>, and/or =<table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
           
            • the <dataType> 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.
          Changed:
          <
          <
        17. the <table> element's attribute role has been changed to type; added documentation for the recognized value "view".
        18. >
          >
        19. the <table> element's attribute role has been changed to type; added documentation for the recognized values for "base_table" and "view".
        20. Added:
          >
          >
        21. optional utype elements are added to <schema>, <table>, and <column> elements.

        22. 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".
        23.  

          Previous Discussion of Proposed Changes

          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 <testArgs> 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.
          2. Add an optional <rights> 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.
          3. Add an optional <dataset> 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.


          <--  
          -->

          META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
          META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
          META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
          META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
          META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
          META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
          META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224859557" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="41938" user="RayPlante" version="1.2"
          META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
          META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
          META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"

          Revision 102008-10-24 - RayPlante

           
          META TOPICPARENT name="IvoaResReg"
          Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
          Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

          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.

          Internal Working Draft Document
          VODataService: a VOResource Schema Extension for Describing Collections and Services
          in progress

          Internal Working Draft Schema
          VODataService-v1.1wd3.xsd

          Working Draft Schema
          VODataService-v1.0.xsd

          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)

          Version 1.0 (currently in use by IVOA registries)

          Proposed Changes

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

          1. The descriptions of tables is done via the tableset element

            The tableset 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:
              • "catalog" is an overloaded term, with different connotations in astronomy and database technology; tableset replaces the catalog element in attempt to shed connotations from both domains. In contrast, the term "table set" has a direct connection to the jargon behind the development of TAP and is more directly appropos.
              • 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/table).
              • The introduction of tableset does not address the issue of backward compatibility with VODataService v1.0 in which the CatalogService resource type lists tables at one level higher--i.e. there is no tableset level. 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.

          2. tableset/name and tableset/table/qualifiedName elements are required and must be unique.

            NVO portal applications discovered that it is important to have unique ways of identifying tables.

          3. tableset/table/qualifiedName should include database catalog and/or schema qualifiers as applicable.

            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.

          4. the TableService is dropped.

            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).

          5. the function and join elements are dropped from the last proposal

              • 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.

          6. Table description extension mechanisms: xsi:type and extended types.

            Richer descriptions of tables will be enabled in two ways:
              • an xsi:type attribute can added to <tableset> or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
              • the <dataType> 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.

          7. the <table> element's attribute role has been changed to type; added documentation for the recognized value "view".

          Previous Discussion of Proposed Changes

          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 <testArgs> 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.
          2. Add an optional <rights> 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.
          3. Add an optional <dataset> 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.


          <--  
          -->

          META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
          META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
          META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
          META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
          Changed:
          <
          <
          META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859392" name="catalogservice.xml" path="catalogservice.xml" size="3814" user="RayPlante" version="1.2"
          META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776711" name="catalog.xml" path="catalog.xml" size="7816" user="RayPlante" version="1.1"
          >
          >
          META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888000" name="catalogservice.xml" path="catalogservice.xml" size="3888" user="RayPlante" version="1.3"
          META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224888041" name="catalog.xml" path="catalog.xml" size="8031" user="RayPlante" version="1.2"
           
          META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224859557" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="41938" user="RayPlante" version="1.2"
          META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
          META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
          Added:
          >
          >
          META FILEATTACHMENT attr="" comment="for v1.1wd4" date="1224887866" name="VODataService-v1.1wd4.xsd" path="VODataService-v1.1wd4.xsd" size="45421" user="RayPlante" version="1.1"
           

          Revision 92008-10-24 - RayPlante

           
          META TOPICPARENT name="IvoaResReg"
          Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
          Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

          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.

          Internal Working Draft Document
          VODataService: a VOResource Schema Extension for Describing Collections and Services
          in progress
          Changed:
          <
          <
          Internal Working Draft Schema
          VODataService-v1.1wd2.xsd
          >
          >
          Internal Working Draft Schema
          VODataService-v1.1wd3.xsd
           

          Working Draft Schema
          VODataService-v1.0.xsd

          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)

          Version 1.0 (currently in use by IVOA registries)

          Proposed Changes

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

          Changed:
          <
          <
          1. The descriptions of tables is done via the tableset element
          >
          >
            Added:
            >
            >
          1. The descriptions of tables is done via the tableset element
          2.  

            The tableset 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:
              • "catalog" is an overloaded term, with different connotations in astronomy and database technology; tableset replaces the catalog element in attempt to shed connotations from both domains. In contrast, the term "table set" has a direct connection to the jargon behind the development of TAP and is more directly appropos.
              • 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/table).
              • The introduction of tableset does not address the issue of backward compatibility with VODataService v1.0 in which the CatalogService resource type lists tables at one level higher--i.e. there is no tableset level. 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.
            Changed:
            <
            <
            1. tableset/name and tableset/table/qualifiedName elements are required and must be unique.

              NVO portal applications discovered that it is important to have unique ways of identifying tables.
            >
            >
          3. tableset/name and tableset/table/qualifiedName elements are required and must be unique.

            NVO portal applications discovered that it is important to have unique ways of identifying tables.
          4.  
            Changed:
            <
            <
            1. tableset/table/qualifiedName should include database catalog and/or schema qualifiers as applicable.

              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.
            >
            >
          5. tableset/table/qualifiedName should include database catalog and/or schema qualifiers as applicable.

            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.
          6.  
            Changed:
            <
            <
            1. the TableService is dropped.

              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).
            >
            >
          7. the TableService is dropped.

            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).
          8.  
            Changed:
            <
            <
            1. the function and join elements are retained from the last proposal

              • There was some discussion about whether this join definition was the best way to capture this information, although an alternative has not been proposed. Retaining join is based on the observation that a practical barrier to using, say, OpenSkyQuery
            >
            >
          9. the function and join elements are dropped from the last proposal

              • 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.
          10.  
            Added:
            >
            >
          11. Table description extension mechanisms: xsi:type and extended types.

            Richer descriptions of tables will be enabled in two ways:
              • an xsi:type attribute can added to <tableset> or <table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
              • the <dataType> 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.

          12. the <table> element's attribute role has been changed to type; added documentation for the recognized value "view".
          13.  

            Previous Discussion of Proposed Changes

            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 <testArgs> 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.
            2. Add an optional <rights> 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.
            3. Add an optional <dataset> 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.
            Changed:
            <
            <
            >
            >
              • Extra types are RelationalSchema, Function, RelationalJoin.
             


            <--  
            -->

            META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
            META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
            META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
            Changed:
            <
            <
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776685" name="catalogservice.xml" path="catalogservice.xml" size="3816" user="RayPlante" version="1.1"
            >
            >
            META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859392" name="catalogservice.xml" path="catalogservice.xml" size="3814" user="RayPlante" version="1.2"
             
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776711" name="catalog.xml" path="catalog.xml" size="7816" user="RayPlante" version="1.1"
            Changed:
            <
            <
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776759" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="26180" user="RayPlante" version="1.1"
            >
            >
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224859557" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="41938" user="RayPlante" version="1.2"
            Added:
            >
            >
            META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859361" name="VODataService-v1.1wd.xsd" path="VODataService-v1.1wd.xsd" size="41876" user="RayPlante" version="1.1"
            META FILEATTACHMENT attr="" comment="for v1.1wd3" date="1224859622" name="VODataService-v1.1wd3.xsd" path="VODataService-v1.1wd3.xsd" size="41724" user="RayPlante" version="1.1"
             

            Revision 82008-10-23 - RayPlante

             
            META TOPICPARENT name="IvoaResReg"
            Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
            Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg

            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.

            Internal Working Draft Document
            VODataService: a VOResource Schema Extension for Describing Collections and Services
            in progress

            Internal Working Draft Schema
            VODataService-v1.1wd2.xsd

            Working Draft Schema
            VODataService-v1.0.xsd

            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)

            Changed:
            <
            <
            >
            >
             

            Version 1.0 (currently in use by IVOA registries)

            Proposed Changes

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

            1. The descriptions of tables is done via the tableset element

              The tableset 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:
              • "catalog" is an overloaded term, with different connotations in astronomy and database technology; tableset replaces the catalog element in attempt to shed connotations from both domains. In contrast, the term "table set" has a direct connection to the jargon behind the development of TAP and is more directly appropos.
              • 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/table).
              • The introduction of tableset does not address the issue of backward compatibility with VODataService v1.0 in which the CatalogService resource type lists tables at one level higher--i.e. there is no tableset level. 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.

            1. tableset/name and tableset/table/qualifiedName elements are required and must be unique.

              NVO portal applications discovered that it is important to have unique ways of identifying tables.

            1. tableset/table/qualifiedName should include database catalog and/or schema qualifiers as applicable.

              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.
            Changed:
            <
            <
            1. the TableService is dropped.

              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).
            >
            >
            1. the TableService is dropped.

              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).
            Added:
            >
            >
            1. the function and join elements are retained from the last proposal

              • There was some discussion about whether this join definition was the best way to capture this information, although an alternative has not been proposed. Retaining join is based on the observation that a practical barrier to using, say, OpenSkyQuery
             

            Previous Discussion of Proposed Changes

            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 <testArgs> 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.
            2. Add an optional <rights> 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.
            3. Add an optional <dataset> 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.


            <--  
            -->

            META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
            META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
            META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776685" name="catalogservice.xml" path="catalogservice.xml" size="3816" user="RayPlante" version="1.1"
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776711" name="catalog.xml" path="catalog.xml" size="7816" user="RayPlante" version="1.1"
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776759" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="26180" user="RayPlante" version="1.1"

            Revision 72008-10-23 - RayPlante

             
            META TOPICPARENT name="IvoaResReg"
            Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
            Changed:
            <
            <

            Meetings: InterOpMay2007ResReg :: InterOpSep2006ResReg
            >
            >

            Meetings: InterOpMay2008ResReg :: InterOpSep2007ResReg
             

            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.

            Added:
            >
            >
            Internal Working Draft Document
            VODataService: a VOResource Schema Extension for Describing Collections and Services
            in progress

            Internal Working Draft Schema
            VODataService-v1.1wd2.xsd
             
            Working Draft Schema
            VODataService-v1.0.xsd

            Features

            VODataService defines the follow extensions of the generic Resource type:

            Changed:
            <
            <
            • 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 catalogs.
            >
            >
            • 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.
            Changed:
            <
            <
            • 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.
            >
            >
            • 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.
            Changed:
            <
            <

            Some samples

            >
            >

            Some samples

             
            Added:
            >
            >

            Version 1.1 (proposed)

            Version 1.0 (currently in use by IVOA registries)

             

            Proposed Changes

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

            1. The descriptions of tables is done via the tableset element

              The tableset 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:
              • "catalog" is an overloaded term, with different connotations in astronomy and database technology; tableset replaces the catalog element in attempt to shed connotations from both domains. In contrast, the term "table set" has a direct connection to the jargon behind the development of TAP and is more directly appropos.
              • 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/table).
              • The introduction of tableset does not address the issue of backward compatibility with VODataService v1.0 in which the CatalogService resource type lists tables at one level higher--i.e. there is no tableset level. 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.

            1. tableset/name and tableset/table/qualifiedName elements are required and must be unique.

              NVO portal applications discovered that it is important to have unique ways of identifying tables.

            1. tableset/table/qualifiedName should include database catalog and/or schema qualifiers as applicable.

              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.

            1. the TableService is dropped.

              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).

            Previous Discussion of Proposed Changes

            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 <testArgs> 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.
            2. Add an optional <rights> 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.
            3. Add an optional <dataset> 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.


            <--  
            -->

            META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
            META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
            Added:
            >
            >
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776604" name="collection.xml" path="collection.xml" size="4589" user="RayPlante" version="1.1"
            META FILEATTACHMENT attr="" comment="v1.1wd2" date="1224776662" name="VODataService-v1.1wd2.xsd" path="VODataService-v1.1wd2.xsd" size="44030" user="RayPlante" version="1.1"
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776685" name="catalogservice.xml" path="catalogservice.xml" size="3816" user="RayPlante" version="1.1"
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776711" name="catalog.xml" path="catalog.xml" size="7816" user="RayPlante" version="1.1"
            META FILEATTACHMENT attr="" comment="for v1.1wd2" date="1224776759" name="VODataService-v1.1wd.html" path="VODataService-v1.1wd.html" size="26180" user="RayPlante" version="1.1"
             

            Revision 62008-05-20 - GuyRixon

             
            META TOPICPARENT name="IvoaResReg"
            Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
            Meetings: InterOpMay2007ResReg :: InterOpSep2006ResReg

            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.

            Working Draft Schema
            VODataService-v1.0.xsd

            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 catalogs.
            • 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

            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 <testArgs> 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.
            2. Add an optional <rights> 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.
            3. Add an optional <dataset> 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.
            Added:
            >
            >
            This change was motivated by recent work on TAP and VOSI.
             
            1. Add extra elements to describe use of tables and databases.


            <--  
            -->

            META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
            META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"

            Revision 52008-05-20 - GuyRixon

             
            META TOPICPARENT name="IvoaResReg"
            Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
            Meetings: InterOpMay2007ResReg :: InterOpSep2006ResReg

            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.

            Changed:
            <
            <
            Working Draft Schema
            VOResource-v1.0.xsd
            >
            >
            Working Draft Schema
            VODataService-v1.0.xsd
             

            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 catalogs.
            • 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

            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 <testArgs> 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.
            2. Add an optional <rights> 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.
            3. Add an optional <dataset> 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.
            Added:
            >
            >
            1. Add extra elements to describe use of tables and databases.
             

            Added:
            >
            >
             
            <--  
            -->
            Added:
            >
            >
            META FILEATTACHMENT attr="h" comment="Tables proposal - deeply nested" date="1211287048" name="VODataService-v1.1-tables-proposal-1.xsd" path="VODataService-v1.1-tables-proposal-1.xsd" size="40107" user="GuyRixon" version="1.1"
            META FILEATTACHMENT attr="h" comment="Tables proposal - partially flattened" date="1211287086" name="VODataService-v1.1-tables-proposal-2.xsd" path="VODataService-v1.1-tables-proposal-2.xsd" size="44901" user="GuyRixon" version="1.1"
             

            Revision 42007-10-03 - RayPlante

             
            META TOPICPARENT name="IvoaResReg"
            Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
            Meetings: InterOpMay2007ResReg :: InterOpSep2006ResReg

            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.

            Working Draft Schema
            VOResource-v1.0.xsd

            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 catalogs.
            • 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

            Added:
            >
            >

            Proposed Changes

             
            Added:
            >
            >
            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 <testArgs> 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.
            2. Add an optional <rights> 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.
            3. Add an optional <dataset> 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.
             


            <--  
            -->

            Revision 32007-10-02 - RayPlante

             
            META TOPICPARENT name="IvoaResReg"
            Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
            Meetings: InterOpMay2007ResReg :: InterOpSep2006ResReg
            Changed:
            <
            <

            VODataService

            >
            >

            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.

            Working Draft Schema
            VOResource-v1.0.xsd
            Added:
            >
            >
             

            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 catalogs.
            • 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


            <--  
            -->

            Revision 22007-09-27 - RayPlante

             
            META TOPICPARENT name="IvoaResReg"
            Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
            Meetings: InterOpMay2007ResReg :: InterOpSep2006ResReg

            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.

            Working Draft Schema
            VOResource-v1.0.xsd

            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 catalogs.
            • 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.
            Added:
            >
            >
            • 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

            Changed:
            <
            <
            >
            >
            Added:
            >
            >
             


            <--  
            -->

            Revision 12007-09-27 - RayPlante

             
            META TOPICPARENT name="IvoaResReg"
            Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
            Meetings: InterOpMay2007ResReg :: InterOpSep2006ResReg

            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.

            Working Draft Schema
            VOResource-v1.0.xsd

            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 catalogs.
            • 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.

            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


            <--  
            -->
             
            This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
            Ideas, requests, problems regarding TWiki? Send feedback