Page tree
Skip to end of metadata
Go to start of metadata

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 termDCTERMSQDClocal

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 termDCTERMSQDClocal

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 termDCTERMSQDClocal
dc.relation.ispartofseriesThere 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.isbnNo 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 termDCTERMSQDClocal

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 termDCTERMSQDClocal direct match. Map to dcterms:dateAccepted?No direct match. Map to

Are dcterms:dateAccepted and reasonable mappings for 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 value.











  • No labels