summary of recent RI discussion

[Paul Harrison]

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. 
> 
> 
>>-----Original Message-----
>>From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
>>On Behalf Of Paul Harrison
>>Sent: 11 April 2005 11:58
>>To: Ray Plante
>>Cc: registry at ivoa.net
>>Subject: Re: summary of recent RI discussion
>>
>>Ray Plante wrote:
>>
>>>Hi RWGers,
>>>
>>>I thought I would try to summarize what I think is the state of the 
>>>various discussion threads.  I wasn't sure until I started looking 
>>>back at the discussion, but we actually have made some progress.  
>>>Here's my summary, segregated by topic.
>>>
>>>1. ownedAuthority ==> registry of registries
>>>
>>>We ressurected the discussion of an <ownedAuthority> tag as 
>>
>>part of a 
>>
>>>mechanism for determining what registries to harvest from and 
>>>aggregating the harvesting at the national/regional level.  The 
>>>various solutions posed suffered from a certain amount of 
>>
>>complexity.  
>>
>>>Bob Hanisch suggested that the IVOA sponsor a "registry of 
>>>registries": a small registry containing only Registry records.  It 
>>>provides a central place for publishers to register their 
>>
>>publishing 
>>
>>>registries and full registries a place to find out how to 
>>
>>publish from.
>>
>>>The idea of aggregating the harvesting was dropped given the 
>>>simplicity of this new mechanism: the number of registries 
>>
>>to harvest 
>>
>>>from might be in the low tens.  Thus, <ownedAuthority> is 
>>
>>not needed.  
>>
>>>This idea also eliminates the need for a harvester interface, which 
>>>currently included a
>>>harvest() function and possibly a getRegistries() function.
>>
>>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, 
>>and I rather liked your idea to have an element in the 
>>Authority that points to the "owning" registry, which would 
>>fulfil this role. 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). There are several use 
>>cases this model can support, that are needed by the current 
>>set of registry implementations/deployments.
>>
>>1. A registry can "own"/publish more than one Authority 2. 
>>Not all registries will be able to support all specialized 
>>schema extensions, so it will not be the case that all 
>>registries are equal - i.e. it will not be possible to create 
>>an "uber"-registry that could satisfy any query by harvesting 
>>from all the publishing registries. The registry of 
>>registries does allow an agent to discover which of the 
>>registries can service a query for a particular AuthorityID.
>>
>>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.
>>
>>>2. harvesting all vs. managed
>>>
>>>We all like the idea of being able to get all records from 
>>
>>a registry 
>>
>>>or just those that originated from that registry.  It was agreed to 
>>>define an OAI set called "ivo_managed" to harvest the latter subset.
>>
>>It is a good idea, but should be used with caution if the aim 
>>is then for a searchable registry to claim to manage all of 
>>the harvested records, as (see my point 2 above) the registry 
>>might not be able to "understand" all of the schema 
>>extensions enough to be able to pass them on.
>>
>>
>>
>>--
>>Paul Harrison
>>ESO Garching
>>www.eso.org
>>
> 
> 
> 


-- 
Paul Harrison
ESO Garching
www.eso.org