Frequently Asked Questions
From Ara Irititja KMS Wiki
What does Ara Irititja do?
Manages physical items and their digital surrogates
The methodology of the real world of an archival or museum collection is reflected in the software interface and the workings of the database. In effect, since the beginnings of the Ara Irititja software, it was established as a virtual museum with a section representing each of the separate media types. As with the archival storage folders and filing cabinets of the physical collection, the database storage is divided into five sections: Photos, Movies, Sounds, Documents and Objects.
This approach facilitates cross-referencing between the items in the physical and digital collections. It also enables the user-friendly interface to present the collection within a simple numerical catalogue framework and thus simplifies both the research and data entry processes. By fulfilling the brief to be easy-to-use, Keeping Culture KMS demonstrates a successful, creative but practical use of information and communication technology, making it unlike many existing museum databases.
At the user interface level, the following example illustrates the manner of representing a document. As in the physical object, the lower, horizontal ribbon of thumbnail images represents a group of separate documents (Archive Items) ), while the vertical ribbon of images represents the individual pages (Archive Views) of a selected document. In this case the Archive Item is a book — the Illustrated Topical Dictionary of the Western Desert Language. Combined with this visual representation, the ‘Item’ and ‘View’ approach allows metadata entry to link in fine detail to the original item in the physical archive collection.
The following illustration shows a Feature highlighted on the page. This Feature, in turn, links to the Fauna Profile of the animal (Dingo), where additional metadata can be stored about the text and illustrated content of the page itself.
Using the extensive customisation options available in the Keeping Culture KMS, additional metadata fields (database attributes) are available and can be designed to record and monitor physical attributes of the original book. These could relate to its condition and detail requirements for conservation management and appropriate storage.
The Annotation function, that is located in the right hand side data panel, could also be used to record advice on management and conservation issues. For example, a paper conservation expert could record in live video format his assessment and practical advice, whilst handling and displaying the original item itself. The video Annotation would then be saved and permanently attached to this Archive Item/document surrogate.
Manages large collections of digital records and physical items
All technologies used in the system are scalable and could adequately handle a 500,000 record database.
Meets particular knowledge needs of diverse communities
Keeping Culture KMS has been developed to specifically respond to evolving knowledge and cultural needs of any community. This is evident in the system's:
• Archive Engine record management • Content Restriction functionality • User Access Management
Operates with other databases of the same or other systems
If more than one repository is required, then a centralised deployment model would provide maximum interoperability.
The system provides Import and Export functionality that can be extended, through plugins, to provide support for different Systems.
Moreover, the underlying requirement for the Open Archives Initiative (OAI) Protocol for metadata harvesting are in place, however the implementation for harvesting has not been developed.
Integrates external tools to improve the software's functionality
Each component in the system has an API with documentation that can be used to extend or integrate external functionality.
Installs easily and easy to integrate
Installation instructions are provided with the system and are also available on this community Wiki.
Facilitates adding content (such as images, video, comment on records, add traditional knowledge to existing metadata record, etc) to old and new records
In addition to the conventional text field methods of recording metadata, Keeping Culture KMS has a number of rich tools for recording, identifying and imparting knowledge to its users. Furthermore, the system levers the power of a relational database to link together associated records. These links can be traversed via the user interface, allowing secondary and tertiary levels of related metadata to be accessible in a single screen.
Annotations provide a method for users to enter personal comments and stories in text, audio and video formats. An entry made in an annotation control is comprised of four parts:
• Date: the creation date of the annotation.
• Contributor(s): the name of the person or persons entering the information or recording the message. An annotation must have at least one contributor to be saved by the System.
• Comment or Message: the annotations text comment or record message. A comment or message must be provided for an annotation to be saved.
• Source: the origin or place from which the information was obtained. Entering source information is optional.
Annotations are displayed in chronological order inside the annotation control. Recorded audio and movie messages can be played, one at a time, directly within the list annotations. Annotations are subject to content restrictions in the same way as any other record in the system.
Features are used to identify 'subject matter' within an Archive Item's media. They comprise of a reference to a Profile record within the system, which is attached to a specific region of a Photo, Document, Object or Movie image. Sound Archive Items have features, but they are not attached to a region.
Features play an important role in the system. Specifically they:
• provide a secondary tier of metadata related to an Archive Item.
• improve the search accuracy when searching for a specific 'subject matter'.
• allow users to visually identify 'subject matter'.
Many of the Attributes (or metadata fields) that make up the schema of a record class, reference the records of another record class. For example, 'Creator' attributes of a Photo Archive Item reference the records of the People Profile. The Profile View panel allows these referenced records to be viewed and edited in an overlay panel without disrupting the user’s workflow.
It is not always possible to predict the relationships that may occur between records. Tags allow references to be created between records that have an unclear or even temporary relationship. Tags also provide a link to a predefined list of subjects.
Searching the database with simple search
There are numerous ways of filtering and finding content within the Archive, one of these methods is by conducting a Basic Search. This search function is developed as a general purpose search for basic and intermediate users of the system. All metadata in the system can be searched, however, administrators can turn on or off the searchability of each metadata element to define a set of searchable fields.
The Basic Search consists of four elements:
• Limit to Archive Item: allows the search to be conducted over a nominated set of Archive Item types.
• Keyword Search: matches partial and complete words found in record metadata. A search term can be constructed using the following operators and formatting:
- The AND operator used between keywords will match all keywords in any order. For example, the search term 'Amata AND Inma' will find records where both words, 'Inma' and 'Amata', are present in an attribute value.
- The OR operator used between keywords will match any of the keywords in the search term. For example, the search term 'Dog OR Dingo' will find records where either or both words, 'Dingo' or 'Dog', are present in an attribute value.
- Quotation marks (") surrounding a phrase (an ordered sequence of two or more words) will match the phrase exactly.
- A combination of AND, OR and phrases can be used to build complex search terms. The AND operator is evaluated before the OR operator.
- The search can be performed in a case-sensitive or case-insensitive manner.
• Reference Search: searches for all references to one or more records of a searchable Profile or List class. For example, entering a person’s name into the People field will find all references to that person's record.
• Date Search: finds records that match an exact date (day, month and year) or a date that falls within a start date and end date range. Often an exact date is unknown and only a partial date, circa date or time period can be entered. The system has been developed to evaluate partial dates as part of the search process.
The following date formats are accepted by the system:
- Decade dates eg. 1940s
- Year dates eg. 1976
- Year and month dates eg. 07/1987
- Circa year dates are evaluated as two years either side of the year eg. circa 1994 searches between 1992 until 1996.
- Circa month dates are evaluated as two months either side of the month eg. circa 06/2008 searches between 04/2008 until 08/2008.
- Circa day dates are evaluated as one week either side of the day eg. circa 23/03/1978 searches between 16/03/1978 until 30/03/1978.
- Range dates eg. 14/09/1959 – 18/09/1959
- Complete single dates eg. 06/07/2010
The Basic Search has AND search logic where all values specified in the search criteria must be matched. The Keyword, Reference and Date search element are optional, the user may enter as much or as little search criteria as they like.
Once an initial search has been conducted, a secondary search can be constrained to search against those records retrieved in the previous search. This can be repeated indefinitely until the desired result set has been achieved.
View of Tjaata (Start) page. Ngurila means Basic Search.
Searching the database with advanced search
The Advanced Search provides a comprehensive fine grain search aimed at advanced and research users. It allows users to:
• Nominate an Archive Item or Profile class to search.
• Apply any content restriction criteria requirements, allowing searches for restricted or unrestricted content including method of restriction.
• Specify a search method:
- AND Logic: all attribute values specified in the search criteria must be met, or
- OR Logic: one or more attribute values specified in the search criteria must be met.
• Select specific metadata attributes to search.
• Search for a specific value, depending on data-type, using:
- a keyword search (see Section 4.1.4 for functionality),
- reference search,
- timecode search with <, >, =, !=, <= and >= operators,
- number search with <, >, =, !=, <= and >= operators,
- dimension search, and
- date search (see Section 4.1.4 for functionality).
• Additional search logic includes:
- Search for null or empty values.
- Search for any value as long as it is not null or empty.
- Search for values 'not equal to' the value specified.
Similarly to the Basic Search, the Advanced Search also allows secondary searches to be constrained to those records retrieved in the previous search. These can also be repeated indefinitely until the desired result set has been achieved.
Browsing the database
The Selection List allows a user to select the records of a particular Profile or List class, then search for any references to the selected records. The search may be constrained using one or more of the following options:
• Features: limits the search to features identified within an Archive Items media. For example, a person identified in a photo.
• Annotation Contributors: limits the search to only those comments and traditional knowledge annotations made by a person or group of people.
• Metadata: limits the search to all metadata other than Features and Contributors.
Administrators can extend and customise the Selection List to display any number of Profile and List classes. These classes could include, but are not limited to:
• Historical Stories
Other forms of browsing
In addition to Basic and Advanced Searches and Selection Lists, users can also browse by:
• Archive Item: view all records of a chosen Archive Item eg Photos, Documents, Movies, Objects or Sounds by way of button.
• Go to Record: go directly to a chosen record by entering its archive number.
• Control Action Buttons: these small buttons (cogs), positioned adjacent to metadata control, reveal a menu displaying options relating to the values defined in the control. One option allows the user to search for references to a defined value.
• Scrolling along thumbnail images of record items.
What sort of Metadata and record schema does Ara Irititja use?
The system's Archive Engine component controls the management of database, record schema and the records themselves. This highly configurable component allows administrators to add, edit and remove record classes and metadata fields, called Attributes, to meet the demands of a growing and transforming knowledge database.
The Descriptive and Administrative metadata fields expressed in this section, and any additional metadata fields, can be constructed through a Wizard style user interface within the administrative section of the system.
The system classifies record classes into four types:
• Lists: a single Attribute record class type used to define a list of values either by name or title. A list is often referenced by an Attribute to provide a set of possible Attribute values. For example, a list of Photographic Formats can be defined which in turn is used to populate a Photographic Format popup menu.
• Profiles: a multi Attribute record class type used to define a non-archival record class. For example, the People Profile contains Attributes for gathering metadata about a person.
• Archive Item: a multi Attribute record class type used to define an archival record class. For example, the system has five Archive Item record classes: Photos, Documents, Objects, Movies and Sounds.
• Archive View: a multi Attribute record class type used to define a subset of metadata related to a digital representation of an Archive Item record class.
Attributes are used to define a set of metadata fields for a record class. An Attribute can take many forms, specifically:
• An Attribute can be one of the following data types: text, number (interger or double), dimension (2D or 3D), timecode (HH:MM:SS), boolean (Yes/No), date or URL.
• An Attribute can be defined to accept a single value or multiple values depending on its data type.
• An Attribute can be static or reference its values from the records of a specific record class.
• An Attribute can reference its values from the records belonging to multiple record classes.
• A reference Attribute can be configured to accept new values or force the selection of an existing value.
• Two or more attributes can be combined to form a tuple.
The Archive Engine does not gain its extensibility by storing metadata as JSON, XML or any other formatted data structure, as some systems do. Through direct manipulation of the underlying relational database, the system maintains a one-to-one relationship between the internal and external record structures. Tables inside the database are constructed using InnoDB engine providing relational integrity through InnoDB's internal management of data references.
The system's Archive Item metadata structure reflects the methodologies used to archive non-digital objects in the physical world. This concept is best described using the process of archiving a Book.
The Archive Item record consists of three related record types:
• Item record: the Item record contains descriptive information about the book as a whole. This would include the title, number of pages, construction materials, reproduction technique, document type, publication date, publisher, etc.
• View record: the book's cover and pages are scanned creating a digital copy of the book. Each scan represents a 'view' of the book. Each 'view' is given a View record containing descriptive information about that view. This would include translation, transcript, page number, features, references, etc. View records are linked to the Item record in page order.
• Media record: each scan receives a Media record to describe the media file. This would include filepath, file size, embedded metadata, aspect ratio, thumbnail filepath, crop coordinates, etc. The Media record is linked to its associated View record.
The Attributes (or metadata fields) of the Item and View records are tailored to accommodate the differences between the five Archive Item types: Photos, Documents, Movies, Sounds and Objects.
The user interface reflects the structure of the archive by providing alternative areas into which you put your data. The General section with the caption, date, place and creator is data which according to the system outlined above, belongs to the View or Item records. The way these fields are organised is customisable. For example, you can put whichever fields from Views or Items in General that you think are the most important for the viewer to see.
What level of User Access does Ara Irititja have?
The Users, Groups and Permissions component controls user access to content and system functionality
The concept of Users, Groups and Permission is best described in reverse order:
• Permissions: A Permission has two main tasks in the Keeping Culture KMS. The first is to allow users to access system functionality like importing records, replacing media, cropping an image, etc. The second is to allow users to access records that are restricted. (ie. content restrictions). For the avoidance of doubt, content restriction is a type of permission that can only be applied to records and Attributes. In a metaphorical sense, a content restriction is a lock on a record and each system function has a lock — also a kind of restriction — then a Permission is a key that unlocks a restriction.
• Groups: A Group is a set of one or more enabled permissions. A Group, metaphorically speaking, is a key ring with one or more Permission keys. The key ring represents a grouping of system functionality and/or restricted content access available to the Group.
• Users: A User is a login access account associated with one person. The exception to this rule is the Guest account that is associated with any number of anonymous people. A User can be made a member of one or more Groups, thus determining the User's access to system functionality and content. Continuing the metaphor, by making a person a member of a group, they are receiving the Group key ring and the keys attached to the key ring. The person can then unlock system functionality and content, using the keys available to them on the Group key ring.
• User access levels are defined by Groups within. There are two mandatory Groups required by the Keeping Culture KMS:
- Super Administrator: provides total access and control over the entire Keeping Culture KMS. In the context of this proposal the Super Administrator would be the level above Administrators.
- Guest: allows anonymous limited access to the system.
The Keeping Culture KMS can have any number of custom Groups, containing any number of User memberships. Groups can inherit the Permissions of another Group, allowing for a hierarchy of access levels to be defined. However, all Groups must inherit the Permissions of the Guest group.
The Users, Groups and Permission concept provides tremendous flexibility in how you administer the Archive. For example, content access and system functionality can be paired together, and users can be members of Groups, with specific functionality.
will require login
Keeping Culture KMS implements account login access by individual username and passwords.
add and remove Community Administrators and Operators
Keeping Culture KMS allows Administrators with the ability to manage system Users. This includes adding and removing user accounts and group membership.
perform other administrative duties such as migration of data and content, statistics
Keeping Culture KMS can be configured to allow Administrator account holders with the ability to perform administrative functions and duties.
will require login
Keeping Culture KMS implements account login access by individual username and passwords.
create new records within own archival collection
Community Administrators could add new records into the community collection to which they are assigned using the system's Portal Configuration.
edit records they have added
Keeping Culture KMS allows Community Administrator accounts to edit records that they have added. However, while it is technically possible for the system to constrain the editing of records to only the account holder that created the record, this would require every Community Administrator to have their own custom content restriction and group. The result would be a complicated content restriction model that would be difficult to track and maintain. A compromise to this approach may be to allow Community Administrators belonging to a community to edit records in their assigned community collection.
add traditional knowledge to records in own community’s collection
Keeping Culture KMS allows a subset of records and traditional knowledge metadata Attributes to be editable by a subset of Community Administrator accounts using the system's content restriction functionality.
add comments to any record
Keeping Culture KMS can be configured to allow Community Administrator account holders with the ability to comment on any record.
will require login
Keeping Culture KMS implements account login access by individual username and passwords. read-only access to select subset of records and content;
Keeping Culture KMS can be configured to allow a subset of read-only records and content to be accessed using the system's content restriction functionality. Content restrictions are explained earlier.
add traditional knowledge to select subset of records and content in own community’s collection
Keeping Culture KMS allows a subset of records and traditional knowledge metadata Attributes to be editable by a subset of Community Operator accounts using the system's content restriction functionality. Content restrictions are explained earlier.
add comments to select subset of record
Keeping Culture KMS allows a subset of records and comment metadata Attributes to be editable using the system's content restriction functionality. Content restrictions are explained earlier.
no login required or login through default guest account
A 'Guest Login' button on the login screen allows access to the archive without a username and password.
Keeping Culture KMS is configured with read-only access to unrestricted content (or 'public' content) by default.
register for login account in order to add comments
Keeping Culture KMS is configured to enable existing account holders the ability to create new accounts for guest users. This means a guest cannot self-register their own account. However, it would not be difficult to amend the software to allow self-registration.
What is the purpose of Restricted records?
Restricting records to a certain group of users
Keeping Culture KMS has been developed to manage and maintain restrictions to content, based on individual, community and cultural protocols. All record access is based on the content restriction permissions in which the user holds. Any record inaccessible to the user through content restriction is hidden, hence maintaining complete secrecy.
A community may wish to restrict a map indicating sacred sites, for example, to Administrators or Elders. User profiles could be connected to content so that the system can recognise that a particular user is permitted to view a restricted record. Alternatively, users may be prompted for a password upon requesting access to a restricted record.
When a user has permission (for example, as an Administrator) to view a restricted content record, the system displays a prompt asking the user whether they wish to view items of a particular content restriction type. The user may request to view these items, or hide them, either temporarily or for the remainder of the time the user is logged into the system.
Keeping Culture KMS has a record Flagging functionality that allows users to notify administrative staff to an issue with a record. A flagged record is obscured from view until an Administrator has either restricted the record or removed the flag from the record.
Accessing records based on appropriate access levels
Record access or content restrictions are administered through a Users, Groups and Permissions component (see earlier section). By default, the system has 'Sorrow' and 'Sensitive' restrictions, however any number of custom restrictions can be added to the system to tailor a desired content access model.
Content restrictions can be applied at three different levels within the system:
• Profile/Archive Item class: provides a global content restriction to all records of a Profile/Archive Item class.
• Attribute: allows a content restriction to be applied to a metadata field (called an 'attribute') of a Profile/Archive Item class.
• Record: allows a content restriction to be applied to a record.
Furthermore, content restrictions can be applied to four methods of system functionality:
• View (Read): prevents the record or attribute from being viewed.
• Modify (Write): prevents the record or attribute from being modified. The user must also have permission to view the record or attribute.
• Print: prevents the record or attribute from being printed. The user must also have permission to view the record or attribute.
• Export: prevents the record or attribute from being exported or downloaded. The user must also have permission to view the record or attribute.
Each restriction method can be assigned multiple restrictions. The user must have permission for all content restrictions assigned to the method in order to 'unlock' the method's functionality.
'View' Content Restrictions by Association
The relational nature of the Ara Irititja database allows for the 'View' method of content restriction to be amalgamated from the referenced record to the record that references it. For example, a Place may be restricted for cultural reasons, therefore any photograph taken at that place should also be restricted. Applying a View content restriction to the place record will result in any photograph that references that place — as its 'creation place' — to also become restricted.
The amalgamation of content restrictions is not enforced by the system by default. Rather, system administrators can specify where these amalgamations should occur, providing a dynamic content restriction model through record association.
How does an Administrator manage records?
Adding new records to database
There are six ways to add new records to the Keeping Culture KMS database:
• Import metadata: create new non-media based records from an external data-source, like csv/tsv formatted files.
• Import metadata with associated media: creates new Archive Item records from an external data-source, like csv/tsv formatted files, containing references to associated media files.
• Add media: create new Archive Item records by ingesting media files into the system. Common metadata and content restrictions for the ingested media can be applied during this process.
• Add record: create new non-media based record within the Administration screens.
• New record by reference: create new non-media based records by entering a value that does not exist into a referenced field. For example, indentifying a new person by name in a photo will automatically generate a new Person record for the identified person.
• Add Audio or Movie annotations: create new Archive Item records by adding audio and movie annotation records.
There are five ways to edit records:
• Edit single record: edit the metadata of a record.
• Merge record: merge two or more records of the same type, forming one record.
• Batch edit: add, edit or remove metadata and/or content restrictions from two or more records of the same type.
• Replace media: replace the media for one record.
• Batch media replacement: replace one or more media files by labelling the replacement media file with the archive number of the media to replace.
Generating reports and printing
Generating reports requires interrogating the underlying MySQL database to output the report data. This requires a staff member with a technical background in SQL and access to MySQL console. With a clear understanding of the individual user organisation’s reporting requirements, a series of templates could be developed to assist non-technical staff in the generation of reports.
Keeping Culture KMS also has many print functions that are generated by the system in PDF format. These can be printed within the browser or downloaded for another purpose. PDF provides consistency in document appearance and avoids the unpredictable output that often occurs when printing from a browser.
Prints are template-based allowing for customisation and for new templates to be added as required. The system comes installed with eight template layouts:
• Full Page Image: Displays a full-page image with minimal metadata. (best-fit page orientation)
• Half Page Image: Displays two images per page with minimal metadata.
• Quarter Page Image: Displays four images per page with minimal metadata.
• Metadata Only: Displays records metadata only.
• Full Page Image with Metadata: Displays a full-page image with metadata.
• Half Page Image with Metadata: Displays a half page image with metadata.
• Quarter Page Image with Metadata: Displays a quarter page image with metadata.
• List: Displays a list of records.
The Print Preview panel with embedded PDF preview using Adobe Reader X.
Tracking statistics like user and administrative activity
The system has a comprehensive Change Log that tracks user activities, records changes and administrative functions. The Change Log can be filtered by entry date, user, record, Profile/Archive Item, attribute, flag, restriction, user group and change log entry event. The state of a record or attribute before being modified is recorded in the Change Log for tracking and recovery purposes.
The following Change Log events are recorded:
• Guest Login/Logout (IP address recorded)
• User Login/Logout (IP address recorded)
• Add/Edit/Hide/Restore/Delete Record
• Apply/Remove Record Content Restrictions
• Record Merge
• Replace Media
• Promote Annotation
• Add/Edit/Remove Flag
• Add/Edit/Remove Attribute
• Apply/Remove Attribute Content Restrictions
• New/Edit/Remove List
• New/Edit/Remove Profile (includes Lists, Archive Items and Archive Views)
• Apply/Remove Profile Content Restrictions
• Import/Export Records
How does an Administrator import/export and migrate?
Migrating records and content contained in the database
A 'dump' of the database, including schema, data and internal routines, can be downloaded as a zip file using the Backup Wizard in the administration section of the Ara Irititja KMS. The data contained in this file is able to be repurposed by importing the data into another instance of MySQL for manipulation and export.
All media, including annotation records, are stored externally from the database. They are stored as files on a hard-drive and can be easily duplicated by a system administrator who has 'root' access to the server.
A Full System Backup function is also available through the Backup Wizard. It contains the database, software files and all media assets.
The Export Wizard could also be used to output record data and media. A custom export plug-in could be developed that outputs data in a format that is compatible with the particular system being migrated to.
Importing records from external files
Metadata contained in CSV/TSV files can be imported into the system via an Import Wizard. The wizard provides tools to accurately map data into the correct fields, including separating column data via custom delimiters and allowing multiple column data to be combined into one field.
Media can be imported along with metadata, providing the CSV/TSV file contains a column with either a relative or absolute file path to the media.
Exporting records from external files
An Export Wizard provides a means for exporting metadata in CSV/TSV format. The wizard allows for the selection of a set of attributes (fields) to export, including media associated with the metadata being exported.
Exporting records in DCMI
Metadata can be exported in qualified Dublin Core expressed in XML. Administrators can specify DC terms for each field within a record's schema. Specifying a DC term is optional. Fields without DC terms are omitted from the export.