The Access Management System (AMS) allows you to manage the access rights to electronic language resources in within ASV TLA framework. These resources consist of Info files, annotation or text files, images, audio or video files that have been uploaded with LAMUS into a corpus. By setting access rights you can either allow or deny access to resources for individual users or groups of users. In any case, the metadata itself will always be accessible, as required by the Open Archive Initiative.
AMS was developed at the Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands.
The main concept underlying AMS is the corpus tree. The corpus consists of nodes and arcs that form a tree-like structure representing the corpus hierarchy. Each node can group other nodes on the basis of, e.g., the geographical region, the discourse genre, the sex or age of the speaker, the dialect of the speaker, the source/target language etc. The lowest level in the hierarchy consists of the actual resources (see Section 1.1.1.2). Consider the following example:
The node labeled 'Corpus' is the top node. The nodes labeled 'Elicited' and
'Spontaneous' are subnodes. These subnodes are sometimes called 'children' of the node
above them, in this case the top node 'Corpus'. The nodes 'Book' and 'News' are children
of the node 'Elicited' and grandchildren of 'Corpus'. Similarly, the nodes 'Telephone' and
'Game' are children of 'Spontaneous' and also grandchildren of 'Corpus'. The nodes labeled
with filenames like book1.wav and game_a.mpg are
at the lowest level and represent the resources.
By using this hierarchical data representation you can specify access rights in the form of rules (see Section 1.1.2) for a certain branch of the tree. A branch consists of a node plus all of its descendants. Therefore, a rule does not only apply to an individual node, but also to all of its descendants. Since a node groups children, grandchildren and other descendants, a branch is called domain in AMS.
To see how rules apply to a domain, consider Figure 1.1
again. Suppose we set the access rights for the domain 'Elicited' to
something like 'readable by everybody'. This means that all the resources in the domain of
the node 'Elicited' are 'readable by everybody': i.e. the (only one in this case)
resources present in this domain - book1.wav - can be accessed by
everybody. Another example concerns the domain 'Spontaneous'. Suppose we want only some,
specific user to be able to access this domain: what we have to do is to set the rule
'readable by user X'. In this way, the resources conv1.txt,
conv2.txt and game_a.mpg will be readable
only by user X.
Nodes like 'Book', 'Telephone' and 'Game' in Figure 1.1 are called session nodes. They group all resources that are part of a meaningful unit of analysis. Nodes like 'Corpus', 'Elicited' and 'Spontaneous' are called corpus nodes. They group session nodes or other corpus nodes, giving the archive its tree-like structure.
Resources is a common name for all kinds of files that can be associated to session nodes. The resources are the very content of the corpus. Resources can be of the following types (with their respective formats):
Images, e.g. JPEG
Video files, e.g. MPEG
Audio files, e.g. WAV
Annotations/Text, e.g. EAF
Info files (all kind of files), e.g. PDF
ASV uses a colour coding reference to represent the access rules that have been set to the various corpora, nodes and resources. This colour coding scheme is as follows:
Green circle: This node or resource is openly available.
Yellow circle with black dot: This node or resource is accessible to registered users of the archive.
Orange circle with diagonal line: Access to this node or resource can be requested.
Red circle with cross: Access to this node or resource is prohibited.
In the example shown here, you can see that access to the node 'Demo' is openly available, whereas the node 'corpus1' is only accesible to registered users of the archive. Access to the node 'Session1_1' and the resource 'background-logo_1_.png is prohibited. These access-rules can all be set with AMS.
In AMS, the access rights of a certain domain are expressed by one or more rules. A rule gives an individual user, or all users from a group, the permission to open, download, and/or read all resources of a certain type within a domain. A rule can also deny that permission. A rule contains the following elements:
a user or a group to which the rule applies;
the type of resource;
the permission or denial to access the node;
a priority of access;
an expiration date (optional);
When there is a rule on a certain node (in which case that rule applies to the entire domain of that node), it is also possible to create a rule on a descendant of that node. In this case, there would be two rules applying to the domain of the descendant (the latter created plus the one already applying to the parent node). Depending on the elements of these rules one of them is considered the 'strongest' and enforces its access rights. More on the calculation of the strongest rule as well as other topics can be found in Chapter 3.
If necessary you can request a user to accept a license agreement before he/she can access resources in a part of the corpus tree. This agreement usually contains arrangements on ethical codes and on the responsibility for data use. More about licenses can be found in Section 3.4.
Roles are preconfigured templates that define in what way a user can manage the corpus. This encompasses access rights, rights to change the content of the nodes, and the right to pass on all of these privileges. Here is a list of the roles:
Archive Manager
The role of Archive Manager can be assigned to each user. This means that all possible rights are granted to this user, such as accessing all resources and changing access rules. An archive manager can, in turn, appoint other archive managers. It goes without saying that this possibility should be used with care. It is the only role that is not bound to a domain.
Domain Curator
A domain curator:
is bound to a domain (i.e. he/she has power over a node and its descendants).
can set and revoke rules on all of the nodes within that domain.
can create, remove and alter users and groups. [Note: altering and removing only works for those users/groups which have been created by the domain curator him/herself].
can delegate his/her rights (except the delegation right itself) to a Domain Manager.
A domain can only have one Domain Curator.
Domain Manager
A Domain Manager, like the Archive Manager, can appoint other Domain Managers. This is the only difference from a Domain Curator, which means that, like the him/her, a Domain Manager can (for a given domain) set and revoke reading rules, create users/groups and edit them.
Domain Editor
In contrast with the roles described above, a Domain Editor can add and/or remove corpus nodes and/or resources (again: for a specific domain). This right is closer related to LAMUS than to AMS itself. Therefore, one generally combines the role of Domain Editor with that of Domain Manager or Domain Curator. In this way one user can, at the same time, upload information in the corpus, change such information and, afterwards, set the access rights.
![[Note]](images/note.png) | Note |
|---|---|
The domain-based roles (curator, manager, editor) can only be accessed and set via the Node Authorization Management, as they are dependant on a certain domain. The Archive Manager role applies to the whole corpus and can be thus selected when creating or editing a user/group. |