Grouping in VOTables. (fwd)

[Doug Tody]

[This may be of broader interest so I am moving this thread over to VOTable]


---------- Forwarded message ----------
Date: Thu, 22 Jan 2004 11:27:37 -0700 (MST)
From: Doug Tody <dtody at nrao.edu>
To: metadata at us-vo.org
Subject: Re: Grouping in VOTables.

This "group" mechanism resembles the "view" in a relational database.
A view is a logical grouping of some subset of the fields of a table
(or of fields from several tables - should VOTable groups permit this as
well?).  A given field may participate in more than one view.  Views are
a logical way of looking at information, but not a physical structuring
of the information.  There can be problems with things such as updates.
Views are in themselves a type of "virtual" table.

This is not the same thing as mapping an object onto the fields of a
table, which is a direct physical mapping of an object to a particular
storage representation.

An object serialized as an XML entity can be easily validated with a schema
in the conventional way.  When we map the object to some physical storage
representation such as a table, schema validation becomes more difficult.
There are basically two options.  We can define the mapping of the object
to the storage representation, use this to extract the object and then
apply schema validation in the conventionl way.  Or we could try to
transform the object schema to the storage representation and directly
validate the stored version as an object.  The problem with this latter
scheme is that we need to merge the schema of the object with that of the
storage representation or container (e.g., table), and if we try to store
multiple objects in the same container, we have to merge multiple schemas,
which can quickly become intractable.

In general we would like to be able to deal with objects independently
of how they are stored.  We want to be able to define an object (i.e.,
data model) in the abstract, and be able to map it to multiple independent
storage representations without affecting our view of the object we are
dealing with.  Probably this means we need to deal separately with the
object schema and the mapping to a particular storage representation.

To validate an object, or load an object into class code within an
application, we would need to first extract the object from the container
by applying the inverse mapping.  Objects stored directly as native XML
entities could skip the extraction step (although even an XPath reference
to a node within an XML document is a limiting case of this).  The
container itself would have only a simple container schema and would not
attempt to validate the objects stored in the container.


On Thu, 22 Jan 2004, Thomas McGlynn wrote:

> Just a quick followup to today's telecon regarding the
> integration of GROUPing and any extension to VOTables.
> The current 1.05 draft says in section 4.7
> 
>    A physical field (i.e. a single column of the table)
>    may therefore participate (logically) to several groups.
> 
> so with the grouping construct a VOTable is not necessarily
> representable as a simple hierarchy.  I don't know how much
> this makes things harder, but I do think any further
> extension to VOTable needs to carefully consider how
> it interacts with the subtleties of previous work.
> 	
> 	Tom
>