TWiki> IVOA Web>IvoaDAL>EPNTAPV20RFC (revision 12)EditAttach

EPN-TAP Proposed Recommendation: Request for Comments

EPN-TAP is a protocol used to describe and access data related to the study of the Solar System.

This document defines the EPN-TAP framework, which is using TAP with the EPNcore meta- data dictionary. The EPNcore metadata dictionary defines the core components that are necessary to perform data discovery in the Solar System related science fields. It includes keywords to describe data products coverage (temporal, spectral, spatial, photometric), origin (instrument, facility), content (target, physical parameters), access, references, etc. Its implementation with TAP (Table Access Protocol) is presented, including service registration guidelines. Topical extension metadata dictionaries are also presented.

Latest version of EPN-TAP can be found at:

Reference Interoperable Implementations

Indicate here the links to at least two Reference Interoperable Implementations)

  • All EPN-Core tables on VOPARIS-TAP-MASER TAP server are compliant.
http://voparis-tap-maser.obspm.fr/__system__/adql/query/form

=> select * from cassini_rpws.epn_core

=> select * from expres.epn_core

=> select * from voyager_pra.epn_core

=> select * from wind_waves.epn_core

...

  • The SPICAM service at LATMOS is compliant:
http://vo.projet.latmos.ipsl.fr/__system__/adql/query/form

=> select * from spicam.epn_core

  • The MPC service at Heidelberg is compliant:
http://dc.zah.uni-heidelberg.de/__system__/adql/query/form

=> select * from mpc.epn_core

Implementations Validators

taplint from STILTS versions >=3.4-2 checks all column metadata and content constraints:

   java -jar stilts.jar taplint tapurl=http://dc.g-vo.org/tap stages='tme epn'


Comments from the IVOA Community during RFC/TCG review period: 2021-09-30 - 2021-11-14

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


Section: Role within the VO Architecture (1.3)
  • the TAP reference is to TAP-1.0; maybe update that to TAP-1.1?
  • include in diagram and reference to DALI (latest) since a lot of the input/output syntax for TAP comes from there and you'll need to refer to DALI directly
  • less necessary: VOSI could be added tom diagram/ref, although the transitive dependency via DALI and TAP are probably OK
Section EPNcore Table (3)

The Type column in the table should be TAP data types: anything "Text" should be datatype "char" arraysize "*" (take care to allow finite arraysize without implementors and validators taking it literally), "Double" or "Float" should be "double" or "float" (exact TAP/VOTable datatype).

For s_region, you should use "polygon" from DALI-1.1 (not spoly) if that is specifically what you intend; there is also "circle" in DALI-1.1. Also, note that WD-DALI-1.2 defines "shape" which is polymorphic so you might want to specify s_region to be "any spatial extent described in DALI" to allow implementations to use "shape" in future. I think that's what "Note 3" is trying to say, but it's not clear. I would caution, however, that polymorphic types like "shape" in the model/API (tap_schema) are harder to implement so I would only do that if there are real use cases that require something other than "polygon". If you find the defintion of polygon in DALI too restrictive (e.g. with respect to required refr frames) this is an excellent time to bring it up in DALI so we can find a solution to support non-ICRS frames.

Also in s_region, the description mentions "celestial of body-related frames". Is that in reference to the spatial_frame_type column a little farther down? If so, I would cross-reference in both descriptions and put those two next to each other so the relationship is as clear as possible? (I purposely have not read the body text yet so this could be explained there, but so many people will skip to this descriptive table that it needs to be as robust as possible on it's own).

For the "shape" column that seems to be a prototyope st-moc, could you use a different column name there? Maybe: space_time_coverage? space_time_cov? st_coverage? With DALI-1.2 introducing "shape" as an xtype this has the potential to be confusing. Also, WD-DALI-1.2 introduces xtype="moc" for the MOC-1.4 ascii spatial moc so it will also specify an xtype for ST-MOC when that becomes a standard. It would be good to specify this column so that could be adopted later. Spatial moc in VOTable are datatype="char" arraysize="*" xtype="moc" and I would expect ST-MOCs to be datatype="char" arraysize="*":xtype="stmoc", so having people use datatype="char" arraysize="*" now (which is what you mean by "Text" there) and add the xtype later (just as metadata in tap_schema) looks like it will work out fine.

-- PatrickDowler - 2021-11-01



Comments from TCG member during the RFC/TCG Review Period: 2021-09-30 - 2021-11-14

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

Operations Interest Group

As one of the document authors, I am basically happy with the text. But before recommending acceptance, I would like to see one EPN-TAP service that passes all validation checks. -- MarkTaylor - 2021-10-04

  • I have updated the Reference Implementation section, and I have listed several services passing all validation checks. -- BaptisteCecconi - 2021-10-28

Radio Astronomy Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee


TCG Vote : 2021-09-30 - 2021-11-14

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        
Edu        
KDIG        
Ops        
Radio        
SSIG        
Theory        
TD        
StdProc        


Edit | Attach | Watch | Print version | History: r44 | r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r12 - 2021-11-01 - PatrickDowler
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback