[OAI-general] Re: Kepler: Author-Based Archivelets
Fri, 8 Jun 2001 20:16:26 -0400
I wanted to clarify on the "similarity" of Kepler framework with
peer-to-peer broker based model. The proposed Kepler framework supports
two types of users: individual publishers using the archivelet publishing
tool and general users interested in retrieving published documents. The
individual publishers interact with the publishing tool and the general
users interact with a service provider and an OAI compliant repository
using a browser. In a way, the extended OAI framework looks very similar to
a broker based peer-to-peer network model [Bob2000]. Typically a user is
both a data provider (using Kepler archivelet) and a discovery user (using
Browser) that accesses a service provider. Thus, the primary mode of
operation might be construed as one of exchanging documents. Note that a
user directly connects to a Kepler user, after getting information about
the document from the service provider, for downloading the published
document. You can view Web Browser + Kepler archivelet as a peer-to-peer
node of a broker based model, where Registration Service + Service Provider
can be viewed as the broker. Consider the following scenario: User 'A'
contacts the broker and query where can he get a specific document. Broker
sends a brief information about the document(s) of interest and also point
out the coordinates of the user "B", who has the document. User 'A" then
contacts user 'B' directly to download the document. I hope this clarifies.
In the end, I should mention that we are not claiming that we are building
a peer-to-peer networking infrastructure. It so happens that we noticed
some similarity between the Kepler framework and the peer-to-peer broker
based model, and we thought of pointing it out in the report.
[Bob2000] Bob Knighten, Peer-to-Peer Working Group,
<say1 To: firstname.lastname@example.org
Sent by: cc: email@example.com
firstname.lastname@example.org Subject: [OAI-general] Re: Kepler: Author-Based Archivelets
06/07/01 11:35 PM
I've just had a play with Kepler and thought I'd share my thoughts. My
comments are based on a brief experience and the technical report, but I'm
sure Xiaoming Liu will correct me if I make technical errors about his
Xiaoming Liu wrote:
> There is no problem of implementing kepler functionalities
> using existing web server, like most OAI compliant data
> providers. But the key difference here is the targetted
> users, kepler is supposed to be used by common users (not
> necessarily computer science major) in desktop, for many
> of these users, it may not be easy/convenient to install
> a complex web server and make it OAI-compliant.
This is true, Kepler is VERY easy to download and use. It's well packaged
it's target platform (windows).
Xiaoming Liu wrote:
> The model of kepler is very similiar to napster/gnutella,
> people simply download it and share their files. I think
> both centralized model (traditional webserver) and
> distributed model (peer-2-Peer) can implement the file
> sharing functionalities, but both have its advantages and
> can not substitute each other.
I take exception to this. Software that immediately `phones home' to a
hard-wired registration server IS NOT PEER-2-PEER, it's just another tier
the client server model. To be peer-to-peer, Kepler would have to contact
other user-level Kepler/OAI clients directly and exchange information about
other Kepler/OAI clients.
Stevan Harnad wote:
> (2) One advantage of institutional rather than individual
> archives is that it puts the long-term preservation function
> into stronger and more durable hands. Can individuals
> promise this same reliability?
This may be the intentions of Keplers builders, but since it contains no
copyright release for mirroring, copying or distribution, the legal footing
such long-term preservation providers would be dubious.
Tim Brody wrote:
> I can foresee a relatively simple PHP/ASP script that would
> allow an author to manage his/her archivelet from a web page.
Kepler is written in Java, so it could be restructured to run as part of a
server. This would, of course, require that the suer be running a web
and have the admin rights to change it's configuration, something not
One of the key problems I see with Kepler is that there's little or no user
education or encouragement to create and check accurate metadata. Documents
with little or no meaningful metadata are going to be VERY hard to browse
matter how intelligent the Service Provider.
On the bright side, having a very-light-weight OAI implementation will make
testing new implementations against it very easy.
-- stuart yeates <email@example.com> aka `loam'
"To err is human--but it feels divine." -- Mae West
OAI-general mailing list