Intrallect intraLibrary 2.8: Administrator's Guide

This document is for intraLibrary administrators carrying out routine administration tasks. For first-time configration tasks see the Configuration Guide.

One or more users may have an administration role in an installation of intraLibrary. When they log-in to intraLibrary these users see an extra Admin Tools section in the toolbar.

When the Admin Tools option is selected an additional toolbar becomes available.

This document describes the facilities that are available in the Admin Tools section of intraLibrary, and the issues that must be considered before changing some of the settings. The section headings follow the items on the Admin Tools toolbar.

The "users" section provides facilities to add, delete and update users.

Users can be created in the following roles:

Guest:: can search and browse the repository, and export objects
Contributor:: can additionally upload, catalogue and publish objects
Librarian:: can additionally delete and unpublish published objects, and edit the classification systems
Administrator:: can control the user accounts and other configurations of the system

The licence for the intraLibrary installation constrains the number of users that can be added in the contributor, librarian and administrator roles.

It is hard to separate the functions of groups from workflows as the two are tightly linked, so they will both be treated together. First the concepts of the submission workflow are described then how to configure a workflow including setting up particular groups of users with particular roles. It should be stressed that intraLibrary has a default workflow which many people will find satisfies their needs and if that is the case there is no need to read this section.

Several new terms will be introduced in this section so it is useful to start with some definitions:

submission workflow: The process of uploading an object into intraLibrary and preparing it to ensure that all necessary information is provided and checked.
stages: The submission workflow can be divided into several stages (typically one to four stages). Stages occur sequentially in a workflow.
completion criteria: An object is unable to move from one stage to the next until it has satisfied all the completion criteria for that stage.
stage transitions: When an object moves from one stage to the next a stage transition occurs. This transition can be used to trigger events.
group member: Users may be assigned to one or more groups and a submission workflow can be assigned to a group. A user can be a member of several groups. One workflow can be assigned for use by several groups.
roles: A group member can be given a specific role in that group. Roles can be named by the administrator. A user can have different roles in different groups.
group alert: When an object undertakes a stage transition a group alert may be sent. A group alert takes the form of an email sent to all users involved in the next stage.
workflow processes: Within a single stage of a submission workflow there can be one or more processes. If more than one process exists then these processes can be carried out in parallel. Processes are defined by grouping together a number of actions which can be used to complete that process.
workflow actions: Workflow actions are predefined (such as edit metadata, or preview object).
upload: The action of submitting an object into intraLibrary. Uploading is carried out in the section of the work area called upload.
available: Objects are available, and can be seen in the available section of the work area, when a user can work on them. Only objects at a stage of a workflow for which the user has been assigned a role will be visible. Users can elect to work on any objects in the available area by reserving them.
reserved: When a user reserves an object it appears in the reserved section of that user's work area and becomes unavailable to other users, though they can see that the object exists and who has reserved it.

The progress of a learning object through its submission to the repository is defined by the stages of the submission workflow. When a learning object progresses through a workflow, stage transitions can trigger certain events, such as a change in the object's published state and sending alerts to users with relevant workflow roles. When learning objects are moved in a workflow, they are moved to a particular stage, such as being sent back to a previous stage for clarification, or progressing to the next stage for classification.

Each stage of a submission workflow can have one or more workflow processes assigned to it. This means parallel processes can be defined, so users in different roles can potentially access the learning object at the same stage, and do different things to it. The things that can be done to a learning object are know as workflow actions. The list of available actions is given below.

Group members can be assigned one or more roles in a submission workflow. A role can be associated with one or more processes in the submission workflow. This flexible arrangement means it is possible to create a variety of different ways for people to collaborate in a submission process. It anticipates the need for users in the system to contribute to the submission of learning objects in more than one way, and the need for special users who have access to most or all of the workflow.

To summarise the properties of a submission workflow:

A workflow consists of several stages.
Each stage can have one or more processes that can be accessed in parallel.
Any group submission role can be given access to one or more workflow processes (multiple submission roles can be defined for a group of users).
Each workflow process can include one or more predefined actions which are made available to users in the relevant role(s).

As described above, it is a property of every workflow stage, that all users who have access to that stage will receive email alerts when objects arrive in that stage. A workflow stage can have the following additional properties.

Property	Description	Additional Parameters
Change publish state	The publish state of the object will change when the object has passed through the stage. By default, objects are not published when they enter the first stage of a workflow, even if they were published before they entered the workflow. Setting this property at any stage, including the first stage, causes the object to be published so it can be seen by other users. Each further uses of this property toggles the published state of the object.
Alert object owner	Object owner will be alerted when stage is completed. This is to allow the contributor of an object to be alerted when something happens to their object, for example when it is withdrawn from the repository.
Alert object owner	Alert message configurable by modifying the email template "stageChangeObjectOwnerEmail.txt"
Email addresses to alert	Emails will be sent to the supplied addresses when an object has passed through the stage. This feature is designed for sending alerts to external entities, such as mailing lists.	Email addresses
Email addresses to alert	Alert message configurable by modifying the email template "stageChangeExternalUserEmail.txt"

There is a set of predefined actions that are available to be included in any workflow process. Some actions may have completion criteria such as conformance to a subset of an application profile, or matching one of a set of licence patterns.

Action	Description	Additional Parameters
Delete	Remove an object completely from the system.
Edit metadata	Metadata/classification editor configured by the chosen Application Profile, and an optional metadata subset.	Metadata Subset
Edit rights	Licence (rights management) editor.
Export	Package export functions.
Preview	Package/file preview.
Upload	Upload or add a new object to the system.
View Metadata	Metadata preview.
Overwrite	Upload a new version of an object to the system.
Move object	Send the object to another stage of the workflow, with comments attached. Typically used at review stages.	Stage ID
Save to filesystem	Write a content package to a folder on the server filesystem.	Path of folder on server filesystem.
Save manifest to filesystem	Write a package manifeset to a folder on the server filesystem. Folder location is a property of the workflow process.	Path of folder on server filesystem.
Import from filesystem	Import a file or content package from the group's folder on the server filesystem.
Return	Puts the object back into the workflow and published state it had before it entered the current workflow.
Transfer object	Move the object into a different workflow stage or different group. User can move the object to any group/stage they have access to.
Change collections	Modify which collections the object is a member of. User can put the object in any collections they have contribute access to.

As mentioned above, some workflow actions may have criteria that need to be met before the process can be completed. In the user interface, the process completion button will be greyed out if these criteria have not been met. The user can still click on the button, but instead of marking the process as complete, it will display details of the completion criteria that have not been satisfied.

Process completion criteria are associated with specific actions. There are currently four actions which have process completion criteria:

Edit Metadata
Edit License
Save Package to Filesystem
Save Manifest to Filesystem

The following paragraphs give details of the process-completion criteria for each of these actions.

The process completion criteria for the "Edit Metadata" action are driven by the application profile. This can be the whole application profile, or a part of the application profile defined in a metadata subset. If the "Edit Metadata" action is included in a workflow process, the metadata record must meet the conditions of the application profile, before the workflow process can be completed.

The conditions that can be imposed by an application profile include:

Completion of all mandatory fields, such as "Title", "Description", "Contributor".
Use of the vocabularies required for certain fields.

The process completion criteria for the "Edit License" action are driven by the licence model. If the "Edit License" action is included in a workflow process, the license information must match one the license patterns in the license model before the workflow process can be completed.

The conditions that can be imposed by a licence pattern include:

Matching the fixed properties of a particular license.
The completion of certain fields, such as "Object Owner".
Particular values being stored in certain fields.

The "Save Package to Filesystem" and "Save Manifest to Filesystem" actions both have only one process-completion criterion. The user must have performed the action before the process can be completed. In technical terms, these two actions have a "state", i.e. the system remembers whether or not the user has performed that action.

Users must reserve a learning object before they can work on it. Once they have reserved the learning object, it moves to their reserved area and the actions in the workflow processes become available. A button is shown for each of the actions in each process, as well as a button to indicate that the process has been completed.

In the reserved area the user can work on the object in various ways: edit metadata, manage licensing etc. When you have completed your work, and met any criteria on the metadata, you click the button to declare the process as completed.

When all the processes at that stage are marked as completed, the object will be moved on to the next stage. Users who have access to the object at the next stage will receive an email alerting them that there is a new object to work on.

There may be one or more workflows available in the system. After creating a group of users, an administrator can assign one of the available workflows assigned to the group. This group of users shares an instance of the workflow. Others groups can share their own instances of the same workflow.

Users get access to processes within a workflow by being assigned workflow roles within the group. To give roles access to workflow processes, the administrator must edit the roles assigned to the process in the workflow-details page. The administrator assigns users to one or more workflow roles in the context of a particular group. Users who are members of more than one group can be given different roles in each group.

To participate in a submission workflow, users must have contributor status. Normal users do not have a Work Area.

Learning Objects belong to one group only, and are therefore part of only one submission workflow. Objects exist at a single stage in the instance of the workflow belonging to that group. Group members assigned a role in a submission workflow may have access to one or more stages of the workflow.

Users share a pending area for each stage of the group's workflow. All users in the relevant roles will be alerted when an object is moved into the relevant pending area. Any user in the relevant roles can then choose to select this object to work on (see below).

To allow a contributor user to add an object into a particular collection, the administrator must give the group "contribute" permission to the collection. An object must be in at least one collection and can be in many different collections.

Each participating user (contributor user) has a work area where they participate in the submission workflow. The work area is divided into four parts, reserved, available, upload and import.

In the available section users can see all the learning objects they potentially have access to. Each learning object has a listing that includes title and description and there are buttons for access to basic functions such as preview. Users can select the objects they want to reserve to work on.

In the reserved section you see all the objects you have chosen to work on. In addition to the basic information and functions, each process that is available on the object is listed below it on a separate line.

In both the available and reserved areas, the list of objects displayed can be constrained by various criteria. Users can apply filters to select objects in a particular group and a particular stage of a workflow. Saved search filters can be used to constrain the list of objects by specific properties.

The upload section is where a user can contribute an object (file, pages, URL, etc) to the system. Users only see this section if they have access to a workflow process that includes the "upload" action. Users can choose whether or not to automatically reserve objects they contribute. Users who are members of several groups can choose which group for contributing the object. If the group has access to more than one collection then they can choose which collections to put the object into.

The import section is provided to enable users to import large files from the server filesystem. Users only see this section if they have access to a workflow process that includes the "import from filesystem" action. When users import an object, they can choose whether or not to automatically reserve that object.

There are number of properties which can be set for a collection by an administration user:

Name
Description
The metadata application profile to be applied to objects in the collection (optional).
The license model to be applied to objects in the collection. (optional)
The default access permissions for the collection.
The classifications system(s) (taxonomies) to be applied to objects in the collection.
Whether or not external systems can search the collection.
Whether or not external systems can harvest metadata about published objects in the collection.

One or more classifications systems (taxonomies) can be used for each collection. This enables shared classification systems to be used for all objects in the repository, seperate classifications to be used for each collection, or both.

The classification systems used for collections affect what users see in their Browse Library interface, and contributing users see in their Classification interface. For example, if collection A has uses classification system A and collection B uses classification systems B and C then:-

A user who only has access to collection A will see classification system A.
A user who only has access to collection B will see classification systems B and C.
A user who has access to collections A and B will see classification systems A, B and C.

Collections in intraLibrary can use different metadata application-profiles and licence models from each other. Many customers may have no need for this feature, so it is important to point out that many installations of intraLibrary will only every use one metadata application-profile and one licence model (if any). If this is the case, then only ever need to be one "active" application profile and licence model, and these will be applied to all collections by default.

However, it is anticipated that some customers will need to manage collections of objects which have different metadata properties, or are licensed under different sets of conditions. In this case the submission workflow will apply the application profile and the licence model appropriate to the collection the object is in. It should be noted that:

The application profile and licence model associated with a collection takes precedence over the application profile and licence model associated with a group (see precedence issues).
If users are allowed to put objects into two or more collections at the same time, then the collections must use the same application profile and licence model (if any).

To manage collections, click on the "Collections" link the "Admin Tools" navigation bar. This will open the "Collections Management" area. In this area an administrator user can change the properties of existing collections, add new collections to a system, remove collections which have no objects in them.

In new installations of intraLibrary, and installations that have been migrated from previous versions of the software, there will be a single collection called "default collection". You can rename and change any other property of this collection by clicking the "Edit Properties" link for this collection.

To add a new collection, click the "Add Collection" button at the top of the Collections Management area. You will be taken to a form to fill in all the properties of the new collection.

For information about changing which collections an object is in, please see the Librarian Guide.

Managing of access to collections is defined through the collections' relationships to groups of users. Every group has a relationship with every collection. For each group-collection relationship, the permission which the group members have when working with objects in a collection are defined.

To make it easier to manage the relationship between large numbers of collections and groups of users, each collection has a default set of access permissions. Groups who have not had specific access-permissions assigned to them for a particular collection get the default access permissions. Therefore the default access permissions for a collection are generally the lowest common denominator of access an administrator wants to allow.

There are four permissions associated with each group-collection relationship, and they are described below. The administrator can choose any combination of them. For example the administrator could allow members of group A to be able to find and preview objects in collection B without allowing them to export and contribute objects. They are:-

find: allow all users in the group to find objects in the collection using search and browse, and see the metadata for the objects they find.
preview: allow all users in the group to preview objects in the collection.
export: allow all users in the group to download the object, metadata and public URL of the object.
contribute: allow contributors in the group to add objects, edit metadata and perform other functions in accordance with their role in a group.

Please note: For simple objects, such as single documents or media files, the distinction between "preview" and "export" has little meaning, since it is necessary to download the file to be able to preview it. The disctinction only has meaning for more complex objects, such as content packages, where it would more difficult, although not impossible, for a user to download every file connected with an object and reassemble it.

A simple example of relating groups to collections is shown in the diagram below. In this case User X is in group A and User Y is in groups B and C. Group A has full access permissions (ie find, preview, export and contribute) to collection A but no access permissions to Collections B and C. Similarly group B has full access permissions to Collection B but no access permissions to Collections A and C.

As a practical example consider the process involved in creating a collection (Collection A) and giving full access to it for members of group A and no access to it for members of group B and group C. Assuming that groups A, B and C already exist, you would need to perform the following steps:-

Click on the collections part of the admin tool bar. Now click on the add collections and create a collection (calling it collection A). Unless there is a reason for not doing so give the collection access to all classification systems in the repository. Now save the collection and return to the collection management page.
From the collection management page click on Manage Access for collection A.
For group A click on Use Specific Permissions and for group A tick the boxes "find", "preview", "export" and "contribute". This will allow a member of group A to have full access permissions to group A.
For group B click on Use Specific Permissions and then make sure that "find", "preview", "export" and "contribute" are not ticked. This will mean that members of group B will have no access permissions for collection A.
For group C click on Use Specific Permissions and then make sure that "find", "preview", "export" and "contribute" are not ticked. This will mean that members of group C will have no access permissions for collection A.

When contributing an object to intraLibrary, there is an order of precedence which determines which application profile and license model is applied to an object. This is only an issue in installations when more than one application profile or license model is being used.

The general order of precedence is collections, groups, default settings. This means that if features are defined at the level of collection then they will be used. If they are not defined at collection level then the ones at group level will be used and if they are not defined at group level then the default settings will be used. For example:-

If an object is entered into a collection which uses an application profile then this application profile will always be used.
If an object is entered into a collection with no application profile but the user is in a group with an associated application profile then this application profile will be used.
If an object is entered into a collection with no application profile and the group does not have an associated application profile then the default application profile will be used.

The administrator's choice of application profile affects which metadata fields users are exposed to users, and what rules are applied to these metadata fields. Typically, an organisation or project will have well defined rules for how metadata should be used, and these are projected using application profiles. They may well base their application profile on a published application profile, such as those given below.

Application profiles can be used to combine fields from more than one metadata model. The IEEE LOM model is included by default. If any other models have been added to the system, fields from these models will also be available for editing in the application profile editor. If you need to add additional metadata models to the system, please contact Intrallect. More information about choosing metadata models is provided in the Configuration Guide for intraLibrary.

One or more application profiles can be active, which means they can be applied to collections or by user groups. See the section on precedence issues for more information about how these two uses of application profiles are related. This enables an organisation to use different application profiles for different kinds of objects or services, whilst managing them all in a single repository system.

The application profile controls several aspects of each metadata field, including cardinality, optionality, visibility, editablity and vocabulary.

IntraLibrary comes with three pre-configured application profiles:

IntraLibrary: This is a simple, minimalistic application profile
CanCore: The Canadian Core application profile (http://www.cancore.ca)
UK LOM Core: The application profile defined by CETIS (http://www.cetis.ac.uk/) as a starting point for LOM-based solutions in the UK

An administrator can also add, copy, delete and edit application profiles inline. If an application profile is to be based on one of the existing ones listed above, or another pre-defined application profile, it makes sense to use "copy" to avoid having to create your new application profile from scratch. When you click "add an application profile", the properties of fields in the new application profile are populated from the defaults that intraLibrary uses.

Intrallect can help you define an application profile that meets the specific needs of your project or service. Please contact Intrallect (support@intrallect.com) for more information.

IntraLibrary includes the ability to edit an application profile inline. To do this, click the edit link of the relevant application profile in the listing. Editing an application profile should only be undertaken by someone who knows what they want to achieve with an application profile and who is very familiar with the IEEE LOM metadata model.

One simple property of an application profile that can be changed easily is the default optionality of an application profile. This affects the list of metadata fields that appears by default in the metadata editor. The default is to show only the mandatory fields. If for example it was desired to show all contributing users all the mandatory and recommended fields by default, the default optionality should be changed to recommended.

The following properties of an individual field can be modified:

Field Size:: How many characters are allowed for an entry in the field
Cardinality:: How many instances of the field are allowed
Visibility:: Whether or not the field is displayed in the metadata editor
Editability:: Whether or not a user is able to edit the value of the field
Optionality:: Whether the field is mandatory, recommended, optional, not-recommended or not-used
Vocabulary:: Which vocabulary is used to populate a fixed-vocabulary field. Select the vocabulary name from the drop-down list.

The administrator can manage the vocabularies used in the metadata by going to the "vocabularies" section of the "admin tools". It is possible to create, edit and delete vocabularies. Vocabularies can be modified in various ways including:

Changing the name and ID of the vocabulary
Adding and deleting terms
Importing terms defined in IMS VDEX format
Changing the order the terms are displayed in
Editing the term or "token" itself
Changing the "source" for a term
Creating labels for each term in multiple languages

The system will prevent you from deleting a vocabulary that is currently being applied in an application profile. It will not stop you from modifying any vocabulary, so it is important to be aware of which vocabularies are being used in the system, and how any changes will affect users.

Changes to the vocabularies affect what terms users will see in the drop-down list for each vocabulary. These drop-down lists are used in the metadata editor, and the advanced search interface. If you edit a vocabulary term (token) itself, metadata records which include the original term will not be affected. If you change the label for a vocabulary term, this change will be visible everywhere the label is used.

Values stored in specified metadata fields can appear as links in the view metadata page. A user can click such a link to see a list of objects which match the value. A good example of where this is useful is when one object makes a reference to another object, using the "relations" part of LOM metadata. The user can click on the link to the reference and see the object the metadata refers to.

Making a metadata field available for "reference search" means a search link will be displayed for every instance of that field that appears in the view metadata page. Reference search is applied to the following IMS/LOM fields by default:

general.keyword
relation.resource.identifier
relation.resource.catalogentry.entry
classification.taxonpath.taxon.entry
classification.keyword

IntraLibrary includes the ability for users to define pre-configured search-filters from the Advanced Search page. Administrators of the system have an additional power to create public filters, for use by others users. This feature has been designed to allow administrators to make commonly used search filters available to all other users of the system.

Public search filters commonly define the sort of search constraint that users might want to deploy as their default search filter. Users will see a list of public search-filters in the relevant drop-down list in their user-preferences page. They can select a default search-filter to constrain the results of all of their search and browse operations.

Contributing users can use saved or "public" search filters to filter the contents of their work area.

NB: Public search filters are not currently exposed to other users in the context of the advanced search interface itself.

The organisation running intraLibrary may wish to use the usage agreement feature of intraLibrary to record user's acceptance of a general agreement to use the system. This agreement may encompass the legal agreements that are defined for the community licences described in the next section or it may simply be a code of conduct. The text of a usage agreement can be entered into the system by the administrator. On first or every login, the user can be presented with this agreement to accept or reject. Details of the acceptance of an agreement are recorded in the database.

A common barrier to the reuse of learning objects is the issue of ownership and copyright. Conflicting copyright agreements, or uncertainty over ownership and usage permissions, is a constant thorn in the side of those who want to share learning objects within or between organisations.

Intrallect has included a community licensing solution in intraLibrary to help overcome some of these barriers. This solution enables learning objects to be deposited in intraLibrary under one or more community licences. These licences define the conditions under which the learning object is made available to other users. One example of such a set of licences is Creative Commons.

It is also common to want to have some kind of usage agreement for a repository. Some users will be depositing learning objects, others will be exporting and reusing learning objects. Organisations will often want these users to acknowledge that certain conditions apply to their use of the repository. IntraLibrary administrators can define usage agreements for the various roles in the system, which users must accept before they get access to the relevant functions.

An organisation can define its own licensing model to be used in their intraLibrary repository. The licensing model consists of a set of one or more community licences. Each licence can have a different combination of the various parameters available in the Intrallect Licensing Information Model (ILIM). These licences define the conditions under which the learning object is made available to other users.

The licences can include permission, requirement and constraint parameters such as:

(Can) modify
(Must) attribute
Non-commercial use (only)

There is also a transfer permission, which specifies how strictly the above conditions are applied if the learning object is passed on to other users. This allows licence conditions of the sharealike type, as used by Creative Commons, to be expressed.

A licence editor action can be included in any process of a submission workflow for an intraLibrary repository. This gives the user an opportunity to select the licence under which they make their learning object available. The completion criteria of the workflow process may define a subset of licences to which the learning object must conform.

The licence editor enables the user to make a choice between the available licence templates. Each licence is presented as a row of icons with an associated radio button. The users clicks the radio button next to their chosen licence. They are then shown other fields that may need to be populated for that instance of the licence, such as the identity of the copyright holder(s). When the user has saved all the necessary information, the licence action has been completed.

When the community licensing system is activated, the licence properties of objects are visible to users when searching and browsing. When a user sees a list of objects, the type of licence will be indicated to them using a set of symbols or phrases. The symbols or phrases represent a particular permission or constraints on the user of the learning object, which may differ between the available licences. Each symbol or phrase can be a link to a description of the relevant constraint, or the relevant part of the full text of a licence agreement.

It is possible to associate different licensing systems with different collections in intraLibrary.

For an organisation to apply their own set of licences in intraLibrary, they will need to do several things.

Discuss possible licensing models with their user community and legal advisors
Select or define one or more licences by:
- mapping these licences against the parameters of the Intrallect Licence Information Model (ILIM)
- choosing or commissioning formal licence agreements
Select or define some icons which represent the distinctive conditions of the chosen licences
Arrange for their licence agreements to be made publicly available, such as at a persistent URL
Work with Intrallect to implement these definitions in intraLibrary (See the Configuration Guide for more details.)

The licence information needs to be stored in the repository, and potentially be portable between repositories and other systems. IntraLibrary uses the following approaches to storage and exchange of licence info:

Store licence information for each learning object according to a licence information-model, ILIM
Allow licence information to be harvested by other systems, following the approach of Project RoMEO

Using the OAI PMH 2.0 protocol
Licence information mapped to an XML record conforming to the ODRL 1.1 specification

Export and import licence information in IMS Content Packages following the model established by the COLIS project

ODRL record stored in an extension to the package manifest

Put a link to online copies of the legal agreements in the relevant fields of other metadata formats, such as:

Dublin Core: dc:rights
IEEE LOM: ims:rights.description

IntraLibrary uses a memory cache of learning objects to improve performance and reduce the load on the underlying database. The maximum number of learning objects stored in the cache is configurable. A larger number will generally improve performance if sufficient memory is available on the server. See the installation notes for more details.

Occasionally a learning object may get corrupted in the cache, for example all its metadata might appear to have been lost. If this happens, the cache can be rebuilt from the learning-object data stored in the database by clicking the Rebuild learning object cache link.

If a search in intraLibrary seems to be producing strange results, or missing objects you think it should be finding, the first course of action should be to re-index the metadata. It's also important to do this if the fields that form part of a simple search are modified in the search configuration.

Re-indexing rebuilds the index the search engine uses to find objects that are relevant to a given query. Depending on the number of objects in the system, re-indexing could take a few seconds, a few minutes, or much longer. Re-indexing updates one metadata record at a time, so there is no major problem in re-indexing whilst users might be searching for objects.

If your installation is configured to support thumbnailing of image objects, you will see a link to "Rebuild object thumbnails". Thumbnails will be created for all single (JPEG) images when they are uploaded into the repository. See the installation guide for more information and configuring the repository to support thumbnailing.

Occasionally it may be necessary to rebuild thumbnails for all the image objects. You might need to do this for the following reasons:

You have just activated thumbnailing in a repository that already contains some image objects.
You have changed one or more properties of the thumbnails, such as the thumbnail dimensions (see the installation guide for more information on how to do this).
You can see some corrupt thumbnails appearing in the search results. In normal circumstances, this should not happen.

If you need to rebuild thumbnails for any reason, click the "Rebuild object thumbnails" link. Rebuilding the thumbnails for a large number of image objects can take a while. Whilst thumbnails are being rebuilt, the "Rebuild object thumbnails" link will be greyed out every time you visit the "system" page.

A message below the "Rebuild object thumbnails" link tells you what the current thumbnails settings are. For example it might say:

Current thumbnail dimensions are 75px square for small thumbnails, 200px wide for large thumbnails and are of quality 7/10.

There are number of addditional settings which can be controlled from the system page:-

Whether or not users are given permission to delete and move objects which they have contributed to the library.
Whether or not users are given the ability to request a new password to be sent to them.
Whether or not templates should be applied to a package on import
Whether or not users comments are exported with metadata
The default language for the system
Whether or not users receive email alerts when an object is commented
Whether ot not users can choose not to use a metadata template
Settings for RSS feed including the stylesheet to be used, the RSS cache update frequency rate and an additional metadata field in the RSS results
The number of records that should be returned for a single OAI list request. The default is 1000.

Metadata templates are defined using XML files which follow the IMS Metadata XML Schema. These files must be placed in the config directory of your intraLibrary installation, inside a folder called metadataTemplates. An easy way to create a metadata template is to create a dummy learning object in intraLibrary with the metadata properties you want. You can then export an IMS Metadata record from this object, and use the resulting XML file as the basis for your new metadata template. The filename of the metadata template must be of the form templatename.xml.

When you have added templates, you need to click Reload Templates in the system section of the intraLibrary admin tools to update the templates used inside intraLibrary. Templates will appear in the relevant drop-down list in the user-preferences page. The name of each template will be the name of the file with the .xml suffix removed. There is a template called default that is supplied with the system. You can overwrite this by creating your own default.xml template in the metadataTemplates folder.

Metadata templates are defined in XML files which follow the IMS Metadata XML Schema. Any property of the IMS/LOM metadata model can be defined in a metadata template. The metadata fields in a template can be populated either by static strings, or dynamic macros generated using information available to intraLibrary.

Metadata template macros can be called up using the macroname in curly brackets, such as {UserFullName}. A complete list of metadata template macros is given in Appendix 1. Metadata template macros cannot currently be called up as part of another string, so including The user who wrote this is {UserFullName} in the copyright.description field won't work.

The following example shows how you can mix static strings and metadata-template macros in the lifecycle section of a template defined IMS Metadata (XML) format:

        

<lifecycle> 
    <contribute>    
      <role>                  
        <source>             
          <langstring xml:lang="x-none">LOMv1.0</langstring>    
        </source>   
        <value>    
          <langstring xml:lang="x-none">Author</langstring>     
        </value>       
      </role>           
      <centity>        
        <vcard>{UserVCard}</vcard> 
      </centity>        
      <date>              
        <datetime>{NowCurrentDate}</datetime>  
      </date>               
    </contribute>     
  </lifecycle>

You can use an XML Editor to compose and validate your metadata template. Using some of the metadata-template macros in particular fields may cause a validation error, but this does not necessarily mean your template will not work in intraLibrary. For example, using the {ObjectFileSize} macro in the technical.size field of the metadata will cause a validation error, because the XML Schema requires this element to contain a number. Therefore, if you are using a validating editor such as XML Spy, it is probably best to insert the metadata-template macro after you have finalised and validated the overall structure of your template.

There are six different types of email alerts which can be sent by intraLibrary. These alerts are used to notify users about changes to objects such as when an object has passed from one stage to another, when an object has been published and when an object has been annotated.

There are three types of alerts that can be used to notify users about objects moving from one stage to another. They are:

Letting individual users know about state changes to an object:
An individual user can choose to receive an email when an object enters a stage they have access to. This option is chosen by the individual user from the group section of the profile page. The email template for this alert is StateChangeEmail.txt which is stored in the email templates directory in the configuration directory on the server.
Letting external people know about state changes to an object:
When writing the xml for a workflow, it is possible to include an action "Email addresses to alert" followed by email addresses and alerts will be sent when the stage is completed (see section on workflows for more details). The template for this alert is StageChangeExternalEmail.txt which is stored in the email templates directory in the configuration directory on the server.
Letting the object owner know about state changes to an object:
The workflow template also has an action to "alert the object owner" and this will alert the object owner when the object changes state (see sections on workflows for more details). The template for this alert is "StateChangeObjectOwnerEmail.txt" which is stored in the email templates directory in the configuration directory on the server.

There are two types of alerts which can be used to notify users when an object has been published. They are:-

Publication notification for user:
An individual user can select the "send notification email" box from "preferences" on their "profile" screen. The email template for this is "UserPublishNotificationEmail.txt" which is stored in the email templates directory on the configuration directory on the server.
Publish notification for external user:
The administrator can decide who obtains alerts when an object has been published in the repository. This is entered at the foot of the "system" section which is part of the "admin tools page". Any number of email addresses can be chosen to receive a message when an object is published in a repository. The text for the message is "adminPublishNotificationEmail.txt" which is stored in the email templates directory on the configuration directory.

In the above section six different types of email notifications were considered. The text for these email notifications can be modified by the administrator by altering the templates which are contained in the email templates directory on the configuration directory on the server in which intraLibrary is installed. The example below shows a sample template for an email about an object changing state (stageChangeEmail.txt). There is a list of the macros which can be used for each template in the section on Email Template Macros.

        

 A new Learning Object is now available.
 
 click on the link below to preview the object:
               __url__

title:
              __title__
description:
              __description__
comment:
             __comment__
classifications:
             __classifications__
             
 This message was sent to you by the administrator of intraLibrary.

The following macros can be used by all the email templates (StageChangeEmail.txt, StageChangeExternalEmail.txt, StageChangeObjectOwnerEmail.txt, UserPublishNotificationEmail.txt, adminPublishNotification.txt, annotationNotificationEmail.txt)

Variable	Description
__repositoryName__	Name of the repository which object is stored in
__url__	The public URL of the learning object
__title__	Name of the repository which object is stored in
__description__	The description of the learning object (from metadata)
__currentStage__	The stage which the object is currently in
__currentWorkflow__	The workflow which the object is currently in
__classifications__	List of all taxonpaths which the object is classified under

The following variables are available for use in each email template except the annoatation notification email (i.e StageChangeEmail.txt, StageChangeExternalEmail.txt, StageChangeObjectOwnerEmail.txt, UserPublishNotificationEmail.txt, adminPublishNotification.txt, )

Variable	Description
__publisher__	Name of the person publishing or moving the object.
__comment__	Comment made when moving the object.

The following variables are available only on the annotation notification email (annotationNotificationEmail.txt)

Variable	Description
__annotation_text__	The text body of the annotation which has been written by the user
__star_rating__	Star rating for the annotation
__annotation_date__	Date of the annotation
__Username__	The name of the user who wrote the annotation

The macros available for populating metadata templates are:

Property	Description	Possible Uses (target metadata fields)
Properties of the user
{UserFullName}	User Account	The full name of the user, as stored in the user profile
{UserAffiliation}	The affiliation (employer) of the user, as stored in the user profile
{UserEmail}	The email address of the user, as stored in the user profile
{UserPreferredLanguage}	The language the user has chosen as their preferred language in their user profile	general.language metametadata.language educational.language
{UserUsername}	The intraLibrary username of the user
{UserVcard}	Returns the user's stored details in vcard format.	lifecycle.contribute.centity metametadata.contribute.centity annotation.centity
Properties related to the current time
{NowCurrentDate}	Current date in UTC format	lifecycle.contribute.datetime metametadata.contribute.datetime annotation.datetime
{NowGuid}	A globally unique identifier (GUID) generated using the current time.
Properties of the learning object
{ObjectMimeType}	Mime-type of single-file object matched by file extension	technical.format
{ObjectPublicURL}	Full "public URL" for this object for this user	technical.location
{ObjectFileSize}	Size in bytes of uploaded file or package zip file	technical.size
{ObjectAggregationLevel}	Not currently supported Placeholder for an automatically generated value of 1-4 depending on predefined rules for assessing the complexity of a learning object.
{ObjectCreationDate}	Date of creation, extracted from metadata in digital file. Currently supported for JPEG images (exif:DateTimeOriginal) only.	lifecycle.contribute.date
{ObjectCreator}	Author/creator of digital object, extracted from metadata in digital file. Currently supported for JPEG images (tiff:Artist) only.	lifecycle.contribute.centity
{ObjectFilename}	Returns filename of uploaded single file, or filename of package .zip file	general.title
{ObjectId}	The OAI identifier of the object	general.catalogentry.entry
{ObjectLocalID}	The number of the object in the repository	general.catalogentry.entry
Properties of the repository
{RepositoryName}	The name give to the intraLibrary repository in the properties file
{RepositoryID}	OAI identifier of the intraLibrary repository assigned in the properties file
{RepositoryAdminEmail}	Email address of the repository administrator
Properties of Application Profiles
{ApplicationProfileName}	The recognised name of the application profile, e.g. "CanCore"	metametadata.metadatascheme
{ApplicationProfileSource}	The authoritative source for the application profile
{ApplicationProfileVersion}	Version number of the application profile
Properties of JPEG images (extracted from EXIF metadata)
{ImageCompressionScheme}	tiff:Compression	Z39.87: Compression.CompressionScheme
{ImageCompressionRatio}	exif:CompressedBitsPerPixel	Z39.87: Compression.CompressionLevel
{ImagePixelWidth}	exif:PixelXDimension	Z39.87: ImageWidth
{ImagePixelHeight}	exif:PixelYDimension	Z39.87: ImageLength
{ImageCameraMake}	tiff:Make	Z39.87: DigitalCameraManufacturer
{ImageCameraModel}	tiff:Model	Z39.87: DigitalCameraModel
{ImageOrientation}	tiff:Orientation	Z39.87: Orientation

Stages	Stage1: Contribute
Processes	Process 1: Upload and Catalogue Upload Edit Metadata (All)
Publish State	Unpublished

Stages	Stage1: Contribute	Stage2: Catalogue	Stage3: Review
Processes	Process 1: Upload Upload Preview Edit Metadata ("General" subset)	Process 1: Catalogue Preview Edit Metadata (All)	Process 1: Check Preview Preview metadata Reject (to stage 2)
Publish State	Unpublished	Unpublished	Published

Stages	Stage1: Create Placeholder	Stage2: Add Content	Stage3: Review Content
Processes	Process 1: Upload Upload Edit Metadata (All)	Process 1: Upload Preview Overwrite Edit Metadata (Technical subset)	Process 1: Check Preview Move (to stage 2)
Publish State	Unpublished	Unpublished	Published