Planning an Implementation

From Metadata-Registry
Revision as of 14:18, 7 September 2010 by TomJohnson (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Decision: Public or Private implementation?

software can also be used behind a firewall, either temporarily or permanently, but some potential may be limited as a result. An example of this is the mapping capability which will be included in the next version of the Registry. If other 'nodes' are not aware of privately implemented registries (or their URIs), these registries will be ignored as mapping connections are built by others, leaving all the mapping burdens for any shared activities on the privately implemented registry institution.


Decision: What Will Be the Institutional Role of the Registry

Metadata creation and maintenance are one of the prime reasons institutions develop vocabularies in the first place, and these activities are generally expensive, requiring significant human effort. Registry services can improve workflow and metadata quality at both the point of creation and for routine maintenance, making better use of machine capabilities and freeing human effort for other activities.

Many Registry implementers have a focus on metadata sharing, either as part of consortia or networks of similar institutions. Controlled vocabularies and data built using Description Set Profiles improves the quality of shareable metadata and makes the sharing process itself easier to automate and manage.

The Registry software will work well in relation to other vocabulary tools already in use by institutions. The new version of the Registry software will be able to ingest vocabularies built with other tools so that Registry services can be used across an institution without requiring that all other tools be abandoned.


Decision: How Will We Use Registry Services?

All Registry services are designed to support the building and maintenance of vocabularies (for owners) and usage of the vocabularies by others (users). Both owners and users are assumed to have an interest in the activities of the other, and the software is designed to facilitate that interactivity for positive benefit by all. An example of this benefit might be to provide evidence that a particular vocabulary built and maintained by an institution is widely used by others, providing a basis for seeking funding support either within or outside that owning institution.

The building of communities around vocabularies are a major goal and value of the Registry software, both to broaden the use of vocabularies and to provide efficient and cost-effective means to build and maintain vocabularies in the current information landscape, where the old 'publish and sell' business models are proving to be unsustainable.


Decision: How Will We Use Versioning?

The Registry software records all changes made, who made them and when, and provides all this information behind the 'History' tab. Using this history, RSS and Atom feeds of changes made are available via simple subscription. An example of this feed is shown on the Registry front page.



Decision: What Kinds of Internal Permissions and Authorizations Will We Need?

The Registry software is built to support group-based vocabulary development and maintenance, including:

  • A variety of statuses to support many different review workflows within the institution using Registry software
  • A simple user management workflow, starting with individual registration