Each item stored in the eSciDocEnhanced Scientific Documentation system will be accompanied by at least one metadata record keeping all descriptive information about the resource represented by the respective item, e.g. the creator and title of a publication.

The functional specifications regarding the bibliographic/descriptive metadata required to describe the item types handled by eSciDocEnhanced Scientific Documentation (e.g. "collection", "image", "publication") are part of the eSciDoc Solution pages. These specifications are implemented by a set of W3CWorld Wide Web ConsortiumXMLExtensible Markup Language schemas which are available in the subversion repository. The metadata record need to conform to these schemas in order to be handled by the system, e.g. to support the creation, modification or search for the item.

The team currently works on a set of application profiles for eSciDocEnhanced Scientific Documentation solutions.

In general, the MDS specification is aimed to "influence" the system in several contexts, (e.g. when generating edit/view item interfaces (GUIGraphical User Interface)) and should serve as a basis for validation and indexing of metadata records. In our discussion on 19th of December we agreed on following usage scenarios for the XMLExtensible Markup Language schema (XSDXML Schema Definition):

In scope metadata schema (XSDXML Schema Definition)

Outlook: simple schema, with few element and value constraints.

Each content type is described by one schema

Objects will be validated according to this schema by the framework in the moment they are stored

XMLExtensible Markup Language schema will be used as basis for transformation definition/document required for indexing by lucene (taks owner: FIZFachinformationszentrum Karlsruhe)

Out of scope metadata schema (XSDXML Schema Definition)

The eSciDocEnhanced Scientific Documentation metadata schemas focus on information to describe the intellectual content of the work. Therefore, it does not include

administrative metadata for the items and files (e.g. pids, owner, accessibility, content type of files). Those elements are implemented as properties of the items or the item components, see PubMan File Properties. Properties can also be searched and will be available for comprehensive exports and transformations to other formats (e.g. Dublin Core)

copyright & license statements = part of administrative metadata

structural and content relations between items. Relations are stored in a separate data stream within the object (rel-ext) and will be available for comprehensive exports and transformations to other formats (e.g. Dublin Core)

validation rules: additional constraints (e.g. "Original size X or Original size Y needs to be filled", "Language has to be specified") may be defined via the Validating service. This service is also considered to implement constraints between genres and relevant metadata elements

display issues: which elements are relevant for which genre (e.g. an ISBNInternational Standard Book Number can only be defined for books)

GUIGraphical User Interface is currently basing on java value objects, thus the interface knows the elements and certain display conditions

As all elements are known to the interface, adding/changing the metadata set requires changes in the interface as well

We currently do not build on an hierarchical structure to express the four entity levels, but describe Publication objects as "flat" objects. Anyway, we should relate our objects to one of the levels (expression or manifestation) defined there

"ScholarlyWork" is a very abstract level, we might build this view by interpreting the relationships "isRevisionOf" eSciDocEnhanced Scientific DocumentationPubManPublication Management will build between objects.

We will consider the re-use of relation specified with ePrints APApplication Profile