Page History

Expectations

This proposal is based on the premis that changes to DSpace metadata characteristics must be backward comparable and retain the same functionality as previously existed to ease transitional for all existing users of the platform.  So many different functional areas of DSpace are reliant on existing metadata functionality, that it is criticial that any changes in functionality also have well defined and scripted updates across releases.

Primary Objective

The primary objective of this proposal is that the DSpace metadata registry be "naturally" extended to support a richer and more expressive "Metadata Schema". Technical Objectives of the rpoposal proposal are to provide the following features:

1. Capability to Define Metadata "Metadata Profiles" for specific that may be assigned to individual DSpace Objects and/or types of Objects.
2. Capability to Define DMCI "subPropertyOf" relationships outside in place of the legacy ns.element.qualifier approach for more expressive inheritance and mapping to OAI_DC
3. Capability to have "immutable" DC, DCTERMS and other "well established" namespaces  to treat as sources for "subPropertyOf" assignments.
4. Capability to to Restrict and Validate Existing DSpace item Object Metadata based on a profile that is either assigned via the parent container or directly tot he DSpace Itemthe assigned "Profile". 
5. Capability to Apply these profiles similarly to DSpace any DSO; Communities, CollectionCollections, Items, Bundles and Bitstreams, even Groups and EPeople.

Expectations for Backward Compatibility

This proposal is based on the premis that changes to DSpace metadata characteristics must be backward comparable and retain the same functionality as previously existed to ease transition for all existing users of the platform.  So many different functional areas of DSpace are reliant on existing metadata functionality that it is criticial that any changes in functionality also have well defined and scripted updates across releases.  Thus another Another very critical feature of this proposal is that this new Schema model should support the above features without significant need to transform existing DSpace Item metadata nor the registry itself.  

...

The DSpace MetadataSchema registry was designed based on an outdated concept of "Application Profiles" and "Qualified Dublin Core" that predated the current DCMI Abstract Model.  Due to this, there are number of significant shortcomings to the current implementation.

1. Namespaces are not really "Schema"
2. Schema may be validated, however, there are no actual rules in DSpace "MetadataSchema" or "MetadataField" data models.
3. Qualification does not effectively meet needs for use of alternative namespaces while still providing clear mappings nor support any ability for programatic mapping to DC for exposing metadata in other namespaces within in OAI_DC.
4. The Schema and Fields defined are insufficient to support attributes and rules for validation of DSpace metadata fields in relation to Item Submission or other methods of Deposit.

...

This proposal seeks to extend the definition of the DSpace Metadata Schema to include support of these features previously found only in the Submission input-forms.xml. Formaizing a strategy for metadata validation in DSpace that is a new core feature.

...

Content Models For DSpace (Extending on MetadataSchema and MetadataField

...

to provide "Metadata Profiles")

Rather than the current MetadataSchema applying to the namespace of the metadata fields that are allowed by the entire repository.  We  It is instead recommend recommended that this table be repurposed and expanded to embody "templates" of MetadataFields that should be used for specific types of DSpace Objects.   Typing would support creation of "Named Profiles" that can be easily assigned to DSpaceObjects as Metadata or or Content Models.  In this case, typing would initially be based on:

• DSpace Object Types (Site, Community, Collection, Item, Bundle, Bitstream)
• DCMI or Other Classes (Collection , Dataset , Event , Image , InteractiveResource , MovingImage , PhysicalObject , Service , Software , Sound , StillImage , Text)
• Custom Local Types, of which the existing Qualified Dublin Core schema will be initial considered one of.

These above types will be expressed through the addition of properties to the MetadataSchemaRegistry and MetadataFieldRegistry tables to provide the facility to expand on and add additional Schema.  Some Hypothetical examples of such schema would be:

...

• Scholarly Item Profile
• Website Item Profile
• Thesis Item Profile
• Technical Report Item Profile
• Journal Article Profile
• Learning Object Item Profile

...

• Multimedia Profile
  • Streaming Video Profile
  • Image Profile
• Document Profile
  
  • Article
  • Spreadsheet
  • Etc

...

• Custom Profile for any new type of DSpace content

Likewise, the The above profiles could be applied heterogeniously though metadata attached to any level of the DSpace object hierarchy.

...

Supporting a similar level of refinement for DSpace Metadata can be supported through the addition of new  MetadataFieldRegistry properties that are capable of storing this relationship.

The following are some basic  features of the proposal:

• Metadata fields can include additional properties for
  • Validation rules such as syntax or vocabulary encodings
  • Flag to designate the field is required.
  • Form field types for input forms
  • Type fields to designate Dublin Core or other metadata schema types, types are initially hard coded but new schema registry is extensible
  • MetadataField should be extended with methods to derive its "dc" type. In the absence of an assigned type, all fields default to dc.description typing.
• MetadataSchema filed will be repurposed and extended to support
  • Identification of the types of DSO it may be assigned to
  • DSpaceObjects will be extended to allow them to have a specific "MetadataSchema" assigned. For example, different schema can be created for Publications, thesis, Multimedia, and so on, each having a different set of fields.
  • DSpace will be able to use the new MetadataSchema registry will replace majority of input-forms.xml file.
  • Additional table(s) will more than likely be required to designate schema that can be used in a specific collection, and thus the input forms that may be enabled in that collection.
  • Inheritance may be used in schema to reduce replication of fields. For example, a base schema with Required DSpace fields that are generate during submission, workflow, archive processes (title, issued, accessioned, available)
  • New schema may inherit from it to reduce replication of metadata fields.

In the case of DSpace

Data Model Changes to Support This Proposal

To support this prpoposal, only additional fields and relational tables will be required to be added to the existing DSpace schema.

MetadataProfile:

Profile will be used to identify a set of MetadataFieldProfile that define the fields allowed on a DSpace Object.

MetadataFieldProfile

Individul field profile used to identify the basic rules allowed for a field assigned to a DSpace Object.

Profile2dso:  

This table will be utilized to directly map any specified schema as a validation target for any existing DSpace Item. One, or more than one Schema assignment will be allow, creating a situation where an Item may be polymorphic and support more than one type.

Profile2container:

This table will support the identification of which profile should be applied to new Items being created in any Collection within DSpace. This will be extended when support for metadata at all levels of DSpace is introduced, allowing assignment of Collection and Community "Types" to Community containers and likewise, support for Specific Bitstream types to be allowed in Item Containers.

A tentative list of new fields and tables is exemplified in the class diagram below.

A Example Use-Case

Metadata Schema Registry