<- AIMs requiring profiles   Go t o ToC  JSON Syntax and Semantics->

The Attributes of Table 1 represented with 3-character codes have been found necessary to identify all Attributes of the AI Modules targets of this Technical Specification.

Table 1 – Coding of AIM Attributes

Attributes Code Attributes Code Attributes Code
Audio Object AUO Input Personal Status IPS Speaker ID SPI
Audio-Visual Scene Geometry AVG Language Preferences LGP Speech Model SPM
Avatar Model AVM Memory MEM Speech Object SPO
Body Object BDO Speech Model SPM Text Descriptors TXD
Body Descriptors BDD Object Instance ID OII Text Object TXO
Face ID FCI Point of View POV Recognised Text TXR
Face Object FCO Portable Avatar PAV Translation TRN
Face Descriptors FCD Speech Descriptors SPD Visual Object VIO

An AIM Profile is identified by:

  1. Three characters identifying the Technical Specification that specifies the AIM.
  2. Three characters identifying the AIM of that Technical Specification.
  3. The Version and Subversion of the Technical Specification.
  4. The AIM Profile-specific sequence of coded Attributes drawn from Table 3.

An AIM Profile can be validly signaled in two ways: as a list of Attributes that an AIM does or does not support by prefixing ALL and NUL to the list of Attributes to indicate whether the list refers to supported or not supported Attributes. This choice allows for a more compact signalling depending on the actual number of Attributes supported by the AIM. For instance, the Profile of a Natural Language Understanding (HMC-NLU) AIM that does not handle spatial information (see Section 8.3) can be labelled by, respectively:

MMC-NLU-V2.1(ALL-AVS-OII) List of supported Attributes
MMC-NLU-V2.1(NUL+TXO+TXR) List of unsupported Attributes

An Attribute can be characterised by Sub-Attributes. For instance, the Sub-Attributes of the Personal Status (EPS) Attribute are Text (PST), Speech (PSS), Face (PSF), and Gesture (PSG). To signal Sub-Attributes used by an AIM, the character @ is prefixed to the Attribute (EPS in the example above) followed by a list of supported Sub-Attributes each prefixed by the character #.

In the first example below, an implementation supports all Attributes of the Personal Status Display (PAF-PSD) specification, but Personal Status only supports the Speech and Face Sub-Attributes. In the second example, an implementation supports the Text, Avatar Model and Personal Status Sub-Attributes but limited to Face and Gesture (e.g., in case of a sign-language capable AIM).

PAF-PSD-V1.1(ALL@EPS#PSS#PSF) List of supported Attributes
PAF-PSD-V1.1(NUL+TXO+AVM@EPS#PSF#PSG) List of unsupported Attributes

MPAI-PRF also supports Translation-related Sub-Attributes. The Test and Speech Translation AIM’s Sub-Attributes signal which languages are supported in which direction as exemplified below:

MMC-TST-V2.1(NUL+TXO@TRN#eng->ita) Signals unsupported Attributes
MMC-TST-V2.1(ALL-ISD@TRN#kor<->fra#ger->swa) Signals supported Attributes

The first case refers to an AIM than only supports text translation from English to Italian and the second to an AIM that does not support Speech Descriptors (see Section 8.5) but supports text and speech translation from both Korean to and from French, and from German to Swahili (Table 4).

The capabilities of an AIM can thus be represented along two dimensions: the first relates to its Attributes and is called Profile and the second relates to its Sub-Attributes and is called Level. Table 2 lists the Sub-Attributes of the Personal Status and Translation Attributes:

Table 2 – Attributes and Sub-Attributes

Attribute Coded Attributes Sub-Attributes Coded Sub-Attributes
Personal Status EPS Text PST
Speech PSS
Face PSF
Gesture PSG
Translation TRN Language 3-letter codes of [6], Part 3

Important note: An AIM implementing AIM Profile signalling need not expose the interfaces of missing Attributes. If all Attributes are supported, all interfaces shall be exposed.

 

<- AIMs requiring profiles   Go t o ToC  JSON Syntax and Semantics->