[OAI-implementers] Friends and Neighbours scheme ... locating
Michael L. Nelson
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:
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 /
Michael L. Nelson
NASA Langley Research Center email@example.com
MS 158, Hampton, VA 23681 http://www.ils.unc.edu/~mln/
+1 757 864 8511 +1 757 864 8342 (f)