[OAI-implementers] Friends and Neighbours scheme ... locating OAI repositories

Michael L. Nelson mln@ils.unc.edu
Mon, 4 Mar 2002 17:43:37 -0500 (EST)

> > Another mailing list I am on related to Z39.50 is talking about the
> > concept of "Friends and Neighbours". It may be a bit early for
> > OAI (not that many sites yet!), but the basic idea is that sites
> > keep track of what other sites they know of. That way, there does
> This looks very like the concepts in Peer-to-Peer, especially Gnutella.
> But I am not sure how well it fits in here. In Gnutella/Fasttrack, people
> want to get a music file, they don't care  much about how precise the
> result is, as long as they can get something. But here we may want a
> definite answer, like: how many OAI data providers and what contents they
> share so far?  

not necessarily...  the original purpose of "friends" was that it would
allow a loosely connected set of DPs w/o having to use a central
registery.  sort of like a bunch of http servers that have html pages that
point to each other.  and "friends" is very DP-centric:  DPs get to decide
who to list as their friends.

for example, the NASA DPs might list each other as "friends", and maybe
some of the other labs & institutes that they share data with (e.g., LANL)
or are affiliated with (e.g., RIACS).  a SP that finds one of these DPs
should be able to get a rough idea of the DPs that cooperate by design,
essentially inferring the "community" of federal research lab DPs.  apply
the standard hubs/authorities, etc. stuff here too.

"ListFriends" did not make it as a verb in OAI 2.0; but perhaps it could
be experimented with using specials sets: "oai_friends" or something
equally mnemonic.  or maybe just a separate metadata format (oai_friends):


its not hard to imagine a simple schema that delineates
who you're pointing to.  

> Another way is to expose the list of data provider in an OAI interface,
> that's what we did in Arc:
> http://arc.cs.odu.edu:8080/oaisp/servlet/OAI-SP?verb=ListRecords&from=&until=&set=&metadataPrefix=oai_dc

yeah, a separate interface is one way to do it too.  

> This might be an easier way to implement a friend/neighbor functions. For
> a data provider, it might support two OAI interface, one for naming
> service, another for real data.
> On Sat, 2 Mar 2002, Steven Bird wrote:
> > I favor a central registry to control the oai:... namespace.  
> I agree a strong central control will be helpful, considering somebody
> wants to build a service provider, he really needs a point to start with.
> Of course, that won't prevent any internal use. 

yeah, a quick browse through Arc reveals that  most of the archive names
don't mean much, and there is going to be collision of obvious acronyms /

> Regards,
> liu

Michael L. Nelson
NASA Langley Research Center		m.l.nelson@larc.nasa.gov
MS 158, Hampton, VA 23681		http://www.ils.unc.edu/~mln/
+1 757 864 8511				+1 757 864 8342 (f)