CMDI Metadata Services

The CmdiMetadataServices component (MDService) is the core component on the consumption side of CMDI.

MDService accepts queries about metadata from MetadataBrowser (and external Applications)

• and passes them to the Metadata Repository(ies) (MDRep)
  
• and/or to the Virtual Collection Registry,
  
• optionally making use of the Semantic Mapping service provided by the Relation Registry,
  
• receiving results and passing them back to the requesting node.

So MDService interacts with:

• MetadataRepository?
  as consumer
• RelationRegistry
  as consumer
• MetadataBrowser
  as provider
• VirtualCollectionRegistry?
  as consumer /provider?
• external Applications
  as provider; but perhaps even consumer thinkable, when an external Metadata Repository provides a (XML)search interface

Regarding deployment: Currently the plan is to provide as much functionality as possible directly by the MDRepository (on eXist). The rational is the efficient computing directly on data with xquery, plus no arguments at the moment justifying next abstraction layer through a java/tomcat based service.

The main competencies/tasks/functions are:

provide Vocabularies

(out of existing schemas)
for the end-user (and user-agent)
needed to be able to formulate a query. (select lists, catalogue, ..)

translate

from Vocabulary-based user query to XPath/XQuery for the MDRepository (and consequently communicate with MDRepository)
optionally employing semantic mapping involving RelationRegistry

Side note: We could think of subtyping MDService or adding "DataPorts?" which would make MDService more "multilingual", so that it can access different MD Repositories (besides the native CMDI MDRep). So there could be a DataPort? for a RDB based repository (well supported by XQuery) or even for Filesystem based repositories. (Which would come near to LocalWorkspace? functionality. See below.)

Interface Definition

This is a reworked proposal on interfaces MDService has to provide:

 .queryModel()
   /* could replace all previously proposed interfaces regarding the meta-model:
      .elements(), values(), components(), query_builder(), 
      .listSchemas(), .listDimensions(), .listVocabularies(), .stats(), .countMetadataEntries()
   */
 .searchRetrieve(query, result_options)
   /* would replace .query() - conforming to SRU-protocol */

queryModel()

This interface provides information about the metadata, ie which components/elements/values are used in the repository (+ the counts). Provided with a component path it returns applicable elements or values in given context, e.g.:

    /Actor/Contact => [Name,Address,Organization,...]
    Language => {List of Languages}

It returns either simple lists, or whole model subtrees. The primary uses are for interaction with MDBrowser

1. in the initialization phase model subtree,
2. during query-building simple list (has to be fast!)

searchRetrieve()

• Core interface retrieving the actual MDRecords based on a query.
• The idea to base the syntax on SRU

If provided with query returns a collection of (abbreviated) MD-Records. Which information is included in the result-set has to be sorted out yet, but we probably shouldn't send around whole MD-Records. If provided with a PID returns one whole MD-Record.

optional/questionable Interfaces

A further experimental interface would be: {{{ searchByExample (Collection[MD-Entries])

=> Collection[MD-Entries]

}}} Based on provided MD-Entries try to find similar

this would require sophisticated processing:

1. identifying set of relevant terms
2. possibly provide the identified terms to the user, for priority ordering
3. adaptive search based on these terms, loosening or tightening the criteria depending on the size of the result-set

An optional separate interface for publishing Resources (not the OAI-PMH way):

 .publishResource(MD) -> MDRep.registerResource()

Relevant resources could be

1. VirtualCollections?,
2. user's "private" Resources she wants to share or
3. new Resources as results of processing existing ones.

It is questionable, if this should be the competency of MDService.
The argument is: One natural place for creating VirtualCollections? seems to be the MD Browser.
Some component needs to care for passing the metadata about the newly created Virtual Collection to the Virtual Collection Registry (VCR). As MDService will be very well informed about user's queries and data, it seems to be a good candidate for handling this, ie register user's VirtualCollection? in the VCR.

Interaction MDService - MDBrowser

Four phases can be distinguished in this interaction:

1. populating the user interface on initialization
2. contextual help during query building
3. submit query and retrieve the resulting MDCollection
4. retrieve one MDRecord

AAI

Access to the Metadata has to be open, thus no AAI necessary here.