ownedAuthority element

[KevinBenson]

Yes Ray what you have there did sound pretty good, and if it is a majority
vote later for that approach, then I won't object.

In general since we have several other areas with curation and things going
on I would like to see it kept real simple and effectively have these 3
rules.

1.) harvestee when returning records in OAI returns records for authority
ids managed or owned (from there Registry).
2.) harvester *may* desire to skip harvesting certain registries if
discovered an authority id has already been received from another registry
that has that particular authority id as being "managed".
3.) If harvester is a "Full Registry" then at an unknown time (presumably
when it kicks off its harvests), it MUST harvest any registry type that it
has been put as a <managedAuthority> and being managed by its own registry.
*Final note smaller publishing registries should be recommended to negotiate
on having a Full Registry manage its authority id.

If we follow these three rules, then we have the flexibility in the
beginning for registries to use a Flat model where by they harvest all known
Registries like we have today, or a structured model by grabbing all the
Resources from mainly Full Registries (and some Publishing Registries-that
don't have there authority id's managed).

The above approach means <ownedAuthority> and <managedAuthority> in the
Registry type Resource.

cheers,
Kevin

-----Original Message-----
From: owner-registry at eso.org [mailto:owner-registry at eso.org]On Behalf Of
Matthew J. Graham
Sent: 05 April 2005 23:15
To: Ray Plante
Cc: Registry List
Subject: Re: ownedAuthority element


Hi,

> On Tue, 5 Apr 2005, Matthew J. Graham wrote:
>> Grrr, it took me some effort to implement this in Carnivore and now
>> you
>> want to drop it?
>
> Yeah, you know what I'm talking about, then  ;-)
>
> Seriously, though.  Should we consider dropping it, or is this an "if
> ain't broke don't fix it" thing?  We do the update properly here as
> well
> (of course), but I'm thinking of those that haven't implemented it yet.

The problem is that certain pieces of VO metadata stored by a registry
are actually operating data for the registry. If these two catagories
were separated more cleanly then it would be make implementing a
registry from scratch easier and let's face it, from here on in, it's
just going to get harder. Dropping it makes design sense but keeping it
makes implementation sense, i.e. I do not have to do extra work.

	Cheers,

	Matthew