A Heurist user that has various administration rights over a database, including: edit database record structure, manage user and workgroup access.

Advanced Search

The Advanced Search Builder provides a means of building more advanced filter expressions, to allow you to more precisely refine your search syntax, to create a more targeted search, searching across a wider range of data, and providing a more sophisticated sorting of results.

Basic Search

You can run a simple, traditional search, matched against record titles, by entering a text string directly into the Filter box


Identifies a record of interest to you and to which you can add private information. Records that you own automatically give you access to this Private section. Once you bookmark a record created by another user, the Private section of the record also becomes available to you, allowing you to store both private and shared notes, tags, etc.


The Bookmarklet link (for a database) can be added to your browser toolbar, letting you capture information in any web page displayed in the browser (including a bookmarks file and search list, such as Google) and analyse it for bibliographic information. You can choose to create a record based on the page or selected text, or links within the page, either as a Web Page / Site record type or any available record type.

The Bookmarklet is a simple Javascript component like those found (and executed automatically) on most web pages. It is easily installed and will not harm your computer.


A group of records temporally linked together by a user. A collection can then be viewed separately in the Search Results pane. A collection can be saved to the Saved Filters Pane if required. Only one collection can be open at any time.

Collection Metadata

A Research Data Australia compliant record containing top level research collection metadata.

Data Entry Form

This page has separate tabs for the user to enter data into a form, including additional metadata. The full set of tabs can be displayed by selecting the Full radio button (Full Mode):

Tabs are:

  • The Shared Information page. This shows the editable content (fields) for a particular record, as defined by its record type. This information is available to view or edit based on the access setting you selected for the record on creation.
  • Private Information Tab. The Private Information page shows your (editable) personal information about the record. The tab content is available within 'bookmarked’ records only (i.e. restricted to the Owner of the record and anyone who has bookmarked the record).
  • Workgroup Tags Tab. The Workgroup Tags page allows a workgroup Administrator (only) to select tags to add to the record. Selected tags appear in the Keywords area of a record and are only visible to the members of the workgroup. This allows workgroup members to refer easily and quickly to records using vocabulary that is familiar and meaningful to the group (e.g. as a group of researchers working collaboratively).
  • Text Tab. The Text page allows you to add extended notes to your record and engage in a discussion with other workgroup members.
  • Relationships Tab. The Relationships page shows a consolidated view of all of this record's relationships (i.e. links between this record and other records, regardless of type). This includes relationships added when completing a relationship marker field in a record. Relationships can be added, deleted and edited within the Relationships tab (although it is best practice to add relationships through the use of a relationship marker field).

Data types

These determine the kind of information that can be stored in a field type during data entry or import. When you are adding a data type, the set of available data types is displayed. You can click on the example shown to see how the data type operates. Click the check-box of the data type you wish to use and click Select.

A range of basic data types exist, including text, numeric, date, geospatial etc. More specialised data types include Relationship Markers, Record Pointers and Term Lists.

Database Structure

A database structure (schema definition) comprises the following key building blocks:

Record types. The entities or research objects you wish to capture. For example: Article. You need to specify and define a record type for each entity that comprises your data

Field types. The attributes that describe the information or data that can be stored in any record of that type. For example, Title, Author, Year, Journal, Volume etc.


The process of resolving any conflicts that arise when a single term is ambiguous.

Disambiguation can occur when:

  • Creating a record. Heurist has been designed to check for duplication and activates a disambiguation process when a new record is being added to the database. Heurist will prompt the user to check whether the data being entered is already in the database by making suggestions. The user has the option to select 'None of the above, and create a new record' where the data is unique. The user needs to be mindful when selecting any of the Heurist records, this will overwrite any data entered.
  • Importing data. Records can be imported into Heurist in bulk in diverse file formats: for example, the bookmarks collected in a browser (E.g. Chrome) or in a citation library (e.g. EndNote or RefWorks). Where duplicate records are identified, Heurist presents these to the user to assess whether to import the record.
  • Harvesting links from a website (see Harvest).
  • Embedding a pointer (to another record) into a record (primary resource).

Expansion Rules

A RuleSet  embedded within a filter and applied to the result-set after each selection. They expand the results to include connected records (entities). Rules can narrow this expansion down to specific entity types, connection types or filters. Use rules to bring in information such as map location or dates for display on a map or timeline.

Faceted Search

A type of structured navigation that provides multiple filters, one for each property (or facet) of your content, which allow you to drill-down on just those properties of the data that you wish to explore more fully.


The FAIMS project (Field Acquired Information Management System (http://fedarch.org) is a highly configurable system for data collection using consumer grade Android tablets, funded by the Australian Research Council (ARC) and National eResearch Collaboration Tools and Resources (NeCTAR). The FAIMS system is suitable for collection of information in libraries, archives and museums, for social surveys, and for a range of natural science field projects, as well as for archaeological survey or excavation (the original target audience). The system is geographically aware, connects to internal or external cameras and GPS, and seamlessly synchronises data collection across multiple tablets for team use.


Researchers can make the Heurist records they use regularly, quickly retrievable by tagging them as one of their 'Favourites'. 

Field Expression

Once you have inserted a base field type into your record structure, you can further define how this field is 'expressed' in this record type only.

The field type expression refers to the use of a field type in a particular record structure: what the user will actually see in the data edit page for records of that type and constraints on the values that can be edited. Thus a single field base can have multiple expressions. Changes to a field's usage/expression include: display name, repeatability, prompts, help text, requirement (e.g. mandatory), etc.

Field Type

Defines the display and use of a field on a data entry form. A Heurist record definition is comprised of one or more field types. A field type is defined based on an underlying data type.


Provides a unique drag-and-tag interface for creating metadata for multimedia files (including spatial metadata) within a framework based on geographic location and time of collection, and to generate XML repository packages without programming. It provides a robust methodology to maintain XML manifests for each folder and sub-folder indexed. The FieldHelper web page and download files are available here.


A digital image, text, sound or other multimedia item uploaded into Heurist records.


Heurist's search engine lets you build and run a filter to precisely target elements of your records (e.g. titles, tags, keywords, special fields etc.) in order to locate and rapidly assemble subsets of records, to which you can optionally apply additional filters (to drill-down on facets of the result-set) and/or rules (to expand the result-set). The result-set is displayed in the Search Results pane. You can optionally save your filter for future use, for analysing, for publishing or sharing with colleagues.

Filters comprise a filter expression, display settings (images, icons, legend) and additional components.

Filter Expression

The filter expression refers to the search string used in the filter, and is based on Heurist's query syntax (for the complete syntax, see Filter Syntax or click the Help option on the Filter Bar).


Gephi is a widely used free, open-source desktop tool that provides great flexibility in the visualisation of networks.  Gephi provides additional sophisticated ways of visualising the data shown in the network diagram.

Group Member

A co-member of a Workgroup (set up for Buildd resource sharing).


HML (Heurist Markup Language) is a version of XML.


Refers to an instance of a type, such as an instance of a record type or field type. For example, 'Paris' might be an instance of a field type 'City Name'.


KML (Keyhole Markup Language) is a file format used to display geographic data in an Earth browser such as Google Earth, Google Maps, and Google Maps for mobile. KML uses a tag-based structure with nested elements and attributes and is based on the XML standard. All tags are case-sensitive and must be appear exactly as they are listed in the KML Reference. The Reference indicates which tags are optional. Within a given element, tags must appear in the order shown in the Reference. For additional Details, go here.

Master Index

This is a publicly accessible list of Heurist databases, which makes available to all users all Heurist core databases and all registered end-user generated databases. Also included are curated templates: well-developed schemas developed by the Heurist team or members of the Heurist community (communities of practices such as HuNI and FAIMS).

My Bookmarks

The set of a user's bookmarked records, as shown on the Saved Filters Pane.

Network Diagram

This provides an interactive (spring-loaded) visualisation of either your database structure or your data result-set. A Structure Network Diagram displays an interactive visualisation of your database structure: record types are shown as nodes, and the connections (pointer fields and relationships) as the links between nodes. A Data Network Diagram shows records as nodes, and the connections (pointer fields and relationships) as the lines (links) between nodes (edges).


A 'composite' field (e.g. a Geospatial object on a map).

Private Notes

A user's own notes or annotations added to a record (including bookmarked records).

These notes are viewable only by that user.

Project Page

The address of the Heurist Project Page is installation-dependant, but it is normally installed at the root web address of the server or as heurist or h4 at this address. For example, on the dedicated Heurist server at the University of Sydney the Heurist Project Page URL is: http://heurist.sydney.edu.au/.

Quick Search

An assisted search dialog that allows the user to quickly search for records based primarily on field type and/or content. (See also Advanced Search.)

Record Pointer

Fields embedded in a Heurist record that point to another record. Record pointers are a way of embedding a 'concrete' link within a record type to another record type. These are used to include or link to data about objects which have their own set of complex attributes such as a person, a site or a book. When a record type is defined, a pointer in that record can be constrained to a particular record type (e.g. a person record) or remain unconstrained (e.g. any record).

Pointers differ from 'relationships', in that a relationship is a record (rather than a field) that provides additional information about the link between two records.

Record Type

Records act as a shared description of research entities of common interest.

Each record instance created by the user is based on a single record type created by the Database Designer.

A record is comprised of fields (attributes) that capture information about a resource (see Resource). The record type definition specifies the set of field types (see Field Type) available in the record, and various properties of the record type.

Heurist provides, by default, a diverse range (over 100) of predefined record types (resources). Some of these are provided by default, while others can be imported. Some of these record types can be configured by Designers, while others are locked for system use.

Designers can in addition define and create their own record types. These are then available for reuse in subsequent databases.


A Heurist record of type Relationship Marker) that forms a connection (a relationship) between any two records in the database (regardless of type). All relationship details are stored in the relationship record itself, which has two (pointer) fields that point to the source record of the relationship and the target record.

The required fields for a relationship record are:

  • Title
  • Primary resource: pointer to the record being linked from (e.g. a book)
  • Relationship type (see Relationship Type)
  • Linked resource: pointer to the record record linking to primary resource (e.g. a book reviewer)

The Relationship Marker data type lets you tightly specify a required relationship in the data entry interface and embed it at a particular point in the data editing form. It describes the type of relationship that can exist between two record types, connected via the relationship record. Both pointer and relationship marker fields can constrain the types of relationship which can be created (e.g. one might constrain a relationship from a person to another person and only allow genealogical relationships; this stops a person being the father of a building or the author of another person).

For instance, a Person record might require the following relationships:

  • School (relationships to an Organisation, 1 (required) relationship, valid terms: attendsSchool)
  • Siblings (relationships to a Person, 0 - n relationships, valid terms: hasBrother, hasSister, has HalfBrother, etc.)
  • Parents (relationships to a Person, 2 values, different relationship types, valid terms: hasFather, hasMother - each must be present)

These can be embedded as Relationship Marker fields at specific points in the data entry screen, like any other detail type (field) used in constructing the Data Entry Screen.

When relationship marker details are used to add a relationship, the relationship record is created as normal in the database; there is no way of telling that the relationship record was created through a relationship marker rather than through the Relationships tab. When the record is reopened in the Data Entry Screen, the form identifies the existing relationships and positions them according to the relationship markers which they satisfy; any additional relationships are displayed on the Relationships tab.

The same relationship marker may offer different terms and/or requirements between different record type pairs. For example, a relationship marker detail in the Unpublished Report editing form might allow the creation of relationship records between the report and either a Person (with relationship types isAuthor, isEditor, isCompiler) or an Organisation (with relationship types isCorporateAuthor, isCommissioner).

The relationship marker may be 'multi value' (that is, multiple relationships can be entered through it), with one and only one author, editor or compiler (Person) required, and an optional Organisation relationship. In practice, to avoid confusion, these relationships would probably be handled by two separate relationship markers.


A reminder is a way for a user to notify or remind themselves and others on a one-off or ongoing basis. Reminders are useful as a means of keeping up-to-date or being reminded to update a record or website or sharing useful research resources


Resource is the generic term for an item, object, entity or abstract concept described in Heurist. A resource is generally represented by a record in Heurist. Typical examples of resources include: Book, Building, Collection, Conference etc.


RuleSets provide a way of expanding the initial search to a larger set of records by specifying which pointers (including reverse pointers) and relationships to follow, in order to add related records to the current results set.

A RuleSet comprises one or more rules. A rule expands the initial search to a larger set of records by specifying which pointers (including reverse pointers) and relationships to follow, in order to add related records to the current result-set.

Saved Filter

A saved filter is the set of search properties (filters, rules etc.) stored by a user and made available on the Saved Filters Pane to the user/workgroup.


Heurist’s 'search' functionality goes beyond simply locating records; it encompasses:

  • filtering records based on simple and advanced search criteria
  • expanding record selections to additional levels based on pointers and relationships, via 'rule sets'
  • narrowing down record results based on properties (or facets), of the search results, via 'faceted search'


Sharing and collaboration are one and the same thing.

Researchers can collaborate by sharing ideas, resources and data in Heurist by:

  • notifying colleagues via email of Heurist record changes
  • establishing a workgroup to share records and notes
  • annotating Heurist records

Heurist records may contain shared data (tags, notes, reminders etc. available to all group members) or private data (visible only to that user) to a record's fields.


A tag is an informal, descriptive keyword (a single or multi-word text string you assign to similar record sub-sets that allows them to be easily found through browsing or searching. For example: 'Favourite'. A tag is essential a field within the Private part of a bookmarked (or user-created) record. Tags enforce a user-centric organisation on a set of records, particular as the number of records grows.

By tagging records with meaningful, multiple search keys, they become a very useful means of organising records, allowing you to mark specific subsets of your bookmarked records based on your particular view of the world and using terminology familiar and meaningful to you individually, in order to identify records that you wish to use in different situations (i.e. a 'reference' collection of records). For example, to identify the records for a class reading list, for a research project, for a paper in preparation or for extra-curricular activities such as travel or events.

Multiple tags can be added to individual records. Multiple records can share the same tag (tags are reusable).

In addition to personal tags, group tags can be assigned to a Workgroup to enable the members of the Workgroup to share easy retrieval of records of mutual research interest. Workgroup tags are managed by a workgroup Administrator.


The Text Encoding Initiative (TEI) is a semantic XML format for marking up text.

Term Code

Used for an official term code such as:

  • 100023 - Australian Govt SEO (Socio Economic Objective)

where, 100023 = "Historical - Other".


Words or phrases that comprise a dropdown menu; these can be defined or chosen by the database designer for a field of type 'Terms List'. Terms can be shared between different field types.

A 'Term List' is the set of predefined 'enumerated' values ('terms') within a particular dropdown (e.g. a term list field type), and is based on all or some items in a vocabulary. A 'vocabulary' is the underlying top level category of related 'child' terms (e.g. 'Language' is a vocabulary, while 'French' is a child term). Vocabularies can be nested (i.e. any child term can in turn become a vocabulary). The lowest level values are the terms. A term list can comprise a hierarchy of nested terms (i.e. nested), with any 'leaf term' being potentially a new term list.

Term lists may be used for any form of classification or categorisation of preconfigured data, such as raw material, condition, period, religious affiliation, language, country etc. For example, a Language dropdown might have the following structure:

Title Mask

Allow you to define composite titles that can be constructed dynamically from field values. The title mask is a string into which field values are inserted to create the title. The constructed value is used as the extended title displayed in search results and other lists. The fields are populated on-the-fly when the record is generated.


Lets you transform your input data to structured output for tailored structured views of your records by applying additional formatting or processing to the result of a query. Standard transforms can be applied, including:

A transform is essentially a template that identifies a set of patterns in a source document (e.g. 'find all the top level headings') and describes what to do with these elements (e.g. write out all the headings as title elements').

Transforms encompass the following three types of file:

  • Input. This is a record of type Document, that stores an XML file containing the structured source data to be transformed. Data is structured through the use of meaningful tags, that identify the different components of the document. You can have multiple XML documents.
  • Transform. This is a record of type Transform, that stores / links to an XSLT file containing the output formatting to be applied to the input (source) data. XSLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other XML documents,[1] or other objects such as HTML for web pages, plain text or into XSL Formatting Objects which can then be converted to PDF, PostScript and PNG. Typically, input documents are XML files. The original document is not changed; rather, a new document is created based on the content of an existing one. Note. A transform is another name for an XSLT or 'XSL Transform'. This is also known as an XSL style sheet. Both terminologies are synonymous and either can be used.
  • Output. This is the output produced by the transform on the source data, and can be in various formats, such as XHTML.

XML and XSLT files can be produced using any text editor (since they are only text), or a dedicated editor, such as Oxygen or OpenOffice.


The 'parent' term for a complete set of 'child' terms that belong to a particular category (e.g. 'Language') of terms. Vocabularies can be nested (i.e. any child term can in turn become a vocabulary. An item within the vocabulary is called a 'term' (e.g. 'French').


A groups of users who have shared access to a set of records (the database*) allowing them to share research interests and work collaboratively on research projects to collectively build up collections of resources or data, and use common tag names. 


Extensible HyperText Mark-up Language. This is a family of XML mark-up languages that mirror or extend versions of HTML, the language in which web pages are written.


Extensible Mark-up Language. This is a mark-up language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable.


EXtensible Stylesheet Language. This is a style sheet language for XML documents.


XSL Transformations. This is an XML transformation language designed specifically to transform an input XML document (like XHTML) into an output XML document which satisfies some specific goal.

Created with the Personal Edition of HelpNDoc: Full-featured Kindle eBooks generator