Vocabulary Maintenance Management

Benefits
This section discusses the benefits of using multilingual controlled vocabularies and the services around them.

Controlled multilingual vocabularies
The benefit of using controlled vocabularies is that the discovery and evaluation of learning resources is improvedbecause the intended concepts are clear and identified uniquely. Discovery can be accomplished, for example, using browsing (in the case of hierarchical vocabularies) or filtering from drop down menus. For example if, without controlled vocabularies, all learning objects would use a metadata element such as 'intended end user role’ or 'learning context’ all with different value sets, it would be much more difficult to correctly respond to users' search requests or implement browsing and for users to understand the metadata resulting from the query. The advantages of using controlled vocabularies are even greater in a multilingual environment. With controlled vocabularies the terms can be translated in the best way. In addition, searches in one language can yield results indexed in another language based on the semantic equivalence established within the multilingual controlled vocabulary.

Vocabularies can also be used for exchanging:


 * Navigation structures
 * Additional information, such as curriculum information
 * Mappings between terms

The disadvantage of a controlled vocabulary is that it limits the metadata tagging to predefined terms. This issue is mitigated in the LOM by providing the possibility to give general free keywords. Hence, the advantages outweigh very much the disadvantages.

Standards and specifications for Vocabularies
The benefit of having standards and specifications for vocabularies is that the exchange between machines is facilitated and that adopting a uniform way of describing a vocabulary, its terms and relationships improves the common interpretation of these components by humans. In the context of the LRE, vocabularies are mainly used for metadata. Hence, the standards and specifications for vocabularies contribute to the benefits of the metadata for learning objects. Metadata can provide information that is useful for all activities following the creation of the learning object. This includes discovery, evaluation, choosing, procurement, resolution, obtaining, modification, integration, and use (including rights).

A number of standards and specifications exist. ZThes has a wide adoption and the latest version has improved features for internationalisation. VDEX has a wide adoption as well. XVD and CEF are the most advanced specifications supporting mappings between vocabularies and alternative structures but it has very little adoption at this stage. SKOS has currently the best approach to the mapping of vocabularies.<> Hence transformers between the formats should be offered to the wider audience of vocabulary developers. This could be achieved by having a range of import and export formats in service (as opposed to multiple transformers from one format to another format.) It does need to be born in mind that not all formats can carry the same properties or elements hence there may be some loss of information when transforming.

A vocabulary bank for education
The challenge a learning resource broker typically is facing is to provide one or more (usually one) application profile(s) with a one (or more as in the case of LOM Classification) controlled vocabulary for each metadata element, that requires one, of the application profile the broker is using. On the other hand the broker typically will be dealing with multiple providers often using their own application profile. In practice, the mapping of vocabularies and the transformation of metadata instances according to application profile A into metadata instances according to application profile B is usually the biggest task when including a provider in the offering of the broker. A major part of the mapping of an application profile is the mapping of the controlled vocabularies. There are three cases with respect to this:


 * The provider uses the same vocabulary as the broker
 * The provider handles the mapping at his side
 * The broker handles the mapping at his side

The benefit of a vocabulary bank of education is that it facilitates all work on the construction of vocabularies and the mapping between vocabularies. It also supports the reuse of terms in vocabularies other than their source, when they name the concept required. Mappings may also be deduced from existing mappings, particularly between synonyms. Providers and brokers that need to construct a new vocabulary will benefit a lot from knowing what other providers and brokers are already using. Naturally, there might be good reasons for having different vocabularies for the same metadata element. However, the job of sharing and reusing metadata is greatly facilitated when unnecessary differences are avoided.

In addition, when providers and brokers are using different vocabularies, the vocabulary bank is of great help in determining a mapping as the vocabulary bank holds also already existing mappings between vocabulary terms and these mappings can be used as such or might be an inspiration for creating an own mapping.

A vocabulary maintenance management tool
Vocabularies and more in particular multilingual controlled vocabularies may have many stakeholders. In the context of the LRE the Ministries of Education of the EUN are primary stakeholders. In addition there are a number of learning resource providers that have adopted the LRE application profile and its vocabularies. Hence, it goes without saying that changing a vocabulary requires some consensus building about the change.

The benefit of a vocabulary maintenance management tool lies in the fact that it supports the change process by gathering change requests, identifying stakeholders, organising discussions about the change, and coming to conclusions.

Policies and Procedures for the LRE thesaurus


Compliance to international standards
The LRE thesaurus was first released in 2000, initially developed in 5 languages. The construction process was consistent with the international ISO 5964 standard "Guidelines for the establishment and development of multilingual thesauri". Since then, the LRE thesaurus has been constantly developed as for the number of languages, at present reaching 19 versions. The displays of the LRE thesaurus are 3, systematic, alphabetic and rotated and are provided for each language version at the following address: http://life.eun.org/ww/en/pub/insight/interoperability/learning_resource_exchange/metadata.htm

Rights policy
The LRE thesaurus is an intellectual property of European Schoolnet, Consortium of Education Ministries of the European Union. For each language version, the responsibility of the translation/revision/update of the thesaurus language version is given to the national Ministry of Education or to an education ministry agency. For those language versions shared between two different countries (i.e. the German version, used in Austria and Germany), the responsibility is given to one of them and the other plays the role of peer reviewer.

Licencing: The use of the LRE thesaurus is regulated by the by-nc-sa Creative Commons Licence. It needs to be defined further when EUN considers something a derivative work.

Policies and Procedures for Updating the LRE Thesaurus
The process of updating the thesaurus has two levels:

Updates of the first type do not need a formal consensus building process. They are: Updates of the second type need a consensus building process since they impact on the thesaurus as a whole. Examples are:
 * 1) Updates that do not impact on the structure of the thesaurus or on the corpus of descriptors.
 * 2) Updates that impact on the structure of the thesaurus and/or on the corpus of descriptors.
 * addition of new non-descriptors;
 * reformulation of intralanguage equivalences (i.e. change the USE and UF relationships);
 * addition/deletion/editing of scope notes;
 * deletion of non-descriptors;
 * addition of new descriptors;
 * deletion of descriptors;
 * promotion of a non-descriptor to the status of descriptor;
 * demotion of a descriptor to the status of non-descriptor;
 * reformulation of a relation between descriptors;
 * addition of a new relation between descriptors;
 * change in the hierarchy (i.e. a descriptor is placed under a MT instead of another)
 * reformulation of relationships between non-descriptors and either descriptors or non-descriptors?
 * editing the descriptor metadata eg adding facets
 * changing the preferred name for term
 * creating a derivative vocabulary (it should not be assumed that LRE Thes terms are only ever used in the LRE Thes. In such cases do the rules above apply in the same way?
 * editing of information about a vocabulary

Usage of the LRE Thesaurus
The usage of the LRE Thesaurus is highly recommended since it is a common European vocabulary in education, translated in 18 languages and used in many national portals.

The LRE thesaurus is currently used by:

European Schoolnet:


 * 1) LRE portal, http://lreforschools.eun.org/
 * 2) ASPECT http://portal.aspect-project.net/Aspect-Portal/Login.iface
 * 3) Xplora http://www.xplora.org/ww/en/pub/xplora/library/resources.cfm (the search is accessible to everybody, upload just to registered users)
 * 4) Insafe http://www.saferinternet.org/ww/en/pub/insafe/resources.cfm (the search is accessible to everybody, upload just to registered users)
 * 5) eTwinning desktop http://desktop.etwinning.net (you need to be registered to see it, The LRE Thesaurus is used internally, even though to the user just a subject sublist is displayed in the upload interface)
 * 6) Insight http://insight.eun.org/ww/en/pub/insight/misc/library.cfm (only search is accessible to public, The LRE Thesaurus is used internally, even though to the user just a subject sublist is displayed in the upload interface)

Italy:


 * 1) National database of teachers' best practices, http://gold.indire.it/gold2/
 * 2) National image database, http://www.indire.it/archivi/dia/
 * 3) National bibliography database of journal articles, http://www.indire.it/rivi/

Austria:


 * 1) National database of educational resources http://bildungspool.bildung.at

Portugal:

Sweden:


 * 1) Science resources national portal, http://www.notnavet.se/ - Science
 * 2) Math resources national portal, http://www.mattenavet.se/ - Maths

Estonia:
 * 1) Matadata Portal - http://ait.opetaja.ee/MetadataPortal/. The reader can browse the content trough different characteristics. One of them is LRE keywords http://ait.opetaja.ee/MetadataPortal/browse/by/LREkeywords. The interface of the portal and the metadata is in two languages: et (Estonian) and en (English).
 * 2) Content providers can use LRE classification for content description. Only top level terms from only one sub-thesaurus (subject names) of LRE classification are used.
 * 3) Koolielu - http://koolitaja.eenet.ee/ (www.koolielu.ee in the future). The classification is based on National curriculum and the top-level terms are related with LRE thesaurus terms (subject names). When content provider describes the metadata and select subject from the curriculum, the LRE term is automatically stored in the repository. Although the field for LRE terms is hidden from the user interface and used only for providing compatible data for LRE network. Koolielu is available only with Estonian Interface.

Spain:

Turkey:


 * 1) National Ministry portal: http://www.egitim.gov.tr (planned use)

 

Using the LRE Thesaurus


Use Cases
The use cases underneath are intended to be implemented in an on-line vocabulary maintenance management tool. It is supposed to work together with a vocabulary editor and the vocabulary bank. Some of the use cases might be implemented in the latter.

Description of roles

 * General Administrator. This role administers the maintenance process such as adding or deleting users and assigning roles to users.


 * Vocabulary administrator. A vocabulary administrator manages all aspects of a specific vocabulary. He would for example give permissions for editing a language version of the vocabulary, create the 'consencus team' and be responsible for the publication of the edited version of the vocabulary.


 * Vocabulary editor. A vocabulary editor is allowed to make structural changes to the vocabulary either via (or independent of) the consencus building process depending upon configuration.


 * Language editor. A language editor is a role which is essentially concerned with all non structural changes of the thesaurus for a given language. He owns the translation of the thesaurus; i.e. translation of descriptors, non-descriptors, and scope notes.


 * Language stakeholder. A language stakeholder is a role which is essentially concerned with all non structural changes of the thesaurus for a given language. This role may translate descriptors, and update non-descriptors and scope notes. This role does not own the translation of the thesaurus.


 * Vocabulary stakeholder. A vocabulary stakeholder is a role which indicates that this registered user has a particular interest in a particular vocabulary. For example, it might be that someone has made a derivative vocabulary and is interested in the changes. Vocabulary administrators will select some or all stakeholders when a change needs to be discussed. Any vocabulary administrator, language administrator, or translator of a vocabulary is by definition also a stakeholder of this vocabulary.


 * Registered User. Any user (also possibly playing other roles of the above) who is registered.

Use cases for administering the maintenance of a thesaurus
There are two main workflows for managing the development of the thesaurus.

Workflow 1 A workflow where suggestions are made (perhaps by non-specialist) and these changes are discussed and mediated prior to any changes being made, then accepted (or rejected) and then performed (e.e. the LRE thesaurus). At this point a new version is published.

Workflow 2 A workflow where information specialists make (possibly large scale) changes to the thesaurus and then the changes are reviewed by either the administrator (and or a panel) prior to publication.

In addition, there could be a case where a user (administrator or editor) is trusted or empowered to make minor changes without review, such as in the case of typographical errors. These two workflows relate to an existing vocabulary, there are also use case where a new vocabulary is created, assuming that there is a justification for it and where a new step version is created, or where a vocabulary is deleted.

Essentially, it is the vocabulary administrator that decides whether to start a consensus building process or not.

Workflow 1
These use cases describe a system that helps in building consensus about a structural change of a vocabulary. The natural workflow is that any registered user submits a request for change. It may be a language administrator, the vocabulary administrator, but also any other stakeholder concerning the vocabulary at hand.

Following a change request the vocabulary administrator decides to follow up on the request or reject it with some explanation. When it is followed up then the vocabulary manager selects a number of registered users for consultation. Typically, this would include the language managers. They can give comments. Eventually the process ends with a conclusion. If the change is accepted then the vocabulary manager effectuates the change on his local copy of the vocabulary and submits it to the vocabulary bank. Irrespective of the acceptance or rejection of the change, the submitter of the change request is informed about the decision.

When a change request is related to a specific language, the vocabulary administrator can forward the change request to the appropriate language administrator; The latter will then follow a similar change set-up procedure as described above.

User registration
Any person can register. However, registration only allows for viewing the closed changes. Other permissions come with other roles and must be requested.
 * Summary

Any person.
 * Actors

This use case is triggered by the actor.
 * Assumptions and triggers


 * Description


 * 1) The user accesses the voc maintenance website and navigates to the registration page.
 * 2) The system displays a registration page. The registration page contains the fields: last name, first name, email address, affiliation, logon name, password, and password recuperation question and answer. It also provides a spam avoiding question such as a captcha or an arithmetic question.
 * 3) The user provides the data and submits the form.
 * 4) The system verifies the spam avoiding question, checks for duplicate logon name and valid email address and then records the data in its database.
 * 5) The system sends a confirmation email to the user. This email contains a link with an encrypted token that when followed will finalise the registration.
 * 6) The system displays a page that informs the user about the confirmation email and what to do with it.


 * Variants and exceptions

Variant: The user gives a wrong answer to the spam avoiding question
 * Replace step 4 by: The system detects a wrong answer to the spam avoiding question
 * The system displays the registration form again with an error message and allows the user to re-enter an answer to the spam avoiding question and re-submit. I.e. continue with step 3.

Variant: The user chooses a logon name that already exists
 * Replace step 4 by: The system detects a duplicate logon name
 * The system generates three valid logon names, based on first name and last name, from which the user can choose and allows the user to re-submit. I.e. continue with step 3.

The user is registered. From this moment on, the user can make proposal for changes and view closed change requests. For other actions, the general administrator must assigns first certain role(s) to this person.
 * Result

Logon
A user logs on to the system A user
 * Summary
 * Actors

This use case is triggered by the user.
 * Assumptions and triggers


 * Description


 * 1) The user accesses the vocabulary maintenance website and navigates to the logon page.
 * 2) The system displays the logon page with a logon and password field and a ‘forgot password’ link
 * 3) The user fills in his logon name and password and submits
 * 4) The system checks the logon name and password and displays a page with all vocabularies the user can access for maintenance or viewing closed requests for changes


 * Variants and exceptions

Variant: Logon failure
 * Replace step 4 by: The system can not find the logon name with the corresponding password. When this happens more than three times, then the logon page is displayed with an increasing delay
 * Allow customer to re-enter logon name and password and re-try. I.e. go back to step 3

The user is logged on and can see to which vocabularies he has access to.
 * Result

Requesting a role with respect to a vocabulary
Any registered user can request a role with respect to a vocabulary.
 * Summary

Any registered user.
 * Actors

It is assumed that the user is logged on. The use case is triggered by the actor. Roles may have attributes. They are as follows:
 * Assumptions and triggers


 * For a vocabulary administrator it is
 * For a language administrator it is 
 * For a stakeholder it is or 




 * Description


 * 1) The user selects a role and selects the values for the corresponding attributes.
 * 2) The system records this request and confirms the successful recording to the user

A user has a pending request.
 * Result

Assigning a role to a user
An administrator can assign roles to registered users. Roles may have attributes. They are as follows:
 * Summary


 * For a vocabulary administrator it is
 * For a language administrator it is 
 * For a stakeholder it is or 

A language administrator can only assign roles pertaining to the specific  pairs he is administering. A vocabulary administrator can only assign roles pertaining to the specific vocabulary he is administering.

An administrator (general, vocabulary, language).
 * Actors

It is assumed that the user is logged on. The use case is triggered by the actor.
 * Assumptions and triggers


 * Description


 * 1) An administrator indicates that he wishes to edit a role.
 * 2) The system displays actual roles and the pending requests. I.e. roles and attributes. The system displays also an "Add new role" button.
 * 3) The administrator selects a role with attributes from the pending request list and hits the "Assign role" button.
 * 4) The system assigns the role with attributes.


 * Variants and exceptions

Variant: Adding a new role
 * Replace step 3 by:
 * 3.1 The administrator clicks the "Add new role" button.
 * 3.2 The system displays the different users that this administrator can see
 * 3.3 The administrator selects a user from the list, a role and values for its attributes.
 * 3.4 The administrator submits the newly defined role

A role is assigned to a registered user.
 * Result

Revoking a role from a user
An administrator can revoke an assigned role from a user.
 * Summary

An administrator (general, vocabulary, language).
 * Actors

It is assumed that the user is logged on. The use case is triggered by the actor. If the role of stakeholder is revoked for a given  then other roles of this user for this vocabulary are also revoked. A language administrator can only revoke roles pertaining to the specific  pairs he is administering. A vocabulary administrator can only revoke roles pertaining to the specific vocabulary he is administering.
 * Assumptions and triggers


 * Description


 * 1) An administrator indicates that he wishes to edit a role.
 * 2) The system displays actual roles and the pending requests. I.e. roles and attributes. The system displays also an "Add new role" button.
 * 3) The administrator selects a role with attributes from the actual role list and hits the "Revoke role" button.
 * 4) The system revokes the role.

A role is revoked from a user.
 * Result

Change request (the change may be structural of non-structural)
Any person (e.g. a teacher) may request a change.
 * Summary

Any person. See also the Issues section for a discussion on who can do this.
 * Actors

This use case is triggered by the actor.
 * Assumptions and triggers


 * Description


 * 1) The user navigates to the change request page.
 * 2) The system displays the change request page.
 * 3) The user provides specifics about the change request. This must include his name, his email addres,  the vocabulary, the type of change, and may include the language to which the change requests applies, and certain values such as a new descriptor, non-descriptor, scope note. The user then submits the request. 
 * 4) The system records the request and sends an email to the vocabulary manager(s).

The user has submitted a change request.
 * Result

Set-up a consensus building process for a change to the vocabulary
The vocabulary administrator sets up a consensus building process.
 * Summary

The vocabulary administrator.
 * Actors

It is assumed that the user is logged on. This use case is triggered by the actor.
 * Assumptions and triggers


 * Description


 * 1) The user navigates to the change management page.
 * 2) The system displays the change management page. This includes a list of pending change requests for the vocabulary. The page has a 'Change set-up' button, a 'Forward' Button, and a 'Reject' button. Possibly we have to foresee here the option for seeing details about the change request, e.g. by hovering over it.
 * 3) The user selects one of the change requests from the list and clicks the set-up button.
 * 4) The system displays the details of the change request. This includes the vocabulary, the type of change, and may include the language to which the change requests applies, and certain values such as a new descriptor, non-descriptor, scope note. It also contains a field for the description of the rules for coming to a conclusion. Typically, this might be a link to a static HTML page. In addition specifics about the concluding process/event may be added such as a cut-off date.
 * 5) The user edits the properties of the change requests, and then submits this.
 * 6) The system links this consensus building process to the original change request, and displays the list of stakeholders of this vocabulary. The list is preceded by check boxes. The list shows also a 'Select all' and a 'De-select all' button
 * 7) The user selects the stakeholders he wants to consult and submits his selection of stakeholders. By doing so he makes them change stakeholders for this particular change.
 * 8) The system records the selection and displays an overview with a 'Confirm' button and an 'Edit' button.
 * 9) The user confirms; i.e. clicks the 'Confirm' button.
 * 10) The system sends an email to all change stakeholders, notifying them about this new consensus building process. This email contains a URL that allows the stakeholder to see and directly comment on the change request.


 * Variants and exceptions

Variant: Rejecting a change request
 * Replace from step 3 onwards all steps by:
 * 3. The user selects one of the change requests from the list and clicks the reject button.
 * 4. The system displays the change request and a comment field where the user can fill in the reason for rejection that will be sent to the user and a field with internal comments that will not be sent to the user.
 * 5. The user fills in the 'Comment to requestor' field and the 'Internal comment' field and submits.
 * 6. The system records this information and sends an email to the person that submitted the change request.

Variant: Re-editing
 * Replace step 9 by:
 * 9.1 The user clicks the edit button
 * 9.2 The system goes back to step 4, displaying the change request and the already provided information about the concensus building. Coming to step 6, the system will display the list of stakeholders with the already selected stakeholders marked.

Variant: Forwarding the request to a language administrator
 * Replace from step 3 onwards all steps by:
 * 3. The user selects one of the change requests from the list and clicks the forward button.
 * 4. The system pops up a list of languages to choose from.
 * 5. The user selects one or more languages.
 * 6. The system records this information and sends an email to the language administrator(s) of the vocabulary that are dealing with the specified language.

Variant: The change is concerning a specific language Here the actor is not a vocabulary administrator but a language administrator, to whom a request was forwarded. The same use case holds mutatis mutandis.

The vocabulary manager has set up a consensus building process for a vocabulary change, has rejected the change, or has forwarded it.
 * Result

Edit the list of change stakeholders
The vocabulary administrator or language administrator adds or deletes people to the stakeholders list for a change.
 * Summary

The vocabulary administrator or language administrator.
 * Actors

It is assumed that the user is logged on. This use case is triggered by the actor.
 * Assumptions and triggers


 * Description


 * 1) The user navigates to the 'Edit stakeholders' page.
 * 2) The system displays the 'Edit stakeholders' page. This shows a list of change requests for the vocabulary that are in progress.
 * 3) The user selects one of the change requests from the list and clicks the 'Edit stakeholders' button.
 * 4) The system displays the list of stakeholders of this vocabulary possibly limited for a language. The list is preceded by check boxes. The list shows also a 'Select all' and a 'De-select all' button
 * 5) The user selects the stakeholders he wants to consult and submits his selection of stakeholders. By doing so he makes them change stakeholders for this particular change.
 * 6) The system records the selection and displays an overview with a 'Confirm' button and an 'Edit' button.
 * 7) The user confirms. I.e. clicks the 'Confirm' button.
 * 8) The system sends an email to stakeholders who have been added or deleted from the list. For people that have been added to the list, this email contains a URL that allows the stakeholder to see and directly comment on the change request.

The list of stakeholders in a vocabulary change has been updated.
 * Result

Add comment to a change request
A stakeholder for a vocabulary change adds a comment to the requested change.
 * Summary

Any stakeholder.
 * Actors

It is assumed that the user is logged on. This use case is triggered by the actor.
 * Assumptions and triggers


 * Description


 * 1) The user navigates to the 'View open change requests' page.
 * 2) The system displays the 'View open change requests' page. This shows a list of change requests for the vocabulary that are in progress, i.e. open, and for which the user is a stakeholder.
 * 3) The user selects one of the change requests from the list and clicks the 'View' button.
 * 4) The system displays the change request and all comments, the most recent on top.
 * 5) The user clicks the 'Add comment' button.
 * 6) The system displays a new page where the user can add a comment.
 * 7) The user fills in the comment field and submits his comment
 * 8) The system records the comment together with the date of submission.

A stakeholders has added a comment to a change request.
 * Result

Conclude change request
A vocabulary manager or language manager concludes a change request
 * Summary

A vocabulary manager or language manager
 * Actors

It is assumed that the user is logged on. This use case is triggered by the actor.
 * Assumptions and triggers


 * Description


 * 1) The user navigates to the 'Conclude change requests' page.
 * 2) The system displays the 'Conclude change requests' page. This shows a list of change requests for the vocabulary that are in progress, i.e. open, and for which the user is responsible.
 * 3) The user selects one of the change requests from the list and clicks the 'Conclude' button.
 * 4) The system displays the change request, a 'Change' button, a 'Reject' button and all comments, the most recent on top.
 * 5) The user clicks the 'Change' button.
 * 6) The system displays a new page where the user can document the change. This page has fields for the type of change, rational, and certain values such as a new descriptor, non-descriptor, scope note.
 * 7) The user fills in the fields documenting the change. In the rational field he can also document how the decision was made for example the outcome of a voting process. The user submits the conclusion.
 * 8) The system records the conclusion together with the date of submission and closes the change request.

The change request has been closed
 * Result

Workflow 2
Assignment of roles and permissions and concensus building (if required) is as per Workflow 1.

Specialist editor makes changes to a vocabulary
An editor downloads a vocabulary for editing to their desktop editor. Makes changes (possibly significant structural changes) and then uploads a new version of the vocabulary to the bank
 * Summary

A vocabulary editor.
 * Actors

It is assumed that the user has the required permission for the vocbaulary to be edited. The use case is triggered by the actor.
 * Assumptions and triggers


 * Description


 * 1) The editor synchromises his editor with the latest version of a vocabulary in the bank
 * 2) This causes the vocbaulary to be downloaded to the local editor
 * 3) The edits are performed and the vocabulary is re-uploaded.


 * Variants and exceptions

Variant: The vocabulary has been altered by another user during the same time period and there are conflicts
 * Replace step 3 by:
 * 3.1 The local editor shows a summary of the conflicts and invites the editor to resolve the conflicts
 * 3.2 The editor resolves the conflicts and commits the changes

An altered vocabulary is available in the bank (but not yet published). The same concensus process as per workflow 1 can then be invoked when all changes have been committed to enable peer review before publication.
 * Result

Use cases that do NOT have an impact on the structure of the thesaurus or on the corpus of descriptors
The use cases below are planned as an extension to the vocabulary bank. They are concerned with the translation of a vocabulary. The use cases may be further elaborated if necessary. It is likely that the functionality underneath is also of value in the editor – working off line. In this case, it would be necessary to provide additional functionality such as export certain language(s) from the bank or editor and merge a translation with an existing vocabulary.

The use cases about the non-descriptors are provided assuming that orphan non-descriptors are allowed. I.e. when a non-descriptor relationship (USE of UF) is deleted, the non-descriptor still remains.

Make a registered user a language administrator for a certain language
The vocabulary administrator gives adds the role of ‘language administrator’ to a registered user. The vocabulary administrator needs to indicate for which vocabulary, which registered user, and which language. In the elaboration must be decided whether this is done for many registered users/languages at the same time or only one.
 * Summary

This functionality is part of the vocabulary bank.

The vocabulary administrator.
 * Actors

It is assumed that the vocabulary administrator is logged on to the vocabulary bank and initiates the use case.
 * Assumptions and triggers

A registered user is now language administrator for a certain language.
 * Result

Revoke the role of a language administrator for a certain language
The vocabulary administrator revokes the role of ‘language administrator’ from a registered user. The vocabulary administrator needs to indicate for which vocabulary, which language administrator, and which language. In the elaboration must be decided whether this is done for many registered users/languages at the same time or only one.
 * Summary

This functionality is part of the vocabulary bank.

The vocabulary administrator.
 * Actors

It is assumed that the vocabulary administrator is logged on to the vocabulary bank and initiates the use case.
 * Assumptions and triggers

A registered user is not any longer language administrator.
 * Result

Add a new non-descriptor in a given language version
The language administrator adds a new non-descriptor. It can be a non-descriptor already known to the system, or a new one. In the latter case, the user will be warned. This use case incorporates the use case 'Add a new non descriptor relationship in a given language version'.
 * Summary

This functionality is part of the vocabulary bank.

The language administrator.
 * Actors

It is assumed that the language administrator is logged on to the vocabulary bank and initiates the use case. A descriptor may have many non-descriptors (i.e. UF relationships), but a non-descriptor should have only one USE relationship.
 * Assumptions and triggers

A new non-descriptor in a given language version is added.
 * Result

Edit a non-descriptor in a given language version
The language administrator edits an existing non-descriptor or one of its attributes. This would be for example correcting spelling or adding a qualifier to distinguish homographs.
 * Summary

This functionality is part of the vocabulary bank.

The language administrator.
 * Actors

It is assumed that the language administrator is logged on to the vocabulary bank and initiates the use case.
 * Assumptions and triggers

A non-descriptor in a given language version is changed.
 * Result

Delete a non-descriptor in a given language version
The language administrator deletes a non-descriptor.
 * Summary

This functionality is part of the vocabulary bank.

The language administrator.
 * Actors

It is assumed that the language administrator is logged on to the vocabulary bank and initiates the use case.
 * Assumptions and triggers

A non-descriptor in a given language version is deleted.
 * Result

Add a new non-descriptor relationship (USE/UF) in a given language version
The language administrator adds a non-descriptor relationship (USE/UF) in a given language version.
 * Summary

This functionality is part of the vocabulary bank.

The language administrator.
 * Actors

It is assumed that the language administrator is logged on to the vocabulary bank and initiates the use case.
 * Assumptions and triggers

A non-descriptor relationship (USE/UF)in a given language version is added.
 * Result

Delete a non-descriptor relationship (USE/UF) in a given language version
The language administrator deletes a non-descriptor relationship (USE/UF) in a given language version.
 * Summary

This functionality is part of the vocabulary bank.

The language administrator.
 * Actors

It is assumed that the language administrator is logged on to the vocabulary bank and initiates the use case.
 * Assumptions and triggers

A non-descriptor relationship (USE/UF)in a given language version is deleted. It makes the non-descriptor an orphan that can be added again with a USE/UF relationship to another descriptor.
 * Result

Add a translation of a descriptor in a given language version
The language administrator adds a translation of a descriptor in a given language version. This may include properties such as scope notes.

This functionality is part of the vocabulary bank.

The language administrator.
 * Actors

It is assumed that the language administrator is logged on to the vocabulary bank and initiates the use case.
 * Assumptions and triggers

A translation of a descriptor in a given language version is added.
 * Result

Modify a translation of a descriptor in a given language version
The language administrator modifies a translation of a descriptor in a given language version. It may be the descriptor itself but may include properties such as scope notes.

This functionality is part of the vocabulary bank.

The language administrator.
 * Actors

It is assumed that the language administrator is logged on to the vocabulary bank and initiates the use case.
 * Assumptions and triggers

A translation of a descriptor in a given language version is modified.
 * Result

Delete a translation of a descriptor in a given language version
The language administrator deletes a translation of a descriptor in a given language version. Consequently all properties such as scope notes are deleted as well.

This functionality is part of the vocabulary bank.

The language administrator.
 * Actors

It is assumed that the language administrator is logged on to the vocabulary bank and initiates the use case.
 * Assumptions and triggers

A translation of a descriptor in a given language version is deleted. Consequently all properties such as scope notes are deleted as well.
 * Result

Use cases that have an impact on the structure of the thesaurus or on the corpus of descriptors
The use cases below presuppose that a concensus building process about a proposed change has been concluded. After the use cases below, which happen on the local editor of the vocabulary administrator, he commits changes by uploading a new version to the vocabulary bank.

Add a descriptor
The vocabulary administrator adds a descriptor and zero or more translations. A number of properties are filled in as well.

This functionality is part of the local editor.

The vocabulary administrator.
 * Actors

It is assumed that the vocabulary administrator has obtained consensus about this change, is logged on to the vocabulary editor, and initiates the use case.
 * Assumptions and triggers

A descriptor with zero or more translations has been added.
 * Result

Delete a descriptor
The vocabulary administrator deletes a descriptor.

This functionality is part of the local editor.

The vocabulary administrator.
 * Actors

It is assumed that the vocabulary administrator has obtained consensus about this change, is logged on to the vocabulary editor, and initiates the use case.
 * Assumptions and triggers

A descriptor with all its properties, translations, and structural realtionships is deleted.
 * Result

Modify a descriptor
See the use case "Modify a translation of a descriptor in a given language version". Once a descriptor has been added it is treated the same way as a translation as far as modification is concerned.

Change a descriptor into a non-descriptor
This should be seen as the deletion of a descriptor which requires consensus building and the addition of a non-descriptor within a given language which does not require consensus building.

Change a non-descriptor into a descriptor
This should be seen as the deletion of a non-descriptor which does not require consensus building and the addition of a descriptor which requires consensus building.

Add a structure relationship (TT, BT, NT, RT) in the conceptual thesaurus or the systematic view
The vocabulary administrator adds a structure relationship.

This functionality is part of the local editor.

The vocabulary administrator.
 * Actors

It is assumed that the vocabulary administrator has obtained consensus about this change, is logged on to the vocabulary editor, and initiates the use case.
 * Assumptions and triggers

A structure relationship has been added.
 * Result

Delete a structure relationship (TT, BT, NT, RT) from the conceptual thesaurus or the systematic view
The vocabulary administrator deletes a structure relationship.

This functionality is part of the local editor.

The vocabulary administrator.
 * Actors

It is assumed that the vocabulary administrator has obtained consensus about this change, is logged on to the vocabulary editor, and initiates the use case.
 * Assumptions and triggers

A structure relationship has been deleted.
 * Result

Add a micro thesaurus
Needs discussion on who can do this. It also depends on if the terms are also being deleted or if they exist elsewhere

Delete a micro thesaurus
Needs discussion on who can do this

Adding and deleting translations of terms
If we allow adding and deleting translations of terms on the bank one by one, then a translation may be in an incomplete state. How is this going to be handled? Does the vocabulary bank have a validation before publishing?

Adding and deleting new structures
Who maintains the systematic view? Can language administrators not provide their own systematic view?

In my view, systematic view is common to all language versions. If somebody asks for a change in the systematic view, the management group should discuss it and then do it if agreement has been reached upon it. The change will affect the structure of all language versions.

Synchronising different language versions
If different language administrators are editing translations, how can we publish a new version, since it will often be the case that someone has not finished yet.

Being part of TESE working group, I can report here my experience. The have an yearly edition and collect/discuss all prposals made (let's say) until a certain period. Then the new edition is released and all new proposals are discussed for the next edition. I think we should manage the updating process in a similar way, settling up a workflow with deadlines for proposals to be taken into account.

I think there should be a management group doung this, composed by 4-5 people, in order to organize all documents and circulate the information, gathering the language version experts, etc.



Synchronising permissions
Where will roles be defined, in the bank or the maintenance management tool? It will probably be necessary to be able to synchronise role assignments. Can for instance a vocabulary manager download/upload role assigments to/from the bank? Should be have single sign-on? 

Who can request a change ?
Should any person be able to request a change or should only registered users be able to request a change or should the vocabulary manager be able to specify this. In the EUN we allow any person. See http://feedback.eun.org. <Mike: Yes anyone request>

Roles vs Permissions
The use cases described assume the existence of an authorisation mechanism based on roles, which means that when some gets a role, he gets all the permissions; if a role is revoked then all the permissions are revoked.

EUN Template for Use Cases
A use case is the description of a sequence of actions, including variants, that a system performs to yield an observable result of value to an actor. The purpose is to come to a common understanding between developers, the end users and the domain experts about the behaviour of the system

A short phrase A short textual description The actors of the use case. Try to be more specific than naming the actor 'user'. Note: the System is not considered to be an actor Assumptions that hold for the use case. For example that the user is already logged in. Sequence of steps showing the interaction between the system and the actor(s). Each step is numbered and has a sentence starting with "The system ..." or "The ...". Further a step may optionally document ideas about how the step is achieved.
 * Name
 * Summary
 * Actors
 * Assumptions and triggers
 * Description

Example Description


 * 1) Customer browses through catalogue and selects items to buy
 * 2) Customer goes to check out
 * 3) Customer fills in shipping information (address; next-day or 3-day delivery)
 * 4) System presents full pricing information, including shipping
 * 5) Customer fills in credit card information
 * 6) System authorises purchase
 * 7) System confirms sale immediately
 * 8) System sends confirming email to customer

Variants and exceptions are described by referring to the numbered steps. For example:
 * Variants and exceptions

Variant: Authorisation failure
 * At step 6, system fails to authorise credit purchase
 * Allow customer to re-enter credit card information and re-try

Indicate the observable result of value to the actor(s). For example: "The customer bought a product" or "The user is logged in"
 * Result

Maintaining other vocabularies
The maintenance of other vocabularies can follow a similar process as the one described for a thesaurus. One could consider to make it simpler, given that for example no (or less) relationships types are used.

Information for new contributors to the VBE
This information is related to the vocabularies administered by the EUN and includes for example all vocabularies of the LRE application profile of the LOM. Contributions may be:


 * 1) Proposing changes to a vocabulary. This might be proposing structural changes, better translations, adding/deleting descriptors and non-descriptors, scope notes, etc. For this the vocabulary maintenance management tool should be used. This is currently under development. In the mean time one can send an email to contact.lre@eun.org.
 * 2) Provide a full translation of a vocabulary. Please send an email to contact.lre@eun.org.

<When consensus has been reached about this section, it will be published on lre.eun.org>