Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Metadata Registry

In the following example :

  • The default "dc" prefix has been redefined as a default "item" prefix used to explicitly apply to all "Items" in the repository.
  • A new "Profile" has been defined with its own namespace to be allowed on Collections A and B.
  • Each custom "Profile" can be applied to a specific DSO type via an "Applies To" mapping to objects that are of its type
  • Each custom "Profile" can enabled in a specific Container (Community, Collection, Item) via an "Allowed In" mapping,

    an additional "dcterm" schema has been created to house the proper dcterms predicates while the "dc" schema continues to hold the existing qualified dc for legacy purposes.

    Metadata Schema: "dcterms"

    where "dcterms:xxx" refinements point to a new Schema in the repository that contains the fields required for the typical dcterms namespace.  In the current case, with the "item" and "item2" schema, this schema is not applied directly to Items, but inherited into defined "item" fields through "refinement".

    IDFieldrefinesencodingdefaultrequiredScope Note
    15dcterms.daterdf:PropertyW3CDTF${now}trueDate of publication or distribution.
    25dcterms.identifierrdf:Property URI trueUniform Resource Identifier
    37dcterms.languagerdf:Property RFC5646en Catch-all for non-ISO forms of the language of the item, accommodating harvested values.
    40dcterms.relationrdf:Property URI   Catch-all for references to other related items.
    57dcterms.subjectrdf:Property Literal   Uncontrolled index term.
    64dcterms.titlerdf:Property Literal  trueTitle statement/title proper.
    66dcterms.typerdf:Property Class  Nature or genre of content.
    .....................

    Metadata Profile Registry

    The profile registry defines fields that may be attached to a DSpace Item.

    • A new "Profile" has been defined with its own namespace to be allowed on Collections A and B.
    • Each custom "Profile" can be applied to a specific DSO type (in this case, Item) via an "Applies To" mapping to objects that are of its type (in the diagram above, this is the profile2dso mapping).
    • Each custom "Profile" can enabled in a specific Container (Community, Collection, Item) via an "Allowed In" mapping  (in the diagram above, this is the profile2container mapping).

     IDNamespaceNameApplies ToAllowed In
     1

    http://mydspace/schema/item

    itemGeneric Item

    ItemAll Collections
     2http://mydspace/schema/item2item2Simple ItemItemCollection A, Collection B

    Item Metadata Profile "

    A

    Generic Item"

    The following exemplifies how the view over the DSpace Metadata Field Registry would change after these adjustments:a Profile for generic items that may have many optional fields attached to them.

     

    elementrefinesencodingdefaultrequiredScope Note
    issueddcterms:issuedW3CDTF${now}trueDate of publication or distribution.
    datedcterms:dateW3CDTF${now} Use qualified form if possible.
    uridcterms:identifierURI trueUniform Resource Identifier
    identifierdcterms:identifierLiteral  Catch-all for unambiguous identifiers not defined by qualified form; use identifier.other for a known identifier common to a local collection instead of unqualified form.
    isodcterms:languageRFC5646en Current ISO standard for language of intellectual content, including country codes (e.g. "en_US").
    languagedcterms:languageRFC5646en Catch-all for non-ISO forms of the language of the item, accommodating harvested values.
    haspartdcterms:relationURI   References physically or logically contained item.
    relationdcterms:relationURI   Catch-all for references to other related items.
    meshdcterms:subjectURI   MEdical Subject Headings
    otherdcterms:subjectLiteral   Local controlled vocabulary; global vocabularies will receive specific qualifier.
    subjectdcterms:subjectLiteral   Uncontrolled index term.
    alternativedcterms:titleLiteral   Varying (or substitute) form of title proper appearing in item, e.g. abbreviation or translation
    titledcterms:titleLiteral  trueTitle statement/title proper.
    typedcterms:typeClass  Nature or genre of content.
    ..................

    Item Metadata Profile "

    B

    Simple Item"

    The second Item schema types would be expressed as follows:profile exemplifies a simple item with a smaller set of fields allowed, but with stricter requirements for populating those fields.

    ..
    FieldrefinesencodingdefaultrequiredScope Note
    issueddcterms:dateW3CDTF${now}trueDate of publication or distribution.
    uridcterms:identifierURI trueUniform Resource Identifier
    languagedcterms:languageRFC5646en trueCatch-all for non-ISO forms of the language of the item, accommodating harvested values.
    meshdcterms:subjectURI   trueMEdical Subject Headings
    titledcterms:titleLiteral  trueTitle statement/title proper.
    typedcterms:typeClass  trueNature or genre of content.................

    Steps To getting There

    • New fields and tables are added to database.
    • New attributes for existing DC schema and addition of the
    • Curent default schema should become an "Item Profile"
    • New DC and DCTerms Schema should be added to Registry after it has been extended.
    • Creation of several "Item Profile" should have subproperties mapped to DC and DCTERMS schema.

     

     
    • Profiles" that can exemplify different types of Items in DSpace. each should utilize the new DCTERMS Schema where-ever possible.
    • Update Tooling to populate any necessary fields in new MetadataField and Profile tables.
    • Improve User interface and DSO data model to include returning details pertaining to Profile types for informing the User interface
    • Creation of new Describe Step and ItemEdit interfaces that enforce validation requirements expressed in the Metadata Profile
    • Creation of MetadataProfile Administrative Interfaces for managing Profiles.

    Summary

    The above proposal clarifies that new capabilities may emerge for "Typing" , "Restriction" and "Validation" of DSpace objects through extension of the existing data model.  The proposed strategy will support stronger typing of not only DSpaceObejcts, but also the values of metadata fields through validation rules such as syntax or vocabulary encodings, requiredness, Dublin Core or other metadata schema types.  DSpace should be able to utilize the new MetadataSchema registry MetadataProfileRegistry as a means to replace large portions of the functionally found in the input-forms.xml file in future DSpace versions.  Additi