EPN-TAP Proposed Recommendation: Request for Comments

Abstract

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 published version of EPN-TAP can be found at:

• https://ivoa.net/documents/EPNTAP/20220705/index.html

Working version with latests edits can be found at:

• https://github.com/ivoa-std/EPNTAP

NOTE: a second round of comments for the TCG has been setup to allow a quick review of this PR that has undergone a re-shape for what concerns the document structure.

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's EPN stage checks all column metadata and content constraints; STILTS v3.4-6 matches PR-EPNTAP-20220705. The following invocation can be used:

   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
• — Both done -- StephaneErard - 2022-03-23
• 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).

• 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
• I'm with Markus. However I have suggested an edit (EPNTAP PR#18) to clarify the meaning. (Parenthetically: this issue comes up in many documents, it would be nice to have some standard language to say "it's a string" e.g. endorsed by DALI) -- MarkTaylor - 2021-11-10

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.

• Updated -- StephaneErard - 2022-03-23

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

• Done -- StephaneErard - 2022-03-23

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.

• (Being processed - we need an alternative name covering s/t/f mocs; would moc_coverage do?) -- StephaneErard - 2022-03-23

• The previous Shape parameter has been renamed to Coverage -- StephaneErard - 2022-07-5

-- PatrickDowler - 2021-11-01

---

Comments by Markus Demleitner

(a) Now that Tom has pointed it out, I agree the use of word "parameter" in this standard is, well, nonstandard. Since it's probably too late to change from "parameter" to "column" throughout without almost certainly getting things wrong, I guess the best we can do is an info box (in an admonition environment) explaining the language. Poke me and I'll try a PR, but then I'd be grateful for input on just how "parameter" came to mean "column" in this standard.

• The focus is on the vocabulary, rather than tabular services. In an EPN-TAP service, EPNCore parameters appear as columns of the table to describe the granules - this is now explained in the intro and start of section 2. But they can be used independently from EPN-TAP tables (eg faceted search); in such contexts they are just parameters, there are no columns to name. A contextual explanation was added in section 1.1.
"keywords" was inherited from PDS3 where parameters are never tabulated - this phrasing has been removed. -- StephaneErard - 2022-03-23

(b) p. 7 I'd drop "As a general rule, a parameter can appear only once in a service table." I think what you're saying here is "Within a SQL table, no column name can occur twice", and that's indeed a general rule, but as a reader I'm wondering why it is states here (and not, say, the unfortunate case-folding rules of SQL, which probably will lead to quite a bit more confusion). If it's supposed to mean something else, then that thing needs to be stated more clearly.

• This was mostly to avoid variations on existing parameters (e.g., radius when diameter exists). Updated. -- StephaneErard - 2022-03-23

(c) p. 11, measurement_type -- I'd prefer if the whole paragraph "The UCD1+ list from IVOA ... Request for Modifications" were dropped -- I don't think it's particularly helpful (I'm sure nobody will put in ancient UCD1 here), and it looks a bit odd in a normative document.

• Done -- StephaneErard - 2022-03-23

(d) p. 11, processing_level -- "this one should be used to meet the expectations of historical users" -- I'm not sure what "historical users" is intended to mean here, and I can't quite make out what the whole sentence says. Could you clarify?

• This has been updated (any specific encoding now goes into processing_level_desc) -- StephaneErard - 2022-03-23

(e) In the processing level table on p. 12, "Partially Calibrated" is translated as "2?" as the EPN code. I think that's an artefact of editing, since processing_level is an integer and hence there's no way to represent "2?". Could you clarify this?

• Updated and fixed -- StephaneErard - 2022-03-23

(f) p. 13 "Data providers must be aware that services which do not use the IAU designations might not be accessible by the clients." -- this is supposed to say "that services which do not use IAU designations will not return the rows for that target to users querying by IAU target name", right? I'd rather see something like this rather than talking about "accessible", which in this case would, I claim, rather be understood as "users will be locked out" rather than "users won't get what they ought to get". Similarly, it shouldn't be "services containing... might not be visible", but in this case, just dropping the "services containing" would be essentially enough: "...that data of interest might not be retrieved if they do not use the recommended...".

• Done -- StephaneErard - 2022-03-23

(g) p. 14, the sample queries: Since you're (rightly) advising against using LIKE on target_class, I'd say you shouldn't show in it an example; just demonstrate the correct usage and be done with it (even more so since this isn't even supposed to demonstrate target_class). While we're talking about style: I'm always in favour of weaning people off "SELECT *". So, in case there's a plausible case here that would suggest only retrieving a few columns, writing these out would, I'd argue, improve the educational value of the example.

• Fixed -- StephaneErard - 2022-03-23

(h) p. 16, the time-constraining queries: Please remove the quotes. While SQL is weakly-typed enough that time_min > ’2455197.5’ will work as expected, there's a lot of luck involved, and we should educate our users to think of types and their literals. Hence, please make it time_min > 2455197.5.

• Fixed -- StephaneErard - 2022-03-23

(i) p. 17, the "Conversions" block in spectral_range: This seems like a leftover of some recipe to me. Can we drop it? If what you really want to say is "the max of the spectral range in wavelength is the min of the spectral range in frequency", I'd suggest to say that in prose; it's odd to see a spectral_range_max_micron come out of nowhere.

• From experience, we need to provide conversion rules with exact coefficients where the parameter is defined (TBC after next pull request) -- StephaneErard - 2022-03-23

(j) For spectral_resolution, I'd again like to drop the "Conversions" part. See remark (i).

• (TBC after next pull request) -- StephaneErard - 2022-03-23

• This has been edited as suggested, and agreed -- StephaneErard - 2022-07-05

(k) p. 20 "use ``none'' if not applicable, although ``body'' is found in older services and may be OK" -- nah, please be clear on what you want. I'd say "body" with all-NULL ci columns wouldn't hurt, but perhaps a magic value for "no coordinates here" will make a few queries faster. Whatever it is, please make up your mind, or we'll end up with a combination of the disadvantages of both approaches. And if we want a NULL value, let's make it NULL -- this will then need to fixed in the DaCHS mixin, sure, but that's a minor problem.

• Fixed - we actually want "none", not NULL -- StephaneErard - 2022-03-23

(l) p. 20 "Current IAU frame is assumed" -- if this is supposed to mean: "assume whatever IAU frame is current at your time", you should explicitly state that (and I think that's a good idea even though that will retroactively change the semantics of existing tables as the "current IAU frame" evolves -- it's not unlikely that such changes will tend to improve existing services overall). If, on the other hand, you mean "IAU frame at the time of writing", you should say that and give a reference to where that is defined. Disclaimer: I admit that I only have a vague idea what "IAU frame" might refer to here.

• clarified, reference added -- StephaneErard - 2022-03-23

(m) p. 20, the cartesian frame: I always wonder if the world agrees whether y is up and z is perpendicular to the plane or it's the other way round. If the world, as it seems to me, does not agree, it might be a good idea to state some preference here -- or state that we don't care.

• left to data providers -- StephaneErard - 2022-03-23

(n) p. 22, the Implementation notes to s_region: these are actually talking about pgsphere, and hence I don't think this should be in EPN-TAP. Let's drop it here and rather expand tutorial coverage on how to pull in the various geometries and how to prep the database for the various possibilities.

• I prefer to keep at least an initial hint in the doc for putative data providers - Our experience is that otherwise they drop the whole matter easily. -- StephaneErard - 2022-03-23

(o) p. 22 "An observatory list is being developed in Europlanet-2024/VESPA and will be implemented in a resolver by merging existing lists (draft here: Observatory Facility Database)" -- I'm not a big fan of promising things in REC-s; most of the time things come out differently, and then these things are like sore thumbs in the standards. In this case, that reference doesn't actually help anyone to pick names that they may be able to keep. Can we drop that sentence and write something like "Regrettably, there is no consensus nomenclature for instruments and their hosts yet. EPN-TAP data providers are advised to pick their instrument identifiers from one of the following lists for the time being:" I'd suggest similar text in instrument_name on p.23.

• Mentions of future implementations were removed - will be linked from a unique web page outside this doc -- StephaneErard - 2022-03-23

(p) p. 23 "care must therefore be taken to use a title not already ascribed to another EPN-TAP service" -- well, if we want this, we have to give people a chance to figure out whether a name they want is already taken. There are a few options for that, among others:

* Prescribe the schema name as the service title and then tell people to select schema_name from rr.res_schema natural join rr.res_table where table_utype=(the epn-core id). * Use the table/title element in VODataService and tell people to select table_title from rr.res__table where table_utype=(the epn-core id). * keep things as they are and give a sample pyvo programme that illustrates how to get a list of existing service titles (that's a four-liner, so it's not that bad).

I don't have major preferences either way, but I insist that if we have uniqueness requirements we give a plausible way for people to somewhat fulfill them.

• Included a tentative TAP request to list existing services -- StephaneErard - 2022-03-23

(q) p. 24 "and must provide an actual and unique link" -- I'd suggest to drop this. The "unique" part could be misunderstood as a requirement that the same URI can't be in a table multiple times (where I'm not sure why we should forbid that, and I certainly don't want to have to validate against such a requirement) or even that the same URI can't be in two different EPN-core tables. As to the "actual": what is that supposed to mean? Retrievable as in "gives a 200 HTTP response"? Do we really want to bind a service's validity to whether all of the data products it lists are actually retrievable? I have similar concerns on thumbnail_url on p. 25 ("and must provide an actual link").

• removed, indeed -- StephaneErard - 2022-03-23

(r) p. 24 "The link may be a call to a web service (e.g., PlanetServer _CRISM service) or the output of a script (e.g., Titan atmospheric profiles service); in both cases the link must include the adequate arguments." Another sentence I'd drop: you couldn't keep people from doing this if you wanted to, and I don't think there's any need to remind them they can do that.

• we maintain the sentence - this is not obvious to everybody, and we have reasons to state clearly that, e.g., links to OGC-compliant services may be provided via EPN-TAP -- StephaneErard - 2022-03-23

(s) p. 24 "Datalinks [...] can be used for this later purpose, and must be provided via the datalink_url parameter." -- what's the rationale of outlawing datalinks as products? You see, if I have datasets that are a few gigabytes big, I usually point people to the datalink services, and I expect clients to do the right thing with them at some point. Sending a few gigabytes down the pipe to some unsuspecting client to me looks like a less desirable alternative to the occasional "I can't read this".

• We're not outlawing datalink as products, we're outlawing documentations in access_url (consistently with dataproduct_type values). Large data products can be handled through access_estsize (we don't expect people to link granules Gb in size in this field) -- StephaneErard - 2022-03-23

(t) p. 25 "Other parameters may be used..." -- I'm not terribly happy about pseudo-document structure half-implied through boldfaced normal paragraphs. The "other parameters" probably do not belong to "Data Access Reference", as its introduction makes "these 3 parameters" mandatory in some sense. So, can't this "Other parameters" thing be replaced by a \subsubsection{Miscellaneous File Metadata} or something like that?

• Done -- StephaneErard - 2022-03-23

(u) p. 25 "accref" -- I'd drop the entire paragraph; this is an implementation detail of the specific way DaCHS handles products and has no impact on other implementations of EPN-TAP, let alone the clients. In the unlikely case a DaCHS operator accidentally uses accref, it's up to DaCHS to do something sensible (which at this point it probably won't do, but we can't fix that from the EPN-TAP spec).

• shortened, but maintained: we've actually seen people using accref in their table, the result was not pretty -- StephaneErard - 2022-03-23

(v) p. 26 datalink_url -- this mentions dlmeta and dlget; these are again implementation details of DaCHS and should not be here. The text I think works reasonably well if you just take out the parentheses. I'd also take out the material starting with "Links can be parameterized" -- how people build the links into their datalink service is up to them (and, really, if it's a datalink service, there's going to be a parameter, ID).

• removed Dachs related details, added an implementation note as a hint (although we no longer do it this way) -- StephaneErard - 2022-03-23

(w) p. 26 datalink_url -- I think this should also briefly mention what the relationship of this column to the normal Datalink techniques for creating datalink is, perhaps: "This column allows operators to include pre-produced links to a Datalink service that are visible to clients not evaluating datalink service blocks \citep{2015ivoa.spec.0617D}. There are no requirements as to the relationship between URLs in datalink_url and links clients can generate from Datalink service RESOURCE-s." Or so.

• See previous comment -- StephaneErard - 2022-03-23

(x) p. 26 -- I'd drop everything in the bib_reference paragraph after "A generic regular expression" on grounds that implementors of the standard probably have not much use for that, and ADS may find reason to change that pattern sooner or later -- we don't want to have to issue an erratum just for that. Instead, I'd say "References are best provided as bibcode\footnote{\url{http://adsabs.github.io/help/actions/bibcode}}, DOI, or arXiv identifier\footnote{\url{https://arxiv.org/help/arxiv_identifier}}, although other forms are acceptable."

• Done -- StephaneErard - 2022-03-23

(y) p. 26 To avoid a semi-recursive definition, I'd say publisher should be defined as "Specifies the operator of the data service, which may be different from the origin or the data."

• rephrased -- StephaneErard - 2022-03-23

(z) p. 28 "The same sources are used for the declaration file in the registry." -- what do you want to convey there? Is it something like "Values given here should also be given in the subject keywords of the service's registry record"?

• Done -- StephaneErard - 2022-03-23

(aa) p. 30 target_time says "Values in ISO 8601 format.", which you can't, because you're giving a SQL table schema. You could say "target_time is given as a TIMESTAMP", but before you do that: is there really a strong case why this can't use JD as well? You see, ADQL even in 2.1 will have virtually no functions for doing arithmetic with timestamps, so that there isn't even a standard way to say "target_time within a day of some event I get from somewhere else in the database" (you can say "target_time between '2021-10-20' and '2021-10-31'" or so, but that only works because you're writing the literals yourself). So, I claim you'd be doing everyone a favour if you used JD here, too.

• OK for timestamp. About JD: this is intended to be compared with other target_time only; in case it is needed, it can be converted to JD for arithmetics. -- StephaneErard - 2022-03-23

(ab) p. 32 "In this case, the target_distance_min/max parameters can provide distances..." -- there's a TBC left over here, but more importantly: I'm really against making the meaning of some column dependent on the presence of other columns. That's really asking for trouble (full disclosure: it's also a nightmare in implementation -- how should I come up with the description of the target_distance columns with such a regulation?)

• this was obsolete, removed -- StephaneErard - 2022-03-23

(ac) p. 33 the dynamical_class, dynamical_type, and taxonomy_code columns seem a bit unfinished and/or underspecified. Perhaps you ought to take them out of the current spec and let them mature outside of the REC? This would also save a Wiki reference, which in my view would be a big win. Also in the solar system objects extension, there's the reference ot the orbital parameters Wiki page with a simple "see"; I'd be a lot more relaxed if the spec said just what exactly implementors should see this page for: normative definitions (yieech!)? friendly advice? a discussion of possible problems?

• (TBC in a coming merge request) - as suggested elsewhere, we're considering moving the Extension section out of the this doc (also valid for next comments) -- StephaneErard - 2022-03-23

• Extensions are now handled outside this REC, links are provided on a web page with a permanent ID. This also points to vocabularies related to EPN-TAP, where possible values are maintained -- StephaneErard - 2022-07-05

(ad) p. 34 "map_height, map_width" -- the description here seems overly terse, and I cannot say I could confidently interpret the "/WCS" there. Is it supposed to mean "in world coordinates"? Since that would make the metadata a lot more complicated (and there's pixelscale, too), I'd say this should simply be "These parameters give the number of pixels along the two axes of a raster map. This specification does not constrain the orientation of such maps, and hence 'width' and 'height' do not correspond to physical directions."

• Remaining typo, corrected (that referred to the OGC protocol WCS) -- StephaneErard - 2022-03-23

(ae) p. 33 Section 2.3.4 "Contributive Works" again seems to be in a shape not yet ready for REC (starting with a missing explanation of PVOL). Perhaps this could mature outside of this REC, too?

• updated (TBC in a coming merge request) -- StephaneErard - 2022-03-23

• Extensions are now handled outside this doc, on a web page with a permanent ID providing links to extensions. The parameters listed in the REC are part of the standard, additional parameters can be added in these pages without impacting the REC -- StephaneErard - 2022-07-05

(af) p. 34 "For dimensionless data (e.g., reflectance), units="" (VOunit standard)" -- I'd leave that out, as it is quite a bit beyond the purview of EPN-TAP. Leave this kind of thing to the SDM.

• (TBC in a coming merge request) -- StephaneErard - 2022-03-23

• removed and deported on Extension page -- StephaneErard - 2022-07-05

(ag) p. 34 "producer_name, producer_institute provide reference to who measured the sample (from Contributive Workds extension)". Well: Contributive works declares the two columns als "from other extensions", so it's a bit of an empty reference. But since I'd drop CW for now, why not just say "Name(s) and Affiliation(s) of the person(s) that created the data as free text" (or be specific and require a single name and a controlled affiliation if you want to make that searchable).

• nice pick, corrected -- StephaneErard - 2022-03-23

(ah) p. 34 "this is in practice the only way to ensure that we get all results" -- for me, that is a bit inappropriate for a spec (who is the "we"?). Moreover, if you make this hash-separated, you should probably recommend the use of ivo_hashlist_has rather than trying hand-crafted patterns, as these are not easy to get right.

• Removed. Again, a leftover from the brainstorming phase -- StephaneErard - 2022-03-23

(ai) p. 34 Is there a reference for "Dana or Struntz classification tags"?

• references added -- StephaneErard - 2022-03-23

(aj) p. 34 "Minor/trace components are not welcome here (would multiply false alarms)." -- again, that's not really spec language. It'll look much better if it says "To reduce the likelihood of false positives, minor and trace components should not be included in sample_classification". Oh, and an example for how values in that column should look like would be really welcome.

• OK, + example added -- StephaneErard - 2022-03-23

(ak) p. 34 "see if we define a code for", "see if negative values of angles can have a" -- please remove these clearly internal annotations; you could perhaps get away with "negative values are reserved for now". Incidentally, floating-point values have NaN, which mostly works fine for NULL or N/A.

• removed -- StephaneErard - 2022-03-23

(al) p. 35 "free string or hash-separated list" in several places -- that phrase, which appears here multiple times, does not make a lot of sense. On the one end, hash-separated lists are a subset of free strings, so from a provider perspective you're not granting additional rights. But you don't buy anything for consumers, either, as they cannot query under the assumption that there are items separated by hashes in there. I'd say: Just make it "free text" and don't pretend people can do more than free text searches in there.

• (TBC in a coming merge request, but yes, this is undecided for now ) -- StephaneErard - 2022-03-23

• removed -- StephaneErard - 2022-07-05

(am) p. 36, "species is also available, see if usage is desirable (absence of a species..." -- again, this sort of stage directions should go from the REC, as should, I think, everything after "Special cases to handle" in the section.

• removed -- StephaneErard - 2022-03-23

(an) p. 37 APIS extension: Either pull the material from the Wiki page into the spec or take out the APIS section from 2.0 to let it mature outside of the REC; we don't want normative material on IVOA-external wiki pages.

• (TBC in a coming merge request) -- StephaneErard - 2022-03-23

• Now linked from extension page -- StephaneErard - 2022-07-05

(ao) p. 37 "The following parameters are proposed to handle VOevents (will comply to a future standard when ready)" is again not really appropriate language for a standard. If you want to keep the extension (rather than letting it mature outside of the REC), then this should probably be something like "VOEvents \citep{2006ivoa.spec.1101S} can be archived in EPN-TAP tables. The following extra parameters are available to complete their metadata:" or so.

• OK -- StephaneErard - 2022-03-23

(ap) p. 38 "instrument_host_name, instrument_name are expected to be “simulation”... " -- this will be less shocking if you start the sentence with "For VOEvents that are actually predictions, use...".

• Done -- StephaneErard - 2022-03-23

(ar) p. 45: "c1: only body and celestial are angular;" ummm: why not spherical?

• in spherical coordinates, c1 is the radius -- StephaneErard - 2022-03-23

(as) In terms of style, I'd prefer if there were commas throughout after "e.g.", and in the few places where that's still an issue, "The data provider must select the type most adapted to his data." would be re-written as "Data providers must select the type most adapted to their data." or so.

• agreed, done -- StephaneErard - 2022-03-23

-- MarkusDemleitner - 2021-11-11

---

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

EPN-TAP is an example of fruitful collaboration that brought a standard from a research community into the IVOA architecture to formalise it. The document starts as a 2.0 version in the IVOA because the former major version was built and used already outside the IVOA community.
The document has taken into account all comments and has been re-shaped to answer them. Also, the EPN-TAP specification path has seen many mutually fruitful connections to other IVOA standards, especially in the Semantics area.
TCG coordination is happy to approve this PR and bring it to Exec for final evaluation.

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.

• (see also answers to Markus (a) )

  • "Keyword" only reamins in target_description, where it refers to keywords from external catalogues (eg, HST)
    clarified parameter = table column in the introduction and start of section 2
    "Parameter name" used in table header as suggested -- StephaneErard - 2022-03-23

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

Rephrased -- StephaneErard - 2022-03-23

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

Done -- StephaneErard - 2022-03-23

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

Rephrased -- StephaneErard - 2022-03-23

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

Rephrased (strings only) -- StephaneErard - 2022-03-23

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

Pretty quotes - I've no idea how to avoid them, even taking inspiration from other docs Examples now use actual services, and have been checked : iks, spectro_asteroids, vvex -- StephaneErard - 2022-03-23

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

v1 is now mentioned in Appendix -- StephaneErard - 2022-03-23

-- TomDonaldson - 2021-11-02

Data Access Layer Working Group

The EPNTAP standard is comprehensive and well presented. Its value to the solar system community is obvious given its strong uptake already. However sections 2.3.2 and 2.3.5 are incomplete and not suitable for a REC at this stage. These sections need to be completed or postponed to a later version before we could approve it.

§1.1

• Granule and parameter should be bolded, or preferably dot points when first introduced as they are key concepts. I share others concerns that the column or field would be more precise and more common usage than parameter
• ¶5 The two levels described are unclear - these would be better as dot points or enumerated
• PDS needs to be defined

• All done -- StephaneErard - 2022-03-23

• ¶7 Section 4 should be mentioned

• Added in introduction - this section is about the dictionary, section 4 is mentioned in 1.2 -- StephaneErard - 2022-03-23

• ObsCore standard should be cited

• Added -- StephaneErard - 2022-03-23

§2

• Sub-sections of §2 have inconsistent capitalisation

• Fixed -- StephaneErard - 2022-03-23

• When parameter names are referred to in the text it would be useful to have them italicised, as is done in ObsCore.

• TBC -- StephaneErard - 2022-03-23

• Is the comment about this section being generated relevant anymore? What about the "To ignore the following section" that appears before many sections?

• No idea, but those are unimportant comments in the latex file - won't be seen by readers -- StephaneErard - 2022-03-23

• General, in earlier sections multiple parameters which are described as one (e.g. c1, c2, c3) are listed in separate paragraphs with the earlier ones missing descriptions, but in later sections they are provided as a comma separated list in the one paragraph (e.g. map_height, map_width) - it would be better to have a single convention. I find the comma separated list less confusing

• Agreed, but using a single line is not practical when the min/max option is used. Instead, we reduced the vertical space between parameter names -- StephaneErard - 2022-03-23

§2.1.1

• Granule_uid - in §2.2.2 internal_reference, there is a statement that granule_uids can never contain the # character. That statement should reflected in this section too.

• Done, here and section 1 -- StephaneErard - 2022-03-23

§2.1.2

• Should the dataproduct_type values/IDs be a vocabulary?

• Working on it -- StephaneErard - 2022-03-23

• The processing_level table should have a table number and be referred to from the processing_level paragraphs
• PSA and PDS4 are not defined

• Both added -- StephaneErard - 2022-03-23

§2.1.4

• c3 (min/max) Example - should c1max be c1_max etc? The _min and _max suffixes are introduced in section 1.2 and should be consistently used throughout the standard. If this cannot be done then this section should mention this exception.

• This is inherited from an older version and difficult to change. Exception added -- StephaneErard - 2022-03-23

• spatial_frame_type - cartesian - "This includes spatial coordinates given in km" Includes implies that there are other values accepted. If so then they should be listed, if not then reword as "Spatial coordinates given in km"

• Corrected -- StephaneErard - 2022-03-23

• incidence (min/max) - does ellipsoid model need to be defined?

• There are indeed several ways to provide illumination angles, either from ellipsoid normal, from centre direction or from the local surface. This is expected to be related to the coord frame in use, but we keep it flexible since this is only a search parameters (accurate values are expected to be located in data files). -- StephaneErard - 2022-03-23

• phase (min/max) - phase may range from -180 to 180 but the formula given shows a lower bound of |incidence - emergence| which would imply it must be positive.

• Clarified in the formula. Negative values are discussed in this § -- StephaneErard - 2022-03-23

§2.1.5

• instrument_name - The example is given in all upper case - does this parameter need to have a statement about case usage?

• Case is a tricky matter here. This will be discussed in the mentioned vocabulary. -- StephaneErard - 2022-03-23

§2.2

• It might be helpful to have a statement about what optional means in this sense - can publishers not include the fields in their table, or must they be present but may be empty?

• Added here, but this is mentioned several times in the text (the columns are optional) -- StephaneErard - 2022-03-23

§2.2.1

• file_name - does file_name need to be unique for the FGI to work?

• I don't know what a FGI is, but file_name doesn't need to be unique in the table - it is however a single value, as in access_url. -- StephaneErard - 2022-03-23

• access_md5 - The (link to a real file) seems redundant

• Fixed -- StephaneErard - 2022-03-23

§2.2.4

• solar_longitude - is northern winter solstice -90 or 270 degrees? It is currently shown as +90

• Fixed, thanks -- StephaneErard - 2022-03-23

§2.3.2

• This section has a lot of editorial comments, TBCs etc - it is not in a REC-suitable state - it needs to be either removed for a later revision or completed

• (All extensions will be moved outside of this doc, on a page with a doi. Text clarified according to comments, anyway) -- StephaneErard - 2022-03-23

• Extensions are now handled outside this REC, links are provided on a web page with a permanent ID - therefore all TBCs are removed. StephaneErard - 2022-07-08

§2.3.5

• This section has a lot of editorial comments, TBCs etc - it is not in a REC-suitable state - it needs to be either removed for a later revision or completed

• Same thing -- StephaneErard - 2022-03-23

• spectrum_type - the wording is awkward. I read "this page" to be referring to the document until I got to the end of the sentence. Suggest something like "A list of possible values is provided on the Lab spectroscopy extension[1] page, together with corresponding UCDs (which appear both under measurement_type and in the data files).

• Discussion clarified, but this will be moved outside this doc -- StephaneErard - 2022-03-23

§2.3.7

• What does "will comply with a future standard when ready" mean? Is there anything not supported by VOEvent v2.0?

• Fixed -- StephaneErard - 2022-03-23

• event_type: Where will the list of values be maintained?

• (to be moved to a reference page) -- StephaneErard - 2022-03-23

§2.3.8

• Where will these other extensions be maintained? How will they be published? How would a provider know they exist?

• Extensions will be maintained outside this doc with a doi / landing page linked in this doc - similar to vocabularies -- StephaneErard - 2022-03-23

§3

• The UCD pos.projection doesn't appear to be in UCDList 1.1 - is it intended to be a new one?

• This has been requested in June 2021 -- StephaneErard - 2022-03-23

• The order of parameters later in the table doesn't match the order they are presented in the text

• TBC -- StephaneErard - 2022-03-23

• Should better match now -- StephaneErard - 2022-07-08

§4.1

• Is the text "(from center)"? in the c3min and c3max rows of the body column intended

• Fixed -- StephaneErard - 2022-03-23

-- JamesDempsey - 2021-12-16

Thanks for the fixes - it all looks good now.

-- JamesDempsey - 2022-08-08

Data Model Working Group

• The use of the term “parameter” is confusing (at least to me) in the document (this has been already raised by others but I have to agree). In general, we are making use of the e.g. column or field term to talk about the metadata and we reserve "parameter" for the query interface. I do not know how complex could be to do a substitution but it could help to use a more common term.

• See comments from Markus, (a) -- StephaneErard - 2022-03-24

• Role within architecture image is not in the preamble as in most (all?) of the IVOA documents and EPNTAP does not appear

• Figure completed -- StephaneErard - 2022-03-24

• About the terms dataset and data product, I do not see a problem of the term "granule" to be more agnostic but I miss more connections to the PDS data model as many of the planetary data I know is in PDS3/PDS4 format. It is nice to see that a table was added to do the comparison for the processing level but I miss more translations (whenever possible) to other metadata fields. That would be very useful for data providers to map their metadata with the EPN-TAP one

• There is an PDS4 dictionary for EPN-TAP, but this is beyond this doc. PDS3 usage is extremely variable between datasets, so we don't attempt to provide a correspondance that would be misleading. -- StephaneErard - 2022-03-24

• Close to the previous point, it would be nice to see the level of integration with NASA services and planetary data analysis tools. Which is the state at this point?

• This is hardly the place to discuss this. This is an on-going IPDA action, not IVOA. The PSA however has an EPN-TAP interface -- StephaneErard - 2022-03-24

• Section 1.3 -> UCD reference has not properly generated

• I think the message is about the figure in the autopreview -- StephaneErard - 2022-03-24

• In the example SELECT * FROM pipo.epn_core WHERE dataproduct_type LIKE ’%im%’: Why is needed the like and not use the exact =? It is not clear to me if the value is exactly “im” or “image”. If it is the first case the equals could be better for performance. If it is the second, the queries for LIKE `%sp%` are ambigous (I imagine it is the first option)

• This may be a hash list, so = should never be used, as it can miss some data. dataproduct_type are encoded on 2 characters-- StephaneErard - 2022-03-24

• Processing level table is overflowing the page and without a title/reference

• Don't know how to fix overflow; table # added -- StephaneErard - 2022-03-24

• In this table, I would remove the question mark for "2?". If this is the decission, the standard must be assertive

• Fixed -- StephaneErard - 2022-03-24

• In section target_name, the freedom of having different formats of the target name (e.g. "(1) Ceres" or "Ceres") makes the system more complex (not sure if the use of the LIKE operator ‘%name%’ could produce false possitives due to substring matches. If the client is going to use a name resolver like quaero providing the main IAU name, it could be simpler to ask servers to have this main identifier (I imagine there is a lot of historical background behind to allow a more flexible approach but it is a good opportunity to change this ambiguity during the standardization).
• The resolving on the server could be more complex but feasible with the introduction of an ADQL name resolver function (e.g target_name(string) that provides the main identifier) that makes use of another service behind (this was tested in astronomy to allow ADQL queries by target name calling behind SIMBAD). In summary, I think that only allowing a main IAU id on the queries could make things simpler (and it is not so complex to create this synthetic column at the server side with the main identifier)

• Concerning names: "(1) Ceres" is not allowed (but the example supports this), either "1" or "Ceres" are.
The suggestion is not practical, as the "main IAU ID" of small bodies change on a regular basis. We can't ask data providers (or servers) to continuously update the data content.
This is a very classic issue in this context, we think the proposed solution is the most flexible one: an optimized client (the VESPA portal) uses quaero on target_name, and alt_target_name provides all known designations when publishing the service - which would help other TAP clients. -- StephaneErard - 2022-03-24

• Section target_class: not clear to me what to put for the mentioned planetary_rings. Null?

• Clarified in both places -- StephaneErard - 2022-03-24

• Time(min/max): Just an opinion on this but in the example
• select * from pipo.epn_core where time_min > ’2455197.5’ and time_max < ’2455927.5’
• the example is a "contains" although, in my view, for discovery it could be better to write an overlaps:
• select * from pipo.epn_core where time_min < ’2455927.5’ and time_max > ’2455197.5’

• Yes - this is only an example. Both queries are meaningful, and available from the VESPA portal to search on ranges -- StephaneErard - 2022-03-24

• spectral_range conversions I would change c*E6 by c*1E6 as this notation looks misleading to me

• Done -- StephaneErard - 2022-03-24

• spectral_sampling_step conversions
• If operator * is used for multiplication I would substitute:
• c*1E6 dlam by c*1E6 * dlam (Same for the other conversions)

• Done (but still in progress) -- StephaneErard - 2022-03-24

• Edited entirely for readibility -- StephaneErard - 2022-07-05

• c1, c2, c3 Something that puzzles me is why for these parameters the min and max are not appearing on the field name with underscores (c1_min and not c1min). It is always like this in all the standard (so it is consistent) but it is not consistent with the rest of fields

• This is now clearly specified -- StephaneErard - 2022-03-24

• spatial_frame_type: I would modify the sentence on the “none” or “body” by default. If the default value is “none” the body value for all services could be just a page note (e.g. Old services have the body value as a default value but that could be deprecated at certain point) but it should not be in the text as a valid value because this could produce that the discrepancy is maintained in the future

• Rephrased, that was obsolete -- StephaneErard - 2022-03-24

• s_region: I understand that different geometries are allowed for this value. However, it is not clear to me which system do the conversion: server or client? An explanation on how to handle conversions could be needed to facilitate implementations. Also, I would like to know how this service could be affected with ADQL 2.1 where the reference frame is dissapearing from the geometrical operator. I think a comment on this could be quite useful for future implementors

• The new implementation note should cover the first point. -- StephaneErard - 2022-03-24

• 2.3.2 First paragraph. Remove TBC for the standard version. If this is the decision (although it could be accepted that it is not a perfect one) the standard should be assertive. That applies also to other TBCs into the text

• Removed (remaining one later, but section 2.3 will probably go outside; next comments implemented though) -- StephaneErard - 2022-03-24

• All TBCs removed -- StephaneErard - 2022-07-08

• map_height, map_width. Although it is in the table, I would put the pix units here for these fields

• Done -- StephaneErard - 2022-03-24

• grain_size: Assign the -1 code if needed but I would remove the non-assertive comment

• Done -- StephaneErard - 2022-03-24

• 2.3.6 APIS extension. Acronym used for the first time but not into the acronym section of without a background here

• (section to be removed - but this is explained in the §) -- StephaneErard - 2022-03-24

• acronym added -- StephaneErard - 2022-07-05

• EPNcore Table types: as commented by others, I would use a more standard way to assign data types (e.g. like in ObsLocTAP where the same discussion arised and an agreement was taken)

• (answered by Mark and Markus were mentioned) -- StephaneErard - 2022-03-24

• Some formating problems in the table for some fields like particle_spectral_sampling_step_Flmoaint

• This section will go out of the present doc -- StephaneErard - 2022-03-24

• In the table I would try to prevent the blank empty page 44

• (to be done on final version) -- StephaneErard - 2022-03-24

• Table 2: It looks strange that the spherical c1min/max is in meters when the rest of coordinates express the distances in km. I imagine there are historical reasons behind

• Indeed - this is the usage in these communities -- StephaneErard - 2022-03-24

-- JesusSalgado - 2021-12-10

I am happy with the changes done. DM voted affirmative

-- JesusSalgado - 2022-07-19

Grid & Web Services Working Group

I agree on the fact that the document is well written and clear, I am not an expert of Solar System related studies so I cannot judge the details of the implementation. I agree with the fact that term “parameter” is a bit confusing in this contest. I see that in the document there are still some of the typos/suggestions identified by the other reviewers, as soon as all of them will be implemented/corrected I will approve it.

• I think all this is addressed in other answers, thanks -- StephaneErard - 2022-03-24

-- IVOA.GiulianoTaffoni- 2022-01-22

Registry Working Group

Firstly, the registry-related sections look good to me. Thank you for both the example registry record AND the standard record in GitHub at https://github.com/ivoa-std/EPNTAP/blob/master/epntap.vor , which can be updated when this goes to REC and included in the RofR.

I share several commenters' confusion around the use of 'parameter' referring to column information. I can see how changing it throughout the text might be a hardship at this point, but more clarification within in the document would be appreciated.

• See answer to Markus (a) + this is now discussed in the text -- StephaneErard - 2022-03-24

Pursuant to that, one of the Rules for parameters notes spaces are allowed internally in string parameters. Does this mean column content (I think it does), in which case I am fine with it, or column names, in which case we should note use of underscore as separator? This seems to be one of the areas that could use a little more clarification.

• Internal spaces in values of course. Updated. -- StephaneErard - 2022-03-24

-- TheresaDower - 2021-11-12

Semantics Working Group

(a) p. 19, the planetary reference frames, and p. 28, spatial_coordinate_description: First, we would suggest to concentrate the discussion of frame and origin in one place (presumably 2.2.3) and then refer to that master place from the other place.

• We have to split sections between mandatory and optional parameters (sections 2.1 and 2.2) -- StephaneErard - 2022-03-24

Then, for spatial_coordinate_description, we'd like to suggest that you at least mention http://www.ivoa.net/rdf/refframe (which is where ICRS would come from, I'd say). I give you that we probably should not include all the myriad reference systems on the Earth there (I seem to remember there are about 8000 of those). But frankly, I think exactly because of the large number of systems it would be valuable to have the "recommended" ones in refframe, and I'd be happy to work with you to include the ones already in use in EPN-TAP services. That way, I'd argue there is at least a bit of hope that clients have a chance to know a refframe in use in an EPN-TAP table, and that users know what they can compare against in their positional queries.

• We have our own list which is much larger. No coord system is recommended (only names), this is driven by the data -- StephaneErard - 2022-03-24

It would also be preferable if the SSIG didn't develop an altogether independent practice here, although it seems that your IAU20xx:49900 naming scheme (that I haven't researched) is already established, and that we certainly don't want to try an replate. Still, using refframe as a way to endorse certain frames from there for use in EPN-TAP where possible would, I think, make the whole thing quite a bit less unwieldy.

• This is not from SSIG but from USGS in relation with OGC standards. We want to remain consistent with those. -- StephaneErard - 2022-03-24

Anyway, both refframe and refposition with their hierarchies have plenty of space for solar system frames/refpos-es without clobbering the celestial frames.

I'm also fairly unhappy with having a wiki page referenced in a REC in a relatively central (and probably operationally relevant: I suppose spatial_coordinate_description will be constrained in essentially every positional query?) place. Can we pull that material somewhere more IVOA-controlled?

• this is expected to become a vocabulary, but this has to be defined in details. For body-fixed frames the reference is the IAU WG on coord systems -- StephaneErard - 2022-03-24

• Specific vocabularies are now maintained outside the REC. They are linked from the Extension page which has a Permanent ID -- StephaneErard - 2022-07-05

(b) p. 36 spectrum_type, "A list of possible values is provided on this page..." If you want this to be a normative word list, please turn it into a proper vocabulary. Tell us and we'll do it.

• This is the next step. For now we'll maintain the Extensions out of this doc -- StephaneErard - 2022-03-24

(c) p. 36 "measurement_type provides the type of measurement/scale as a UCD (REFF, I_over_F, etc...)" -- ummm... these are not UCDs, are they? Does this refer to UCDs that should still be created? If so, it would be good to have at least some RFMs in before this goes to REC, and the strings here should correspond to what you ask for there.

• REFF, I_over_F… are standard physical quantities, we got UCD last year for those -- StephaneErard - 2022-03-24

(d) In general, from a semantics perspective we would like to discourage the practice of overloading columns such that they have different UCDs in different "instances" of a model, as it happens here with the ci_* columns. I am fairly sure this will result in a lot of trouble down the road. A UCD is an expression that a column contains things of a certain sort ("elements of the concept"). Now, if you have relations that look as if you could build a union between them (because column names and types match) but really have different interpretations for what's behind the names -- which is what the differing UCDs say in the end --, you are inviting the creation of relations that are not well-defined (because for some of their elements, c1_min, say, means one thing and for others, some other thing).

For EPN-TAP, that ship has sailed a long time ago, so we'll have to see how things work out. For future standards, I'd suggest we try to avoid this. At least in the realm of database tables, I would hope that we are approaching a level of maturity where we can avoid this sort of thing by having multi-table models, and you'd have tables pos_sphere, pos_cyl, etc people can join when they want to do positional searches. But as I said: for EPN-TAP, I'm fine with trying it this way.

• Thanks for support -- StephaneErard - 2022-03-24

-- MarkusDemleitner - 2021-11-11

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
• Thanks - at least most of the epn_core tables at http://voparis-tap-maser.obspm.fr/tap/ are fully compliant as of now. So I'm happy. -- MarkTaylor - 2021-11-09

Radio Astronomy Interest Group

• Late comments from our Interest Group. Not required, but . just in case you find it interesting probably for a next version.
• We have seen a typo in section 2.1.4 column time (min/max) -> "... the location where time is measured must be provided though the time_refposition parameter. " --> through

• Fixed -- StephaneErard - 2022-03-24

• Figure 1 doesn't show EPN-TAP itself (or is it my rendering ?)

• Added -- StephaneErard - 2022-03-24

• in section 2.1.2, the Notes of the processing_level tables claim that the table is a compilation from PSA, PDS4 and ObsCore. Could be useful to say who is what .

• The origin of the parameters is stated in the column names. -- StephaneErard - 2022-03-24

• in section 2.1 for "measurement_type" the "obs.image" UCD value seems inconsistent with the statement "only UCDs related to physical quantities" can be used. The image type is given by dataproduct_type and measurement_type should be a photometric quantity or "counts" or whatever ?

• Thanks. All UCDs were fixed in the doc. -- StephaneErard - 2022-03-24

• In radio astronomy, for radar planetary observations one telescope acts as the transmitter, and another as the receiver, but only one instrument_host_name seems to be available. Is there a solution for that

• This is a list, so both instruments can be included. -- StephaneErard - 2022-03-24

• We imagine that for solar system radioastronomers everything makes sense but for extra SS astronomers the large number of columns may be difficult to catch.
  • There are observations interesting for both SS and extra SS astronomers (it's the same "sky" we share). That"s why some common understanding could be interesting. Specially in the radio domain.
  • The structure of section 2.1 (mandatory parameters) is clear enough. Section 2.2 is less. We wonder if parameters there should not refer to the appropriate 2.1 subsection when it exists. Or alternatively the 2.2 section could be organized in parallel to 2.1
  • At the beginning of 2.3 (extensions) and overal introduction to all these extensions and their rationale could be useful (maybe with a few examples.
  • An UML/VO-DML diagram for the implicit datamodel (one class per subsection in 21) could help clarity in a future version

• TBC (next iteration).
We decided against a UML diagram for this doc. -- StephaneErard - 2022-03-24

• It seems that some colum names ("parameters") are very similar concepts with ObsCore but the name are generally different. I imagine renaming the parameters is something which will be destructive for SS applications. But in the future we couild imagine to use utypes which are currently unused in EpnCore to create more interoperability between ObsTAP/SIA and EPNTAP services. For example :
  • epncore "granule_id" is very close from Obscore "obs_publisher_did"
  • '' "measurement_type" '' "o_ucd"
  • " "processing_level" " "calib_level"
  • " "instrument_host_name" " "facility_name"
  • " "creation_date" " "obs_creation_date"
  • " "release_date" " "obs_release_date"
  • " "publisher" " "publisher_id"
  • " "ra" " "s_ra"
  • " "s_ra" " "s_dec"

• We started EPNCore from ObsCore and PDS parameters, and changed the names when the usage is different or uses a different list of values. Parameters can be mapped, but can't be directly compared. -- StephaneErard - 2022-03-24

• In the future dataproduct_type values should be made consistent with the list in ObsCore. Both should rely on the new definition of dataproduct_type vocabulary adopted by the semantics working group. For ascendant compatibility we should have both the two letter symbols and obscore names as valid nomenclature

• We try to handle this through a common vocabulary, but the logic here is different from ObsCore - this is maybe the only case where we kept the ObsCore name with a different usage, and it illustrates why this is not a good idea. -- StephaneErard - 2022-03-24

-- FrancoisBonnarel - 2021-12-06 -- MarkLacy - 2021-12-10

Solar System Interest Group

I have to take exception to the statement on page 15 that "Any target has a unique target class." This is not true and I've been plagued by it for 30 years. Transitional objects like Chiron and Wilson-Harrington are classed as both "comet" and "asteroid", and will continue to be until there is a more comprehensive taxonomy that can cover the spectrum of small bodies with discrete classes that planetary scientists broadly adopt. How those objects are classed in any particular data context largely seems to depend on the nature of the observation or analysis. In PDS, for example, both classifications are listed for transitional objects in some products but not in others. Similarly, and especially when dealing with legacy data, objects like Pluto and Ceres have multiple classes associated with their names dependent on the era of the observation. It may seem like a trivial point, but a service built on an assumption of uniqueness will make data for these highly interesting objects partially inaccessible by ignoring the multiple classifications applied to them.

On the other hand, I suspect this is a case where "The Perfect" could easily become the enemy of "The Good". So carry on - Postero tempore melius faciemus.

• Target and target class here refer to parameters, not to the essence of these bodies - what it really means is that this pair of values uniquely identifies an object, and both are required to handle homonyms. This was rephrased.
Suggestion for Pluto is asteroid#dwarf_planet, added another comment for transitional objects (asteroid#comet). This is a lesser problem anyway, because you don't have to specify target_class in a query. Quod non malum.
-- StephaneErard - 2022-03-24

While I don't disagree with any of the points raised by other reviewers, I am concerned that the document I am reading now, dated October 2021, will read substantially differently if the majority of suggestions are adopted. That's not necessarily bad, but I would offer to review it again once the changes were made partly as an editing pass, and partly to make sure that what I think I understand now has not changed.

• Altogether, this review hugely improved the text, and helped clarified some touchy aspects. Thanks everybody -- StephaneErard - 2022-03-24

-- AnneRaugh - 2022-01-25

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee

---

Second Round TCG RFC period: 2022-07-08 to 2022-08-01

A second round of comments for TCG members, based on the revised PR-EPN-TAP-2.0-20220705, is proposed here before the TCG vote.

The authors consider that all the comments of the reviewers in the initial RFC period have been addressed in the most recent version (PR-EPNTAP-20220705). TCG members please check that this is the case, and vote to approve if so; concerns that have not been addressed can be noted below.

TCG Vote : 2021-08-01 - 2022-08-11

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

---