Difference between revisions of "Development/Projects/BCAUL Pilot/Metadata mapping/DC"

From AtoM wiki
(Migrate basic page content)
 
m (Fix title)
Line 1: Line 1:
−
{{#pagetitle:BCAUL pilot project - Qubit import / export:  Dublin Core}}
+
{{#pagetitle:BCAUL pilot project - Qubit input/export:  Dublin Core}}
 
[[Main Page]] > [[Development]] > [[Development/Projects]] > [[Development/Projects/BCAUL Pilot]] > [[Development/Projects/BCAUL Pilot/Metadata mapping]] > DC
 
[[Main Page]] > [[Development]] > [[Development/Projects]] > [[Development/Projects/BCAUL Pilot]] > [[Development/Projects/BCAUL Pilot/Metadata mapping]] > DC
  

Revision as of 12:29, 29 July 2015

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

Note

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.


Purpose

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

Analysis

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.

Core
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
Relations
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=" "

Mapping

DC simple DC qualified Repeating Qubit fields Input Output
Title
Title

<dc:title>

  No information_object::title    
  Alternative Title

<dcterms:alternative>

No information_object::alternate_title    
Creator
Creator

<dc:creator>

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

<dc:subject>

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

<dc:description>

  No information_object::scope_and_content    
  Table Of Contents

<dcterms:tableOfContents>

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

<dcterms:abstract>

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

<dc:publisher>

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

<dc:contributor>

  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".
Date
Date

<dc:date>

  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

<dcterms:created>

Date Valid

<dcterms:valid>

Date Available

<dcterms:available>

Date Issued

<dcterms:issued>

Date Modified

<dcterms:modified>

Date Accepted

<dcterms:dateAccepted>

Date Copyrighted

<dcterms:dateCopyrighted>

Date Submitted

<dcterms:dateSubmitted>

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.
Type
Resource Type

<dc: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.
  
Format
Format

<dc:format>

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

<dcterms:extent>

Yes    
  Medium

<dcterms:medium>

Yes    
Identifier
Identifier

<dc:identifier>

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

<dcterms:bibliographicCitation>

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

<dc:source>

  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".
Language
Language

<dc:language>

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

<dc:relation>

  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

<dcterms:isVersionOf>

Has Version

<dcterms:hasVersion>

Is Replaced By

<dcterms:isReplacedBy>

Replaces

<dcterms:replaces>

Is Required By

<dcterms:isRequiredBy>

Requires

<dcterms:requires>

Is Part Of

<dcterms:isPartOf>

Has Part

<dcterms:hasPart>

Is Referenced By

<dcterms:isReferencedBy>

References

<dcterms:references>

Is Format Of

<dcterms:isFormatOf>

Has Format

<dcterms:hasFormat>

Conforms To

<dcterms:conformsTo>

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).
Coverage
Coverage

<dc:coverage>

  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

<dcterms:temporal>

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

<dcterms:spatial>

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

<dc:rights>

  Yes information_object::access_conditions

information_object::reproduction_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

<dcterms:accessRights>

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

<dcterms:license>

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

<dcterms:audience>

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

<dcterms:mediator>

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

<dcterms:educationLevel>

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

<dcterms:provenance>

No information_object::archival_history    
Rights holder
  Rights Holder

<dcterms:rightsHolder>

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

<dcterms:instructionalMethod>

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

<dcterms:accrualMethod>

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

<dcterms:accrualPeriodicity>

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

<dcterms:accuralPolicy>

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

Taxonomies

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
Retrieved from "http://wiki.accesstomemory.org/index.php?title=Development/Projects/BCAUL_Pilot/Metadata_mapping/DC&oldid=895"

Account

Page

Search