ownedAuthority element
Aurelien Stebe
aurelien.stebe at sciops.esa.int
Wed Apr 6 03:40:01 PDT 2005
This sounds simple enough and would work nicely.
I'm just wondering what would be best between a "managedAuthority" and a
"managedRegistry"
managedAuthority : the result for the "ivo_managed" set is quite simple
to process for the registry.
managedRegistry : the info is not redondant (in the ownedAuthority of
the publishing registry and the managedAuthority of the full one) and
the managed registries ivo-ids can be directly stricken from the list of
"to harvest" while doing a havest cycle.
cheers,
Aurelien
KevinBenson wrote:
>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
>
>
>
More information about the registry
mailing list