On Wed, Sep 11, 2019 at 03:58:20PM -0700, Kimberly Chapman wrote: [snip] > I don't know how this really works on the technical side since I'm not a > developer, but from my perspective as a repository manager, this works > really well. It allows us to display information needed for specific types > of content according to standards; for example, using ETD-MS to describe > the degree level for theses and dissertations, or CSDGM to describe > bounding coordinates for geospatial materials.
There are three database tables involved in storing metadata. The "metadata schema registry" table holds a URL and a "short name" for each metadata schema, and an opaque "metadata schema ID" number. When you install a new schema, a new, unique metadata schema ID is assigned to it. The "metadata field registry" holds the element and qualifier names for each field in each schema, along with the schema ID and an opaque "metadata field ID" number. When you declare a field in a schema, a new, unique metadata field ID is assigned to it. The metadata values bound to a DSpace object are actually identified by metadata field ID in the "metadata value" table, which also holds the text value of the field, the identity of the object to which it is bound, and other information, such as ordering when a field has multiple values. By looking up the field ID in the metadata field registry, the element and qualifier names can be recovered for display, as well as the schema ID. Then by looking up the schema ID in the metadata schema table, the short name (or URL) of the schema can be recovered for display. During ingestion, the schema short name and the element.qualifier name of each field are looked up in similar fashion to get the field ID which is actually stored with the field's value(s). By this means, DSpace can represent an enormous number of namespaces and their fields. The Qualified Dublin Core namespace is always required because DSpace uses it internally, but any number of additional namespaces can be layered on to represent concepts that were not standardized by DCMI. Recent versions of DSpace ship with several additional namespaces which will be loaded automatically at installation. If you cannot find a namespace which defines a concept that you need, you can create your own namespace and fields. There is a "registry loader" tool for installing complete metadata schemas, and an XML format for representing them to the tool. There is also an administrative Web user interface section which can be used to create and modify namespaces interactively. One important limitation of this approach is that DSpace can only *manipulate* metadata which exist in a flat space or a 2-level hierarchy. DSpace can also store more complex metadata representations as additional bitstreams on an item, but these are merely preserved with the item and cannot be used to identify or locate the item. Some further reading: https://wiki.duraspace.org/display/DSDOC6x/Metadata+and+Bitstream+Format+Registries -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/20190913150516.GA9808%40IUPUI.Edu.
signature.asc
Description: PGP signature
