Difference: SimpleDALRegExtV12RFC (1 vs. 2)

Revision 22021-03-16 - MarkTaylor

 
META TOPICPARENT name="IvoaTCG"

SimpleDALRegExt1.2 Proposed Recommendation: Request for Comments

The latest version of SimpleDALRegExt 1.2 can be found at:

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 three 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.
  • SSAP services can now declare a productType (sect. 3.3.3). This is to support the growing number of SSAP services publishing time series, but the vocabulary is also intended for re-use in Obscore (from where it comes). Accepting this as REC would also make the vocabulary http://www.ivoa.net/rdf/product-type accepted.
The refframe vocabulary, http://www.ivoa.net/rdf/refframe/, includes a few legacy terms from VOTable COOSYS the intended meaning of which is now uncertain (barycentric, geo_app). We should find some solution for them as part of this review.

Reference Interoperable Implementations

The auxiliary capabilities for the S-Protocols are a consequence of the 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 from discovering data collections simply needed to be mentioned in this spec.

Similarly, using a vocabulary for the reference frames rather than an in-schema list is just intended to cut down on the number of lists of reference frames in 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).

The declaration of product type, on the other hand, has operational consequences; several services in the VO already declare their product type; try

Changed:
<
<
SELECT ivoid, res_title, detail_value



FROM rr.resource



NATURAL JOIN rr.res_detail



WHERE detail_xpath='/capability/productType'
>
>
SELECT ivoid, res_title, detail_value
FROM rr.resource

Added:
>
>
NATURAL JOIN rr.res_detail WHERE detail_xpath='/capability/productType'
 on a RegTAP service. On the client side, version 3.15_3 (beta) of the spectral analysis programme SPLAT uses this to let users select time series services (as opposed to spectral services).

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

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



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

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Operations

Changed:
<
<
Sec 1:
Some of the external standards referenced are quite old,
e.g. VOResource 1.03. Should these be updated?

Related: "Unlike with the previously mentioned specifications,
this specification may apply to later versions of the RI and
VOSI standards." I don't really understand that - does it mean
you have to work with e.g. VOResource 1.03 and not later versions?

"relevence"/"relevent" -> "relevance"/"relevant"

Sec 2:
Return of the evil quotes! Reading the HTML version I see e.g.
(cut'n'pasted from the browser):

- the role attribute must be set to ßtd"

- their values should be "GET" and äpplication/x-votable+xml"

Sec 3.1.2:
"canoncical" -> "canonical"

Sec 3.1.3:
"at least on matched record" -> "at least one matched record"

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

Sec 3.3.3:
In the productType Meaning section, it says

"with each element declaring one of http://www.ivoa.net/product-type"

That's the wrong URL, and the text is a bit terse.
Change to something like:

"with each element declaring terms taken from the vocabulary
http://www.ivoa.net/rdf/product-type"?
>
>
Yes, it looks OK. I made a few comments of a mostly trivial nature which Markus addressed. Only one worth recording here:
 
Changed:
<
<
--Notes transcribed from MarkTaylor - 2021-03-12
>
>
  • 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?
Added:
>
>
    • [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        
SSIG        
Theory        
TD        
Changed:
<
<
Ops        
>
>
Ops *      
 
StdProc        

Revision 12021-03-15 - TheresaDower

 
META TOPICPARENT name="IvoaTCG"

SimpleDALRegExt1.2 Proposed Recommendation: Request for Comments

The latest version of SimpleDALRegExt 1.2 can be found at:

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 three 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.
  • SSAP services can now declare a productType (sect. 3.3.3). This is to support the growing number of SSAP services publishing time series, but the vocabulary is also intended for re-use in Obscore (from where it comes). Accepting this as REC would also make the vocabulary http://www.ivoa.net/rdf/product-type accepted.
The refframe vocabulary, http://www.ivoa.net/rdf/refframe/, includes a few legacy terms from VOTable COOSYS the intended meaning of which is now uncertain (barycentric, geo_app). We should find some solution for them as part of this review.

Reference Interoperable Implementations

The auxiliary capabilities for the S-Protocols are a consequence of the 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 from discovering data collections simply needed to be mentioned in this spec.

Similarly, using a vocabulary for the reference frames rather than an in-schema list is just intended to cut down on the number of lists of reference frames in 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).

The declaration of product type, on the other hand, has operational consequences; several services in the VO already declare their product type; try

SELECT ivoid, res_title, detail_value



FROM rr.resource



NATURAL JOIN rr.res_detail



WHERE detail_xpath='/capability/productType'

on a RegTAP service. On the client side, version 3.15_3 (beta) of the spectral analysis programme SPLAT uses this to let users select time series services (as opposed to spectral services).

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

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



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

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Operations

Sec 1:
Some of the external standards referenced are quite old,
e.g. VOResource 1.03. Should these be updated?

Related: "Unlike with the previously mentioned specifications,
this specification may apply to later versions of the RI and
VOSI standards." I don't really understand that - does it mean
you have to work with e.g. VOResource 1.03 and not later versions?

"relevence"/"relevent" -> "relevance"/"relevant"

Sec 2:
Return of the evil quotes! Reading the HTML version I see e.g.
(cut'n'pasted from the browser):

- the role attribute must be set to ßtd"

- their values should be "GET" and äpplication/x-votable+xml"

Sec 3.1.2:
"canoncical" -> "canonical"

Sec 3.1.3:
"at least on matched record" -> "at least one matched record"

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

Sec 3.3.3:
In the productType Meaning section, it says

"with each element declaring one of http://www.ivoa.net/product-type"

That's the wrong URL, and the text is a bit terse.
Change to something like:

"with each element declaring terms taken from the vocabulary
http://www.ivoa.net/rdf/product-type"?

--Notes transcribed from MarkTaylor - 2021-03-12

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        
SSIG        
Theory        
TD        
Ops        
StdProc        
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback