Tree view of registry

[Guy Rixon]

Hi,

at

http://ag02.ast.cam.ac.uk/registry/tree

you will find a prototype of a new interface to a full registry: a  
tree view. This web-app treats the IVO identifier as a hierarchical  
space and gives you three main features.

If you know the identifier for a resource you can predict a URL from  
which you can HTTP-get the resource document (knock off the ivo://  
prefix and prepend http://ag02.ast.cam.ac.uk/registry/tree/). If you  
get it with wget or curl or some custom application, then you just  
see the XML. If you use a web browser, a linked-in stylesheet  
displays the resource document so that you can read some of it easily.

If you don't know the identifier you can browse the registry as a  
tree. The first branch is by publishing authority and then the tree  
branches at the slashes in the resource keys. (Although resources  
keys formally have no hierarchy, many publishers use them that way  
and it's sometimes handy to work tree-wise. Try it on the Vizier  
collection; it breaks up the metadata flood quite well.)

If you want just a part of a resource (and if you know the  
identifier) you can use an XPath to extract it, as in these examples:

http://ag02.ast.cam.ac.uk/registry/tree/uk.ac.cam.ast/vospace?xpath=/ 
curation

http://ag02.ast.cam.ac.uk/registry/tree/uk.ac.cam.ast/iphas-dsa- 
catalog/IDR?xpath=/capability[@standardID='ivo://ivoa.net/std/ 
ConeSearch']/interface/accessURL

The first one reads "who looks after the IoA-Cambridge VOSpace?" and  
the second means "what's the cone-search URL for the IPHAS IDR?" The  
latter form is ugly, but it actually works in a browser and would  
work in an app without special, supporting libraries.

These features are complementary to the established search-interfaces  
for the registry. They don't remove the need for an XQuery search or  
a TAP-like ADQL search. They do, IMHO, offer a useful and easy way to  
look up individual resources.

The programming time to do this was tiny: two flights, one  
uninteresting talk at ADASS and an hour tonight to fix a selection  
bug. This illustrates the ease with which one can handle hierarchical  
data using a real XML database and a RESTful arrangement of the  
service. The code is one servlet, two JSPs and an XSLT glued to the  
side of a regular AstroGrid registry which hosts the data; the  
underlying DB is eXist.

Cheers,
Guy 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3006 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/registry/attachments/20081117/691852e6/attachment-0003.bin>