VODataService becoming WD, then PR

[Gerard]

Hi Francois


> 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.
> 
You seem to imply that the introduction of foreign keys in the metadata
specification requires the introduction of primary keys as well. Is that
correct?
In relational databases foreign keys are constraints, and on the target
table a primary key or at least a uniqueness constraint must have been
defined and must be captured. 
I don't see though why for the problem at hand it is necessary to add this
complication.

To me it seems that the main use of a "foreign key" definition in the
VODataService
and the equivalent(/same?) TAP schema is to inform users about the
relationships between tables so
they can learn what joins they can usefully make. That at least the concept
I tried to capture in
the little model I proposed. I wanted to be able to say that one tables
references another and how the reference is implemented.
To support this you only need to know which column(s) in the "from table"
correspond to which columns in the "target table". I used table and column
names iso ID/IDREF combinations as I thought that tables and columns were
not given ID attributes. It is also much more readable. 


> 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.
> 
Why would TAP put that restriction on the metadata? 
Why would you only be allowed to publish your database through TAP if you
had followed a particular design strategy, if it is so simple to describe
the general case?

Cheers
Gerard