prototype: scalable VOSI-tables-1.1

[Mark Taylor]

On Tue, 5 May 2015, Markus Demleitner wrote:

> Hi,
> 
> On Mon, May 04, 2015 at 01:56:08PM -0700, Patrick Dowler wrote:
> > The basic aproach is to define a RESTful resource tree following the
> > VODataService model: tableset, schema, table. All the example URLs below
> > work but note that the table names are fully qualified because that is how
> > it works in TAP right now. There are separate discussions on that so it
> > isn't really relevant here.
> 
> Well... depends.  If you're using fully qualified names, there's no
> strong reason to talk about schemas in your URL scheme at all, as the
> table names are guaranteed unique.
> 
> There is a good reason not to talk about schemas: ADQL table
> references have one to three components, and mapping those components
> to a constant number of two levels on the tables endpoint may be
> painful with empty or magic path elements.
> 
> True, the problem of a mismatch between the VODataService model and
> ADQL table references already exists in  VODataService itself.
> Given that valid table references can have one to three "segments"
> (and one could imagine query languages with even more exotic table
> references behind a TAP service), I now believe it was an error to
> require schema in VODataService 1.1 (1.0 didn't have it), and I
> propose to re-allow (and even recommend) table elements as direct
> children of tableset there.
> 
> I've just added as much on
> http://wiki.ivoa.net/twiki/bin/view/IVOA/VODataServiceNext --
> comments are welcome there.
> 
> In short, I'd like to reduce explicit modeling of naming hierachies
> in our protocols, and I think there's little to be gained by it here,

I follow the reasoning, but there is one advantage gained by
the current schema/table hierarchy in tableset and TAP_SCHEMA,
and that is an organisational grouping that's useful for
presentation of database metadata to users.  For instance the
GAVO DC has 63 schemas and 138 tables; it may be more digestible
for users to see a list of 63 separate data collections at top
level from which they can drill down, rather than an undifferentiated
bag of 138 tables (though in this case the difference of a
factor of 2 is not a very strong argument).

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/