Mobile Key Service Strategy

Summary: An action plan to integrate the ETI mobile keys with other components of Key to Nature and to provide an automated self-service facility supporting uploading and configuring mobile keys on the Wiki. Once a key is configured on the Wiki, the separate identification application optimized for mobile devices processes the data and provides the identification service.

1 Introduction

The mobile keys offer a way to identify organism directly in the field, using any internet-capable smartphones. The user interface of this key is specifically adapted to the small screen sizes available on such devices.

The mobile key always asks one question at a time in a predefined sequence. It requires the submission of identification data in a exchange format and can be used with data defining an authored single-access keys or with matrix data. In the latter case, the software algorithmically creates a single access key based on principles of best average progress (entropy or information gain-based). An advantage of having matrix data is that the key can offer the user to "skip" a question which is too difficult or cannot be answered with the specimen being observed.

The mobile key uses a database and server-side functionality for its operation. To make the interaction between original key data and the specific needs of the mobile player as flexible and agile as possible, the mobile key database is considered only a cache of data existing elsewhere. It may obtain these identification data, e.g., as

• an SDD document containing an authored single-access key,
• an SDD document containing matrix data (coded descriptions),
• a Wiki page using describing a single-access key in template syntax
• a custom connector to another database (the structure of which does not have to be identical to the structure of the mobile key database).

In the case of SDD documents, the SDD document may have been uploaded directly to the Wiki or it may reside anywhere in the web (this includes SDD documents dynamically generated from databases such as FRIDA).

In addition to the definition of identification data, a mobile key may be filtered by a list of taxon to which the resulting key shall be limited. This optiona allows significant re-use of larger keys for smaller educational projects. Again the source of the taxon filter may be various methods, which can be extended over time:

• a plain wiki page containing a list of taxa
• a list of semicolon-separated taxon names directly in the mobile key setup.
• xml-based methods (to be decided, SDD taxon name lists are possible)

2 Wiki-based mobile key configuration

To make the setup of a mobile key as simple and user-driven as possible, the setup of the key is based on the following conventions:

• Each mobile key must have a page on the Key to Nature or SpeciesID Wiki, on which any information (text, images, links) relevant to the key may be presented.
• The key will be described using a standard metadata template, identical to the one used for keys outside the wiki.
• The configuration of the mobile key will be realized by adding the template "MobileKey Configuration". Examples:

{{MobileKey Configuration | Quick Access Code = a short combination such as "KGRO3" for quick access from | SDD Formatted Identification Data Upload = (an SDD file that has been uploaded to the wiki, both Image: and Media: naming conventions are accepted) | SDD Formatted Identification Data URI = (alternatively, the URL of an SDD file on the web<ref>SDD files residing on external servers are less desirable, because the system response may be less reliable if many servers are involved. If possible, please upload your data to the wiki.)</ref> ) | Wiki Key Page = (a wiki page containing a single-access key in wiki-syntax) | Names Filter Page = (a wiki page containing a list of taxon names; same spelling as names in the key) }}

2.1 Taxon list syntax

Among the simplest options to create a taxon list for filtering a larger identification key is a list of taxon names directly on a wiki page. When in edit mode, each name must be on a separate line. To make this list of taxa slightly better readable when not in edit mode, the following conventions are adopted:

• If the line starts with one or several asterisks ("*"), hash characters ("#") or colons (":"), the characters as well as any whitespace are ignored. In the MediaWiki syntax, asterisks result in bulleted, hash characters in numbered, and colons in indented lists.
• A line starting and ending with brackets "()" will be ignored, allowing for comments in the list
• Any line starting with "=" sign will be ignored, allowing to add arbitrary subheadings into the taxon list.
• Within a taxon name, the use of double apostropes (indicating start and end of italic font in MediaWiki) is allowed; these will be stripped from the taxon names prior to further processing.

---

2.2 Implementation

The current ETI mobile key is modified such that the key-selection page offers the 5-8 most frequently requested keys for a given country or language (which is asked in an earlier step), plus an option to enter the name of key. To obtain usage frequency data, each time a new couplet is requested, a counter for the key is incremented (which is more useful than just recording "key started"; but which may have to be normalized by the total number of couplets in the key).

The key-metadata table contains at least: InternalID (primary key), Language, KeyName (= SetupWikipage, unique), WikiURL, QuickAccessCode (unique), LastModified, CoupletUsageCounter, TotalCouplets. In addition, a second table is used for Country, to support keys applicable to more than one country. The key data are harvested into separate tables for single-access or multi-access identification data.

The mobile key tables will not become the primary location of the identification data for the purpose of updating the information. The mobile key tables are just a cache, optimized for operation of the mobile key.

The initial harvesting and later updating of the mobile-key database occurs to the following rules:

• Initial harvesting: If a name entered in the mobile device does not already exist in the mobile key database, the mobile key will look at one or several registered key repositories (initially, e. g., the KeyToNature and SpeciesID wikis). If a page of that name exists, it will display an appropriate message ("harvesting a new key"), read the page in raw mode (URL with parameter action=raw) and parse the page for the configuration template record described above. The SDD data is then loaded, the taxon list harvested, and the resulting key written into the mobile key database.
• If the key already exists in the mobile key database, the key will immediately start with the start page. However, at the same time, the last updating date of the Wiki page will be compared with the date saved in the mobile key database. If an updating is necessary, the old key is deleted and an initial harvesting is started over. Depending on the time that this takes, the mobile key application will display an appropriate updating message.

3 Availability of the mobile key service

Initially, the mobile key service will be free. However, in the future it may be necessary to generate some revenue to cover the operating costs for hardware, network bandwidth and management cost. In this case, the service to cache a key can be protected by eTokens. An eToken is simply a long passphrase, created by a service provider. An example might be: "ETI_KeyCreationToken=4952319508376797032581037". The eToken is initially not associated with a mobile key. As soon as a mobile key configuration using this eToken is encountered, the mobile key service will pick up that key as being registered with the eToken and provide mobile services for that key. However, should a second key (having a different name) attempt to use the same key, the mobile key service will issue a warning ("eToken is already used for key XYZ; you cannot use an eToken for multiple keys!"). The key for which the eToken is validly registered may be changed over time, the mobile phone service will update its cached data accordingly without requiring additional eTokens.

eTokens may be provided to associated educational partners in batches, to be then distributed to the schools participating in the project.

One problem with this mechanism is that users might want to change the name of their key over time. To accomodate this, the mobile key service may implement additional methods (e. g., checking the wiki if the old key name is now a redirect to the new name); these can be added as required.