Project

General

Profile

Actions

Bug #324

open

perl implementation of harvester api

Added by Matt Jones over 22 years ago. Updated almost 21 years ago.

Status:
In Progress
Priority:
Immediate
Category:
Harvester
Target version:
Start date:
11/08/2001
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
324

Description

Need to implement registry and harvester.


Related issues

Blocked by Metacat - Bug #162: need harvest/batch load for metacatResolvedDuane Costa10/24/2000

Actions
Blocked by Metacat - Bug #325: create site filters to convert site metadata to eml packagesResolvedDuane Costa11/08/2001

Actions
Actions #1

Updated by James Brunt about 22 years ago

Matt Jones and David Blankman can provide the start of the requirements for
this program based on discussions we had at the October meeting and a flow
diagram of communication with metacat that we produced. This development should
be done in close communication with Matt and the other KNB developers. There
are also some packaging related problems that will need to be addressed but
alas that is another bug.

Actions #2

Updated by Owen Eddins almost 22 years ago

April 11 David, Owen and James had an impromptu Harvester meeting and decided
that for purposes of 'Harvesting' .xml files that the web service architecture
did not make any sense. To much overhead to try and manage arbitrary files on
a file system. What we were trying to do with the current design was create a
lightweight dbms with out providing any controls on how files got in or out of
the 'dbms'. What we decided was we needed a one time metacat loader tool to
upload in to Metacat a .xml file. See cvs pubs for old design of Harvester. A
new design doc will be placed in pubs directory with metacat loader design for
further discussing. It was decided that all the ideas we had been discussing
for the web service were appropriate but only for harvesting metadata out of
RDBMS.

Actions #3

Updated by Owen Eddins over 21 years ago

Just an update. Currently looking in to Morpho classes and how to adapt them
to create a generalize client interface to Metacat. From this we're going to
create a command line tool for one time uploading of .xml files and datafiles
in to metacat.

Actions #4

Updated by Matt Jones over 21 years ago

Excellent. You might also consider looking at the Metacat.pm perl module that I
wrote. It is a perl client interface to metacat, and I think it is the easiest
way to access the metacat system from the command line. I wrote it to use in
the NRS and OBFS data registries, which use perl as a backend to their HTML form
submission pages. Just a thought. You can find it in the webmdentry module on
cvs.nceas.ucsb.edu (I think the path is webmdentry/src/Metacat). There are some
examples of its use in there as well (load-dataset.cgi and load-dataset.pl).

Actions #5

Updated by Owen Eddins over 21 years ago

Matt,

Thanks for responding. Yes, I looked in to using your perl scripts to do this
and I agree that they probably are a quicker solution for a command line tool.
It's essentially written already for pre beta 9 EML. I downloaded it and
installed it and got it working easily. The problem is that we also are
working on creating an automated data replication engine (essentially the
Harvester with a cooler name) and a web service interface to the Metacat that
implements a WSDL I have hacked up to define a very light weight 'API' for
EML. I spent some time last week looking at the Morpho classes and they look
like they can lend themselves easily to being turned in to a generic client
side set of classes. Since we are looking in to other methods of connecting to
Metacat other than Morpho generializing these classes seems a worth while
effort. The ClientFramework class is the big one but other that most of the
others seem pretty general. Most of the methods in MetacatDataStore seem
relevent to the 'API' I'm thinking of. What do you think?

Actions #6

Updated by Redmine Admin almost 11 years ago

Original Bugzilla ID was 324

Actions

Also available in: Atom PDF