ownedAuthority element

[Paul Harrison]

Ray Plante wrote:
> Hi guys,
> 
> Just for the record, it was my fault that ownedAuthority was omitted from 
> the VORegistry schema, and that the meaning of managedAuthority and 
> ownedAuthority got switched.  Sorry `bout that.  

I think to make this work sensibly we do need this distinction to be 
reinstated - perhaps with the less ambiguous terms ownedAuthority and 
queriableAuthority - Then it would be much easier to work out what 
should be done in complicated harvesting/querying scenarios Imagine 3 
registries

RegistryA
    ownedAuthority=A

RegistryB
    ownedAuthority=B
    queriableAuthority=B
    queriableAuthority=A

RegistryC
    ownedAuthority=C
    queriableAuthority=C
    queriableAuthority=B
    queriableAuthority=D

Some points of note
1. Here registryA is making a explicit declaration that it does not want 
to be harvested
2. RegistryB is making a declaration that it is searchable for the 
authorityID A.
3. Registry C is obviously intended to be the "Full" registry in this 
case (i.e. the only that you would configure your components to query 
first) - it even knows about an authority "D"! - However note it cannot 
service queries for authority A (perhaps there is a schema extension in 
A's entries that it cannot handle). However, an intelligent agent could 
discover from the registry C that registry B was able to satisfy a 
request for something from authority A


> 
> That said, I thought I would throw one more thought into this discussion 
> before we all sleep on it.  I was planning to suggest that we drop the 
> <managedAuthority> element from the Registry type; instead, we would put a 
> reference to the managing Registry in the Authority type.  The main reason 
> is that it is currently clumsy to maintain.  Each time a new Authority ID 
> is defined, not only must an Authority record be created, but the existing 
> Registry record must be updated.  If we instead put a <managingRegistry> 
> (or <homeRegistry>) element into the Authority record, no other updates 
> are necessary. 
> 
> Finding the registry that manages/owns an authority ID is similar.  
> Instead of 
> 
>    where @xsi:type='Registry' and managedAuthority='{authID}'
> 
> we would,
> 
>    where @xsi:type='Authority' and identifier='ivo://{authid}'
> 
> and then pull out identifier from the <managingRegistry> element.  To 
> learn more about the Registry you would have to resolve the identifier 
> into its record.  
> 

This seems like a good idea, as it would enforce the fact that only one 
registry can own a particular AuthorityID. The queriableAuthority 
mentioned above should still be a subelement of a registry element though.

As has been mentioned elsewhere, perhaps the real difficulty is that 
some metadata needed for the operation of the registry is being defined 
in the registry schema, and we need to clearly separate these.

When setting up harvesting of a registry it would be useful if the 
Identity operation of section 3.15 of the registry interface were 
mandated to return the authorityID element as well, then it would be 
easy to  add harvesting of a registry simply by knowing the end point of 
the service.

-- 
Paul Harrison
ESO Garching
www.eso.org