VOResource Schema changes to easy relational mappings...

[Paul Harrison]

Hi

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 strictly needs to be made - it would be useful if we could decrease the cardinalities of some of the elements - I have identified a number of cases where this could be done at almost no cost.


1. we allow a multiple Relationship elements which can each have multiple RelatedResource elements within them. The purpose of this is to allow the related resources to be grouped by relationshipType - however the same effect can be obtained by only allowing a single RelatedResource element within the Relationship element and then repeating Relationship elements.

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

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.

3. curation/date - do we need this at all? the resource record itself has attributes that seem to cover the needs (unless an audit trail of all the update dates is required)- it is used by a lot of records (9888) but only 
ivo://ivoa.net/rofr
ivo://CDS.VizieR
ivo://CDS.VizieR/registry
use it more than the single time - if it were removed then it would require automated editing of many records, but again if it were given a cardinality of 1 only a handful of records would need hand editing...


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 disruptive - A handful of resource  records needing to be edited compared with potentially many software systems if the namespace is changed (Admittedly depending on whether the software uses the live schema or not, it will need changes - so that it does not allow the newly forbidden multiple cardinalities - but these can be done gradually, and the whole registry does not become instantly invalid/outdated).

I might find more as I look further...

Paul.