 |
 |
|
 |
|
 |
|
 |
|
     
|
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
The IMesh Toolkit
[ Work In Hand > Components> Annotation> Annotation Design ]
Glossary of Terms Used in this Design
Whilst some of the terminology is standard to UML design, as an aid to readers this document attempts to give a comprehensive list of all terms iused in the design with their meaning.
| Actor | in UML the role of an agent, usually but not exclusively human, which, whilst usually external to the system, interacts with the system designed. |
| Annotation | comment, opinion or additional information made on a record of a resource or even, under certain circumstances, the resource itself [1]. |
| Annotation form | the html form displayed to the actor onto which comments and values such as the star rating must be entered for successful creation or editing of an annotation. |
| Annotation Service | the range of functions made available to the prime user of the resource retrieval service which enable him or her to create, view, edit and delete annotations upon the records provided. |
| AUP | Acceptable Use Policy: a set of conditions of use imposed by a system or institution on the users of its (computing) services; contravention can result in penalties. |
| Auto-moderation | moderation of annotations carried out by the system in the Moderator's absence. The aim in this system is to place as many annotations onto the database for immediate viewing as soon as possible. Ideally the auto-moderator will only withhold questionable annotations, based on the criteria loaded. |
| Auto-rejection | one of the options available to the human Moderator on viewing those annotations withheld by the auto-moderator. In this option (s)he rejects the annotation, i.e. deletes it from the system without acknowledging its reception as would be the case with Rejection. |
| Basic design | the term for the original set of functions of the Annotation service without the extension of Auto-moderation. |
| Collaboration diagram | shows detailed interactions among objects, in the form of message passing [2]; however it only shows key transactions in a scenario whereas sequence diagrams follow the narrative flow of entire use cases and are traceable to the use case text. For this reason sequence diagrams are adopted throughout. |
| Filter | a means within the auto-moderation process of identifying incoming annotations originating from persons outside the expected annotator community by testing the annotator's email domain or the nature of the string prior to "@" in the address. When switched on, the filter flags up annotations not identified on the filter's list and increases the threat value. |
| Form | in this system a means of obtaining input from a user or moderator in the form of text and other values to permit annotation creation, editing etc. Most likely an html form in format. |
| Form validation | the process whereby a form is checked to ensure it holds the minimum allowable input from the user to permit annotation creation, editing etc. Where validation tests insufficient input, it redisplays the form for completion. |
| Initial Priority | in the process of auto-moderation, this is the start value, with a default of 0 which can nonetheless be set by the Moderator in Set Moderation Values. In effect it allows the Moderator to reduce the tolerance of the auto-moderator by inputting a value that brings the system closer to threat threshold. In other words fewer threats need to be identified before an annotation is flagged up as unviewable; the higher the initial priority value the more quickly threat threshold is reached. |
| Logfile | a file written by the system indicating errors and other unusual events events that occurred during the operation of the system. |
| Moderation | the process by which annotations are inspected for acceptability for viewing by users of the annotation service. The expectation is that 95% of annotations will be acceptable. |
| Moderation values | a collective term for all values entered by the Moderator to set the level of the system's tolerance to threats posed by annotations' content or provenance, including Watchlist words , Threat and Star-rating thresholds, Initial Priority and email filter lists. |
| Moderator | the person(s) responsible for filtering out any annotations or parts of annotations that are deemed inappropriate by the annotation system operator in terms of content. OR the role within the UML design of such a person. |
| Record | a (relatively) short description of a resource provided or pointed to by the service [1]. |
| Rejection of annotation | the process by which the Moderator informs the annotator in a rejection form of the decision to reject the annotation and the reasons involved. (See Auto-rejection) |
| Resource | material of a high-quality nature pointed to by the service and described or summarised for the benefit of users in a record [1]. |
| Resource description | equal to Record [1]. |
| Results set | a grouping of results from a search, usually ordered alphabetically or chronologically. |
| Robustness diagram | see Introduction Approach to the Annotation Design |
| Screen prototyping | a process of outlining the contents of what the actor will see as (s)he navigates through the system in terms of screens, their messages and the options they offer the actor. |
| Sequence diagram | see Introduction Approach to the Annotation Design |
| Star rating | the number of points out of a set maximum that annotators can award to a resource in terms of their approval, e.g. 3 out of 5. |
| Star rating threshold | a value set by the Moderator in Set Moderation Values which identifies a possibly inappropriate annotation given the low number accorded by the annotator, e.g. 2 out of 5 as a cautious threshold, 0 out of 5 as a more optimistic setting. |
| Threat | the degree by which an annotation may be seen as approaching the point of ineligibility for automatic viewing on the annotation database, i.e. the threat threshold. |
| Threat threshold | the point at which the threat value of any annotation reaches the breaking point for eligibility as automatically viewable on the annotation database. If an annotation's threat value equals the threat threshold, it is automatically flagged as unviewable and must await the Moderator's manual inspection. |
| Threat value | the running total of points awarded against an annotation when being tested by the auto-moderator for eligibility for automatic viewing. The value increases each time the system identifies an individual threat such as unacceptable word on the Watchlist, etc. This value can be artificially raised from the outset by the Moderator increasing the initial priority value. |
| Use case | see Introduction Approach to the Annotation Design |
| User | the general user of the basic design of the annotation system, capable of viewing or creating annotations and editing or deleting their own creations, but not of any moderation activity. |
| Validation | the process of ensuring that the minimum required values are present and within range. |
| Watchlist | A list of words or phrases created by the System Moderator(s) which constitute fail criteria for the text of any annotation submitted to the auto-moderation system. Each word or phrase possesses a numerical value which is configurable by the Moderator. Obscene language attracts the highest values, some of which may constitute an addition to the running threat value which alone would exceed the threat threshold. |
[1] The relationship between annotation, record and resource:
 |
[2] "Applying Use Case Driven Object Modeling with UML", Chapter 6, p.110,
Doug Rosenberg and Kendal Scott, 2001, Addison-Wesley ISBN 0-201-73039-1