summary of recent RI discussion

[Tony Linde]

Sorry, Paul, I'm getting confused about your 'searchable'
registry/authority. A full registry is one which supports the query
interface and which contains *all* resource records from *every* authority:
every full registry is identical in the records it contains (subject to
harvesting overlaps).

Saying that a registry contains 'searchable' authIDs does not make sense as
every searchable (full) registry contains *all* authority records and all
resource records.

> A full registry might have the entries
> 
> <Resource xsi:type="Authority">
>    <identifier>my.authority</identifier>
>    <OwnedByID>ivo://my.authority/Registry</OwnedByID>
> </Resource>
> ...
> <Resource xsi:type="RegistryType">
>    <identifier>another.authority/FullRegistry</identifier>
>    <searchableAuthority>my.authority</searchableAuthority>
>    <searchableAuthority>another.authority</searchableAuthority>
> </Resource>

Firstly, I still think we need both ownedBy and managedBy authIDs to
differentiate between those IDs which a registry can and cannot change (can
change owned resources, cannot change managed resources).

Secondly, I don't think that publishing registries ought to have registry
entries. They are not VObs resources since they are not accessible to the
VObs. When a publishing registry links up with a full registry it is a
private matter between them - no-one should ever know about the publishing
registry. It might be using registry software to make it easier for its
records to be uploaded into the full registry but it is not really a
registry: it is not a VObs resource and should not be listed as such.

> The reality is that not all registries can 'support' 
> arbitrary extensions even in this limited extent - even the 

They're going to need to find ways - we cannot restrict resource extensions
so we need to find a way of handling them - even if the registry has to save
them in separate text files and append them when returning the full record -
there are ways of making it work.

> something with a new extension (which in this model they 
> would have to do in an new AuthorityID) all that they need to 

There is certainly no need for a new authID to publish a new resource. Any
and all types of resource can be published under the one authID.

> be possible for an intelligent agent to work out which 
> registry could acually fulfill the query.

The goal must be that all registries support all queries: that is what we're
working towards.

Cheers,
Tony. 

> -----Original Message-----
> From: Paul Harrison [mailto:pharriso at eso.org] 
> Sent: 11 April 2005 14:36
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: Re: summary of recent RI discussion
> 
> Tony Linde wrote:
> >>Surely the separation of the owned Authority and searchable 
> Authority 
> >>concept is still needed even by the registry of registries fully to 
> >>describe what is out there.  As well as <Registry> records, 
> it needs 
> >>to contain <Authority> records,
> > 
> > 
> > Why should it contain auth records? Any full registry contains all 
> > records so has all the auth records anyway. The registry of 
> registries 
> > simply makes it easier to find new registries that have 
> been added and 
> > from which one must harvest.
> 
> The registry of registries was proposed to have only 
> <VOresource xsi:type="RegistryType"> records
> > 
> > 
> >>and I rather liked your idea to have an element in the 
> Authority that 
> >>points to the "owning" registry, which would fulfil this role.
> > 
> > 
> > I assume you mean an additional element in the authority 
> record, not 
> > in the authority element. Sounds a good idea - I'd assumed 
> it was there.
> > 
> well there is not - that is what this discussion is about...
> 
> > 
> >>The "managedAuthority" elements in each of the Registry 
> elements would 
> >>then be the list of authorityIDs that were searchable in a 
> particular 
> >>registry (i.e. the set of harvested, and owned AuthorityIDs).
> > 
> > 
> > No - all records are searchable in a registry. The owned 
> and managed 
> > authIDs are the ones which are harvested.
> 
> there is no mechanism in the schema for saying that you are a 
> publishing
>   only registry - with the proposed separation of attributes, 
> this could be signaled by the registry having the following entries
> 
> <Resource xsi:type="Authority">
>    <identifier>my.authority</identifier>
>    <OwnedByID>ivo://my.authority/Registry</OwnedByID>
> </Resource>
> <Resource xsi:type="RegistryType">
>    <identifier>my.authority/Registry</identifier>
>    <!-- there is no searchableAuthority here --> </Resource>
> 
> A full registry might have the entries
> 
> <Resource xsi:type="Authority">
>    <identifier>my.authority</identifier>
>    <OwnedByID>ivo://my.authority/Registry</OwnedByID>
> </Resource>
> <Resource xsi:type="Authority">
>    <identifier>another.authority</identifier>
>    <OwnedByID>ivo://another.authority/FullRegistry</OwnedByID>
> </Resource>
> <Resource xsi:type="RegistryType">
>    <identifier>my.authority/Registry</identifier>
>    <!-- there is no searchableAuthority here --> </Resource> 
> <Resource xsi:type="RegistryType">
>    <identifier>another.authority/FullRegistry</identifier>
>    <searchableAuthority>my.authority</searchableAuthority>
>    <searchableAuthority>another.authority</searchableAuthority>
> </Resource>
> 
> > 
> > 
> >>1. A registry can "own"/publish more than one Authority 2. 
> >>Not all registries will be able to support all specialized schema 
> >>extensions,
> > 
> > 
> > Registries do not have to 'support' the schema extensions 
> in the sense 
> > of being able to interpret them. They just have to store them. 
> > Basically, if a search matches a record, the whole record 
> is returned, 
> > whatever its structure.
> > 
> The reality is that not all registries can 'support' 
> arbitrary extensions even in this limited extent - even the 
> pure xml registries might need some extra configuration 
> before this can be done. So if someone wants to publish 
> something with a new extension (which in this model they 
> would have to do in an new AuthorityID) all that they need to 
> do is persuade one searchable registry to support their 
> extension, and then with the registry of registries it would 
> be possible for an intelligent agent to work out which 
> registry could acually fulfill the query.
> 
> Even in a perfect world of idential registry implementations, 
> it would be a good idea to make explict this separation of 
> roles, as it makes it easier to create to two sets proposed 
> for harvesting.
> > 
> >>I still think that it might be better to replace the term "managed" 
> >>with "searchable"  in these discussions, because I think 
> that "manage" 
> >>has meant "own" to some people.
> > 
> > 
> > No, because a registry is searchable on all authIDs, not 
> just the ones 
> > it owns and manages.
> 
> I am not sure I understand your point here (what other 
> categories are there besides owned and managed in current 
> parlance?), but as I showed above a "publishing" registry 
> would not have a "searchable" entry for the authorityID that it owns.
> 
> > 
> > Cheers,
> > Tony. 
> >