Is XPATH the way to search a data model?

[Guy Rixon]

On Tue, 18 May 2004, David Berry wrote:

> Guy,
>
> > > 2) Can it have astronomical knowledge built into it, or is it just a
> > > sort of dumb regexp system for structured text?
> >
> > It's the dumb one. But, as i said above, it's regexp for a data graph, not for
> > text; this makes it more powerful.  If we want to use XPath for astronomical
> > inference, then we have to do that via the details of the data model.
>
> Are you saying that it *is* possible to somehow supplement XPath with "details
> of the data model" so that it can do astronomical inference? Or are you
> saying that astronomical inferencing is nothing to do with XPath?

Mu. There are two levels of tech here and the situation differs between them.

If you get a generic tool that knows XPath (tool in the sense of executable
programme; there is one in Xalan, I think) then it knows no astronomy and
can't be taught any.  If you use an XPath class-library (e.g. in Xalan and
dom4j), then you can have an ontological layer stacked on a format-aware
layer. The XPath is the format-aware bit.

E.g., if your ontological layer knows that {Ra, dec, equinox} and {gal-lat,
gal-long} are interconvertable systems, then you can ask the format layer to
look for either of these. You can find all the galactic positions, at any
depth in the model, have the ontology engine make up ra-dec equivalents and
splice the equivalents back into the data, if that helps.  You can ask for all
the celestial positions that are in B1950.  You can ask for all the positions
that lack an equinox if you're sanatizing the data.  All these searches can be
expressed in XPath if the software generating the XPath understands the model.
Expressing the searches without XPath would be tricky and fragile.

Units are a problem with XPath. (More detail needed in following email?)

> > > What I mean is, if for
> > > instance you searched a StandardQuantity for a Frame (Frame "A") holding
> > > the 3 axes:
> > >
> > > (heliocentric radio velocity, ICRS RA, ICRS Dec)
> > >
> > > could XPATH do anything sensible if the StdQ did not contain this exact
> > > Frame, but instead contained a Frame (Frame "B") containing the 3 axes:
> > >
> > > (Galactic longitude, geocentric frequency, galactic latitude)
> > >
> > > ?? Obviously Frame A and Frame B are not identical, but given a
> > > position in Frame B it is possible to convert it into Frame A without
> > > needing any extra information over and above that stored in the
> > > Frames. What we want is a search system which has enough astronomical
> > > knowledge to be able to do this. What you want from your search system is
> > > for it to say "no I cannot find Frame A but Frame B looks very similar and
> > > I can give you a Mapping which will convert positions in Frame B into the
> > > corresponding positions in Frame A". Such recoverable mis-matches between
> > > what the client wants and what the server can provide is bound to happen
> > > over and over again in the VO. So can XPATH be used to do this sort of
> > > searching? If not, then should we not drop XPATH in favour of building
> > > customised intelligent searching into our code which searches the data
> > > model itself rather than just some specific data format?
> >
> > If Frame A and Frame B are of types that share some common ancestor in the
> > inheritence scheme, then I _think_ that XPath can be set to search for that
> > ancestor.  I.e., you could ask it to find a StandardQuantity containing a
> > CoordinateFrame, say. Or you could pattern-match the UCDs looking for "POS.".
> >
> > XPath does searching; it doesn't do transformation.  See XSLT for
> > transformation, and note that XSLT is built around XPath: it looks for
> > patterns using XPath and applies transformations to them. In principle, we
> > could build an astronomical search-and-transform thingy using XSLT scripts.
>
> OK, so XSLT can in principle be told how to convert between FK4 B1968.2
> (RA,Dec) and FK5 J2003.2 (RA,Dec)?  Presumably this conversion would not
> be done by XSLT itself but by some extrenal transformation code. But are
> you even saying that XSLT could infer the *need* to convert between
> these two systems?

XSLT can do simple arithmetic and simple string manipulation on element
values. You need external code to do proper maths (e.g. spherical trig).

XSLT itself doesn't infer things. It matches patterns and transforms the
things that match.  This may be enough for most cases.

Suppose that you have a system that generates XSLT documents on the fly and
then applies them to data. You can generate XSLT that says "list me all the
surface photometry* and every time you see a position, convert it to J2000".
These are XSLT's two main functions: selecting a sub-graph of the input data
and replacing some nodes in that graph with alternative representation.

(* Presumes that you can list all the element types to do with surface
photometry in the XSLT.)

The trick is to have an ontological layer that informs the use of XSLT. In
most cases "ontological layer" = "astronomical application". You don't
generally need a wizz-bang computer-science tool for the ontology.

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523