Discovering Data Collections Within Services: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: http://ivoa.net/documents/Notes/discovercollections/20161111/ Temporary location of document build updated according to the RFC comments below: http://docs.g-vo.org/discovercollections.pdf Source Repository: https://volute.g-vo.org/svn/trunk/projects/registry/discovercollections RFC period: 2017-03-01 through 2017-04-12Implementations | ||||||||
Changed: | ||||||||
< < | 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. | |||||||
> > | 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. Note: see below for caveat on CADC's use of this. | |||||||
On the client side, WIRR implements discovery of data collections in this way -- 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 -> Service Discovery -> 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 publicComments from TCG membersWG 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 ) | ||||||||
Added: | ||||||||
> > | In trying to configure the ivo://cadc.nrc.ca/IRIS data collection with related service relationships and aux capabilities I ran into a problem: the capability child element is not allowed (schema validation exception) and when I looked in the relevant xsd I see that it is only allowed in a resource of type Service. The example A.1 is actually a resource of type CatalogService (extends DataService extends Service) whereas ivo://cadc.nrc.ca/IRIS is a resource of type DataCollection (extends Resource). The end of page 6 covers this issue and promises that VOResource-1.1 will allow capabilities in DataCollection... so at this point I cannot implement aux capablities since we used DataCollection. The recommendation to use CatalogService in place of DataCollection as a stop gap seems to force clients back into service-oriented discovery. I have a feeling we would regret making that recommendation. Is it sensible to put this note on hold until we have VOResource-1.1 and can describe DataCollection resources properly? On a more general note, since DataCollection can have zero or more relationship(s) it looks like a suitably complex join in RegTAP could find DataCollection resources that are servedBy TAP services without the aux capabilities, so it looks like this is a denormalisation of the VOResource model to make it possibly to do this (efficiently) without a join? Is that the essence? -- PatrickDowler - 2018-02-14 | |||||||
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:
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
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.
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)<--
|