Dear Arnold, dear all,
Stating the obvious:
The mechanism to encapsulate DMs ina VOTable must be as light and
general
as possible, so that in a single VOTable we can still embed various
data models;
it is then up to the client application to interpret only the
relevant part(s).
Exec summary of my email:
My view would be that:
1.- The VOTable parser must be instructed on how to behave
by VOTable mechanisms (i.e. by votable attribute names),
not by data model specific utypes (i.e. votable attribute values!).
2.- Then, and only then, the VOTable parser will pass the necessary info
to an additional STC (or any other DM) interpreter
to make sense of the underlying astronomical information,
*without* having to read the entire VOTable again.
Keep reading if you want to see an example of what I mean...
On Sep 21, 2006, at 11:12, Arnold Rots wrote:
> Francois,
>
> I looked at the three scenarios and suggest some minor changes to
> encapsulate the linkages between various STC components, without using
> FIELDrefs.
> [...]
> STC representation:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <TABLE ID="M81">
> <GROUP utype="stc:AstroCoordSystem" >
> <PARAM utype="stc:AstroCoordSystem.id" value="TT_ICRS_TOPO"/>
> <GROUP utype="stc:AstroCoordSystem.TimeFrame" >
> <PARAM utype="stc:AstroCoordSystem.TimeFrame.TimeScale"
> value="TT" />
> <PARAM utype="stc:AstroCoordSystem.TimeFrame.TOPOCENTER"
> value="" />
> </GROUP>
> <GROUP utype="stc:AstroCoordSystem.SpaceFrame" >
> <PARAM utype="stc:AstroCoordSystem.SpaceFrame.ICRS" value="" />
> <PARAM utype="stc:AstroCoordSystem.SpaceFrame.TOPOCENTER"
> value="" />
> <PARAM utype="stc:AstroCoordSystem.SpaceFrame.SPHERICAL"
> value="" />
> </GROUP>
> </GROUP>
> <GROUP ID="Coords1" utype="stc:AstroCoords">
> <PARAM utype="stc:AstroCoords.coord_sys_id" value="TT_ICRS_TOPO"/>
> </GROUP>
>
> <FIELD ID="OT" name="ObservingTime" datatype="char" arraysize="19"
> utype="stc:AstroCoords.Time.TimeInstant.ISOTime"
> ref="Coords1" />
> <FIELD ID="RA" name="Right Ascension" datatype="double" unit="deg"
> utype="stc:AstroCoords.Position2D.Value2.C1" ref="Coords1" />
> <FIELD ID="DEC" name="DEClination" datatype="double" unit="deg"
> utype="stc:AstroCoords.Position2D.Value2.C2" ref="Coords1" />
> <FIELD ID= "Err1" name="RA_Error" datatype="float" unit="arcsec"
> utype="stc:AstroCoords.Position2D.Error2.C1" ref="Coords1" />
> <FIELD ID= "Err2" name="DEC_Error" datatype="float" unit="arcsec"
> utype="stc:AstroCoords.Position2D.Error2.C2" ref="Coords1" />
> </TABLE>
>
Dear Arnold,
Let's follow the Err2 field, as an example.
A parser will see the ref="Coords1", and will search for it and find a Group with that ID.
Then what?
Yap, there is a PARAM whose value is TT_ICRS_TOPO, but how to link it back to the correct GROUP where the entire STC info is provided?
From a human point of view, it is feasible because our eyes/brains
are trained
and we will notice that the value TT_ICRS_TOPO is also given in
another PARAM
and we can infer that the GROUP that PARAM belongs to is the one to
be used to get
STC info.
But how would a parser know that? It cannot check or cross match all
the values
in the votable to find what it needs.
Of course, an STC parser will use a different algorithm (the utypes)
to figure
that out. But that would mean that a VOTable parser must also be an
STC parser.
Obviously, VOTABLE and STC (or any other DM) are components of the VO, and should be kept as distinct as possible.
This is way I claim that the FIELDref and/or ref mechanism is the only way to go.
My view would be that:
1.- The VOTable parser must be instructed on how to behave
by VOTable mechanisms (i.e. by votable attribute names),
not by data model specific utypes (i.e. votable attribute values!).
2.- Then, and only then, the VOTable parser will pass the necessary info
to an additional STC (or any other DM) interpreter
to make sense of the underlying astronomical information,
*without* having to read the entire VOTable again.
Alberto Received on 2006-09-21Z12:53:54