VODataService becoming WD, then PR

[Francois Ochsenbein]

About the primary/foreign key definitions -- there is a convention
in VOTable which makes use of GROUPs and the ID/REF mechanism, as in
the following example:

<TABLE name="table1" ... >
  <GROUP ID="Galaxy_ID" name="primaryKey">
    <!-- full definition of the primary key components: -->
    <FIELDref ref="tab1_col1" >
    <FIELDref ref="tab1_col2" > ...
  </GROUP>
  <FIELD ID="tab1_col1" name="Cluster" ... >
  <FIELD ID="tab1_col2" name="Galaxy" ... >
  ...
</TABLE>

<TABLE name="table2" ... >
  <GROUP ref="Galaxy_ID" name="foreignKey">
    <!-- Components of the foreign key, referencing the PK of table1 -->
    <FIELDref ref="tab2_col1" >
    <FIELDref ref="tab2_col2" > ...
  </GROUP>
  <FIELD ID="tab2_col1" name="ClusterName" ... >
  <FIELD ID="tab2_col2" name="GalaxyNumber" ... >
  ...
</TABLE>

With this mechanism as of as many keys as necessary can be defined,
and a column may be a component of several foreign keys.
It seems to me that this way should be mappable to TAP schema
as well as the Registry one. However I don't see how you can
avoid to use ID/ref mechanisms: a foreign key has always to
refer to the definition of a primary key. The name of the primary
key might be the same of a table, since by definition there is only
one primary key per table. But you might also wish to define several
keys for a table, in which case you have to assign names to your keys
to be able to reference them.

My wish is really to be able to express one concept (relational tables),
if not with exactly the same terms, at least in terms which can be 
mapped between the various dialects without any loss of information: 
if for instance in TAP one column can only be part of a single foreign
key, while the Registry has not this restriction, we loose the full
interoperability.

--Francois

>On 2008-11 -18, at 10:06, Gerard wrote:
>
>> A TAP inspired example could be the Database<-Schema<-Table<-Column
>> relations in the TAP_SCHEMA,
>> ff this were modeled as follows
>>
>> TAP_SCHEMA.databases
>> name
>> ...
>> primary key(name)
>>
>>
>> TAP_SCHEMA.schemas
>> database_name
>> name
>> ...
>> primary key(database_name, name)
>>
>> TAP_SCHEMA.tables
>> database_name
>> schema_name
>> name
>> ...
>> primary key(database_name, _schema_name, name)
>>
>> TAP_SCHEMA.columns
>> database_name
>> schema_name
>> table_name
>> name
>> ...
>> primary key(database_name, _schema_name, table_name, name)
>>
>> Fore xample TAP_SCHEMA.columns has a foreign key (database_name,
>> schema_name, table_name) to tables,
>> (database_name, schema_name) to schemas and database_name to databases
>> This further complicates a column-level definition of the foreign key.
>
>
>
>Yes - so I think that my attempt to do this with a single extension
>attribute on the TableParam is beginning to stop being "simple". It
>would be necessary to have a list value for the fkey.
>
>e.g. on the TAP_SCHEMA.columns.database_name column
>fkey="tables.database_name, databases.database_name"
>
>and similarly on the other columns that make up the key.
>
>This I think leads us to wanting to go with Gerard's suggestion, which
>is effectively a reintroduction of a (better) tableJoin element that
>had been previously dropped. I also prefer the idea of having the
>ForeignKey defined as a child of Table.
>
>Cheers,
>	Paul.

================================================================================
Francois Ochsenbein       ------       Observatoire Astronomique de Strasbourg
   11, rue de l'Universite F-67000 STRASBOURG       Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr   (France)         Fax: +33-(0)390 24 24 32
================================================================================