Re: [greenstone-devel] Assigning top level metadata for collection withnavigation

From Katherine Don
DateWed, 03 Mar 2004 14:02:30 +1300
Subject Re: [greenstone-devel] Assigning top level metadata for collection withnavigation
In-Reply-To (20040228184336Z2273409-17128+73-mail4-centrum-cz)
Hi Jakub

First of all, congratulations on what you have achieved so far. It sounds like you have a good understanding of Greenstone.

Greenstone does not handle metadata that is not related to particular files very well. Using the Librarian Interface you can assign metadata to folders as well as to documents, but this is to facilitate assigning common metadata to lots of documents, and it can only be displayed via the documents themselves, not via the folder.

My understanding of your problem is that you'd like to be able to display folders, and navigate between them. And for each folder, display a list of all images in that folder.

To display a folder and its metadata separately from the images, you _will_ need to have a dummy document. Greenstone cannot locate resources unless they have an id, (which means they are a document) or they are associated to a document.
I suggest that you use your gallery html files as the document for each folder. Any folder metadata can be assigned to this file, and then displayed by linking to this file. You could generate a list of the images in the folder as the document content.

So from the folder display, by displaying the [Text] you get the list of images. And using next and previous metadata you can navigate between folder documents.

In the gallery file, to get the thumb icons displaying, you will need to hard code the file path.
The image source url will be something like the following

You cannot put [assocfilepath] directly here as you could do in a format statement, but you can infer it if you know the document id of the image.

What kind of ids are you using for the images? Do you use Greenstone hash ids, or do you generate your own?
$doc_obj->set_OID(); will use greenstone ids, but you can pass in a string to this function, and that wil be assigned as the id.
$oid = "oid1";

The assocfilepath for an associated file (eg thumbicon for a document) is the same path as the doc.xml file is stored in the archives directory.
folders in the archives directory are based on ids, and shortened to be only 8 characters long.
What I suggest you do is modify the way directory names are created in the archives directory, so that the full document id is used as the directory name. This was the assocfilepath for any image will be just the doc id of its document.

You will need to modify (in gsdl/perllib): in sub get_doc_dir {

there is an if-else clause:
if (defined $doc_info && scalar(@$doc_info) >= 1) {
# this OID already has an assigned directory, use the
# same one.
$doc_dir = $doc_info->[0];
$doc_dir =~ s//?doc.xml(.gz)?$//;
} else {
do some stuff splitting oid into 8 char bits and testing whether the dir exists.


You need to comment out all the content of the else clause and put in $doc_dir = $OID;

So now, when you come to put in the links for the thumb icons you know the path to the icon. You may not know the name of the image - if they are all called thumb.jpg or something this would make it easier.

Does this all make sense?
So, have gallery html files for each folder, assign the folder metadata to these, and using the modified oid handling, you can make hard coded links to the thumb icons in the gallery file.

Note, the gallery files could be created by your plugins during importing, if you are not already doing that.

Anyway, have a go at this and let us know how you get on. Please let me know if you don't understand anything I've just said. And, if this solution doesn't work for you we may be able to come up with other ideas.

Katherine, Michael and David (this was a group effort)

Jakub □ehan wrote:

> Hello,
> I'm writing thesis about Greenstone that should describe the system to Czech users. Along with this, I'm also working on few collections that should demonstrate the potential of Greenstone. One of the tasks I should do is to create a collection of photographs - the image of existing collection (called DKF in the text)created and maintained on Masarykiana University in Brno, Czech Republic. The requested functionality is given and I should try to reach it using Greenstone (of course with some exceptions, because Greenstone is more generic and not designated only for maintaining photographs).
> I did almost all I needed, but then I got stuck with displaying some metadata. I will describe the problem so that my "problem" will be presented in context:
> From the original collection I got metadata stored in XML format and the image files. The original structure of collections can be described like:
> library
> -- folder*
> ----- photography*
> -------- instance*
> where:
> folder - set of photographs covering the related topic
> photography - container of different versions of the same image (different resolutions)
> instance - the image itself
> Important associated metadata are ID, Title, Description, Previous, Next (folder, photograph) and filename, resolution (instance).
> In the original collection (DKF) user can view the folders, go to previous/next folder/image and view the photographs in different resolutions (many other functions like adding image to favorites, sending it by e-mail ... - but that wasn't my goal).
> I converted the metadata into Greenstone directory metadata format so that all important metadata about one photograph (= title, description and metadata about all the instances) are in one Fileset element. The element is bound to filename of representative instance (I chose the one with the highest resolution, but it really doesn't matter).
> Then I created new plugin that accepts all graphic formats. It checks if there are some metadata associated with the file being processed and if so, it creates new document. All the metadata are associated with this document and also all the instances of images are asociated (as files). The plugin generates internal address (based on the import directory and unique identifier) to allow navigation between documents in one folder.
> Finally I altered main.cfg file and made new cgiarg available. This argument is used when viewing the document to decide what resolution (i.e. large, normal or thumbnail) should be shown. It also allows to retain the resolution when navigating through the collection using previous/next.
> To this point everything works fine - I have collection of images with navigation, different resolutions and all the metadata - all except the ones on the folder level.
> And that is my problem - I don't know how to make available the metadata on folder level. There are no physical documents to bind the md to. I thought about creating "blind" documents - only to hold the metadata ... but it isn't good solution.
> I have also tried to generate "gallery" from the metadata - html like file that would contain links to all images in the folder and would have associated folder level metadata with it. But there is the problem, that I can't get to the image files associated with the documents (there is no way (or I don't know it) how to get link to image associated with different document). That is - I can easily insert links to the documents, but I cannot show the thumbnails (which is quite important when talking about gallery :-)).
> So - I have the gallery with the main ("bottom") level working fine, but all the folder metadata are lost (which is unacceptable).
> I would like to ask if you have any suggestions how to solve this problem - to assign "pure" metadata, that are linked to sets of different documents rather than to one specific document. And (equally important), where and how to show the metadata.
> I really apologize for the length of this text - I only wanted to fully describe the problem. I sought the mail archives for this topic, but I haven't found anything.
> Thanks for any suggestions or comments,
> have a nice day
> --
> Jakub Rehan
> --------------------
> P□□□LOHA O DAN□CH! Jak p□iznat dan□, on-line formul□□□e pro v□po□et dan□, da□ov□ tiskopisy ke sta□en□, adres□□□ finan□n□ch □□□ad□ na
> _______________________________________________
> greenstone-devel mailing list