View Source

Examples of simple mappings of the current "dc" schema in the DSpace metadata registry into "dcterms" (DCTERMS), "qdc" (QDC), and "local" (Local) schemas:

1.8 "DC" DSpace schema term	DCTERMS	QDC	local
dc.publisher	dcterms:publisher	qdc.publisher	n/a

dc.publisher maps very simply to dcterms and qdc values of publisher. Because the element matches in dcterms and qdc, there is no need to devise a local registry element.

1.8 "DC" DSpace schema term	DCTERMS	QDC	local
dc.identifier.citation	dcterms:bibliographicCitation	qdc.identifier.bibliographicCitation

Only a small adjustment is needed to map dc.identifier.citation to QDC and DCTERMS values that use "bibliographicCitation."

More complicated mappings:

1.8 "DC" DSpace schema term	DCTERMS	QDC	local
dc.relation.ispartofseries	There is no direct match in DCTERMS. Can specify that this refines dcterms:isPartOf?	There is no direct match in QDC. Can add qdc.relation.ispartofseries or relegate to local?	local.relation.ispartofseries
dc.identifier.isbn	No direct match. Refines dcterms:identifier.	No direct match. Refines qdc.identifier.	local.identifier.isbn

There is no direct mapping between the registry element dc.relation.ispartofseries and either DCTERMS or QDC. Given the lack of QDC and DCTERMS matches, may suggest mapping to a local registry and leaving out of the QDC and DCTERMS registries. Alternately, we could add a qdc.relation.ispartofseries element and develop a way of coding for elements that refine, rather than match to, existing DCTERMS. A similar situation exists for dc.identifier.isbn (and several other elements).

Decision point: map this refinement to DCTERMS and QDC, thus flexing compliance? Or map to local? When there are no direct matches in DCTERMS and QDC, it is preferable to extend those namespaces to incorporate refinements to existing elements? Or to move to local?

1.8 "DC" DSpace schema term	DCTERMS	QDC	local
dc.description.provenance	dcterms:provenance	qdc.provenance	local.dspace.provenance?

dc.description.provenance would seem to be easily mapped to provenance terms in DCTERMS and QDC. This element, however, is automatically filled by DSpace with preservation metadata. Would it be valuable to split the values of this element into local and QDC/DCTERMS fields? This would allow the automatically-generated metadata to be stored in local.dspace.provenance, leaving DCTERMS and QDC provenance fields to be filled by users.

Decision point: Separate DSpace administrative field into local namespace and reserve DCTERMS and QDC terms for users? Or directly map between registries without distinguishing DSpace-filled fields?

1.8 "DC" DSpace schema term	DCTERMS	QDC	local
dc.date.accessioned	No direct match. Map to dcterms:dateAccepted?	No direct match. Map to qdc.date.accepted?	local.date.accessioned

Are dcterms:dateAccepted and qdc.date.accepted reasonable mappings for dc.date.accessioned? Or should this DSpace-generated value be relegated to a local element? According to DCTERMS documentation, dateAccepted is defined as "Date of acceptance of the resource," with Comment: "Examples of resources to which a Date Accepted may be relevant are a thesis (accepted by a university department) or an article (accepted by a journal)." This definition seems distinct from the DSpace-filled dc.date.accessioned value.