Overview

The Islandora module is a Drupal module written to allow the Drupal content management system to act as a front end to the Fedora Digital Repository.The module enables viewing and management of Fedora objects. This includes ingest, purge, add data stream, searching and browsing by collection. This version of the module does not store any data regarding any of the Fedora Objects in the Drupal database. The only data stored in Drupal is the configuration data telling Drupal how to connect to Fedora.

This version of the documentation refers to the Drupal 6/Fedora 3 version of the Islandora module. An earlier version works with Drupal 5/Fedora 2 but will probably not be maintained.

Requirements

To use the module you will need to have both Fedora and Drupal installed and have a basic understanding of Fedora, Foxml 1.1, and Drupal.

To take full advantage of the module you will need to enable the Fedora Resource Index in the Fedora config file.  You  should also have Fedora gsearchinstalled.  Fedora gsearch includes Lucene and enables full text searching.

Other requirements beyond what is needed by Fedora and Drupal include:

• PHP5-curl
• PHP5-soap
• PHP5-xsl
• Clean URLs enabled in Drupal
• Drupal file system may need to be set to public.

Optionally you may want Imagemagick and Ghostscript installed to create thumbnails from pdfs on ingest.

Conventions and Policies

To make the module more flexible and useful we have also made some specific decisions regarding our Fedora objects. For the module to be able to browse collections, your collection objects should have a hasModel entry in the RELS-EXT datastream that points to islandora:collectionCModel. This lets the module know that the object represents a collection and it will then query for objects that are members of this collection.

Installation

Before installing any of the Islandora modules make sure you have Fedora and Drupal installed and properly configured.  Make sure you can use the admin tools in Fedora to ingest and purge etc., before you try to configure Islandora. 

To install the Fedora drupal module all you have to do is extract the fedora_repository.zip to the correct directory on the Drupal server. Most modules in Drupal are installed in the sites/all/modules or the sites/default/modules directory. For multi-site Drupal installs you can also put it in sites/sitename/modules.

For more information on installing Drupal modules you can check the Drupal documentation.

Once the files are in place you have to login in to Drupal and configure the module.

Configuring

The first thing that needs to be done is to enable the module. To do this login to Drupal, choose Administration->Modules and find the Digital Repository module in the list of modules. Enable the check box associated with the Digital Repository module and then click Submit.

Once the module is enabled there are basically two parts of the module that need to be configured. The first part is the Fedora connection information, which include URLs needed to pass/receive data from Fedora. The second part of the configuration involves configuring permissions to determine who can do what to Fedora objects from within Drupal.

There are various ways to get to the module admin area in Drupal. The easiest is to click on Administer, then click on the by module tab. Find the Digital Repository section and click on Fedora Collection List.

Modify the settings so they match your server. Usually the only thing that you will need to change would be localhost (which is the default setting) to your Fedora server's ip or domain name. You will probably have to change the name of the Lucene index name to match your FGSearch index name. The Fedora Default Display Object PID and Fedora Datastream ID are defaults used by Drupal when it can't find a pid/datastream so you will want to point these to an object/datastream that exist in your Fedora repository. Usually it is an image that says object not found or image not available.

There are a couple of text entry fields that you cannot see in the image above.  One of these is Pid namespaces allowed in this Drupal install.  If you want to be able to view or manage Fedora objects their pid namespaces must be listed here.  Similar to the retain pid namespaces in the older versions of Fedora config file.

Drupal Servlet Filter

Download the DrupalFilter.jar file from here: Link

The latest version of the module no longer connects to Fedora using the fedoraAdmin user. We now connect to Fedora as the Drupal user. This allows greater flexibility in who can do what to an object. For more info on how we use XACML check out the wiki page here

To install the Drupal servlet filter you should copy the DrupalFilter.jar file to the Fedora webapps classpath, for example $FEDORA_HOME/tomcat/webapps/fedora/WEB-INF/lib. If Drupal has a different database backend than Fedora you will also have to drop the database driver's jar file in this directory as well. For instance if are using postgres for Fedora and Mysql for Drupal you will need the mysql jar file on your path so the servlet filter can connect to the Drupal database.

To enable the servlet filter to connect to your Drupal database you will also have to edit an xml file and place this file in the same directory as your $FEDORA_HOME/server/config/fedora.fcfg file. This file should be called filter-drupal.xml and look similar to this:

<?xml version="1.0" encoding="UTF-8"?>
            <!--File to hold drupal connection info for the FilterDrupal servlet filter.  For multisite drupal installs you can include multiple connection elements.  We will query all the databases and assume any
              user in any drupal db with the same username and password are the same user.  We will gather all roles for that user from all databases.  This is a potential security risk if a user in one drupal db has the same username and password
              as another user in a seperate drupaldb.  We are also assuming all drupal dbs to be mysql.  This file should be located in the same driectory as the fedora.cfcg file-->
            <FilterDrupal_Connection>
              <connection server="localhost" dbname="drupaldb" user="dbuser" password="password" port="3306">
                <sql>
                  <!--Different sql statement for each connection.  This is for drupal multisites that are setup using one database with table prefixes.  We don't do this but some people might.-->
                  SELECT distinct u.uid as userid, u.name as Name, u.pass as Pass, r.name as role FROM users u,role r, users_roles where u.name=? and u.pass=? and r.rid=users_roles.rid and u.uid=users_roles.uid;
                </sql>
              </connection>

            </FilterDrupal_Connection>

If you have a multi-site Drupal install the connection element can be repeated to include multipe Drupal databases

Once you have the DrupalFilter jar in place and the xml file configured, you will have to edit $FEDORA_HOME/tomcat/webapps/fedora/WEB-INF/web.xml to use the Drupal Servlet filter. You will have to add two entries to this file.

1. In the <filter-name> section between the XmlUserfileFilter and the EnforceAuthnFilter and
2. In the <filter-mapping> section.

See example below:

<filter>
            <filter-name>XmlUserfileFilter</filter-name>
            <filter-class>fedora.server.security.servletfilters.xmluserfile.FilterXmlUserfile</filter-class>
          </filter>
          <filter>
            <filter-name>DrupalFilter</filter-name>
            <filter-class>ca.upei.roblib.fedora.servletfilter.FilterDrupal</filter-class>
          </filter>
          <filter>
            <filter-name>EnforceAuthnFilter</filter-name>
            <filter-class>fedora.server.security.servletfilters.FilterEnforceAuthn</filter-class>
          </filter>
          And here

             <filter-mapping>
               <filter-name>XmlUserfileFilter</filter-name>
               <url-pattern>/*</url-pattern>
             </filter-mapping>
             <filter-mapping>
               <filter-name>DrupalFilter</filter-name>
               <url-pattern>/*</url-pattern>
             </filter-mapping>
             <filter-mapping>
               <filter-name>EnforceAuthnFilter</filter-name>
               <servlet-name>AxisServlet</servlet-name>
             </filter-mapping>

You will now have to start or restart Fedora to enable the Drupal servlet filter.

To verify the Drupal filter is working you can try to sign into the Fedora Admin client using a username from the Drupal database. For the password, use the password that is stored in the Drupal users table as is (you will be using the hash not the actual password).

PHP

For uploading large files you may have to modify the php.ini file and or possibly the settings.php file for your drupal site.

Drupal Permissions

You can assign various permissions to Drupal roles. You can also create custom roles in Drupal. For more information on Drupal roles visit the Drupal website.
By configuring the modules permissions you can limit who sees the objects in the Fedora Repository by role. This means you could have users that can admin objects and users who can only view, for example, but if a user can add a data stream to one object they can do it for all objects.  For finer grained policies you would need to use XACML POLICY streams in each object.

XACML Security

Since Fedora is made aware of Drupal usernames and roles via the Drupal Servlet filter we can now add XACML Policy streams to Objects. Fedora will make decisions based on the POLICY datastream combined with the username/roles of the current Drupal user.  More information regarding XACML is included below under Architecture.

Architecture

Fedora does not really have a sense of Collections or Communities etc., everything is an object.  But an object can act as a collection through relationships.

Full Size

ERROR: You are using a new version of the Gliffy Plugin for Confluence, but have not purchased a new license. To create new diagrams, either revert to an older version of the plugin, or purchase an upgrade license

^{The diagram above demonstrates the relationship between collection objects, objects and content model objects.}

Collection Objects

In Islandora a collection object is the same as any other object.  Except Collection objects should have a hasModel relationship to the islandora:collectionCModel and they must have a COLLECTION_POLICY datastream.  This relationship tells Islandora that this is a collection object.  It will then query the resource index for objects that have a relationship of isMemberOfCollection to this collection object.

The isMemberOfCollection is the default relationship used by Islandora, you can use others by specifing the relationship element in the collection policy xml.  You would then have to store a QUERY datastream in the collection object.

The islandora:collectionCModel defines three datastreams:

• COLLECTION_POLICY
• COLLECTION_VIEW
• CHILD_SECURITY

Collection Policy

A Collection policy is an XML datastream in a Fedora object with a dsid of COLLECTION_POLICY. The collection policy defines what CONTENT_MODELS are allowed to be ingested and related to this object. An example of a COLLECTION_POLICY may look something like:

<?xml version="1.0" encoding="UTF-8"?>
          <collection_policy>
            <!---we will define allowed mime types and what to do with various types as part of the content model-->
            <contentmodels>
              <contentmodel name="REFWORKS">
                <pid_namespace>vre:ref</pid_namespace>
                <pid>islandora:refworksCModel</pid>
                <dsid>ISLANDORACM</dsid>
              </contentmodel>

              <contentmodel name="STANDARD_PDF">
                <pid_namespace>vre:pdf</pid_namespace>
                <pid>islandora:standard_pdfCModel</pid>
                <dsid>ISLANDORACM</dsid>
              </contentmodel>
            </contentmodels>
           </collection_policy>

The above XML would allow two types of objects to be ingested. It would allow STANDARD_PDF and REFWORKS. How these are ingested and viewed is determined in the actual CONTENT_MODEL data stream.

Collection View

A collection view data stream is a data stream that contains an XSLT that defines the view of the list of objects. The collection view data stream must have a dsid of COLLECTION_VIEW. An example of a COLLECTION_VIEW may look something like this: [Example collection view code]

The Drupal Fedora module asks for the query to return SPARQL XML so a query like:

select $object $title $content from <#ri>
where $object <fedora-model:label> $title
and $object <fedora-model:hasModel> $content
and $object <fedora-rels-ext:isMemberOfCollection> <info:fedora/demo:pid>
and $object <fedora-model:state> <info:fedora/fedora-system:def/model#Active> order by $title

Would return results like:

sparql xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result">
  <head>
    <variable name="object"/>
    <variable name="title"/>
    <variable name="content"/>
  </head>
  <results>
    <result>
      <object uri="info:fedora/vre:ref-coll-188"/>

      <title>A Test Collection</title>
      <content uri="info:fedora/fedora-system:FedoraObject-3.0"/>
    </result>
    <result>
      <object uri="info:fedora/vre:ref-coll-188"/>
      <title>A Test Collection</title>
      <content uri="info:fedora/islandora:collection"/>
    </result>

    <result>
      <object uri="info:fedora/test:mark-library-1009"/>
      <title>Building a Library 2.0 Tapestry</title>
      <content uri="info:fedora/fedora-system:FedoraObject-3.0"/>
    </result>
    <result>
      <object uri="info:fedora/test:mark-library-109"/>
      <title>Building a Library 2.0 Tapestry</title>

      <content uri="info:fedora/fedora-system:FedoraObject-3.0"/>
    </result>
    <result>
      <object uri="info:fedora/test:mark-library-141"/>
      <title>Coping With Change: Sys/Admin</title>
      <content uri="info:fedora/fedora-system:FedoraObject-3.0"/>
    </result>
</sparql>

You would use the XSLT above to transform the SPARQL XML  to HTML.

Child Security

All objects ingested and related to a collection object will look for a CHILD_SECURITY datastream in the collection object.  This stream will then become the POLICY stream of the newly ingested object.  This basically gives us security at the collection level.  All objects in that collection will have the same POLICY stream.  If there is no CHILD_SECURITY stream at the collection level we will assume the object is publically viewable and can be managed by the user who ingested it there will be no POLICY stream at the object level and Drupal permissions and global XACML policies will be the only barriers to modifing this object.

Anonymous users

If you would like anonymous users to be able to view public objects using Islandora you will have to add a user to the $FEDORA_HOME/server/config/fedora-users.xml file.

 <user name="fedora_anonymous" password="anonymous">
          <attribute name="fedoraRole">
            <value>fedoraUser</value>
          </attribute>
        </user>

Islandora will send the username of fedora_anonymous and password of anonymous for all unauthenticated use.

Collection Query

A Collection object may have a QUERY datastream. If the object does have a datastream with a dsid of QUERY the Islandora module will attempt to use it to get a list of objects that are related to that collection object. If there is no QUERY datastream the module will try the generic one shown in this document. Any custom query/XSLT combo should be written to expect SPARQL as the result.

Content Models

As mentioned in Collection Policy above, Islandora uses Content models to determine what mimetypes are allowed to be ingested and what to do with the object on ingest. For instance, a PDF content model may tell the module to create a thumbnail and ingest the thumbnail as a datastream along with the actual PDF datastream.  This extends the Fedora Content Model Architecture (CMA).

Also in our content model you can define the data entry form you would like the module to display as well for that object type. This enables the display of different data entry forms for different object types.

Using the display_in_fieldset XML element we can also determine how the object is displayed when a user drills down to the object view.  You can also define what to do when a datastream is added.

Currently the Islandora content models are stored as XML datastreams in a Fedora Content Model object with a datastream id of ISLANDORACM. The collection policy datastream references different content models and therefore determines what type of object can be ingested in a collecton. The Make Demo Smiley Stuff Islandora Aware page has some examples of Collection Policies and Content Models. There are also some sample content models linked to below in the adding a content model section.

In the content models we are really doing is providing hooks that can be called at appropriate times, such as add datastream, edit meta data, ingest etc.  The functions that are called by these hooks could then read more XML from the content model, for instance defining a data entry form.  By using Islandora Content models you can make Islandora use the code that you provide.  You would drop your php code into the modules directory (probably under the plugins directory within the module) and then using the XML above you would be able to call your custom code or a combination of existing and custom code.  Of  course you would have to have write access to the directory to copy your code.

Collection and Object Admin

If you have the appropriate Drupal permissions you will be able to ingest, purge, add datastream etc. In Drupal your permissions are determined by the roles of the user you are logged in as.  These permissions can be limited further by XACML policies.  For instance if you have a Drupal role that says you are allowed to add datastreams you will be allowed to add datastreams to all objects, except objects that have a XACML policy that denies it.  View can also be blocked at the Fedora level using a XACML policy.

To manage objects in Fedora you browse to the object and if you have the correct permissions you would be able to add a datastream, purge a datastream, edit the metadata, or purge the object.
Currently you have to edit raw XML to edit collection policies, content models, collection views etc.  For instance to change a collection view you would browse to the collection object, download the COLLECTION_VIEW stream, modify the XML, purge the COLLECTION_VIEW stream and then add the modified file back as a datastream with an id of COLLECTION_VIEW.  There are some sample XML files shipped as part of the module.  These files include some Islandora content model, collection view, and collection policy example files.

Creating an Islandora Content Model

The best way to create a content model would be to use the Fedora Admin client.  We would like to have all objects created in Islandora but for now the best way to create a Content Model would be using the Fedora Admin client.  There is some documentation on the admin client here.  It is for Fedora 2.2.4 but most of it will be the same.

Once you are signed into the admin client you can go File->New->Content Model.  Then enter a description of the content model and you will probably want to give it a custom pid.  A custom pid will be easier to remember and document.  If you don't use a custom pid you will end up with something meaningless like changeme:5.  More info regarding Fedora content models can be found here.

You can now click on the datastream tab of the Admin client.  The DS-COMPOSITE-MODEL stream contains information on what datastreams objects of this type will have.  You will probably want to edit this stream to add information regarding datastream id's and mimetypes.

To enable Islandora to make use of the newly created content model you will need to add an Islandora XML datastream.  This datastream should have a dsid of ISLANDORACM.  Currently the only way to create an ISLANDORACM stream is by hand.  You can start with a sample and edit it in an XML editor.

The ISANDORACM stream is XML that tells Isandora what to do with an object when it is ingested, metadata is modified, a datastream is added and when viewing.  In the xml you reference php functions that will be called at the appropriate time.

The snippet below is part of the ISLANDORACM stream we have added to the demo:DualResImage content model object.  The snippet below describes what to do when viewing the object   See the comments for an explanation.

 <display_in_fieldset> <!--when an a user drills down to the objects page the php functions below will be
called to display the object.  To see the php functions view the modules source code and find the file
referenced in the xml-->
    <datastream id="MEDIUM_SIZE">
      <method> <!-- this will show the MEDIUM_SIZE datastream inline on the page -->
        <file>plugins/ShowDemoStreamsInFieldSets.php</file>
        <class_name>ShowDemoStreamsInFieldSets</class_name>
        <method_name>showMediumSize</method_name>
      </method>
    </datastream>
    <datastream id="QDC"> <!-- this will show the dublin core xml stream via an xslt in a collapsed fieldset-->
      <method>
        <file>plugins/ShowStreamsInFieldSets.php</file>
        <class_name>ShowStreamsInFieldSets</class_name>
        <method_name>showQdc</method_name>
      </method>
    </datastream>
    <datastream id="FULL_SIZE"> <!-- there is no method here so the FULL_SIZE stream will not be included in
the view but the default detailed list of content will link to the stream-->
      <allowed_mime_type>image/jpeg</allowed_mime_type>
      <add_datastream_method> <!-- when adding a datastream the function below will be called.-->
        <file>plugins/ImageManipulation.php</file>
        <class_name>ImageManipulation</class_name>
        <method_name>manipulateImage</method_name>
        <modified_files_ext>jpg</modified_files_ext>
        <datastream_id>MEDIUM_SIZE</datastream_id>
        <parameters>
          <parameter name="width">120</parameter>
          <parameter name="height">160</parameter>
        </parameters>
      </add_datastream_method>
    </datastream>
  </display_in_fieldset>

The snippet below is from the same file but tells Islandora what to do when a new object of this type is ingested.

 <ingest_rules>
    <rule>
      <applies_to>
              image/jpeg
            </applies_to>
      <methods>
        <method> <!-- the function manipulateImage will be called when a new image is uploaded
this function will take the uploaded file, scale it and add it as MEDIUM_SIZE datastream-->
          <file>plugins/ImageManipulation.php</file>
          <class_name>ImageManipulation</class_name>
          <method_name>manipulateImage</method_name>
          <modified_files_ext>jpg</modified_files_ext>
          <datastream_id>MEDIUM_SIZE</datastream_id>
          <parameters>
            <parameter name="width">160</parameter>
            <parameter name="height">120</parameter>
          </parameters>
        </method>
      </methods>
    </rule>
  </ingest_rules>

The snippet below says what datatstream to create from the data entry form.  In this case there is also XML that the ingest php function will use to build the data entry form.

 <ingest_form dsid="QDC" page="2">
    <form_builder_method>
      <file>plugins/DemoFormBuilder.php</file>
      <class_name>DemoFormBuilder</class_name>
      <method_name>buildQDCForm</method_name>
      <form_handler>handleQDCForm</form_handler>

    </form_builder_method>
    <form_elements>
      <element>
        <label>Title/Caption/Image Name</label>
        <name>dc:title</name>
        <type>textfield</type>
        <description>The name given to the resource</description>
        <required>true</required>
      </element>
      <element>
        <label>Creator/Photographer</label>
        <name>dc:creator</name>
        <type>textfield</type>
        <description>An entity primarily responsible for making the content of the resource such as a person, organization or service.</description>
        <required>true</required>
      </element>
      <element>
        <label>Subject</label>
        <name>dc:subject</name>
        <type>select</type>
        <description>Subject</description>
        <required>false</required>
        <authoritative_list>
          <item>
            <field>image</field>
            <value>image</value>
          </item>
          <item>
            <field>photograph</field>
            <value>photograph</value>
          </item>
          <item>
            <field>presentation</field>
            <value>presentation</value>
          </item>
          <item>
            <field>art</field>
            <value>art</value>
          </item>
        </authoritative_list>
      </element>
      <element>
        <label>Description</label>
        <name>dc:description</name>
        <type>textarea</type>
        <description>Description of the Image</description>
        <required>true</required>
      </element>
      <element>
        <label>Publisher</label>
        <name>dc:publisher</name>
        <type>textfield</type>
        <description>An entity, (including persons, organizations, or services), responsible for making the resource available.</description>
        <required>false</required>
      </element>
      <element>
        <label>Contributor</label>
        <name>dc:contributor</name>
        <type>textfield</type>
        <description>An entity responsible for contributing to the content of the resource such as a person, organization or service.</description>
        <required>false</required>
      </element>
      <element>
        <label>Date</label>
        <name>dc:date</name>
        <type>textfield</type>
        <description>Temporal scope of the content if known. Date format is YYYY-MM-DD (e.g. 1890,1910-10,or 2007-10-23)</description>
        <required>false</required>
      </element>
      <element>
        <label>Resource Type</label>
        <name>dc:type</name>
        <type>textfield</type>
        <description>Genre of the content of the resource. Examples include: home page, novel, poem, working paper, technical report, essay, dictionary.</description>
        <required>false</required>
      </element>
      <element>
        <label>Source</label>
        <name>dc:source</name>
        <type>textfield</type>
        <description>A reference to a resource from which the present resource is derived.</description>
        <required>false</required>
      </element>
      <element>
        <label>Identifier</label>
        <name>dc:identifier</name>
        <type>textfield</type>
        <description>A unique reference to the resource; In this instance, the accession number or collection number.</description>
        <required>false</required>
      </element>
      <element>
        <label>Language</label>
        <name>dc:language</name>
        <type>select</type>
        <description>The language of the intellectual content of the resource.</description>
        <required>false</required>
        <authoritative_list>
          <item>
            <field>eng</field>
            <value>English</value>
          </item>
          <item>
            <field>fre</field>
            <value>French</value>
          </item>
        </authoritative_list>
      </element>
      <element>
        <label>Relation</label>
        <name>dc:relation</name>
        <type>textfield</type>
        <description>Reference to a related resource.</description>
        <required>false</required>
      </element>
      <element>
        <label>Rights Management</label>
        <name>dc:rights</name>
        <type>textarea</type>
        <description>Information about intellectual property rights, copyright, and various property rights.</description>
        <required>false</required>
      </element>
    </form_elements>
  </ingest_form>

There are some interesting examples of ISLANDORACM streams here and here.  Right now there is a little overlap with the ISLANDORACM datastream and the Fedora DS-COMPOSITE-MODEL stream in that they both list datastreams and mimetypes.  Our XML schema is not yet finalized so we may try to reduce this duplication but the priority for this is not very high right now.

Adding a Collection Policy to a Collection Object

As noted earlier a Collection Policy is a datastream in a Collection or Parent type object that says what object types are allowed to be related to this object on ingest and can optionally specify the relationship to use.  If there is no relationship element the default relationship will be isMemberOfCollection.

Below is a snippet of the COLLECTION_POLICY stream we added to the demo:SmileyStuff object.

 <contentmodels>
    <contentmodel name="STANDARD_JPEG">
      <pid_namespace>demo:Smiley</pid_namespace>
      <pid>demo:DualResImage</pid>
      <dsid>ISLANDORACM</dsid>
    </contentmodel>
  </contentmodels>
  <relationship>fedora:isMemberOf</relationship><!-- the demo Smiley Stuff QUERY stream queries for isMemberOf
so we will use that relationship on ingest-->

Creating a COLLECTION_POLICY stream is similar to creating an ISLANDORACM stream in that you will have to create the XML by hand.  It is probably best to start with an example collection policy, edit the example and save it as a different name.  You can use the Fedora Admin client to add the COLLECTION_POLICY stream or use Islandora itself (Browse to the Collection object expand the detailed list of content and add the datastream).  The main requirement is that the datastream have a dsid of COLLECTION_POLICY.

Some examples of Collection Policy XML can be found here and here.

Adding a Child Security Policy to a Collection Object

To enable Islandora to use XACML policies you will need to add a datastream with a dsid of CHILD_SECURITY to any object that will act as a collection type object.

Creating and adding this stream is similar to the COLLECTION_POLICY and ISLANDORACM streams above.  They will have to be created/modified by hand in a XML editor.  Currently the only way to add these streams is using Islandora and the add stream form or using the Fedora Admin client.  For instance to add security for the demo:SmileyStuff collection you would add an XACML stream with a dsid of CHILD_SECURITY to the demo:SmileyStuff object.

This stream will then be added to all objects ingested in this collection as its POLICY stream.  Be careful with POLICY streams as all access to an object can be lost if an object has an invalid POLICY stream.

We are also parsing the CHILD_SECURITY stream of the collection object to determine what users/roles can ingest at this level.  This means that for now the XACML policies will have to be parseable by our simple parser.  Eventually we may add a callout as determined by the Collection Policy to determine who can ingest in this collection.

Our XACML policies start out by denying access and then providing exceptions for users with certain roles or loginids.  We parse the file looking for these roles/ids and if the user has any we allow them to ingest in this collection.

An example XACML policy can be found here.  This policy will allow all users to view but only the role administrator and user fedoraAdmin can modify.  This could be the starting point of other policies and by adding users and roles determine who can modify the objects.  Here is another example that could be used as a starting point.  This example will block all users access to all actions except to the users and roles listed.

Depending on your global XACML policies you may have to add a policy file to the $FEDORA_HOME/data/fedora-xacml-policies/repository-policies that will allow users that do not have the role of administrator to ingest objects (if you want non admin users to be able to manage objects).  An example XACML policy that will allow this can be found here.  This file will work as an example but opens API-M to all authenticated users.  If you have an XACML policy in every object that limits API-M this may be ok but you will probably want to modify this global policy to only allow certain roles to access API-M.

By combining Drupal permissions and the Fedora XACML policies we hope to be able to keep the XACML relatively simple.

Enabling Search and Advanced Search

To enable searching in Islandora you would have to:

1. Install and configure Fedora Gsearch which includes Lucene.  Edit the appropriate foxmlToLucene.xml to index the fields you would like to be searchable.  By default the Dublin Core and many of the Fedora properties are indexed.
2. Modify the Islandora admin interface so it is pointing to the index you just configured.  The default gsearch index name is BasicIndex.
3. Turn on Drupal search and configure the Drupal search block (See the Drupal docs on how to do this). This will give you the default search behaviour and Islandora adds a tab to the search results page that shows the results from the repository.
4. Islandora also includes a rudimentary advanced search block. This block allows boolean searching across fields.  To enable this block login to Drupal and goto Administrator->Blocks.  Tell Drupal where to show the block.  You can also configure the block to show how many times to repeat the search fields.
5. If you have modified the foxmlToLucene file you will want to modify the searchTerms.xml file so you can query your custom fields.  The searchTerms.xml is located in the root directory of the Islandora module.  A sample can be found here.

Installing Islandora's Demo Objects

We added the ability to ingest some demo objects from the Islandora admin interface.  From this same interface you can also automatically update the demo:SmileyStuff collection with a COLLECTION_POLICY, COLLECTION_VIEW, when updating the demo:SmileyStuff the installer will also update the demo:DualResImage content model.  To enable Islandora to update the demo:SmileyStuff collection you must run $FEDORA_HOME/client/bin/fedora-ingest-demos.sh.  This script will install the Fedora demo objects.

To install the demos you must have already installed and configured Fedora, Drupal and the Islandora module.  If Fedora and Islandora/Drupal are configured properly and you are logged in with the appropriate rights you can:

• Click the Administrator link
• Find the Fedora Collection List link and click on it.  You should now be on the Islandora admin page.
• There is a tab at the top that says Install Demos.  It would look similar to below.  In the image below most of the demo objects are installed/updated.  If you were starting from scratch there would be five check boxes.demosInstall.jpg
• Choose the demos you would like to install.  If this is your first install you may want to install all the demos to get an idea how Islandora works.

You may still want to read the instructions on how to make Islandora aware of the demo:SmileyStuff collection.  It makes use of Content Models, Collection Policies etc.

Using the Fedora demo objects

Instructions on how to make the Fedora demo objects visible in Fedora can be found on this page: [Make Islandora aware of the demo SmileyStuff collection]

Installing a New Collection

If you installed the Islandora Demo objects you now have a top level collection.  This collection has a COLLECTION_POLICY stream that says you can ingest other collections.  Ingesting a collection is the same as adding any other item except the file you are uploading is not an image, pdf, or audio etc.  The file you are uploading is an xml file.  The xml file will be the COLLECTION_POLICY for the new collection object.

Once you have the demos installed you can add your own collection to the Islandora top collection.

• Navigate to the Islandora top collection.  It should be set as your default out of the box.  If it is not you can http://$DRUPALBASEURL/fedora/repository/islandora:top/-/Islandora+Top+Level+Collection.
• Click on Collection Description to expand the collections fieldset.
• Click on the folder icon.  This will start the ingest process.
• Click next.  There is only one Content Model associated with this collection.
• Click Browse.  Choose a file to ingest.  This should be an xml Collection Policy File.  Here is an example file. LINK

If you used the Collection Policy linked to above you will now be able to ingest jpgs into the new collection.