Metadata Schemas

Metadata Schemas in Use/Of Interest to the Islandora Project

This page provides links to the metadata schemas we are using in our VRE projects, or provide examples models for our work.

  • Administrative/General
  • Library/Bibliographic
  • Images
  • Sound
  • Video
  • BioScience/Chemistry
    • CML (chemistry)
    • Critter (in-house schema)
    • EMBL (gene sequences)
    • EML (ecology)
    • MzXML (mass spec data)
    • NCBI (gene sequences)
    • SNOMED-CT (medical terminology)
  • Business
    • UBL (business processes)
    • XBRL (business)
  • Humanities

General Fedora-Drupal in First Islandora

General Fedora-Drupal

This is a general description of the UPEI Fedora/Drupal system and how we are using bth products, on their own and integrated. This is based on a description created by Paul Pound on March 28, 2008. *

General System and Components

  • Fedora 2.2.1 with fgsearch 1.1, Kowari (xx) and Postgres (XX).
  • Drupal 5.x, php5, and mysql (XX).
  • Lucene (XX), curl (XX)
  • api-a (api-a includes methods to mostly consume the objects) is locked down so authorization is required.
  • api-m (mangement api used for ingest etc.) needs authorization as well and can only be used from specific ip addresses. Both of these settings are pretty common but some users probably have api-a more open and rely on the xacml security policies.

We have drupal on one box, Fedora on another and the databases are on a third.

Search and Display

Currently we send rest type calls to Lucene via Curl. The results are provided in xml that we display using an xslt to transform the results to html.

  • Collection listing: we send an itql query to Fedora's resource index (in our case Kowari as mptStore does not understand itql) via curl/rest. We receive xml results and for the modules in test we are parsing the xml in php but will be switching to xsl. This will give us much more flexibility as we can store the xsl with the collection object.
  • Datastream listing: we send a soap call to Fedora that returns an array which is displayed using php code.
  • Metadata display: we are grabbing the QDC or DC datastream from the object via soap. Since the returned datastream is xml we are using an xsl to transform the stream to html.

Editing and Ingest

  • To edit the metadata we grab the QDC/DC xml stream and parse it to create a html form. In our standalone app we use an xsl, but our newer Drupal-based technique uses Drupal's form api: after parsing it in php we pass a php array to Drupal which builds the form.
  • For ingest each collection will have a collection_policy datastream (if it doesn't have one we can fallback to a standard that is part of the module). The collection_policy defines what content_models are allowed as part of this collection. A content_model in our case defines what type of file can be ingested and what to do to that file (such as create thumbnail etc).
  • All the management functions use soap to add, purge, modify, ingest etc.


  • We are mapping drupal paths/menus to php functions.
  • We use the form api for the forms.
  • We use IMCE to upload the files. By using IMCE we can give file size quotas, and storage limits to drupal roles. We can also limit what type of files they are allowed to upload using IMCE. IMCE is the same widget tinyMCE uses to upload files.
  • We rely on clean urls and the drupal file system being public. Initially we tried to support normal urls and clean urls but it gets to hard to maintain when there are so many paths to something.
  • We have several permissions you can configure which include add fedora datastreams, edit fedora metadata, ingest new fedora objects, purge objects and datastreams, and view fedora collection.
  • Specific roles can have a range of permissions so you can define who can do what.

Importing Refworks into Islandora

The Islandora IR has been setup to use exported refworks citations as the file type for ingest.  Using refworks gives us a few advantages. 

  • We can export citations from many databases providers.  This gives us complete and accurate data to start with (most of the time).
  • Global editing of refworks records.  This is usefull for adding what we call the university name (username) and departments to the refworks record. 

Setting up a RefWorks account for this purpose:

  1. Create an account.
  2. Use the “Customization” feature to re-label User1 to “AuthorID” and User2 to “Department”.  The “AuthorID” will be the same as the username that the faculty members will use to login to the repository to manage their own documents. The “Department” will be the same as the “roles” used in Drupal/Fedora to provide permission control and  provide the ability for users to browse publications by academic department. Often the departments can be retrieved from LDAP and stored as roles in Drupal.  The specific department code should match the “LDAP” provided codes or the roles created in Drupal.

Method 1 – using library databases

  1. Search one or more of your library’s citation databases (e.g. PubMed, EBSCOHost, Proquest, etc.) to find the citations.
  2. . Use the database’s “export to RefWorks” built-in functionality if available. Some databases offer instead the ability to save the citations into a tagged format file which you will need to import into RefWorks using RefWorks’ “filters” (using References – Import).
  3. Once the citations are in RefWorks, you may find some citation data has been imported into the wrong field and needs to be fixed by hand. An example is conference proceedings, which often require moving information to different fields.
  4. Step 4. Edit the records (individually or using global edit depending on how you handled the importation) to add the AuthorID and Department info to each.  You can add multiple authors or departments using semi colons to seperate the values.

Method 2 – manually entering citations into RefWorks

In RefWorks, click References – Add New Reference, select the “Ref Type” to make sure you get the right template for the type of document, then fill in the blanks as appropriate. Make sure you include the AuthorID and Department data.  You can add multiple authors or departments using semi colons to seperate the values.

Final steps – exporting records from RefWorks to the Repository

Regardless of which method you use to get the records into RefWorks, the final step in Refworks is to pull together the new records to be imported into the repository into a single folder.  Use the RefWorks option “References – Export” to select that folder, choose “RefWorks XML” as the format, and export the set. Use your web browser’s “Save Page As” function to save the exported records to a text file for later importation into the repository.

Importing the Refworks file into Islandora

  1. Login to Islandora
  2. Click Digital Repository - located in the left hand column
  3. Click on the Institutional Repository Collection - on the content section of the page
  4. Click on Collection Description to expand the collection's fieldset
  5. Click on the blue ingest folder
  6. Leave Refworks selected and click Next
  7. Choose Browse and find the exported Refworks file you just saved.
  8. Click Next

Islandora will parse the Refworks file and create a citation object for each reference element in the file.  Users with the appropriate roles can then add the full text to the citations.

Islandora Receives Major Grant Funding

Islandora was the recipient of major research funds this month, coming from 2 funded projects under ACOA's AIF (Atlantic Innovation Fund) initiative. DiscoverySpace, led by Mark Leggott, is a 3-year, $2.5 million project to build on Islandora's unique approach to research collaboration and data stewardship with the Virtual Research Environment (VRE) framework. The project will work with the larger open source community to build a rich ecosystem of tools for all research domains. In addition to enhancing the core Islandora software, the project will release dozens of specialized Sprouts, providing rich collaborative environments for a wide range of disciplines. The project will also work toward the development of a service entity that will provide support, hosting and custom development for external partners.

Image removed.

Three innovative projects by UPEI researchers were awarded AIF funding on January 26. Shown here are recipients Mark Leggott, University Librarian; Dr. Don Reynolds, Dean of AVC, accepting on behalf of Dr. Chris Riley; and Dr. Anne Muckle, Clinical Bacteriologist. The Veterinary Laboratory Quality Assurance Program Expansion (VLA-QAP) is a project of the Atlantic Veterinary College (AVC) led by C. Ann Muckle, AVC’s Lab Director of Diagnostic Services. AVC will develop software and systems for web-based delivery of impartial, objective, verification program for veterinary labs to verify and assure diagnosis. The project will use a special version of the Islandora software to deliver their services and resources in a unique online environment. As with the broader Islandora software, applications developed for this project (such as the virtual microscopy system) will be released as open source.