[greenstone-devel] Greenstone custom metadata

From Matei Lunca
DateThu, 15 Jun 2006 21:55:31 +0200 (CEST)
Subject [greenstone-devel] Greenstone custom metadata

If anyone knows how to troubleshoot this, we would appreciate a reply.

I've set up a Greenstone library for a faculty of Utrecht University, The
Netherlands. Ours has a custom metadata set that is made up out of form
results that have to do with written reports.

The form results get parsed and written to a neat and simple xml format
bij a small Java program I've written. No problemo.

The import and build scripts for Greenstone get run from the command line
with a Unix bash script. All done by the book according to the regulations
of the Developer's manual. Works well, although Greenstone reports that it
cannot parse a few XML documents that it creates itself (!). (Source docs
for testing are all Word .doc, not much out of ordinary stuff in there.)

The problem is the following: When importing the collection in the
Greenstone client the metadata does not show up. I know Greenstone sees my
custom metadata file, because when I take the file out of the "metadata"
subfolder of the collection, the Greenstone client objects and proposes to
build a Dublin Core or other standard metadata set. This is reasonable.
The thing is, there is not much else in the way of error reporting that
can point me to what I am doing wrong. No "System.out.println()" as it
where for the programmers out there.
Either the Windows format that I am writing the xml, cfg and so on files
in gets unreadable chars in Unix, or I get filenames/file locations wrong.
Where is it documented that one should name custom metadata files A and
put them in folder B?

The collection is reachable through the web page, but the metadata does
not show up, only bare documents/html, and the possible search category
drop down menu contains descriptions like _dtx_ and such in stead of
"Title", "Subject", and so on.

Anyway, kudos to the Greenstone development team. I hope somebody out
there can offer me a hint to solve our problem here.


Matei Lunca, Utrecht University, The Netherlands