(r6) Discovercoll11RFC < IVOA

IVOA Web>IvoaResReg>Discovercoll11RFC (revision 6) (raw view)~~EditAttach~~
---++ Discovering Data Collections Within Services: Endorsed Note - Request for TCG Comments and Approvals

Document Link: http://ivoa.net/documents/Notes/discovercollections/20161111/

Source Repository: https://volute.g-vo.org/svn/trunk/projects/registry/discovercollections

RFC period: 2017-03-01 through 2017-04-12

---++ Implementations

Several publishing registries (at least GAVO's, HEASARC's, and CADC's) already produce records as defined in this specification. Also, the future Registry Interfaces 1.1 (also in RFC) intends to employ the method proposed here.

On the client side, WIRR implements discovery of data collections in this way -- [[http://dc.zah.uni-heidelberg.de/wirr/q/ui/fixed?field0=capid&operator0=%3D&operand0=ivo%3A%2F%2Fivoa.net%2Fstd%2Ftap%25&field1=textfields&operator1=%3D&operand1=ucac4&MAXREC=20&OFFSET=0][sample query]].

Also, TOPCAT has experimented with this scheme since several releases. At ftp://andromeda.star.bris.ac.uk/pub/star/topcat/pre/topcat-full.jar, you'll find it in the TAP window (TAP -&gt; Service Discovery -&gt; Reg Prototype). If your TAP service isn't shown with the right number of tables there, please consider fixing your service's registry interface.

---++ Comments from the interested public

---++ Comments from TCG members

WG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.

---+++ TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler_ )

---+++ Applications Working Group ( _Pierre Fernique, Tom Donaldson_ )

I have to thanks the authors of this note to bring a solution to a serious problem in the orginal design of VO registry. I have to say that elements presented in this note would have help a lot in the implementation of Aladin v10 which had to do, in some cases fragile assumption (based on prefix url...), and in some other cases, has no solution at all. If this note is followed by the providers, my client developper life will be definitively easier. Also, I appreciate a lot that the solution proposed has concretely a very light impact on the existing content of the registry. I will clearly encourage all providers to follow this note as fast as possible in order to improve the quality and the usability of the VO registry content.

*I approve this note*

Some minor suggestions:<br /><br />* Page 6: The detal of the rational for standardID suffix syntax is probably not really required in this note. or ?<br /><br />* Page 9 : the specific citation of VizieR current state for illustrating the impact of the addition of aux. will be obsoleted when VizieR will applied the note recommendation. I would suggest to remove VizieR citation, and just evocate "a service"...<br /><br />* page 11: The reference http://gavo... for WIRR is a little bit obscured for me. <br /><br />* Page 15: typo: Removed secion on =&gt; section

---+++ Data Access Layer Working Group ( _François Bonnarel, Marco Molinaro_ )

 The problem  tackled by this note is real and the proposed solution looks smart and working. We strongly support this proposal for recommendation.


        However, a few remarks could be taken into account by the authors:


            page 3 : introduction


                   - It should be nice to describe the "reverse case" where a collection is served by several services (eg : non Standard interface, ConeSearch, TAP and HiPs for a catalogue)

                   - It's better to use the word ObsTAP instead of ObsCore: Obscore is the model but the ObsCore spec explicity designates TAP services serving ObsCore tables as "ObsTAP".


            page 5 / 2.1 The statement "either one of main or auxiliary capabilities" : does that mean inclusive or ?

            page 6 = the sentence "This note  proposes to mark the auxiliary ...." expresses the main modification proposed by the note. It could be usefully repeated in a new short section just after 2.1 called "Implication for standardID expression" to clarify the actual modification (all the other stuff being "good practice actually"


             page 9 : sentence "In order to offer an immediate solution for the outlined problem... ".  We propose  "In order to offer a solution for legacy identifiers" we propose to form auxiliary identifiers for them...

                   ----> because it seems to be something which may last a while...

-- IVOA.FrancoisBonnarel - 2017-11-09

-- IVOA.MarcoMolinaro - 2017-11-09


---+++ Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel_ )

a bit out of my area of expertise, but the content seems consistent and logical. This does seem like content where we should be giving a 'preferred' method and guidance to implement.

I had one question in reading the text, which does not effect the assessment, merely a curiosity. Section 2.1.2 specifically states that an ID of form "ivo://ivoa.net/std/sia#query-aux-2.0" generates queries for all minor versions as well (tag-n.%). My question is what happens for ID with a specified minor version "ivo://ivoa.net/std/sia#query-aux-2.2"? If this returns exact match only, how does one get exact match for '2.0'? It seems that the minor version is irrelevant in this thread, given the backward compatibility requirements.

   * No, the query-aux-2.0 is not the query pattern ignoring the minor version, it is the full identifier that lets people match for minor versions if they have to for some reason. The actual query patterns are discussed in sect. 2.2. Any hints on how to make that clearer are appreciated -- IVOA.MarkusDemleitner - 2017-09-13
typos in section 2.1.4: 2 instances of 'notherntel' rather than 'northerntel', and 1 instance of 'sourtherntel' rather than 'southerntel'

   * Fixed, thanks -- IVOA.MarkusDemleitner - 2017-09-13
I have no objection to the content and approve the Note. -- IVOA.MarkCresitelloDittmar - 2017-09-11
---+++ Grid & Web Services Working Group ( _Brian Major, Giuliano Taffoni_ )

---+++ Registry Working Group ( _Markus Demleitner, Theresa Dower_ )

---+++ Semantics Working Group ( _Mireille Louys, Alberto Accomazzi_ )

---+++ Education Interest Group ( _Massimo Ramella, Sudhanshu Barway_ )

---+++ Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick_ )

---+++ Data Curation & Preservation Interest Group ( _Françoise Genova_ )

---+++ Operations Interest Group ( _Tom !McGlynn, Mark Taylor_ )

---+++ Knowledge Discovery in Databases Interest Group ( _Kai Polsterer_ )

---+++ Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo_ )

---+++ Standards and Processes Committee ( _Françoise Genova_)

<br /> <!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
Topic revision: r6 - 2017-11-09 - FrancoisBonnarel
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema