Settings Management
Semantic Turkey distinguishes 4 levels, or "scopes", for settings:
- SYSTEM: settings defining the behavior of the system.
- Project: settings scoped to project level. These settings are thus present in each project with values that are local to each project, independently.
- User: settings scoped to user level. These settings are thus available, independently, to each user. We refer formally to settings with this scope as USER SETTINGS, even though they correspond to what are commonly known as system preferences (as the term preference expresses implicitly something setup by the user according to their preference)
- PU: settings scoped to project-user level. These settings are not only scoped to each project, but each user can set them independently. Commonly referred as project preferences
Order of Evaluation of Settings and their Defaults
Settings may have default values. These correspond to values that can be specified at a certain scope for a certain scope. E.g. a default for PU setting defined at the system level is a default value for a setting that operates at the PU level, but being defined at system level is shared by all users on all projects. So, if a value of for that PU setting is not defined by any user for any given project, that default is used. PROJECT and USER settings have only system-level defaults. PU settings have different level of defaults: project, user and system.
The following ones are the associated workflows for resolving the setting value by first looking into the asserted value, and then on list of defaults.
- SYSTEM: no default
- PROJECT --> default(project, system)
- USER --> default(user, system)
- PU --> default(pu,project) --> default(pu,user) --> default(pu,system)
The expression default(<scope>, <location>) referes to the default value, set for the setting of scope <scope>, on a certain scoped <location>. E.g. default(pu, user) refers to the default value for any project preference, expressed by the user. So this default value is set for a certain setting by the user, and is considered for that property on all projects, unless overridden, in a specific project P, by a default specified by a project manager for P, or by an explicit value expressed by the user for P.
The concept of default above is not to be confused with factory settings. Defaults are stored in files and have...default values :-), which can be however changed by users or, depending on the scope of the default, project managers or administrators only. Factory settings are the last resource for certain settings and might be hard-wired in the code, that is, if a value is not set, and no default is available, then the application resorts to a certain factory-set default value.
Location of Settings Files
The following table lists all settings types, including defaults for various locations and where their values/defaults are stored
| Property Name | short reference | stored in |
|---|---|---|
| user settings (system preference) | USER | users\<username>\plugins\<plugin>\settings.props |
| pu settings (project preferences) | PU | pu_binding\<projectname>\<username>\plugins\<plugin>\settings.props |
| system settings | SYS | system\plugins\<plugin>\settings.props |
| project settings | PROJECT | projects\<projectname>\plugins\<plugin>\settings.props |
| user settings default | default(user,system) | system\plugins\<plugin>\user-settings-defaults.props |
| pu settings - project default | default(pu,project) | projects\<projectname>\plugins\<plugin>\pu-settings-defaults.props |
| pu settings - user default | default(pu,user) | users\<username>\plugins\<plugin>\pu-settings-defaults.props |
| pu settings - system default | default(pu,system) | system\plugins\<plugin>\pu-settings-defaults.props |
| project settings defaults | default(project, system) | system\plugins\<plugin>\project-settings-defaults.props |
Each property is local to a plugin. Actually, the <plugin> placeholder may refer to an extension point (in that case, the property is shared by all plugins implementing the extension point) or by a specific plugin implementation. Plugin implementations in turn use their plugin ID if they are singletons, or generate specific IDs of the form: <PluginID>.inst_<instID> if they foresee to have more than one instance. All IDs have the form of a namespace.
Notable Settings
We list here some settings that are usually not known, or not available through the usual user interface (e.g. VocBench), to provide an easy reference for Semantc Turkey users.
Project Settings
Available Languages: definition list in the defaults of the "languages" project property
Semantic Turkey comes with a default definition list of languages that can be shown in different options: editing languages per each project, language proficiencies of the users, language for showing the content, etc... Each of these options restricts the set of languages that can be chosen by users, adopted in projects etc.. but no language can be ever selected if it has not been by first declared in this definition list.
The definition list is actually a default for the "languages" project property defining the overall set of languages that can be adopted in a given project. As a consequence, the "language" property for each project is located in:
<STData>/projects/<projectname>/plugins/it.uniroma2.art.semanticturkey/settings.props
while the generic definition list is available at:
<STData>/system/plugins/it.uniroma2.art.semanticturkey/project-settings-defaults.props