Difference: VODataServiceV12RFC (4 vs. 5)

Revision 52021-03-12 - MarkTaylor

 
META TOPICPARENT name="ResourceMetadata"

VODataService 1.2 Proposed Recommendation: Request for Comments

The latest version of VODataService 1.2 can be found at:

While future versions may be migrated elsewhere, VODataService 1.2 is managed by the legacy volute repository at: http://volute.g-vo.org/viewvc/volute/trunk/projects/registry/VODataService/

Summary

VODataService 1.2 is an incremental update to the widely-used VODataService Registry extension (98% of all registry records use VODataService resource types). We expect 100% backward compatibility.

We believe there are three main points for TCG review:

  • Post-STC1 (and realistically usable) Space-Time coverage in the registry; sect. 3.2

  • New resource types to support multi-resource services (as per Discovering Data Collections); sect. 3.1

  • Waveband is now governed by a vocabulary of messenger types; promoting this to REC would also make the vocabulary http://www.ivoa.net/rdf/messenger accepted (with Photon and Neutrino included as new terms).

There are also a few minor changes to tableset conventions. This requires review by those familiar with VOSI Tables and TAP.

Changelog since REC-1.1


In approximate order of importance:

  • Deprecated STCResourceProfile and replaced it with spatial, temporal, and spectral children of coverage; spatial has a frame attribute not further defined so far to allow for future extension to e.g., solar system bodies.

  • Dropped vs:Waveband and changed waveband to being controlled by a vocabulary that initially grows a generic Photon and a Neutrino concept over what the previous Waveband had.

  • Introduced new DataResource and CatalogResource resource types and wove them into the inheritance hierarchy to CatalogService; these are to be used for "dependent" resources.

  • New (optional) table/@nrows attribute gives an estimate for the size of a table

  • extendedType is now defined to correspond to VOTable xtypes in the absence of extendedSchema.

  • Required inclusion of quotes for delimited identifiers in a SQL context.

  • Sanctioning the use of footprint/@ivo-id to indicate the footprint standard used (this goes against the semantics of the ServiceReference tye underlying footprint, because the reference was originally intended to go to a registered service returning footprints – but no such services ever came around, and instead people used ivo-id as specified now).

  • Now allowing any vs:DataType element to define vs:InputParams.

  • In order to still ensure schema validation of type names, now advising to have an explicit xsi:type in param's dataTypes.

  • Deprecated TAPType.

  • DataType/@arraysize no longer defaults to 1, and the interpretation of arraysize=1 as a scalar is withdrawn. Use empty arraysize for scalars now.

  • Added a SHOULD requirement on CatalogResources to have a tableset.

  • Deprecated DataCollection and StandardSTC (which are no longer needed).

  • Adding a summary of the Discovering Data Collections EN.

  • BaseParam's delim attribute no longer defaults to blank. That conflicted with VOTable, where other conventions are in place (e.g., for string arrays).

  • Now discouraging the use of delim outside of InputParams.

  • No longer requiring unique table names within a tableset; uniqueness is now required within a schema. Many services have been in violation of the old unique-within-tableset rule for a long time without operational difficulties, and this change affects little as fully qualified names are now required for the main uses of tableset.

  • Ported source to ivoatex.

Reference Interoperable Implementations

Changed:
<
<
On the production side, DaCHS has been producing records with most of these features for quite some time. As an example, see the Heidelberg data center's OAI endpoint at https://dc.g-vo.org/oai.xml

Also on the production side, VizieR is producing VODataService 1.2-compliant records, including coverage declaration, on http://cdsweb.u-strasbg.fr/registry/beta/ , which is slated to become the primary VizieR publishing registry in Mid-2021.

On the consumption side, the Heidelberg RegTAP service parses the extra information and exposes it in custom RegTAP extensions rr.stc_spatial, rr.stc_spectral, and rr.stc_temporal. The table's nrows attribute shows up in rr.res_tables.
>
>
On the production side, DaCHS has been producing records with most of these features for quite some time. As an example, see the Heidelberg data center's OAI endpoint at https://dc.g-vo.org/oai.xml

Also on the production side, VizieR is producing VODataService 1.2-compliant records, including coverage declaration, on http://cdsweb.u-strasbg.fr/registry/beta/ , which is slated to become the primary VizieR publishing registry in Mid-2021.

On the consumption side, the Heidelberg RegTAP service parses the extra information and exposes it in custom RegTAP extensions rr.stc_spatial, rr.stc_spectral, and rr.stc_temporal. The table's nrows attribute shows up in rr.res_table.
Added:
>
>
Also on the consumption side, TOPCAT (versions >4.8 and pre-release) consume and display the nrows quantity in TAP metadata display where applicable.
 

Implementation Validators

The syntax (and a bit of the semantics, too) of VODataService records can be checked with ordinary XML schema validation tools. As setting up the necessary schema locations is somewhat involved, you might want to use DaCHS's dachs val xsd command.

For VOSI tables endpoints of TAP services, the STILTS taplint validator release >3.4, or failing that the latest pre-release, will validate against the schema coming with this PR.

Comments from the IVOA Community during RFC/TCG review period: 2021-03-01 to 2021-04-23

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document



Comments from TCG member during the RFC/TCG Review Period: 2021-03-01 to 2021-04-23

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Operations

Standards and Processes Committee

TCG Vote : Vote_start_date - Vote_end_date

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.

Group Yes No Abstain Comments
TCG        
Apps        
DAL        
DM        
GWS        
Registry        
Semantics        
DCP        
KDIG        
SSIG        
Theory        
TD        
Ops        
StdProc        
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback