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:

• https://ivoa.net/documents/EPNTAP/

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.

=> 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:

=> select * from spicam.epn_core

• The MPC service at Heidelberg is compliant:

=> 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

• Sample comment by WikiName
  • Response (by WikiName)

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

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

• No, I disagree here. We had these exact types in previous specs, and they only caused all kinds of validation trouble for no operational gain at all. No client will bother whether a value is float or double, and individual operators may have good reasons for choosing one or the other. Similarly, there is absolutely no operational problem in choosing char(40) over text in a specific table, and the spec has no reason to outlaw this. Even more importantly, we should not close the door to pushing out unicodeChars or something equivalent on non-VOTable output. By the way, this minimal specification style is also used by RegTAP, ObsLocTAP, and hopefully anything else that does this kind of thing. -- MarkusDemleitner - 2021-11-09

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

In general the document seems clear, and it seems like it would be straightforward both to implement services and to query the services and consume results. I trust the interest group experts on the domain-specific details of the parameters/columns so I gave those only a cursory review. I'll echo the comment from Operations that the implementations need to pass validation.

I have the following fairly minor editorial comments and questions. Page numbers refer to those in the pdf:

• Since this document is explicitly defining TAP services, I found the use of the word "parameter" confusing. Maybe add a sentence mentioning how "parameter" relates to the TAP notion of "column", either that they are effectively equivalent, or in what ways they differ?
  • To a lesser extent, the notion of keyword also seems essentially equivalent but also has just an implicit relationship to the "parameter" and "column", although "keyword" is used in a different way on p. 42 in the description of target_description.
  • For the EPNcore Table, the header for these parameters/columns/keywords is just "Name". Maybe a header of "Parameter Name" or "Column Name" would tie things together just a little more explicitly.

• p. 5, paragraph 2 (in section 1.1) was unclear to me.
  • Should "consists in" be "consists of"?
  • The first sentence seems to say there will be one table per service, and the second seems to say there can be multiple. Can this be clarified?

• p. 5, paragraph 3 (in section 1.1): Because of the spacing in the formatting, I might replace "/" with "and" in "A unique query can then be sent to / answered".

• p. 5, paragraph 4 (in section 1.1): I don't know what this means: "Any optional parameter can be used whenever required."

• p. 6 (in section 1.2), regarding "Some parameters can be multivalued...", it's implicitly clear due to the VOTable spec that this refers only to string-type parameters, but it might be worth making that explicit to confusion if numeric arrays are ever included.

• For the Example TAP queries on pp. 11, 14, 16, 18, 47:
  • The single quotes as rendered in the pdf (but not the html) are the pretty kind that the ADQL parsers don't like. If there is a way to force the simple ASCII single quotes there, it would make cutting and pasting a little more useful.
  • I realize that it would be difficult to maintain a live service that responds nicely to the example queries for the life of the document, but even now it was not obvious to me where to find a service where they would run. I might have missed it, but I didn't see the "pipo.epn_core" table in any of the reference implementations. Would it be reasonable to say something like, "The example queries are for illustration purposes only. The exact table names and contents will vary depending on the service. At the time of writing, these queries will return results on the EPN TAP service at <one of the reference implementations>." Having runnable queries now would help validate that there aren't typos in the document's examples and could possibly help other early implementers. Including similar examples as service-provided examples on a reference implementation could also be helpful.

• Appendix A says "No previous version yet." Since the Introduction mentions a previous version that was limited to test purposes, would it make sense to say something similar in Appendix A?

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.