Generic handling of metadata

IN PROGRESS

Introduction

 * The goal of the Generic metadata editor component is to make eSciDoc solutions support different metadata profiles and at a later stage the versioning of the metadata profiles.
 * The goal is to enable more automated configuration for tools that deal with metadata viewing, editing, searching, export and to lower efforts for introduction and adoption of new metadata profiles.
 * The concept is not closely related to particular technology, though the first implementation will be based on JSF and XML Beans and demonstrated via FACES  solution.
 * The final aim is to enable easier adoption in the solution without need to change the source code of the solution
 * Naturally, more specializations for each particular solutions would require changing of the source code, but the aim of this approach is to minimize these efforts.

Motivation

 * use FACES  solution for management of any resources that have images and not only for Face items e.g.  FACES diamonds
 * support MPDL efforts in transferring Metadata Application Profiles to DCAP
 * MPDL solutions can have light-weight starting point to adopt new resources (and their descriptions)
 * Have formal (DC recommendation) expression of a Metadata profile that describes a resource
 * supports interoperability of different metadata profiles
 * each metadata/resource(concept)/ has URI (linking with other profiles and resources)
 * Support versioning of a metadata profile
 * Develop standardized set of GUI patterns that can be applied in screen definitions

Use cases

 * generic configuration of screens(forms) with metadata during:
 * edit
 * providing auto-suggest or pull-down lists for metadata
 * basic validation of metadata (based on literal constrains or controlled vocabularies, optionality)
 * have various edit-configurations for same metadata profile
 * view
 * associate with standardized GUI elements depending on user preferences
 * having various views for same metadata profile
 * searching of content resources
 * enabling generation of metadata-based search forms for various metadata profiles
 * have various search form configurations for one or multiple metadata profiles at the same time


 * metadata handling
 * interoperability of resource descriptions
 * prepare for semantic search
 * validation of resource description syntax

Constraints

 * The metadata are not necessarily natively provided in format such as ePrints metadata record example
 * this may cause many repositories (including eSciDoc) to change their internal metadata storage or implement a lot of changes
 * rather a service that is able to validate a metadata record for given DSP
 * requires however proper definition of the profiles in accordance with DCAP
 * namespace designation for all metadata used
 * service to validate metadata record
 * service to evtl. export metadata record in a format such as the example above
 * Example of metadata records in eSciDoc repository:
 * Face Item
 * Diamond Item
 * Publication Item
 * Digitized Resource

Some further benefits

 * allows for creation of a metadata profiles public repository and relation to metadata registry
 * possibly easier transformations between profiles
 * maybe DSP model can be seen as model to describe ANY metadata profile in this case?

Discussion

 * see Discussion
 * see Technology basics

Metadata profile definitions

 * is a formal (machine readable) representation of a particular metadata profile version used to describe a resource
 * DCAP DSP(DC Recommendation) - will be used for Faces implementation
 * XSD
 * there may be several instances of metadata profile definitions that represent a version of a metadata profile e.g. Faces Metadata Profile v1, Faces Metadata Profile v2, Publication Metadata Profile V1, Publication Metadata Profile V2

Screen configuration

 * A screen configuration is based on the metadata profile version and may be extended with specifics necessary for particular screen
 * There may be single screen configuration for a metadata profile version, or there may be multiple screen configurations for a metadata profile version to express different needs for e.g. viewing, editing, searching, exporting, browsing screens, metadata value specific edit forms (such as PubMan genre specific metadata edit form) etc.

Tools and components

 * Administration utility
 * Metadata profiles administrator component
 * This component would allow for registration of new metadata profiles, their validation (in accordance with the structural requirements of the formalization language in which the metadata profile is defined), and registering the metadata profiles with the solutions that need to use it. (this would mean, publishing it at a place which is monitored by the solution).
 * Screen configurator tool
 * This component would allow for generation of screen profiles based on the formal metadata profile schema. The default screen profiles can (if needed) be modified by the user with e.g. inclusion of helper fields that are not part of the metadata profile, specifying configuration for e.g. genre-specific edit forms or definition of field groups on the screen.
 * Screen registration tool
 * This component would allow for users to create own screen configurations for metadata profile version and validate them in accordance with the screen configuration structural requirements.
 * see also Faces implementation page - administration tool draft

Faces

 * see Faces implementation page

PubMan

 * Not started.

VIRR

 * Not started.