Grouping in VOTables. (fwd)

[Doug Tody]

If VOTable grouping is not a view mechanism but rather is a mechanism for
expressing relationships and structure within a table, then it should be
possible to do something like this:

    o	Start with an XML entity.

    o	Map this to the fields of a VOTable, with the structural information
	of the original entity recorded in a GROUP record (this could
	include a reference to an externally defined data model).

    o	Use the GROUP record to extract the original XML entity.

    o	Use a schema to validate the XML entity or map it to some class
    	code for use in an application.
 
Is this possible?  If not, and the group mechanism is intended to reflect
fixed relationships and substructure within a table, shouldn't this sort
of transformation be supported?



On Thu, 22 Jan 2004, Thomas McGlynn wrote:

> Mark Taylor wrote:
> ...
> > 
> > I'm not sure what is the motivation for allowing a FIELD to participate in
> > multiple GROUPs.  The GROUP example given in the VOTable document is of 
> > associating a quantity with its error value, which doesn't match this kind of 
> > usage (you'd typically have disjoint groups in that case).  One can imagine 
> > various possible semantics for this sort of grouping - the views thing 
> > that Doug mentions is one I hadn't thought of - but it's true that 
> > allowing arbitrarily complicated membership of groups complicates matters.  
> > It's already come up as one of the possible problem areas in the recent 
> > VOTable/V2 discussion on the VOTable list.  So I'm somewhat in sympathy
> > with what I take to be the point of Tom's comment above that we should 
> > be cautious about adding such things unless there are solid reasons for 
> > incorporating them.  Can anyone explain a use case in which membership 
> > of multiple groups would be a Really Useful Feature?
> > 
> > Mark
> > 
> 
> 
> I'm not really defending the reusable column concept in general but I don't
> think it's hard to find potentially useful applications.  Still it wouldn't
> break my heart to forbid this.  After all no one is writing
> tables with groups yet that I know of, so it wouldn't hurt anything.
> 
> Suppose we have a position entity which comprises a position and an
> error in the position and we want to have some of these in VOTables.
> If there are several positions recorded in each row, it's likely
> that one or more or them might share the same error information.  So
> the field with the error might appear in more than one position group.
> 
> Or suppose we decide that we want tables to have the possibility
> of a specified unique key.  If the unique key comprises multiple fields
> then the natural way to specify it, might be to use some specifically
> named group.  So VOTables that
> support this convention may have a group which contains the unique
> key columns, and these columns may also belong to groups that reflect
> some other internal structure.
> 
> Until we work out what we want to do with groups it's easy enough to
> make things up!
> 
> 
> 	Tom