MetaManager

MetaManager

Flexible Metadata Definition and MetaManager Distributed Metadata System:
  In A Nutshell

The Flexible Metadata Definition (FMD) and MetaManager Distributed Metadata System, a system which implements FMD, provide a flexible and complete solution to metadata needs. Both FMD and MetaManager are in development, but early versions are in operational use. The following show some of the data and system architecture highlights.

The FMD data architecture provides an efficient means for tailoring a metadata system for specific needs via the choice of a relatively small number of functionally-related metadata blocks instead of many hundreds of individual metadata elements. The block approach also provides an efficient approach for communications between MetaManager systems even if they are tailored differently from each other. Due to its comprehensive nature FMD can be mapped to other metadata formats, providing system interoperability. Data group membership allows for inheritance of metadata in both a tiered and union fashion.

MetaManager can be configured to work standalone for a single organization's needs, or as part of a defined, trusted group of MetaManager systems that are even owned and managed across organizations, or as part of a fully open, dynamic collaboration of organizations. Internally, metadata is controlled according to user, group, and world access of read and write. A user can create a record and be the only person who can modify it, or can allow others in a defined user group to modify it. Likewise data can be defined as approved for public reading or not.

MetaManager is a client-server based system. The server communications protocol definition will be available with the server so that organizations can create whatever clients meet their needs. Or we can create those specialize clients.

Key Features:

Flexible Metadata Definition

Functional block oriented
FMD is composed of a core block that is used for all metadata records, and any number of extension blocks, each defined as a cohesive set of elements based on a common descriptional function. This means that the amount of metadata metadata is just based on knowing which, generally, small number of extension blocks are used instead of knowing which large number of elements are used.
Set membership
An FMD record can be defined as being a set member of another FMD record. In this way hierarchies of metadata records can be built to provide the functionality of inheritance, where the metadata of a parent record is considered to be also describing the object defined by a child record, unless specifically overridden by metadata in the same blocks and elements as the parent record.
Mappable formats
Maps to other metadata formats are easily define and can be used to filter transfers and searches of data between FMD and other metadata formats.
XML definitions
The FMD is defined via an XML DTD. Likewise, mappings are defined via XML DTDs.

MetaManager

Client-server architecture
This provides the strengths and utility of a multi-user, multi-tasking system available over a network.
Distributed, collaborative system architecture
A MetaManager installation can be composed of multiple MetaManager systems, each managing their own metadata corpus, yet working together as a single system. Subsequently, a MetaManager system can be configured to operate as a stand-alone system, as a member of a trusted group of systems, or as an open-access system available to collaborate with whatever other open-access MetaManager systems are available online. Distributed systems are not required to belong to or be managed by the same organization.
Data ownership and access control
Every metadata record is owned both by a user and a group. Access control is comprised of a per record definition of user, group, and other read and write permissions. For instance a record can defined as writable by the group to which the record's owner belongs and as readable by the public (other). Likewise, a record can have no public read access, which is useful for records that are considered not ready for public use on a system that contains other data usable by the public.
Hierarchical user account classes
Six levels of user accounts are defined that correspond to system access privileges.
  • sysadmin - ability to add, remove, and modify all metadata, ability to add, remove, and modify user accounts
  • superuser - ability to add, remove, and modify all metadata regardless of group ownership
  • groupadmin - ability to add, remove, and modify metadata owned by own group, ability to modify some aspects of user accounts in own group
  • user - ability to add, remove, and modify own metadata; possible future control of what a user is allowed to add
  • viewer - ability to search and read all data approved for public consumption: This is a MetaManager account allowing clients to use this account to provide data for reading to the user of the client, generally the public
  • disabled - used if an account should remain defined but unused.
Session management
All user sessions are managed allowing for a full login, perform work, logout cycle. Idle sessions are timed out at a configurable time so that when a user forgets to logout it doesn't leave an indefinite open access.
XML system definition
An XML DTD is used to define what FMD blocks are used within a particular system. This provides a filter definition that is used when other MetaManager systems or clients communicate with the MetaManager system, basically allowing it to know what FMD blocks it knows about and allowing it to simply ignore other FMD blocks in the incoming communication.
Simple message protocol
MetaManager server requests are simple verb-argument sets with complex arguments defined in XML. Responses are simple response code-argument sets with complex arguments, such as search results, defined in XML.
Logging
Full logging with message importance levels. A logging level threshold is defined which will allow only those messages that are equal to or more critical than the threshold to be logged.
Database Management System backend
MetaManager leverages standard DBMS systems for data storage and access. This builds on the strengths of a mature, robust technology field and allows MetaManager not to have to duplicate technology that is well covered by other systems. This means that the raw data is directly accessible via the DMBS used and data backups and integrity checks and fixes can be performed using standard tools.
TCP/IP communications protocol
MetaManager works on any network that supports TCP/IP.

Read the white paper (PDF) discussing the details of the FMD/MetaManager technology approach.