SimpleDALRegExt1.2 Proposed Recommendation: Request for Comments

The latest version of SimpleDALRegExt 1.2 can be found at:

• https://ivoa.net/documents/SimpleDALRegExt/20211004/

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

Summary

SimpleDALRegExt defines a group of registry extensions for describing related "Simple" DAL services: Cone, Image, Spectra, etc. Occasional tweaks to vocabularies and incremental changes to the services' own standards are tracked here to keep potential registry search results in line with actual service capabilities, and to show connections between resources in new ways: in this case, adding auxiliary capability descriptions (see below.)

Changes since 1.1

Most of the document is unmodified. Some vocabulary cruft has been removed and tested with searches across all current registries to assure backward compatibility.

There are two changes which should be reviewed:

• Section 4, the auxiliary capabilities. Introducing these has been the original motivation for building SRE 1.2.
• SSAP services can declare which reference frames they support in POS. So far, there has been a list of those in the schema. We now point to a vocabulary developed in the run-up to MCT, http://www.ivoa.net/rdf/refframe/. Accepting this as REC would also make this vocabulary accepted.

Reference Interoperable Implementations

TCG has determined reference implementations for this standard are irrelevant, or in the case of auxiliary capabilities, satisfied with example records as listed below.

The auxiliary capabilities listed are a consequence of the already Endorsed Note on Discovering Data Collections. Compared to TAP auxiliary capabilities, they have not been used much yet (there are ivo://org.gavo.dc/lensunion/q/im and ivo://org.gavo.dc/hppunion/q/im, though). Hence, to our knowledge there is no client takeup of them. Consider this change editorial in nature; the standards identifiers as taken from Discovering Data Collections simply needed to be mentioned in this spec.

Similarly, using a vocabulary for the reference frames rather than listing it within this document decreases the number of lists of reference frames scattered across the various standards. It has no operational implications (even less so since to date few services or clients actually offer different reference systems in SSAP queries).

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

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)

---

---

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

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

This revision of SimpleDALRegExt (v1.2) is a minor one, introducing auxiliary capabilities to align simple protocols with the Discovery in Data Collections Endorsed Note and taking advantage of a vocabulary of reference frames for the positional filtering parameters.

Is also fixes minor discrepancies and typos.

Approved. -- JanetEvans, MarcoMolinaro - 2022-02-17

Applications Working Group

Approved. These changes seem straightforward and likely to improve the data discovery experience. I have no significant concerns from an Application perspective.

-- TomDonaldson - 2021-10-25

Data Access Layer Working Group

Approved

-- JamesDempsey - 2021-11-30

Data Model Working Group

Just a few comments

• Introduction: bullet list: SIA: clarify that the document applied to both SIA1 and 2 because those 2 versions are very differents to each other
  • Added some text to this effect, but stressing that a future SIAv2 registry extension (that would come with the document) should be preferred. -- MarkusDemleitner - 2021-12-02
• Next paragraph (take it as a comment and add it if you agree) : their power of data discovery..... : I would add that this power also comes from the fact that S*P query responses have all the same structure (at least for the core), thus the same query can be send to different services AND the same code can parse responses from different query/services
  • I've put in a bit of language to this effect. -- MarkusDemleitner - 2021-12-02
• Next paragraph: I really appreciate the effort to explain how different standards nested to build the registry. This is (for me) the most difficult part of the OV landscape and any effort to clarify it is welcome.
• Same remark for the last paragraph of the introduction
• Section 2 page 8: the note in the top of the page looks like a requirement with (...authors should, ...., not include...). Why putting this statement in a note and not including it in the text.

approved

• • Well, it's in effect an implementation note, warning against a pitfall resulting from a formerly common mis-application of the standards. What's normative in that admonition is mentioned in the running text. Outlawing additional vs:ParamHTTP interfaces, on the other hand, would require a lot more thought (that, I think, would end in not outlawing them). -- MarkusDemleitner - 2021-12-02

-- LaurentMichel - 2021-12-01

The changes mentioned are in volute rev. 6062 -- MarkusDemleitner - 2021-12-02

Grid & Web Services Working Group

Approved. I have no significant concerns from the GWS perspective.

-- GiulianoTaffoni - 2022-01-10

Registry Working Group

Approved with product type removed and backward-compatibility checked. The refframe vocabulary itself looks good to me based on work with institutional holdings, further comments from astronomers and engineers with a wider background welcome.

-- TheresaDower - 2021-11-11

Semantics Working Group

This document points to two vocabularies : product type (https://www.ivoa.net/rdf/product-type/2020-03-09/product-type.html) and refframe (http://www.ivoa.net/rdf/refframe), which are still not approved. This can't go forward until refframe and product-type are fixed.

• Right. Product type will be a topic at the Spring 2021 interop. Refframe... well, I'd be happy if someone else felt responsible for it. But yes, at least as long no other standard takes up refframe and gets it approved, this RFC is about refframe, too, and this can't go on unless we figure out what to do with the ancient VOTable terms. -- MarkusDemleitner - 2021-05-06
• Update on this: The Refframes are, I think, ok, though it sucks a bit that we really don't know what geo_app was supposed to mean. The product type thing has been removed from the current spec (and I believe now that this ought to be handled on the level of VOResource itself). -- MarkusDemleitner - 2022-01-25

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Radioastronomy Interest Group

These comments are probably coming too late and anyway IG approvals is only optional. So just look at that if you find this interesting. I only have a few remarks

• ConeSearch : 3.1.4 catalog element has this comment "When the service can access more than one catalog, this input parameter, if available, is used to indicate which service to access." The second service should be replaced by "cataog" i think.
  • Yes, that's been a typo that almost went undiscovered through two revisions. Thanks for catching it finally. -- MarkusDemleitner - 2022-01-31
• my comments for SIA. Radioastronomy projects are great consumers of SIA2. Some features there only apply to SIA1.0 because there are a lot of differences between the two versions
  • 3.2.3 : SimpleImageAccess imageServiceType. this actually doesn't exist for SIA2. And the element is required. 3 possibilities : A) add a sentence telling it's not required for version 2 B) recommand to use only atlas in case of version 2 - because full retrieval is the only direct possibility in sia2 and is very similar to atlas. C ) add two other modes for SIA2 = retrieval and datalink. Because DataLink is a standard possibility to access cutout facility from the sia2 query response. Solution B is probably the less disruptive.
    • I'd say most SIAv2 services will probably be Pointed, but admittedly it's conceivable they're Atlas, too. I wouldn't even rule out stretching SIAv2 to Mosaic and Cutout (with some reasonable default area when that's not specified). Hence, while some additional language on SIAv2 here might be nice, I'd say it's not so desirable as to introduce a very late change in the document. In the end, SIAv2, I think, should eventually define its own registry extension. -- MarkusDemleitner - 2022-01-31
  • 3.2.5 testQuery and the Query Type :
    • To transform POS SIZE in SIAV2, RANGE is probably not the most straightforward. CIRCLE would be better. * Perhaps from a practical point of view, but SIAv1 POS/SIZE indeed translates into some sort of coordinate range, at least when the poles are outside of the RoI, which is more like SIAv2's RANGE -- MarkusDemleitner - 2022-01-31
    • It should be made explicit that in case of SIA2, POS SIZE should be absent. POS exists but has a different syntax and datatype. SIZE doesn't exist. So everything should be done with "extras" for SIA2
      • No, I don't think that's necessarily the right way to deal with this. Of course, just writing MAXREC=1 in extras would be sufficient for SIAv2, but it is not unreasonable to encourage validators to turn POS/SIZE into a RANGE for SIAv2. -- MarkusDemleitner - 2022-01-31
  • 3.2.7 RegTAP, imageServiceType (!) : see above for modes

-- FrancoisBonnarel - 2022-01-28

Solar System Interest Group

Approved. One very minor point: On page 19 there is a "Note" that I think is intended to refer to the 'p' on the end of the "ssap" prefix. But the Simple Line Access protocol uses the same prefix convention ("slap"). So it seems like either the "Note" should be repeated for the SLA prefix, or expanded to cover both prefixes ending in 'p', or perhaps this has been a convention for long enough that it no longer requires a special, boxed explanation at all and a simple parenthetical remark (e.g., "(the final 'p' is added to avoid acronym collision)") could address any remaining confusion. -- AnneRaugh - 2022-01-25

• I agree that admonition box isn't very helpful any more; it reflects an ancient discussion related to the abuse of XML namespaces for SSAP utypes. If this were a WD, I'd drop the box and be done with it. However, since this is in very late PR and the box, I think, does not hurt very much, I'd prefer not to touch it (in particular as it's not related to the stated goals of this document version). Let's drop it when we next touch this. -- MarkusDemleitner - 2022-01-31

Theory Interest Group

Time Domain Interest Group

Operations

Yes, it looks OK. I made a few comments of a mostly trivial nature which Markus addressed. Only one worth recording here:

• Sec 3.1.4: I don't understand the business about specifying the catalogue in the test query, since this term doesn't appear in SCS itself. No doubt this is a hangover from some long-standing wrinkles in SCS which we don't want to mess with now, but maybe a couple of words of explanation would be in order?
  • [Markus]: Hm... Frankly, I'm not sure what to write... I'd say if it hasn't bothered anyone so far, we can let it sit until we've worked out how we'd like to do this in the next version of SCS.

-- MarkTaylor - 2021-03-16

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