VOResource Schema changes to easy relational mappings...

[Markus Demleitner]

On Thu, Jun 09, 2011 at 11:36:48AM +0100, Paul Harrison wrote:
> In order to make a better VOResource schema for mapping to a
> relational model there are a number of changes that could be made -
> every time the cardinality of an element is unbounded a table join
[...]
> In the AstroGrid registry there are 1208 resources that use the
> relationship element and of those only 2 use multiple
> relatedResource elements within a single relationship
> 
> ivo://org.gavo.dc/__system__/tap/run
> ivo://org.gavo.dc/lensunion/q/im
Since both of these are mine: I'd be fine with flattening out the
relationships and could fix the RRs as soon as we decide to do this.
Actually, the grouping of relationships of the same type was a bit
painful in implementation, so simplifying this will actually help
implementors IMHO.

> 2 AccessURL - I remember the argument for having multiple
> accessURLs - i.e. to be able to specify fallback URLs - however
> there are no resources in the registry that make use of this -
> perhaps this is outside the scope of what the registry should be
> trying to do - fallback on a single address should be done via
> network layer techniques.
Agreed.

> Now for the even more controversial aspect (for the purists) - I
> suggest that we make a retrospective change to VOResource 1.0
> without making a change to the namespace - this would be much less
I'm all for being a bit naughty here.  The alternative would be a
long process with uncertain results.  As long as we only touch unused
or little-used features I think "retroactive changes" (great term!)
are far preferable.

Cheers,

         Markus