1 / 15

VOQL/ADQL/MYDB for VO

T HE US N ATIONAL V IRTUAL O BSERVATORY. VOQL/ADQL/MYDB for VO. William O’Mullane Johns Hopkins University. Virtual Observatory Query Language Layers. VOQL3 SkyXQuery. future XML-based query language.

mali
Download Presentation

VOQL/ADQL/MYDB for VO

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. THE US NATIONAL VIRTUAL OBSERVATORY VOQL/ADQL/MYDB for VO William O’Mullane Johns Hopkins University NVO Team Meeting / Victoria

  2. Virtual Observatory Query Language Layers VOQL3 SkyXQuery future XML-based query language. SQL-like query language and federation system i.e. combination of SkyQuery , JVOQL and VO standards VOQL2 SkyQL Astronomical Data Query Language (ADQL) and VOTABLE to exchange information between machines VOQL1 WebServices NVO Team Meeting / Victoria

  3. Registry IVOA SkyNodes Register Lower level ADQL (including regions) and services to Support VOQL. MetaData LEV1 PerformQuery Tables Columns VOQL SKYQL ADQL ADQL ADQL MetaData LEV2 PerformQuery Tables MetaData Columns LEV4 PerformQuery XMatch MetaData Tables LEV1 PerformQuery Columns Tables XMatch Columns ExecPlan Footprint Architecture later End 2003 Open SkyQuery Portal VOQL Portal Uses only Registry, Lev3 and Lev4 SkyNodes. High Level Language allowing seemingly uniform access to services. MetaData SkyQuery LEV3 SkyQueryWebApp VOQLQuery PerformQuery Tables Columns XMatch ExecPlan Clients May use Services at any level NVO Team Meeting / Victoria

  4. SkyNode Levels NVO Team Meeting / Victoria

  5. SkyQL and ADQL • Same semantics different syntax • ADQL - parse tree easy for SkyNodes • SkyQL – textual easy for humans • ADQl Includes Rots regions, Xmatch,math functions • Simple parser working both ways(demo) ADQLtoSkyQLSkyQLtoADQL NVO Team Meeting / Victoria

  6. MYDB – not in v0.4 • local space for data and results • Like astorgrid mysapce • Requires on node • User Identification • Job tracking/monitoring • Asynchronous execution • CasJobs does all of this (short demo) • http://skyservice.pha.jhu.edu/devel/casjobs • Should we try to do this for OpenSkyQuery now? • What about across nodes… NVO Team Meeting / Victoria

  7. MYDB across Nodes • Need user identification across nodes • Centralize (not nice technically nor politically) • How to integrate with exiting mysapce and MYDB … • Federate ! (IBM/MS Paper ) • Authentication service on each node • User signs up anywhere or uses exisiting id • Accept userids issued by trusted nodes • Authenticate userid with node it is supposed to be from NVO Team Meeting / Victoria

  8. Security with federated Auth. • How secure do we want this? • Should the userid be: • an encrypted token • just a number • Do we copy user info to each node so we can have integrity constarins in our db on USERID NVO Team Meeting / Victoria

  9. MYVOSPACE Next step is an integration service One stop service NVO Team Meeting / Victoria

  10. Current Issues for discussion Since v0.3 NVO Team Meeting / Victoria

  11. Hardcore Levels • Drop Lev3 Skynode • Require Footprint/Region intersect for Skynodes. • Personally – I think we will have nodes without and would rather have a name for them NVO Team Meeting / Victoria

  12. Interface Issue Currently PerformQuery returns VOTable Votable performQuery (ADQL query) M.Hill would like a more general wrapper e.g. IVOAResult performQuery (ADQL query) HereIVOAResult would be abstract or a wrapper containing VOTable or some pointer to a file. Would also allow for putting other things in result (region densities Yasuda San has suggested). NVO Team Meeting / Victoria

  13. Neighbours or XMatch • Xmatch is a probabilistic matching returning all neighbours taking account of errors. • B. Mann suggests we should use lowest common denominator which is Neighbors – this would return all objects within a certain distance of each other not using the errors. NVO Team Meeting / Victoria

  14. Region Specification Issue Have suggested Region,RefionUrl,RegionXml. Region would take simple strings like ‘Circle j200 810 34.2 0.1’ • Rots has another suggestion for Region strings which is comprehensive Is this as complex as just using the XML … NVO Team Meeting / Victoria

  15. A. Rots Region Strings define CSys = (TimeFrame = (TimeScale='TT') and (TimeRefPosition='TELESCOPE')) and (SpaceFrame = (CoordFrame='ICRS') and (CoordRefPosition='TELESCOPE')) and (SpectralFrame = 'OBSERVATORY') and (CoordFlavor = 'SPHERICAL') define CArea = (TimeInterval = (StartTime=(ISOTime='2000-01-01')) and (StopTime=(ISOTime='2002-12-31'))) and (Region = (Circle = (Center='60.0d,30.0d') and +(Radius='10arcmin')) and (SpectraLinterval = (LoLimit='1GHz') and (HiLimit='2GHz')) define CSpec = (Time = (CoordResolution<='10s')) and (Pos2Vector = (CoordResolution<='10arcsec,10arcsec')) and (Spectrum = (CoordResolution<='50MHz')) The query: select <SelectList> from <ResourceList> where <WhereClauses> and SearchLocation = (CoordSystem = $CSys and CoordArea = $CArea NVO Team Meeting / Victoria

More Related