P 105 Japanese Virtual Observatory (JVO) :implementation of VO standard protocols
Yuji Shirasaki1, Masahiro Tanaka1, Satoshi Honda1, Satoshi Kawanomoto1,Yoshihiko Mizumoto1, Masatoshi Ohishi1, Naoki
Yasuda2, Yoshifumi Masunaga3, Yasuhide Ishihara4, Jumpei Tsutsumi4, Hiroyuki Nakamoto5, Yuusuke Kobayashi5,
1 NAOJ, 2 U. of Tokyo, 3 Ochanomizu U., 4 Fujitsu Ltd., 5 SEC Ltd.

Abstract

We developed the third prototype toward aJapanese Virtual Observatory (JVO). IVOA
standards, such as Simple Image Access andADQL, were adopted to the system for thefirst time. We also constructed an OAI-PMH
publishing registry, a web service based
searchable registry, and VO data services
based on SIA and SkyNode protocols. Most ofthe components were build by using open
software, except for an XML database usedfor searchable registry.
We present features of the JVO proto 3
system and results of a performancemeasurement.

1. Data Service

We are developing a SkyNode toolkit forbuilding a VO compliant data service. First
primitive version was released this May, and thesecond release is expected in this October.
Fig.1 shows its architecture of JVO Skynode.
The toolkit mainly provides a part of “SkyNodecontroller” where ADQL is converted to the DB
native SQL, and the result is returned in theVOTable format.

3. VO Portal ServiceFig.3 JVO Portal query page

A VO Portal service provides a seamless access tothe distributed astronomical databases. JVO portal
accepts JVO query language (JVOQL) which hassimilar syntax with the VO standard. JVOQL candescribe a cross match query not only for the catalog
services but also for image and spectrum services. Asan example, JVOQL shown in a snap shot image of theright figure describes a query to X-ray, IR, and opticalcatalog services and an optical image service. JVOQL
is divided into queries
for each data service.
Eachqueryistranslated
toVO
standard
query
formats, ADQL, SIAP
and SSAP, according
to the service type.

Fig.4 VOTable viewer

5. Science use case

Fig.5 Image viewer

Fig.6 Spectrum viewer

We applied this VO system to the study ofenvironment of QSOs by combing the QSO
catalog data service and Subaru image dataservice. Since we don’t have a reduced dataarchive yet, raw data of pre-selected five fields
are retrieved from the SMOKA and MASTARS
service operated by NAOJ, and they are
reduced with a standard analysis tool andregistered as a skynode database. The fields are
selected through cross-matching between QSO
database and SuprimeCam frame database. A
workflow for this study is as follows:

Data resources currently available from JVO
are: (1) Subaru Deep field survey catalogs andimages, (2) Subaru SuprimeCam Open Data
Performance are measured to construct
Archive, (3) QSO catalog compiled by Veron etal. and copied from VizieR, (4) SDSS DR2. Etc… robust and reliable data services. EspeciallySIAP
a memory usage is the most critical one toSkyNode & SSAP
SkyNodeMetadata Query
SIAP & SSAP
HTTP
SOAP/HTTP
deal with a huge number of accesses, and it
wasexpected
that,in
ourAXIS
Table
Parameter
Interface to• column1
1. Select QSO coordinates from the QSO database
ADQL
VOTableimplementation, a lot of memory are used for
Query
the VO world• column2• ...
2. Search multi-bands imaging data which covers theXML to Java object deserialization. WeQSO regions
noticed that proto3 is consuming a lot of
3. Create a catalog from the imaging data by invoking aSQL formemory and they
SExtractor Web service.
Converterbackend
DB
4. Estimate the objects’ photoZ around the QSO
are not freed.
5. Clustering Analysis
ResultSet
This is now fixed
Formatter
SkyNode Controller
by making aWe succeeded to federate the catalog andconstraint on theimage data service. By incorporating theA collection of tables actuallyFig.1 JVO SkyNode architecture. memory usage ofqueried.
workflow system that is under development, alleach user and an
the procedure will be done in an automatic way.
active GC.
Fig.7 Memory usage

4. Performance testColumn• name• dataType• unit• UCD• ...

mainTable

mainHTM• dataID• ...

• dataID• htmIndex

regionTable

regionHTM• queryID• regionID
• ra
• dec
• size1• size2• regionExpr• queryID• regionID• htmLow• htmUpp

2. Registry Service

We have constructed a publishing registry
and a searchable registry. The
publishingregistry was made by using a NVO software,and which was slightly modified to adapt therecent VOResource schema. Metadata of data
resources are registered through the web form

Interface, and these data are distributedby the OAI-PMH protocol to the VO.
Searchable registry collects metadata fromthe publishing registry not only of JVO but
also of the other VO projects. A native XML
DB, Karearea® (SEC), is used for managing
the collected metadata.

Our searchable registry alsocollects table matadata fromskynodes. These data are usedfor
resolvingtheservice
endpoint URL from the SQL
table name, and for assisting auser to make a query.

Fig.2 Publishing Registry

The implementedWSinterfaces
enables
akeyword-based
searchandanidentifier-basedsearch.
ADQL
search interface isunder preparation.

Fig.3 Searchable Registry

Out of thefield of viewFig.8 QSO-Galaxies Clustering Search

6. Future Plan
We are now developing an operational systemaiming at an alpha version release in the end of
this physical year (~2006/3). More user friendly
interface for query and data visualization will beprovided in this version. We will start a dataservice of Subaru SuprimeCam reduced imagefrom 2006/4.