Registry - database planning
Basic Registry Requirements/Expectations
Data held in registry
- The data to be held in the registry can be found on this page Common Terms Registry under the format heading.
Requirements to the DB:
- Versioning (dated history of edits to each entry)
- Multiple levels of permissions:
- potentially on field level (eg. Read, Add new, Edit, all as separate items)
- with (and without) moderation
- limited to non-core
- particular translation only
- Vendor name-spaces (hosted by RtF/GPII) treated independently with same permissions within - controlled by Vendor.
- API providing access to Registry to allow read only access to terms for use with different ontologies (for displaying, sorting, browsing)
- Should be able to handle the load as described below
- A series of tools will be used to maintain the registry. An API should allow for this
- The registry is expected to contain 1,000 - 10,000 terms.
- Each term will have a set of properties (description, value range, name, ID, etc).
- For each term, multiple translations can exist.
- There will be a limited amount of writes to the registry - highest in the beginning, then dropping.
- Generally more reads are expected, but even this is not expected to be that high at any point in time, as this is a basic registry used for looking up terms and their properties - not used programatically by the GPII to lookup terms for each profile loaded, or the like.
- Generally low usage. Used primarily by people creating products or tools for working with user preference sets. Or by researchers. Unless other tools don't cache the values (and so this database is hit for each time a term appears on a screen) the usage should be relatively low.
- One tool that may use the Registry is the tool for viewing and editing a user's needs and preferences, since it needs to get labels (or their translations) to populate its UI.
Expected Usage and User Interfaces
- Browsers of the Registry - usually done through an onotology of some type
- A simple interface for listing, browsing and searching the terms of the database. Read their descriptions, definitions, value-range, etc. Should support displaying the terms in multiple languages. Terms should be sortable according to fields
- Registry Maintenance workers - ( has extra maintenance and tracking fields visible)
- New item entry / item edit interface (moderated)
- interface makes it easy to look for related or similar (or same meaning) terms
- provides instructions for what goes in where
- interface for adding new terms along with descriptions and translations. Also moderated editing of some fields in existing terms.
- Translators - side by side original and translation (and maybe other translation(s) as well) (with google translate button for first pass and a wiktionary button for word meanings)
- Moderators interface -
- provides side by side with old version
- shows differences
- shows data on track record of submitter (and if they are banned)
- allows scoring of submissions across very broad lines (e.g. this was spam, this was a duplicate item, this was POOR/FAIR/GOOD/EXCELLENT ly written, )
- Ontology creators using API -- (usually use this via API and their ontology tool -- but also need to search . for the latter would they use the same tools as new entry?? or ???)
- Browser Tools
- many different browsers
- mostly ontology based
- READ ONLY
- Allows passing of comments to editors
- Allows access to different translation layers
- Data entry/edit Tools
- used to enter and maintain the database
- different levels of authority
- Translation/Edit tools
- used to create translation layers for the database
- different levels of authority
- language/region specificity possible
- Collection of Use Cases
- Generation of example data entries
- UI design and discussion
- Decision of technology and implementation