BCAUL pilot project - Qubit input/export: Dublin Core

From AtoM wiki

Main Page > Development > Development/Projects > Development/Projects/BCAUL Pilot > Development/Projects/BCAUL Pilot/Metadata mapping > DC


This is historical development documentation, migrated from the now-defunct Artefactual wiki. The content was first added there on October 30, 2008, and last updated on December 5, 2008. For more information, see the landing page for this development project: BCAUL Pilot Project. The content was moved to the AtoM wiki on July 29, 2015.


Map Dublin Core elements to Qubit fields to support:

  • OAI harvesting (output as Dublin Core xml).
  • Design of Dublin Core data entry templates (input).

A design goal of Qubit is to fully support simple Dublin Core, ensuring that DC elements map to core Qubit objects and properties (fields).


Simple DC comprises 15 elements. In mapping these to the current Qubit (1.0.4), elements fall into 3 groups:

  • Core: There is a one-to-one relation between a DC element and a field in Qubit's information_object table.
  • Relations: Qubit stores data corresponding to a DC element in related records residing outside of the information_object table.
  • Custom fields: Qubit can only store data corresponding to a DC element via "custom fields", i.e. by creating related records in the property table.

Ideally, no DC elements should be handled as custom fields but should be moved to the core information_object fields or handled via relations.

title maps to information_object::title
description maps to information_object::scope_and_content
format maps to information_object::extent_and_medium
identifier maps to information_object::identifier
relation maps to information_object::related_units_of_description
rights maps to information_object::access_conditions and information_object::reproduction_conditions
creator get from actor via related event records, type="creation"
subject get from term via related object_term_relation records
publisher get from actor via related event records, type="publication"
contributor get from actor via related event records, type is not "creation" or "publication"
date get from related event records
coverage get from term via related object_term_relation records
Custom fields
type store as property::name="resource_type" value=" "
source store as property::name="source" value=" "
language store as property::name="information_object_language" value=" "


DC simple DC qualified Repeating Qubit fields Input Output


  No information_object::title    
  Alternative Title


No information_object::alternate_title    


  Yes actor::authorized_form_of_name Input as event, type="creation". Get actors via related creation events.


  Yes term::name Input as subject access point (object_term_relation). Get terms via related related object_term_relations.


  No information_object::scope_and_content    
  Table Of Contents


No property::name="table_of_contents" Add custom field (property record).  


No property::name="abstract" Add custom field (property record).  


  Yes actor::authorized_form_of_name Input as event, type="publication". Get actors via related publication events.


  Yes actor::authorized_form_of_name Input as event, type="contribution". Get any actor from related events where type does NOT equal "creation" or "publication".


  Yes event::date_display Input as event. Get creation events only[?].
  • In DC simple, not possible to differentiate types of dates, use date of creation only.
  Date Created


Date Valid


Date Available


Date Issued


Date Modified


Date Accepted


Date Copyrighted


Date Submitted


Yes event::date_display type_id=" " Input as events, using "dc_date_types" taxonomy type. Get related events where type_id equals id of terms from "dc_date_types" taxonomy.
Resource Type


  Yes property::name="resource_type" Add custom field (property).
  • Note that RAD template required similar field (General material designation)
  • In future iteration, may add as core field of information_object.


  Yes information_object::extent_and_medium Qubit does not support multiple entries. Qubit data relating to format is stored in a single field (extent_and_medium) that cannot be easily normalized into separate extent and medium elements, especially at aggregate levels of description (fonds, series, file) where this field may contain multiple extent statements.






  No information_object::identifier   Get contact_information::country_code + repository::identifier + information_object::identifier to ensure globally unique identifier.
  Bibliographic Citation


No property::bibliographic_citation Add custom field (property).  


  No information_object::title Input as a relation between two information_objects, with type="source". Get information_object from related relation record where type="source".


  Yes property::name="information_object_language" value=" "    


  No information_object::related_units_of_description Input into simple text field.
  • May include information relating to more than one relation.
Cannot normalize Qubit data into multiple relation tags.
  • In future iteration, Qubit will register relation between information_objects in relation table.
  Is Version Of


Has Version


Is Replaced By




Is Required By




Is Part Of


Has Part


Is Referenced By




Is Format Of


Has Format


Conforms To


Yes information_object::title Input as relations using "dc_relation_type" taxonomy. Cannot currently output as DC qualified (interface for registering relations not yet implemented).


  Yes term::name Input as place and historical event access points.

Get terms from related object_term_relations.

Note that:

  • Historical event terms are also extended as historical_event objects.
  • Place terms are also extended as place objects.
  Temporal Coverage


Yes term::name Input as historical event access points.
  Spatial Coverage


Yes term::name Input as place access points.
Rights Management


  Yes information_object::access_conditions


In DC simple, map input to access_conditions. Note that Qubit does not support this as a repeatable element. Get access_conditions + reproduction_conditions.
  Access Rights


Yes information_object::access_conditions Input to text field (string). Cannot normalize Qubit data (single field) to repeating elements.


Yes information_object::reproduction_conditions Input to text field (string). Cannot normalize Qubit data (single field) to repeating elements.


Yes property::name="audience" value=" " Add as custom field (property) with controlled taxonomy ("audience"); interface should allow multiple values.  


No property::name="audience_mediator" value=" " Add as custom field (property).  
  Audience Education Level


No property::name="audience_education_level" value=" " Add as custom field (property).  


No information_object::archival_history    
Rights holder
  Rights Holder


Yes actor::authorized_form_of_name Input as rights linking information_object to rights object and rights object to one or more actors via rights_actor_relation (interface not yet implemented). Get rights holders for information_object via rights and right_actor_rleation.
Instructional method
  Instructional Method


Yes property::name="instructional_method" value=" " Add as custom field (property) with controlled taxonomy ("instructional_methods"); interface should allow multiple values.  
  Accrual Method


Yes property::name="accrual_method" value=" " Add as custom field (property) with controlled taxonomy ("accrual_methods"); interface should allow multiple values. Get from related property records where name="accural_method".
  Accrual Periodicity


No information_object::accruals Input to Qubit text field accruals with controlled taxonomy ("accrual_periodicity"); cannot be structured as repeating field.
  Accrual Policy


Yes property::name="accrual_policy" value=" " Add as custom field (property) with controlled taxonomy ("accrual_policy"); interface should allow multiple values. Get from related property records where name="accural_policy".


DC event types

  • Created
  • Published
  • Contributed
  • Valid over
  • Made available
  • Modified
  • Accepted
  • Copyrighted
  • Submitted

DC resource types

See DCMI Type Vocabulary:

  • Collection
  • Dataset
  • Event
  • Image
  • Interactive resource
  • Moving image
  • Physical object
  • Service
  • Software
  • Sound
  • Still image
  • Text

DC relation types

  • Is source of
  • Has source in
  • Is version of
  • Has version
  • Is replace by
  • Replaces
  • Is required by
  • Requires
  • Is part of
  • Has part
  • Is referenced by
  • References
  • Is format of
  • Has format
  • Conforms to

Create the following taxonomies, either empty or with sample data, as place-holders for local taxonomies:

  • DC audience types
  • DC instructional methods
  • DC accrual methods
  • DC accrual periodicity
  • DC accrual policy