explanation of various Registries attempted and a new element needed

KevinBenson kmb at mssl.ucl.ac.uk
Tue Apr 12 04:12:27 PDT 2005


I believe Roy asked the question to explain these various Registries such as
full and publish.  So thought that I would attempt it, just to see how many
conflicting e-mails I receive.  Maybe in the end we will be on the same
page.

General Comment:
 * In general there is nothing that distinguishes between a full and/or
publish registry in the Registry Type Resource, hence if I am an app writer,
I would think I could connect to Heasarc and query on it.  We should
probably add some kind of new element to the Registry type to do some kind
of distinguishing and also put the search interface endpoint available as an
optional element?

 * Roy in general I suspect the only difference between the registries
listed below are nothing more than a couple of config property changes that
is all.  All this "Documents and Thinking" can make things a bit confusing,
but the "Reality" is they are very similar and there logic is probably
almost exactly the same with just a few minor tweaks of the config.  Much
like Ray pointed out really it is down to "roles" these registry types play
more than anything else.

Publishing Registries:
	Documents and Thinking:
1.) It is not required to support a Search interface
2.) It holds only Resource records pertaining to its dataset or its registry
only.
3.) It returns information back on OAI harvest calls for those resources it
owns.
4.) It does not do any harvesting. Especially no automatic harvesting.
	Reality:
1.) It will most likely have a search interface. (But don't count on this,
just thinking how new registry implementation writers have done this,
because having it is only an advantage of being able to search your
publishing resources.)
2.) It will return Resources back in OAI for what it owns same as #3 above.
3.) It will have its harvesting turned off.
4.) Eventually implementers may realize why not let them do some harvesting
making them a "Public Special Registry" or even a "Full" registry possibly.
After all who is going to know, unless performance really gets bad? :)

Special or Local Registry:
	Documents and Thinking:
1.) It is hidden from the world. Nobody knows it exists except the installer
of the registry and particular apps (normally local apps).
2.) It might harvest to get external registries.  It may even be like Full
and harvests from all registries.
3.) Might even have backdoor stuff to allow them to change any Resources not
just there own they update.  Remember this registry is hidden.
4.) It will have a Search interface and No Harvest Interface.
	Reality:
1.) It will be the same implementation as a Full Registry just possibly
smaller size of records in its storage.
2.) This means it will have a Search Interface and probably a Harvest
Interface as well.  After all it is hidden who cares if it has a Harvest
interface.  Again who is going to know? :)


Full Registry:
	Documents and Thinking:
1.) It will have a Search Interface and a Harvest Interface.
2.) Harvesting will be turned on automatically.
3.) It should harvest all Registry Types.  And all harvest is strongly
recommended to be via date "from" date.
4.) Much like Publishing registry, it returns its resources it manages
and/or owns back on the OAI form.
*5.) New - It *may* skip harvesting of certain Publishing Registries if they
are known to have its registry managed by another Full Registry.
	Reality:
1.) Okay nothing quite different from "Documents and Thinking". Realize this
is nothing more than a "Reality" Publishing Registry with search interface
and harvesting.


In a nutshell that is my opinion.  Does this fall in line with other
Registry implementations?

In general we do need more things on our Registry Type.  Most likely a
Search and Harvest endpoint.  Right now we just have the one "accessURL"
which I currently assume is the harvesting endpoint.  Only "word of mouth"
lets me know who registries really are.  In general there is nothing that
tells me that NCSA is a publishing registry only,  I might think it is a
Full Registry.  Or that Carnivore is a Full Registry, I might suspect that
it is a Publishing Registry.  So I would recommend as well to have something
that distinguishes these registry types even though I understand that they
are quite similar.

Cheers,
Kevin



More information about the registry mailing list