This document is for intraLibrary administrators carrying out routine administration tasks. For support with decision-making about configuration 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, as in the illustration below:

This document describes the technical 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 in the document correspond to 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 an intraLibrary installation constrains the number of users that can be added in the contributor, librarian and administrator roles.

In the "system" area the administrator can add and remove email addresses to the publish notification list. When an object is published into the repository, every email address added to this list will receive an email notification giving information about the object.

In the "system" area the administrator can choose a number of general configuration options that will affect users. These include whether to allow users the ability to delete and unpublish objects that they have contributed to the library. If this option is not selected then only librarians can delete and unpublish objects. If this option is set to yes, users in the contributor role will see the unpublish and delete buttons beside published objects that they have contributed to the repository.

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.

group 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 roles are used to give users access to workflow processes.

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 workflow actions which can be used to complete that process.

workflow actions

Workflow actions are predefined (such as edit metadata, or preview object) and are associated with a workflow process.

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. If the user is the only person with access to a particular stage in a workflow, objects in that stage will automatically go to the reserved area.

A submission workflow defines the steps that an object passes through as it is uploaded, catalogued and published into the repository. IntraLibrary has a highly configurable workflow. It enables complex, multi-role workflows to be defined, whilst still supporting the simplicity of a single-stage workflow where appropriate.

The progress of an object through its submission to the repository is defined by the stages of the submission workflow. When an 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 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 object at the same stage, and do different things to it. The things that can be done to an 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 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 role can be given access to one or more workflow processes (multiple group 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).
• Some workflow actions can be configured to require completion within a workflow stage before the object can be moved to the next stage.

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 (although the users can configure this themselves in their "profile"). 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 use of this property toggles the published state of the object.
Complete on any	Where a workflow stage has more than one process, by default all processes must be completed in order to move the object to the next stage. Setting this property means that the object may be moved to the next stage by completing only one process in the stage.
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 message configurable by modifying the email template "stageChangeObjectOwnerEmail.txt". See Email Templates section for more information
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
	Alert message configurable by modifying the email template "stageChangeExternalUserEmail.txt". See Email Templates section for more information.

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. See Metadata Subsets section.
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. New version has same metadata as old object. The exception is if a new title has been entered at upload or imported in a content package.
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 for a workflow process. If the "Edit Metadata" action is included in a workflow process, the metadata record must meet the conditions of the application profile and any metadata subset, 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". NB: If a metadata subset has been defined for the workflow process, only the mandatory fields that are included in the metadata subset must be completed to meet the completion criteria for that process.
• Use of the vocabularies required for certain fields.

The process completion criteria for the "Edit Licence" action are driven by the licence model. If the "Edit Licence" action is included in a workflow process, the licence information must match one of the licence patterns in the licence 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 licence.
• 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.

If a workflow stage has more than one process defined, and more than one of these processes has completion criteria, then all of the completion criteria for all processes in a stage must be met before an object in that workflow can be moved to the next stage. The exception is if the workflow has the property "Complete On Any" set, which means that only one process needs to be completed to move the object to the next stage.

Intrallect can create workflows to customer's requirements, or you can define your own workflows and import them into intraLIbrary. The following workflows are given as examples of what is possible. Each defines one or more processes, related actions and the published state (published/unpublished) in a workflow with one or more stages.

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: Contribute	Stage2: Clear Rights	Stage3: Catalogue	Stage4: Classify
Processes	Process 1: Upload Upload Preview Edit Metadata ("General" subset)	Process 1: Rights Preview Edit Rights	Process 1: Transcription Preview Edit Metadata (General and Technical) Process 2: Subject Preview Edit Metadata (Subject) Process 3: Education Preview Edit Metadata (Education)	Process 1: Classify Preview Edit Metadata (Classification)
Publish State	Unpublished	Published	Published	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

Users must reserve an object before they can work on it. This can happen in one of three ways:

• The user is the person who uploaded the object, and they ensured that the "reserve" checkbox on the upload page was checked.
• The user is the only person with access to the stage the object is in. In this case the object automatically goes into their reserved area.
• The user clicks on the "reserve" button for that object from the available section of their work area.

Once they have reserved the object, it appears in their reserved area and the actions in the relevant workflow processes become available. A button is shown for each of the actions in each process, as well as a button to click when 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 they have completed their work, and met any criteria on the metadata, they 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. Alternatively, if that workflow stage has the property "Complete On Any" set, then only one process for that stage needs to be completed for the object to be moved 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, unless they have changed their user profile to not receive group alerts.

A workflow definition can be added to intraLibrary by a user who has administrator access to the repository. To do this, you must have created your workflow definition in an XML document which conforms to the XML Schema for submission workflows, which is publicly available at http://www.intrallect.com/xsd/intralibrary_workflow_v0p4.xsd. See the intraLibrary Configuration Guide for more details on how to configure a workflow.

An administrator can remove a contributor from the system. If there are objects which the contributor is working on, the administrator will have the option to have the object's ownership information removed.

Administrators can also remove whole groups from the system. If the group is currently working on objects then the administrator will have the option to transfer the objects to another group.

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. Other 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.

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 an "available" 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 "available" 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 to 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 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 My Objects. When the user has group role access to a workflow stage that includes the action "import from filesystem", they will also have an Import section in their work area. If they do not have group access-permission to upload to any collection, neither the Upload nor Import section will not appear in their work area.

In the available section users can see all the objects they potentially have access to. Each 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 so that they can work on them.

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 search 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 they are contributing the object to. 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.

Collections are used in intraLibrary to collect together objects which have a common property, such as ownership or object type. There are various reasons why a collection might be created, but the main practical reason is for controlling different kinds of access to a set of objects, or what kinds of metadata or licences are applied to them. Different levels of access to a collection can be assigned to different groups of users, for the purpose of controlling which users can see what objects, and which parts of the repository users can contribute to.

There are a number of properties which can be set on a collection:

• Name
• Description
• Identifier: A string that can be used to identify the collection
• Application Profile: The metadata application profile to be applied to objects in the collection (optional)
• Licence Model: The licence model to be applied to objects in the collection (optional)
• Default Permissions: The access permissions that are applied to groups without specific permissions (normally the minimum level of access)
• Access to Taxonomies: The classification system(s) that can be applied to objects in the collection
• Searchable by External Systems: Whether or not external systems can search the collection
  • More information on this is available in the Controlling Remote Access to Collections
• Harvestable by External Systems: Whether or not external systems can harvest metadata about published objects in the collection
• Allow Public Preview: Whether or not external users can preview objects in the collection using a public URL
• Allow Public Package Download: Whether or not external users can download packaged versions of objects in the collection, using a public URL

One or more classification 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 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 ever use one metadata application profile and one licence model (if any). If this is the case, then there only ever needs to be one "active" application profile and licence model, and these will be applied to all collections by default.

However, 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 in 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, and 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's 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 five 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. The permissions 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.
• comment: allow all users in the group to attach comments and star ratings to objects.
• contribute: allow contributors in the group to add objects, edit metadata and perform other functions in accordance with their role in the 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 distinction 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.

For a user to contribute an object to a collection they must:

• have a repository role of "contributor"
• be a member of a group which has contribute permission for that collection
• have a role in the group's workflow which allows them to contribute objects

The ability of external systems to search an intraLibrary repository is configurable for each collection within the repository. Two approaches are currently supported:

1. selectively opening/closing collections for external search
   • this is controlled by editing the properties of a collection in the "admin tools" interface
   • a collection is either open to external searching or closed to external searching (default)
2. controlling access using authentication tokens
   • tokens are created and assigned to a collection in the "collections" section of the admin interface
   • tokens can supplied by external systems making search requests
   • results will only be returned from collections to which the supplied token has been assigned, or to which no tokens have been assigned

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 (i.e. find, preview, export, comment 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", "comment", 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", "comment", 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", "comment", 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.

There are several options for configuring the use and behaviour of metadata and vocabularies within intraLibrary. The most important is the "application profile", which is used to control which metadata fields are in use in a particular context, and the rules for applying these metadata fields. It is also possible to modify the metadata vocabularies available within the system. Subsets of the available metadata fields can be created to define which fields contributors and cataloguers see in a workflow.

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 expressed 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, you can do so by adding a new application profile or copying then editing an existing one in the "metadata" section of the "admin" menu. More information about defining 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 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 application profile designed to get you started
• CanCore: The Canadian Core application profile (http://www.cancore.ca)
• UK LOM Core: The application profile defined by JISC CETIS and other partners (http://www.cetis.ac.uk/profiles/uklomcore/) 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 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 contributing users all the mandatory and recommended fields by default, the default optionality should be changed to recommended. It is also possible to change the names of the levels of optionality, e.g. you can set "mandatory" to appear in the Metadata Editor as "fields that must be filled in", etc.

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. Only the optionality levels used in an application profile appear as options to users, so if only Mandatory, Optional and Not Used are applied to fields, then contributors will only see those three options. It is also possible to change the names of the levels of optionality, e.g. you can set "mandatory" to appear in the Metadata Editor as "fields that must be filled in", etc.

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 term is used.

It is possible to control what metadata fields users in different group roles can see and edit within different processes of a workflow, e.g. you may wish those uploading objects to only see and fill in the title, description and keywords for an object, with cataloguers filling in the rest of the metadata at the next stage. You may also wish the cataloguers to be able to see the automatically generated identifier for an object, but not be able to edit it. An administrator can manage this by configuring metadata subsets in the "metadata" section of the "admin" tools. Metadata subsets configured there are associated with workflows by their name, so it is important that the name of the subset be exactly the same as the subset name in the associated workflow. You must configure any subsets associated with a workflow before you upload the workflow to the repository in the "workflows" section of the "admin" tools. However, it is possible to edit a subset once both subset and workflow are active in the repository.

This interface allows you to configure the following aspects of the search features in intraLibrary.

• Simple Search: Which metadata fields are included in a simple search.
• Advanced Search: Which metadata fields appear in the drop-down list of available fields in the Advanced Search interface.
• Reference Search: Whether or not the contents of a field are displayed as a search link in the "view metadata" page. Typically used for "reference" fields, such as identifiers.

By default intraLibrary is configured to use all the main free-text metadata fields in a simple search. Those metadata fields with fixed vocabularies are excluded from this index because they might skew the search towards words that are used as tokens in the vocabularies.

You can use this interface to change these defaults. If you do change these settings, you must re-index the metadata (see later) before they will take effect.

The default drop-down list of metadata fields in the advanced search interface includes the metadata fields that are commonly considered useful. However, you may wish your users to have access to searching other metadata fields. This interface allows you to configure which metadata fields appear in the drop-down list.

Values stored in specified metadata fields can appear as links in the view metadata page. A user can click these links to see a list of objects which have that same value in their own metadata. A good example of where this is useful is when one object makes a reference to another object, using the "relation" fields from the IEEE 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. End users can then click that search link to carry out a reference search when viewing metadata for an object. Reference search is carried out as a "simple search" of the term in the link being clicked on, which means the search runs against all the fields specified for "simple search", not just for that specific metadata field. So you must ensure that the correct fields are configured for simple search for your users.

IntraLibrary includes the ability for users to define reusable searches ("search filters") from the Advanced Search page. Administrators of the system have an additional power to create public filters, for use by others users.

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.

Contributor users can use public search filters or their own personal search filters to search 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 users' 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, and users can see what agreements they have accepted at any time in their profile.

A common barrier to the reuse of 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 objects within or between organisations.

Intrallect has included a community licensing solution in intraLibrary to help overcome some of these barriers. This solution enables objects to be deposited in intraLibrary under one or more community licences. These licences define the conditions under which the 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 objects, others will be exporting and reusing 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), which is based on the Open Digital Rights Language (ODRL). These licences define the conditions under which the 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 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 object available. The completion criteria of the workflow process may define a subset of licences to which the object must conform.

The licence editor enables the user to make a choice between the available licence templates. Each licence may be presented as a row of icons or phrases with an associated radio button. The user 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, or alternatively, a single Terms and Conditions of Use link may be shown directing them to an external web page. The symbols or phrases represent a particular permission or constraints on the user of the 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.

1. Discuss possible licensing models with their user community and legal advisors
2. Select or define one or more licences by:
   • mapping these licences against the parameters of the Intrallect Licence Information Model (ILIM) which is based on the Open Digital Rights Language (ODRL)
   • choosing or commissioning formal licence agreements
3. Select or define some icons which represent the distinctive conditions of the chosen licences
4. Arrange for their licence agreements to be made publicly available, e.g. through a persistent URL
5. Work with Intrallect to implement these definitions in intraLibrary (See the Configuration Guide for more details.)
6. Once everything is configured within the system, they must switch on the "enable rights mode" option in the "system" menu to make licensing options appear to users.

The community licensing solution in intraLibrary does not:

• Enable users to constrain searches for objects by licence criteria
• Enable administrators to control access to objects, such as
  • Restrictions on user access by licence type
  • Restrictions on domain/institution access by licence type
• Record the user's acceptance of the licence for each object
• Include any kind of technical enforcement of licence conditions.

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, based on ODRL
• 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

• Creative Commons: http://creativecommons.org/
• Project RoMEO: http://www.lboro.ac.uk/departments/ls/disresearch/romeo/
• Open Digital Rights Language (ODRL): http://odrl.net/
• COLIS Project: http://www.colis.mq.edu.au/

IntraLibrary uses a memory cache of objects to improve performance and reduce the load on the underlying database. The maximum number of 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 an 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 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 is 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 search configuration is modified.

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 intraLibrary 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.

If you have made changes or additions to the metadata templates ( see later), you will need to use the Reload templates link to reload the templates before the changes will be recognised.

If your intraLibrary system is experiencing a bug or error, this setting allows you to view an error log for the error. Click "Enable Error Log", then run through the steps in the system that originally caused the error. When the error recurs, go back to "system" and click "view". A window will open up with an error log. You can click "Disable Error Log" when you are finished with looking at the error.

This allows to you to view the intraLibrary log file over the web. Warning: this can become a very large file unless it is regularly rotated.

Displays the total number of objects in your installation of intraLibrary, and the total number of published objects.

There are a number of additional configuration 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 content package on import.
• Whether or not users comments are exported with metadata.
• The default language for the system.
• The metadata template (if any) to apply to the results of an external search request (see the Integration Guide for more information).
• The metadata template (if any) to apply to the results of an external harvest request (see the Integration Guide for more information).
• Whether or not users in different system roles receive email alerts when any object receives a comment from a user.
• 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.
• Whether or not the system's licensing model is switched on so that any licences configured appear in the workflow, rights editor and object listings (this option is "Enable Rights Mode" in the system menu), and what licence pattern will be applied by default to objects on upload. See Licences section.

Email addresses to which notifications are sent whenever an object is published.

When the intraLibrary system sends out emails, it uses the Simple Mail Transfer Protocol (SMTP). To do this, it must be able to connect to an SMTP server. An SMTP server accepts emails from sources it recognises, and relays the emails towards their destination via a chain of similar SMTP servers.

The SMTP server you use may be on your local network, or available on the internet. A non-local SMTP server will normally require a username and password before relaying emails.

The following settings are requried for a non-authenticated SMTP server:

• Server Description: Anything you want to use to identify the SMTP server
• Server Name: The full domain (or IP) address of the SMTP server
• Server Port: The IP port used to connect to the SMTP server (usually 25)

The following additional settings are required for an authenticated SMTP server:

• Username: The username for authentication by the SMTP server (if any)
• Password: The password for authentication by the SMTP server (if any)

The values you enter in these fields may well be the same as the configuration of your outgoing mail server in your normal mail client, e.g. Mozilla Thunderbird or Microsoft Outlook.

It can sometimes be difficult to be sure if you've got the SMTP settings right. The system can send out a test email to help you check everything is working.

To check the email connection is working:

1. enter your email address
2. click "Send Test Email"
3. check your email - you should receive an email with the return address that has been assigned to your intraLibrary installation, with a subject heading of "Testing IntraLibrary SMTP Server"

If you don't receive an email, first check your spam or junk folders to see if it ended up there. If not, then you need to go back and review your SMTP settings.

If you have a problem or bug in your installation of intraLibrary, it may occasionally be necessary for a member of Intrallect's support team to get access to your repository. You can allow this by switching on "support access".

Enabling support access will create a temporary user with admin rights and send the login details to the Intrallect support team. This will grant the Intrallect support team temporary access to the application in order to diagnose the problem. The support user will persist until the support access is disabled.

In order for support access to work, the application must have enough capacity in its software licence to allow the addition of a new (temporary) user with contributor, librarian and administrator permissions.

In normal operation, the support section of the "Admin Tools" will include the message "support access is currently disabled", and link to "Enable External Support Access". If you have been asked by a member of the Intrallect support team to activate support access in your installation of intraLibrary, click the link to "Enable External Support Access".

If you do not have enough capacity on your software licence, the page will display the message "it was not possible to enable support access as there was not enough capacity on your licence." If this happens, you need to take away contributor privileges from one of your existing users before you can enable support access.

When support access is active, the support section of the "Admin Tools" will display information about the status and identity of the support user, and a link to "Disable External Support Access".

If you click "Disable External Support Access", then the support login will be de-activated. Re-activating support access again will create a completely new login for the Intrallect support team.

To save the user having to repetitively enter easily definable metadata values, intraLibrary can optionally populate metadata records with pre-defined values. These pre-defined, or default, values are defined in stored templates which must themselves be valid IMS Metadata records in XML format. In these metadata templates any metadata field can be assigned a default value, or multiple default values where appropriate.

Metadata templates are defined using XML files which follow the IMS Learning Resource 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 object in intraLibrary with the metadata properties you want. You can then export an IMS Learning Resource 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 or updated templates in the metadataTemplates folder, 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. Templates are also made available to users in the Metadata Editor in their work area, so that they can be applied while editing metadata.

The system can also be configured to apply metadata templates to records exposed to external systems via service interfaces. You may wish, for example, to ensure that a particular copyright statement appears in metadata records harvested via an OAI-PMH service, or that a particular field is populated with a Public URL when using SRU to query your repository from your website. More information about these interfaces can be found in the intraLibrary Integration Guide.

The following options are available in the General Configuration section of the system page:

• Metadata template to apply to search results
  • values and macros in the selected template will overwrite the values stored in the relevant fields of each record returned in a search request.
• Metadata template to apply to harvested results
  • values and macros in the selected template will overwrite the values stored in the relevant fields of each record returned in a harvest request.

Metadata templates are defined in XML files which follow the IMS Learning Resource Metadata XML Schema. Any property of the IMS/IEEE 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 macro name in curly brackets, such as {UserFullName}. A complete list of metadata template macros is given in Appendix 1: Metadata Template Macros. 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 Learning Resource 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 groups section of their 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 intraLibrary installation 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 intraLibrary installation 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 intraLibrary installation 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 receives 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 in the configuration directory on the intraLibrary installation server.

The administrator can choose to send an alert to all administrators and/or all librarians when an object has been commented on by a user. This is done through the "system" section of the "admin tools page". The text for this alert can be altered by changing the "annotationNotificationEmail.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 the object is stored in
__url__	The public URL of the object
__title__	Name of the repository which the object is stored in
__description__	The description of the object (from metadata field "description")
__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 annotation 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 (comment) 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 created 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, institution or project) 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 date / 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 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 or granularity of an 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
{ObjectPublicManifestURL}	A Public URL allowing download of the object's content package manifest, for this user
{ObjectPublicURLAsZIP}	A Public URL allowing download of the object as a .zip file IMS Content Package, for this user
Properties of the repository
{RepositoryName}	The name given 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
{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