• target_class is defined as being a member of a special vocabulary, either from Simbad, NED, or defined in other IVOA vocabulary. I would either remove the ambiguity by applying a prefix, or better yet mandate that said vocabularies are to be published in SKOS form (as per the IVOA Vocabularies Note), and a reference to them added in a field target_class_vocabulary_url, or similar.
• obs_creator_name should not be creator_id, to maintain a relationship similar to that between obs_publisher_did and publisher_id? If there is a creator other than the publisher, it should have an entry in a VO Registry.
• obs_creator_did is not defined clearly. A discussion appears in SSA, that it should either be referred to, or brought to the ObsTAP document (where I think it makes more sense). Plus, it should be made clear that for publishers who are the same entities creating the data, obs_creator_did and obs_publisher_did can (should?) be the same.
• bib_reference is set with UCD meta.bib, as if it only could contain an ADS bibcode, but some publications might make use of the DOI, more generic than the bibcode. Should DOIs be allowed? Then we would need a new UCD (see list of proposed UCDs to go with ObsTAP).
• obs_release_date: if obs_release_date is NULL, data_rights (if present), must be "proprietary".
• s_ucd is proposed to be either pos, or uv, but no UCD for uv exists. I think it should not be pos, but pos.eq (as we are mandating ICRS coordinates). Instead of UV, I propose to have one of the following:
  • pos.uv (with sub UCDs pos.uv.u and pos.uv.v)
  • pos.eq; arith.fft (adding an arith.fft UCD)
• s_calib_status is said to be one of NOT CALIBRATED, FINE, or COARSE, while for other [te]_calib_status strings are lowercase. Shouldn't this be made so?
• t_resolution can be made NULL. A recommendation was made to set t_resolution to t_exptime for non time-resolved frames. Wouldn't it be better that NULL mean non-time resolved frames, and time-resolved ones had the corresponding t_resolution value?
• t_calib_status has no attached enumeration. I see arguments both to support the same one as in s_calib_status (i.e. not calibrated, fine, or coarse), or to go with the spectral ones (calibrated, uncalibrated, relative, normalized). We should decide, and specify which one.
• em_ucd calls their values from the SSA proposal, but actually one less UCD is recommended from those specified by the SSA Recommendation. I think having arith.log qualifiers for em_ucd would help in the logarithmic cases, and spect.dopplerVeloc; arith.ratio can be used for c based redshift.
• em_res_power should be specified as freq/delta_freq when em_ucd is em.freq, and energy/delta_energy when em_ucd is em.energy.
• o_ucd should not be allowed to be NULL, if present. If it is, for me it means the dataset corresponds to a non-well known observable, and little software could work with it, so why put it in the VO?
• o_units should follow the units proposal (including scaling) proposed by Pedro Osuna et al. in their note on accessing Spectral data using SIAP: http://ivoa.net/Documents/Notes/SADimEq/SpectrumAccess_DimensionalEquation-20040521.pdf
• o_units must be present if any of o_detection_limit or =o_stat_error= are provided.
• facility should be the same as in theVOResource medata for registering facilities, and should also be registered with the ADS: http://vo.ads.harvard.edu/dv/facilities.txt
• instrument should also have a place in the Registry, but possibly this discussion falls outside of ObsTAP.

+ Material to help for implementation (proposed by Igor Chilingarian)

• provide online files of Appendix C (TAP_SCHEMA tables, sql code example for tables initialisation)
• provide online version of some queries exposed in the use-cases and obtained results

+ Some proposals for missing, or alternate UCDs (by JuanDeDiosSantanderVela)

• access.estsize: could be phys.size; meta.file
• s_region: could need a new one to support STC-based footprints, analogous to instr.fov; then, the UCD would be pos; instr.footprint.
• obs_creator_name: could be a new one, meta.id.creator, similar to meta.id.PI, or meta.id.parent. Also, a primary/secondary (Q) meta.creation might be added, and meta.id; meta.creation be used.
• o_ucd: could be meta.ucd; obs.
• s_ucd: could be meta.ucd; pos.
• em_ucd: could be meta.ucd; em.
• data_rights: could be meta.curation; meta.code, or meta.code; meta.curation; however, both are Primary UCDs, which does not allow for the combination.
• em_stat_error: could be stat.error; em.wl instead, as we will always use wavelength.
• obs_title: could be meta.title; obs.
• s_resolution_min: should be pos.angResolution; stat.min.
• s_resolution_max: should be pos.angResolution; stat.max.
• t_calib_status: could be meta.code.status; instr.calib; time.
• facility: could be meta.id; instr.tel.
• instrument: could be meta.id; instr.