Video use cases

• 1: TV search use case
• 1.1: Dialog configuration
• 1.2: TV search plugin
• 1.3: TV search resources
• 1.4: NLP configuration by OB
• 2: TV display use case
• 2.1: Dialog configuration
• 2.2: TV display plugin
• 2.3: TV display resources
• 2.4: NLP configuration by OB
• 3: TV content get info use case
• 3.1: Dialog configuration
• 3.2: TV content get info plugin
• 3.3: TV content get info resources
• 3.4: NLP configuration by OB
• 4: TV move backwards use case
• 4.1: Dialog configuration
• 4.2: TV move backwards resources
• 4.3: NLP configuration by OB
• 5: TV move forwards use case
• 5.1: Dialog configuration
• 5.2: TV move forwards resources
• 5.3: NLP configuration by OB
• 6: TV VOD EPG information use case
• 6.1: Dialog configuration
• 6.2: TV VOD EPG information plugin
• 6.3: TV VOD EPG information resources
• 6.4: NLP configuration by OB
• 7: TV none use case
• 7.1: Dialog configuration
• 7.2: TV None plugin
• 7.3: TV none resources
• 7.4: NLP configuration by OB
• 8: Audiovisual App Opening use case
• 8.1: Dialog configuration
• 8.2: Audiovisual App Opening resources
• 8.3: NLP configuration by OB
• 9: Change language use case
• 9.1: Dialog configuration
• 9.2: Change language resources
• 9.3: NLP configuration by OB
• 10: Section Show
• 10.1: Dialog configuration
• 10.2: Section Show resources
• 10.3: NLP configuration by OB
• 11: Subtitles remove use case
• 11.1: Dialog configuration
• 11.2: Subtitles remove resources
• 11.3: NLP configuration by OB
• 12: Global resources for TV use cases
• 13: Legacy Video API for Spain
• 14: Adapter request-response model v1 to v3

1 - TV search use case

TV search use case

Introduction

The TV search use case is a global experience designed and developed by Aura Global Team that allows Telefónica customers to ask Aura for TV content using a vocal interface.

Find additional information in following the documents:

• Discover the TV search specifications and the particularities of the use case development.
• Learn how to configure the generic-dialog for TV search use case.
• Access to the TV search plugin.
• Discover which are the resources used by the TV search use case.
• Find out the NLP configuration for each OB for the TV search use case.

Specifications

Kernel API

In order to resolve the user’s search request, Aura uses Video Contents normalized Kernel API.

Request-response model

TV search use case is adapted to the new request-response normalized model v3.

Available channels

Once TV search v3 use case is fully normalized, it will be available for any channel that implements normalized v3 request-response model including TV related data.

Search features

Currently, the normalized TV search use case includes basic search features and smart answers for entertainment content:

• Search by title
• Search by genre (movie, series, documentaries, programs, short films and games)
• Search by subgenre (action, scare, love, etc)
• Search by actor or director

In addition to these search features, the use case includes a contingency or fallback search mode used in case the Video Contents API does not provide any answer to Aura request. The contingency or fallback search mode could be deactivated by configuration.

🆕 As a novelty in the current release, the use case is able to provide the users with smart answers features, meaning that the entities included in the user’s requests can be included in the answer.

Therefore, the answer could be of this type: “That’s what I’ve found about [$title, $participant, $genre, $subgenre]

For example:

• The user asks for a specific title: “Play a film starring Brad Pitt”
• In previous versions, Aura sends the content provided by the API as “That’s what I’ve found for you”
• Now, the entity can be included in the answer, giving the user a most personalized answer: “That’s what I’ve found about Brad Pitt”

Current limitations

Currently, the TV search use case does not include these features:

• Request for a specific season o episode of a TV Series.
• Search content from third-parties (content must belong to Aura’s catalog).
• Search including temporary entities or time intervals.
• Search sport content based on entities.

Use case development

The TV search use case development includes these components:

Understanding features

• TV search use case intent: intent.tv.search

• TV search use case entities:

⚠️ Other entities in the user’s request are not taken into account in the searching process.

In order to understand users’ requests (utterances), Aura is trained with:

• NLP expression to recognize the user’s utterance and detect her intention.
• TV catalog in order to understand TV content (titles, actors, director) in the user’s utterance and detect them as Aura entities.
• Other content like genre or subgenre.

Use case logic

Once Aura has recognized the user’s utterance based on NLP components, the use case should be resolved based on:

• Aura Bot dialog:

  TV search is built over the generic-dialog-v3.

  • Check the section Configuration of the generic-dialog for TV search use case in order to know the required configuration for the TV search experience.

• CLF Plugin:

  Complex Logic Framework is used for the recognition of the user’s request.

  • Check here the TV search plugin.

1.1 - Dialog configuration

Configuration of the generic-dialog for TV search use case

Specific configuration

The TV search use case is triggered by the generic-dialog-v3. For this use case, the required specific configuration is set below:

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "triggerConditions": [
        {
            "intent": "intent.tv.search",
            "settings": {
                "locales": {
                    "error": [
                        "core:flc.answer.error"
                    ]
                },
                "needTvResolution": true,
                "payloadType": "tv"
            }
        }
    ],
    "onlyIn": [
        "movistar-plus",
        "set-top-box"
    ]
}

Specific values

1.2 - TV search plugin

TV search plugin

Introduction

The TV search plugin resolves the request from a user searching a video content.

It includes some key steps described in the following sections.

Validate input request

This step validates that the input request fulfills all the requirements from the input schema.

If the input data has an error the resource returned is: tv:video.model-validation.request.error.

Filter invalid entities

The TV search plugin executes the step for entities validation listed below and prepares data before resolving the request:

1. Check that season/episode entity contains a number. In other case, it removes this entity.

Entertainment Search

The search of video content is based in the received entities.

The search stage follows the following steps:

Build the search_query param

The search builds a search_query param using label values of entities to prioritize the searched video content. If the label value is null for an entity, then the canon value is used.

Entities used to search are grouped by:

• Title entities: ent.audiovisual_documental_title, ent.audiovisual_film_title, ent.audiovisual_tvseries_title and ent.audiovisual_tvshows_title
• Participant entities: ent.audiovisual_actor and ent.audiovisual_director
• Genre entities: ent.audiovisual_genre and ent.audiovisual_subgenre

The priority to search using these entities is described as follows:

1. If there are title entities and other entities, then the search_query parameter is built only using title entities.
   • For instance: title: ("Matrix" OR "La princesa prometida")
2. If there are participant entities and other entities, then the search_query parameter is built only using participant entities.
   • All entities (ent.audiovisual_actor and ent.audiovisual_director) are used for fields actor and director.
   • For instance: actor: ("Tom Cruise" OR "Martin Scorsese") OR director: ("Tom Cruise" OR "Martin Scorsese")
3. If there are genre entities and other entities, then the search_query parameter is built only using genre entities.
   • The ent.audiovisual_genre is used with the field content_category and the ent.audiovisual_subgenre with field genre.
   • For instance: content_category: ("MOV" OR "SER" OR "DOC") AND genre: ("TE" OR "AC")
4. If there are not any entities allowed, then a query param to search is not built.

With this prioritization, the system builds a search_query param that will be used to call the API video query for searching purposes.

API video query

After preparing the search_query parameter, we will make a query to the Telefonica Kernel video API by searching through all the possible fields with the remaining words. To make this API call, several parameters are needed, which are described below:

• user_id: Input data[aura_user][user_id]
• administrative_number: Input data[app_context][user][account_number]
• access_token: Input data[aura_user][access_token]
• scopes: Input data[aura_user][scopes]
• purposes: Input data[aura_user][purposes]
• device_type: Input data[app_context][device][type]
• catalog_types: List of allowed catalog types. The value can now be a list of catalog types provided by the device, as long as the values are one of the following predefined identifiers: VOD, LIVE, L7D, LCH, LSR.
• search_query: String with a custom search query based in the received entities.
• show_series: series.
• profile: Input data[app_context][user][video_profile_name]. This field may not be implemented in certain cases and this could give the error 501 Not Implemented in the video API according to the documentation. To prevent this problem we should send this field only when input data has this value.
• commercialization_types: List made by SVOD.
• max_quality: Input data[app_context][device][max_quality]

Search response

When performing a search, the following possible scenarios can occur for the response received by the search:

a. Receive an API error. The returned resource is tv:video.api.answer.error.

b. Receive no results at all. Then, it executes the contingency search if it isn’t disabled by configuration. If it is disabled by configuration, the returned resource is tv:video.search.no-results.

c. Receive a single result by searching for one title entity. The returned resource is tv:video.search.by-title.simple-result and params with the value of the title searched for.

d. Receive several results by searching for one title entity. The returned resource is tv:video.search.by-title.multiple-results and params with the value of the title searched for.

e. Receive a single result by searching for one actor/director entity. The returned resource is tv:video.search.by-participant.simple-result and params with the value of the participant searched for.

f. Receive several results by searching for one actor/director entity. The returned resource is tv:video.search.by-participant.multiple-results and params with the value of the participant searched for.

g. Receive a single result by searching for one genre entity. The returned resource is tv:video.search.by-genre.simple-result and params with the value of the genre searched for.

h. Receive several results by searching for one genre entity. The returned resource is tv:video.search.by-genre.multiple-results and params with the value of the genre searched for.

i. Receive a single result by searching for one genre and one subgenre entity. The returned resource is tv:video.search.by-subgenre.simple-result and params with the value of the genre and subgenre searched for.

j. Receive several results by searching for one genre and one subgenre entity. The returned resource is tv:video.search.by-subgenre.multiple-results and params with the value of the genre and subgenre searched for.

k. Receive a single result in all other cases. The returned resource is tv:video.search.by-default.simple-result.

l. Receive several results in all other cases. The returned resource is tv:video.search.by-default.multiple-results.

Contingency search

The contingency search is a more in-depth search to get, at least, one response. This search uses the entire utterance in every search field.

Contingency search is based on the following steps:

Normalization section

When a request is made by the user, it is possible to find certain words with no real value for Aura, so the system is not able to redirect them to obtain a response. For this reason, a list of forbidden words known as “ignore-words” will be declared, which will be eliminated.

The first step is to transform the entire utterance received as input to lowercase, removing all non-alphanumeric characters and separators. Once the utterance has been normalized, the words that belong to the list of “ignore-words” are eliminated.

This list is declared in a resource file called normalizer_rules.json. This file can be found in the following path: src.aura_clf_video.resources.[language].normalizer_rules.json Where [language] must be replaced by each language, for example: es-es.

If the language does not have the normalizer rule defined, it will be redirected to a default folder: src.aura_clf_video.resources.default.normalizer_rules.json

If, for example, the language is Spanish, the path to the resource where the normalization rules are defined will be: src.aura_clf_video.resources.es-es.normalizer_rules.json

• Normalizer rules structure It is a dictionary where all the items are declared in a list as shown below:

  {
    "ignore_items": [
      "ignore item 1",
      "ignore item 2"
    ]
  }
  

• Validation of resource content
  The normalization is done sequentially, a previous rule cannot affect a succeeding one.

  For example:

  • The utterance is “ok aura some”.
  • We define “aura” and also “ok aura” in the “ignore-words” list.
  • If we remove “aura” firstly from the original utterance, we obtain the following normalized utterance: “ok some”. In this case, “ok aura” does not have any effect.
  • In short, the correct order should be: first, remove “ok aura” and, after that, remove “aura”. In this case, we will obtain the final utterance as “some”.

“Ignore-words” will be automatically validated in order to prevent this behavior in every Pull Request.

If after normalization the normalized phrase is empty, the resource returned is: tv:video.search.contingency.no-results

API video query

After normalizing, we will query the Telefonica Kernel video API by searching through all possible fields with the remaining words.

To make this API call, a series of parameters are going to be needed, which are described below:

• user_id: Input data[aura_user][user_id]
• administrative_number: Input data[app_context][user][account_number]
• access_token: Input data[aura_user][access_token]
• scopes: Input data[aura_user][scopes]
• purposes: Input data[aura_user][purposes]
• device_type: Input data[app_context][device][type]
• catalog_types: List of allowed catalog types. The value can now be a list of catalog types provided by the device, as long as the values are one of the following predefined identifiers: VOD, LIVE, L7D, LCH, LSR.
• search_query: Is a joint of the normalized phrase by OR operator. Use this format to search by any fields. Example: “La resistencia Shameless” the search_query is “(La OR resistencia OR Shameless)”.
• show_series: series.
• profile: Input data[app_context][user][video_profile_name]. This field may not be implemented in some cases and this could give the error 501 Not Implemented in the video API according to the documentation. To prevent this problem, we should send this field only when input data has this value.
• commercialization_types: List made by SVOD.
• max_quality: Input data[app_context][device][max_quality]
• current_region: Input data[app_context][location][currentRegion] if exists. Otherwise, do not use this param.

Contingency search response

When performing a contingency search, there are four possible scenarios for the response received by the search:

a. Receive an API error. The returned resource is tv:video.api.answer.error

b. Receive no results at all. The returned resource is tv:video.search.contingency.no-results

c. Receive a single result. The returned resource is tv:video.search.contingency.single-result

d. Receive several results. The returned resource is tv:video.search.contingency.multiple-results

Response

The response follows this response schema.

Where:

• intent: input intent.

• entities: input entities.

• result_intent: This field is always MEDIA.SEARCH because it is the response associated to this domain.

• resources: List of response resources that includes three main parameters:

  • type: Type of the response resource.
  • name: Name of the response resource. Example: tv:video.search.contingency.single-result
  • params: This field returns any required parameter in the resource.

• payload: Information provided by the Kernel API, when we make the search request. If we receive a response. This field includes the following parameters:

  • type: The value of this field depends on the type of data included in the field data (info returned by the API):
    • If it is a value: details
    • If it is a list: content_list
  • data: It returns the information provided by the Kernel API.

• status: Final status request. this field includes field the following parameters:

  • code: Status code.
  • message: Status message, which describes the status code.
  • params: Parameter that sends details of status. This field does not appear if it is empty.

• actions: Actions to follow with the result of request.

• conditions: Condition for the actions to be applied.

1.3 - TV search resources

TV search use case resources

Introduction

The TV search use case will use three different types of resources:

• Aura Platform global resources
• Common resources for video use cases
• Specific resources for the use case: tv.search

Specific resources for the use case: tv.search

The resources associated to the TV search plugin are defined below:

1.4 - NLP configuration by OB

NLP configuration by OB

Introduction

The current document includes the configuration of the NLP model for the TV search use case in the OBs where it is available.

Brazil

The aura-nlpdata repository structure in Brazil is organized by channel: aura-nlpdata-br-[channel]. Each repository will contain the files for the available use cases in this channel.

The following configuration corresponds to the STB channel, which is included in the repository: https://github.com/Telefonica/aura-nlpdata-br-stb

Intent

intent.tv.search

Entities

• ent.audiovisual_actor
• ent.audiovisual_director
• ent.audiovisual_documental_title
• ent.audiovisual_film_title
• ent.audiovisual_genre
• ent.audiovisual_subgenre
• ent.audiovisual_tvseries_title
• ent.audiovisual_tvshow_title

Pipeline stages

The following stages of STB’s pipeline have been used to develop this UC:

• CluRecognizerWrapper
• EntityTaggerAdapterWrapper

The whole pipeline.jsonfile is available at: https://github.com/Telefonica/aura-nlpdata-br-stb/blob/master/data/pt-br/stb/pipeline.json

Spain

The TV search use case is available for three channels: Movistar Plus, Movistar Home and STB.

Intent

intent.tv.search

Entities

• ent.audiovisual_actor
• ent.audiovisual_best
• ent.audiovisual_director
• ent.audiovisual_documental_title
• ent.audiovisual_film_title
• ent.audiovisual_genre
• ent.audiovisual_most_watched
• ent.audiovisual_releases
• ent.audiovisual_sports
• ent.audiovisual_sports_circuit
• ent.audiovisual_sports_player_driver
• ent.audiovisual_sports_player_rider
• ent.audiovisual_sports_season
• ent.audiovisual_sports_season_motor
• ent.audiovisual_sports_team
• ent.audiovisual_sports_unit
• ent.audiovisual_subgenre
• ent.audiovisual_tv_episode_number
• ent.audiovisual_tv_season_number
• ent.audiovisual_tvseries_title
• ent.audiovisual_tvshow_title
• ent.device_mobile
• ent.device_tv
• ent.time_instant
• ent.time_interval
• ent.time_interval_future
• ent.time_interval_past

Pipeline stages

The following stages of STB’s pipeline have been used to develop this UC:

• CluRecognizerWrapper
• PygrapeGrammarWrapper
• EntityTaggerAdapterWrapper

The whole pipeline.json files can be checked here for each channel:

• Movistar Plus: https://github.com/Telefonica/aura-nlpdata-es/blob/master/data/es-es/mp/pipeline.json
• Movistar Home: https://github.com/Telefonica/aura-nlpdata-es/blob/master/data/es-es/mh/pipeline.json
• STB: https://github.com/Telefonica/aura-nlpdata-es/blob/master/data/es-es/stb/pipeline.json

2 - TV display use case

TV display use case

Introduction

The TV display use case is a global experience designed and developed by Aura Global Team that allows Telefónica customers to ask Aura for a TV channel or other entities using a vocal interface.

Find additional information in following the documents:

• Discover the TV display specifications and the particularities of the use case development.
• Learn how to configure the generic-dialog for TV display use case.
• Access to the TV display plugin.
• Discover which are the resources used by the TV display use case.
• Find out the NLP configuration for each OB for the TV display use case.

Specifications

Kernel API

In order to resolve the user’s display request, Aura uses Video Contents normalized Kernel API.

Request-response model

TV display use case is adapted to the new request-response normalized model v3.

Available channels

Once TV display v3 use case is fully normalized, it will be available for any channel that implements normalized v3 request-response model including TV related data.

Display features

Currently, the normalized TV display use case includes the following display features:

• Display by channel (both for Brazil and Spain OBs)
• Display by content: title, genre, subgenre, actor or director (for Spain OB)

Therefore, the answer could be of this type: “This is what they are broadcasting now on that channel”

Use case development

The TV display use case development includes these components:

Understanding features

• TV display use case intent: intent.tv.display

• TV display use case entities: Entities vary across the OBs where this experience is available: Check NLP configuration by OB.

In order to understand users’ requests (utterances), Aura is trained with:

• NLP expression to recognize the user’s utterance and detect her intention.
• TV catalog in order to understand TV content (channels, titles, genres, subgenres, actors, directors) in the user’s utterance and detect them as Aura entities.

Use case logic

Once Aura has recognized the user’s utterance based on NLP components, the use case should be resolved based on:

• Aura Bot dialog:

  TV display is built over the generic-dialog-v3.

  • Check the section Configuration of the generic-dialog for TV display use case in order to know the required configuration for the TV display experience.

• CLF Plugin:

  Complex Logic Framework is used for the recognition of the user’s request.

  • Check here the TV display plugin.

2.1 - Dialog configuration

Configuration of the generic-dialog for TV display use case

Specific configuration

The TV display use case is triggered by the generic-dialog-v3. For this use case, the required specific configuration is set below:

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "triggerConditions": [
        {
            "intent": "intent.tv.display",
            "settings": {
                "locales": {
                    "error": [
                        "core:flc.answer.error"
                    ]
                },
                "needTvResolution": true
            }
        }
    ],
    "onlyIn": [
        "movistar-plus",
        "set-top-box"
    ]
}

Specific values

2.2 - TV display plugin

TV display plugin

Introduction

The TV display plugin resolves the request from a user displaying a channel or content.

It includes some key steps described in the following sections.

Validate input request

This step validates that the input request fulfills all the requirements from the input schema.

If the input data has an error, the resource returned is:
tv:video.model-validation.request.error.

Display channel or content

The display channel or content is based in the received entities.

The display stage follows the steps set below:

Build the search_query param

The display plugin builds a search_query param using label values of entities to prioritize the searched channel content or video content. If the label value is null for an entity, then the canon value is used.

Entities used to search are grouped by:

• Channel entities: ent.audiovisual_channel
• Title entities: ent.audiovisual_documental_title, ent.audiovisual_film_title, ent.audiovisual_tvseries_title and ent.audiovisual_tvshow_title
• Participant entities: ent.audiovisual_actor and ent.audiovisual_director
• Genre entities: ent.audiovisual_genre and ent.audiovisual_subgenre

The priority to search using these entities is described as follows:

1. If there are channel entities and other entities, then the search_query parameter is built only using the first channel entity.
   • For instance: channel_name: "La 1"
2. If there are title entities and other entities, then the search_query parameter is built only using title entities.
   • For instance: title: ("Matrix" OR "La princesa prometida")
3. If there are participant entities and other entities, then the search_query parameter is built only using participant entities.
   • All entities (ent.audiovisual_actor and ent.audiovisual_director) are used for fields actor and director.
   • For instance: actor: ("Tom Cruise" OR "Martin Scorsese") OR director: ("Tom Cruise" OR "Martin Scorsese")
4. If there are genre entities and other entities, then the search_query parameter is built only using genre entities.
   • The ent.audiovisual_genre is used with the field content_category and the ent.audiovisual_subgenre with field genre.
   • For instance: content_category: ("MOV" OR "SER" OR "DOC") AND genre: ("Terror" OR "Acción")
5. If there are not any entities allowed, then a query param to search is not built.

With this prioritization, the system builds a search_query param that will be used to call the API video query for searching purposes.

Video query API

After preparing the search_query parameter, we will make a query to Video Contents normalized Kernel API by searching through all the possible fields with the remaining words.

To make this API call, several parameters are needed, which are described below:

• user_id: Input data[aura_user][user_id]
• administrative_number: Input data[app_context][user][account_number]
• access_token: Input data[aura_user][access_token]
• scopes: Input data[aura_user][scopes]
• purposes: Input data[aura_user][purposes]
• device_type: Input data[app_context][device][type]
• catalog_types: use LIVE value if there are channel entities, else use VOD,LIVE,L7D value for title entities, participant entities or genre entities.
• search_query: String with a custom search query based in the received entities.
• show_series: series.
• commercialization_types: List made by SVOD.
• max_quality: Input data[app_context][device][max_quality]
• order: personal
• commercial_offer: Input data[app_context][user][profile] if exists. Otherwise, do not use this param.
• live_at: if there are channel entities use UTC current time at which the request is made. Otherwise, do not use this param.
• profile: Input data[app_context][user][video_profile_name] if exists. Otherwise, do not use this param.
• current_region: Input data[app_context][location][currentRegion] if exists. Otherwise, do not use this param.

The fields current_region and profile may not be implemented in certain cases and this could give the error 501 Not Implemented in the video API according to the documentation. To prevent this problem, we should send these fields only when input data has this value.

Display response

When a user requests for displaying a channel, the following possible scenarios can occur for the response:

a. Receive no results at all. Then, it executes the contingency search.

b. Receive content with channel info. The returned resource is tv:video.display.by-channel.single-result

c. Receive content with channel info has already been broadcast or recieve a video content. The returned resource is video.display.by-default.single-result

d. Receive content with channel info that has not been broadcast yet or the content does not have enough information to be played. The returned resource is video.display.by-default.detail-result

e. Receive more than one type of content with channel info or video content. The returned resource is tv:video.display.by-default.multiple-results

f. Receive an API error. The returned resource is tv:video.api.answer.error

Contingency search

The contingency search is a more in-depth search to get, at least, one response. This search uses the entire utterance in every search field.

Contingency search is based on the following steps:

Normalization section

When a request is made by the user, it is possible to find certain words with no real value for Aura, so the system is not able to redirect them to obtain a response. For this reason, a list of forbidden words known as “ignore-words” will be declared, which will be eliminated.

The first step is to transform the entire utterance received as input to lowercase, removing all non-alphanumeric characters and separators. Once the utterance has been normalized, the words that belong to the list of “ignore-words” are eliminated.

This list is declared in a resource file called normalizer_rules.json. This file can be found in the following path: src.aura_clf_video.resources.[language].normalizer_rules.json Where [language] must be replaced by each language, for example: es-es.

If the language does not have the normalizer rule defined, it will be redirected to a default folder: src.aura_clf_video.resources.default.normalizer_rules.json

If, for example, the language is Spanish, the path to the resource where the normalization rules are defined will be: src.aura_clf_video.resources.es-es.normalizer_rules.json

• Normalizer rules structure It is a dictionary where all the items are declared in a list as shown below:

  {
    "ignore_items": [
      "ignore item 1",
      "ignore item 2"
    ]
  }
  

• Validation of resource content
  The normalization is done sequentially, a previous rule cannot affect a succeeding one.

  For example:

  • The utterance is “ok aura some”.
  • We define “aura” and also “ok aura” in the “ignore-words” list.
  • If we remove “aura” firstly from the original utterance, we obtain the following normalized utterance: “ok some”. In this case, “ok aura” does not have any effect.
  • In short, the correct order should be: first, remove “ok aura” and, after that, remove “aura”. In this case, we will obtain the final utterance as “some”.

“Ignore-words” will be automatically validated in order to prevent this behavior in every Pull Request.

If after normalization the normalized phrase is empty, the resource returned is: tv:video.display.contingency.no-results

API video query

After normalizing, we will query the Telefonica Kernel video API by searching through all possible fields with the remaining words.

To make this API call, a series of parameters are going to be needed, which are described below:

• user_id: Input data[aura_user][user_id]
• administrative_number: Input data[app_context][user][account_number]
• access_token: Input data[aura_user][access_token]
• scopes: Input data[aura_user][scopes]
• purposes: Input data[aura_user][purposes]
• device_type: Input data[app_context][device][type]
• catalog_types: List that is made by VOD, LIVE and L7D.
• search_query: Is a joint of the normalized phrase by OR operator. Use this format to search by any fields. Example: “La resistencia Shameless” the search_query is “(La OR resistencia OR Shameless)”.
• show_series: series.
• profile: Input data[app_context][user][video_profile_name]. This field may not be implemented in some cases and this could give the error 501 Not Implemented in the video API according to the documentation. To prevent this problem, we should send this field only when input data has this value.
• commercialization_types: List made by SVOD.
• max_quality: Input data[app_context][device][max_quality]
• order: personal
• current_region: Input data[app_context][location][currentRegion] if exists. Otherwise, do not use this param.

Contingency search response

When performing a contingency search, there are four possible scenarios for the response received by the search:

a. Receive an API error. The returned resource is tv:video.api.answer.error

b. Receive no results at all. The returned resource is tv:video.display.contingency.no-results

c. Receive a single result. The returned resource is tv:video.display.contingency.single-result

d. Receive several results. The returned resource is tv:video.display.contingency.multiple-results

Response

The response follows this response schema.

Where:

• intent: input intent.

• entities: input entities.

• result_intent: This field is always MEDIA.SEARCH except when the resource is:

  • video.display.by-channel.single-result, then the field value is CHANNEL.PLAY
  • video.display.by-default.single-result, then the field value is CONTENT.PLAY

• resources: List of response resources that includes three main parameters:

  • type: Type of the response resource.
  • name: Name of the response resource. Example: tv:video.display.by-channel.single-result
  • params: This field returns any required parameter in the resource.

• payload: Information provided by the Kernel API, when we make the display request. If we receive a response, this field includes the following parameters:

  • type: The value of this field depends on the type of data included in the field data (info returned by the API):
    • If it is a value: details
    • If it is a list: content_list
  • data: It returns the information provided by the Kernel API.

• status: Final status request. This field includes the following parameters:

  • code: Status code.
  • message: Status message, which describes the status code.
  • params: Parameter that sends details of status. This field does not appear if it is empty.

• actions: Actions to follow with the result of request. This plugin could include the following actions:

  • REMOTEON.ZAPTO: The target for this action is stb and its parameters are:
    • channelId, channelNumber and deviceId when we have the resource tv:video.display.by-channel.single-result
  • REMOTEON.PLAYTO: The target for this action is stb and its parameters are:
    • contentId, deviceId, liveProgramId and catalogType when we have the resource video.display.by-default.single-result and content has already been broadcast.
    • contentId, deviceId and catalogType when we have the resource video.display.by-default.single-result and content is a video content.
  • MAKE_SOUND: The target for this action is channel and its unique parameter is sound with the value:
    • positive when we have the resource tv:video.display.by-channel.single-result, video.display.by-default.single-result, video.display.by-default.detail-result, tv:video.display.by-default.multiple-results, tv:video.display.contingency.single-result, tv:video.display.contingency.multiple-results
    • negative when we have the resource tv:video.display.contingency.no-results and tv:video.api.answer.error.

• conditions: Condition for the actions to be applied.

2.3 - TV display resources

TV display use case resources

Introduction

The TV display use case will use three different types of resources:

• Aura Platform global resources
• Common resources for video use cases
• Specific resources for the use case: tv.display

Specific resources for the use case: tv.display

The resources associated to the TV display plugin are defined below:

2.4 - NLP configuration by OB

NLP configuration by OB

Introduction

The current document includes the configuration of the NLP model for the normalized TV display use case in the OBs where it is available.

Brazil

The aura-nlpdata repository structure in Brazil is organized by channel: aura-nlpdata-br-[channel]. Each repository will contain the files for the available use cases in this channel.

The following configuration corresponds to the STB channel, which is included in the repository: https://github.com/Telefonica/aura-nlpdata-br-stb

Intent

intent.tv.display

Entities

| ent.audiovisual_channel | “Quiero ver La 1” |

Pipeline stages

The following stages of STB’s pipeline have been used to develop this UC:

• CluRecognizerWrapper
• PygrapeGrammarWrapper
• EntityTaggerAdapterWrapper

The whole pipeline.jsonfile is available at: https://github.com/Telefonica/aura-nlpdata-br-stb/blob/master/data/pt-br/stb/pipeline.json

Spain

The TV display use case is available for three channels: Movistar Plus, Movistar Home and STB.

Intent

intent.tv.display

Entities

| ent.audiovisual_channel | “Quiero ver La 1” | | ent.audiovisual_*_title | “Ver Titanic” | | ent.audiovisual_subgenre | “Pon esta comedia” | | ent.audiovisual_genre | “Pon la película” | | ent.audiovisual_actor | “Quiero ver la peli de Brad Pitt” | | ent.audiovisual_director | “Ver el documental de Almodóvar” |

Pipeline stages

The following stages of STB’s pipeline have been used to develop this UC:

• CluRecognizerWrapper
• PygrapeGrammarWrapper
• EntityTaggerAdapterWrapper

The whole pipeline.json files can be checked here for each channel:

• Movistar Plus: https://github.com/Telefonica/aura-nlpdata-es/blob/master/data/es-es/mp/pipeline.json
• Movistar Home: https://github.com/Telefonica/aura-nlpdata-es/blob/master/data/es-es/mh/pipeline.json
• STB: https://github.com/Telefonica/aura-nlpdata-es/blob/master/data/es-es/stb/pipeline.json

3 - TV content get info use case

TV content get info use case

Introduction

The TV content get info use case is a global experience designed and developed by Aura Global Team that allows Telefónica customers to ask Aura for a TV channel information using a vocal interface.

Find additional information in following the documents:

• Discover the TV content get info specifications and the particularities of the use case development.
• Learn how to configure the generic dialog for TV content get info use case.
• Access to the TV content get info plugin.
• Discover which are the resources used by the TV content get info use case.
• Find out the NLP configuration for each OB for the TV content get info use case.

Specifications

Kernel API

In order to resolve the user’s request, Aura uses Video Contents normalized Kernel API.

Request-response model

TV content get info use case is adapted to the new request-response normalized model v3.

Available channels

Once TV content get info v3 use case is fully normalized, it will be available for any channel that implements normalized v3 request-response model including TV related data.

Currently, STB channels in ES are already available.

Display features

Currently, the normalized TV content get info use case includes basic get content information features for channels:

• Content get info by channel

Therefore, the answer could be of this type: “This is what they are broadcasting now on that channel”

Use case development

The TV content get info use case development includes these components:

Understanding features

• TV content get info use case intent: intent.tv.content_get_info

• TV content get info use case entities:

⚠️ Other entities in the user’s request are not taken into account in the get content info process.

In order to understand users’ requests (utterances), Aura is trained with:

• NLP expression to recognize the user’s utterance and detect her intention.
• TV catalog in order to understand TV content (channels) in the user’s utterance and detect them as Aura entities.

Use case logic

Once Aura has recognized the user’s utterance based on NLP components, the use case should be resolved based on:

• Aura Bot dialog:

  TV content get info is built over the generic dialog v3.

  • Check the section Configuration of the generic dialog for TV content get info use case in order to know the required configuration for the TV content get info experience.

• CLF Plugin:

  Complex Logic Framework is used for the recognition of the user’s request.

  • Check here the TV content get info plugin.

3.1 - Dialog configuration

Configuration of the generic dialog for TV content get info use case

Specific configuration

The TV content get info use case is triggered by the generic dialog v3. For this use case, the required specific configuration is set below:

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "triggerConditions": [
        {
            "intent": "intent.tv.content_get_info",
            "settings": {
                "locales": {
                    "error": [
                        "core:flc.answer.error"
                    ]
                },
                "needTvResolution": true
            }
        }
    ],
    "onlyIn": [
        "movistar-plus",
        "set-top-box"
    ]
}

Specific values

3.2 - TV content get info plugin

TV content get info plugin

Introduction

The TV content get info plugin resolves the request from a user getting information about channel.

It includes some key steps described in the following sections.

Validate input request

This step validates that the input request fulfills all the requirements from the input schema.

If the input data has an error, the resource returned is:
tv:video.model-validation.request.error.

Get content info about a channel

The content get info about a channel is based in the received entities.

The content get info stage follows the steps set below:

Build the search_query param

The content get info builds a search_query param using label values of first entity ent.audiovisual_channel to prioritize channels searching. If the label value is null for an entity, then the canon value is used.

Entity used to search is: ent.audiovisual_channel

The entity will be used as follows:

1. If there are channel entities and other entities, then the search_query parameter is built only using the first channel entity.
   • For instance: channel_name: "La 1"
2. If there are not entities allowed, then a query param to content get info is not built.

With this prioritization, the system builds a search_query param that will be used to call the video query API for searching purposes.

Video query API

After preparing the search_query parameter, we will make a query to Video Contents normalized Kernel API by searching through all the possible fields with the remaining words.

To make this API call, several parameters are needed, which are described below:

• user_id: Input data[aura_user][user_id]
• administrative_number: Input data[app_context][user][account_number]
• access_token: Input data[aura_user][access_token]
• scopes: Input data[aura_user][scopes]
• purposes: Input data[aura_user][purposes]
• device_type: Input data[app_context][device][type]
• catalog_types: LIVE.
• search_query: String with a custom search query based in the received entities.
• show_series: series.
• commercialization_types: List made by SVOD.
• max_quality: Input data[app_context][device][max_quality]
• order: personal
• commercial_offer: Input data[app_context][user][profile] if exists. Otherwise, do not use this param.
• live_at: UTC current time at which the request is made.
• profile: Input data[app_context][user][video_profile_name] if exists. Otherwise, do not use this param.
• current_region: Input data[app_context][location][currentRegion] if exists. Otherwise, do not use this param.

The fields current_region and profile may not be implemented in certain cases and this could give the error 501 Not Implemented in the video API according to the documentation. To prevent this problem, we should send these fields only when input data has this value.

Content get info response

When a user requests for getting content information about a channel, the following possible scenarios can occur for the response:

a. No content with channel info is received. The returned resource is tv:video.content-get-info.by-channel.no-results

b. Receive content with channel info. The returned resource is tv:video.content-get-info.by-channel.single-result

c. More than one type of content is received. The returned resource is tv:video.content-get-info.by-channel.multiple-results

d. The request does not contain any ent.audiovisual_channel entity. The returned resource is tv:video.content-get-info.by-channel.no-results

e. Receive an API error. The returned resource is tv:video.api.answer.error

Response

The response follows this response schema.

Where:

• intent: input intent.

• entities: input entities.

• result_intent: This field is always MEDIA.SEARCH.

• resources: List of response resources that includes three main parameters:

  • type: Type of the response resource.
  • name: Name of the response resource. Example: tv:video.content-get-info.by-channel.single-result
  • params: This field returns any required parameter in the resource.

• payload: Information provided by the Kernel API, when we make the content get info request. If we receive a response, this field includes the following parameters:

  • type: The value of this field depends on the type of data included in the field data (info returned by the API):
    • If it is a value: details
    • If it is a list: content_list
  • data: It returns the information provided by the Kernel API.

• status: Final status request. This field includes the following parameters:

  • code: Status code.
  • message: Status message, which describes the status code.
  • params: Parameter that sends details of status. This field does not appear if it is empty.

• actions: Actions to follow with the result of request. This plugin could include the following actions:

  • MAKE_SOUND: The target for this action is channel and its unique parameter is sound (with negative value assigned). This action is returned when we have the resource tv:video.content-get-info.by-channel.no-results

• conditions: Condition for the actions to be applied.

3.3 - TV content get info resources

TV content get info use case resources

The TV content get info use case will use three different types of resources:

• Aura Platform global resources
• Common resources for video use cases
• Specific resources for the use case: tv.content_get_info

Specific resources for the use case: tv.content_get_info

The resources associated to the TV content get info plugin are defined below:

3.4 - NLP configuration by OB

NLP configuration by OB

Introduction

The current document includes the configuration of the NLP model for the TV content get info use case in the OBs where it is available.

Brazil

The aura-nlpdata repository structure in Brazil is organized by channel: aura-nlpdata-br-[channel]. Each repository will contain the files for the available use cases in this channel.

The following configuration corresponds to the STB channel, which is included in the repository: https://github.com/Telefonica/aura-nlpdata-br-stb

Intent

intent.tv.content_get_info

Entities

• ent.audiovisual_actor
• ent.audiovisual_actor
• ent.audiovisual_best
• ent.audiovisual_channel
• ent.audiovisual_director
• ent.audiovisual_documental_title
• ent.audiovisual_film_title
• ent.audiovisual_genre
• ent.audiovisual_most_watched
• ent.audiovisual_releases
• ent.audiovisual_sports
• ent.audiovisual_sports_circuit
• ent.audiovisual_sports_player_driver
• ent.audiovisual_sports_player_rider
• ent.audiovisual_sports_season
• ent.audiovisual_sports_season_motor
• ent.audiovisual_sports_team
• ent.audiovisual_sports_unit
• ent.audiovisual_subgenre
• ent.audiovisual_tv_episode_number
• ent.audiovisual_tv_season_number
• ent.audiovisual_tvseries_title
• ent.audiovisual_tvshow_title
• ent.device_mobile
• ent.device_tv
• ent.time_instant
• ent.time_interval
• ent.time_interval_future
• ent.time_interval_past

Pipeline stages

The following stages of STB’s pipeline have been used to develop this UC:

• PygrapeGrammarWrapper
• EntityTaggerAdapterWrapper

The whole pipeline.jsonfile is available at: https://github.com/Telefonica/aura-nlpdata-br-stb/blob/master/data/pt-br/stb/pipeline.json

4 - TV move backwards use case

TV move backwards use case

Introduction

The TV move backwards use case is a global experience designed and developed by Aura Global Team that allows Telefónica customers to move the content backwards on the TV using a vocal interface.

Find additional information in following the documents:

• Learn how to configure the generic dialog for TV move backwards use case.
• Discover which are the resources used by the TV move backwards use case.
• Find out the NLP configuration for each OB for the TV move backwards use case.

Specifications

Request-response model

TV move backwards use case is adapted to the new request-response normalized model v3.

Available channels

Once TV move backwards v3 use case is fully normalized, it will be available for any channel that implements normalized v3 request-response model including TV related data.

Currently, STB channel in ES is available for channelData V1. And channelData V3 is suitable for STB in Brazil with time entity recognition: ent.time_length_hour.

Display features

Currently, the normalized TV move backwards use case includes basic move backwards features for some entities:

• Move the TV content backwards
• Move backwards by specifying the desired time

This UC also includes specific verbs without entities. For AP repository the key verbs are: “retroceder”, “retornar” and “rebobinar”. For Brazil, they are “recuar” and “retroceder”.

Therefore, the answer could be of this type: “Okay, I’ll rewind the TV content.”

Use case development

The TV move backwards use case development includes these components:

Understanding features

• TV move backwards use case intent: intent.tv.move_backwards

• TV move backwards use case entities:

⚠️ Other entities in the user’s request are not taken into account in the move backwards process.

In order to understand users’ requests (utterances), Aura is trained with:

• NLP expression to recognize the user’s utterance and detect the user’s intention.

Use case logic

Once Aura has recognized the user’s utterance based on NLP components, the use case should be resolved based on:

• Aura Bot dialog:

  TV move backwards is built over the generic dialog v3.

  • Check the section Configuration of the generic dialog for TV move backwards use case in order to know the required configuration for the TV move backwards experience.

4.1 - Dialog configuration

Configuration of the generic dialog for TV move backwards use case

Specific configuration

The TV move backwards use case is triggered by the generic dialog v3. For this use case, the required specific configuration is set below:

• Configuration for Brazil OB in STB channel. In this configuration, no default value is defined, as the STB device will resolve it when receiving an empty value in the parameter levels. A new entity is now recognized: ent.time_length_hour. Additional recognition was required by the aura-bot in order to obtain the total number of seconds to be returned in the parameter levels. To obtain that convertion into seconds, a new function has been created in utiles called: getSecondsLevelsWithTimerRecognizer.

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "suggestions": false,
    "triggerConditions": [
        {
            "intent": "intent.tv.move_backwards",
            "settings": {
                "locales": {
                    "success": [
                        "tv:tv.moveBackwards"
                    ],
                    "error": [
                        "core:flc.answer.error"
                    ]
                },
                "actions": [
                    {
                        "name": "SEND_KEY"
                    },
                    {
                        "name": "MAKE_SOUND"
                    }
                ],
                "payloadType": "tv",
                "functions": {
                    "params": [
                        "currentIntent",
                        "persistentData",
                        "genericUtils",
                        "configuration"
                    ],
                    "algorithm": "return new Promise(async (resolve, reject) => { try { const params = { levels: await genericUtils.getSecondsLevelsWithTimerRecognizer(currentIntent, configuration) }; persistentData.dialogData.actionParams['SEND_KEY'] = params; resolve(); } catch (error) { reject(error); } });"
                }
            }
        }
    ],
    "onlyIn": [
        "set-top-box"
    ]
}

4.2 - TV move backwards resources

TV move backwards use case resources

The TV move backwards use case will use two different types of resources:

• Aura Platform global resources
• Common resources for video use cases

4.3 - NLP configuration by OB

NLP configuration by OB

Introduction

The current document includes the configuration of the NLP model for the TV move backwards use case in the OBs where it is available.

Brazil

The aura-nlpdata repository structure in Brazil is organized by channel: aura-nlpdata-br-[channel]. Each repository will contain the files for the available use cases in this channel.

The following configuration corresponds to the STB channel, which is included in the repository: https://github.com/Telefonica/aura-nlpdata-br-stb

Intent

intent.tv.move_backwards

Entities

• ent.audiovisual_genre
• ent.time_length_sec
• ent.time_length_min
• ent.time_length_hour
• ent.time_instant

Pipeline stages

The following stages of STB’s pipeline have been used to develop this UC:

• PygrapeGrammarWrapper
• EntityTaggerAdapterWrapper

The whole pipeline.jsonfile is available at: https://github.com/Telefonica/aura-nlpdata-br-stb/blob/master/data/pt-br/stb/pipeline.json

5 - TV move forwards use case

TV move forwards use case

Introduction

The TV move forwards use case is a global experience designed and developed by Aura Global Team that allows Telefónica customers to move the content forwards on the TV using a vocal interface.

Find additional information in following the documents:

• Learn how to configure the generic dialog for TV move forwards use case.
• Discover which are the resources used by the TV move forwards use case.
• Find out the NLP configuration for each OB for the TV move forwards use case.

Specifications

Request-response model

TV move forwards use case is adapted to the new request-response normalized model v3.

Available channels

Once TV move forwards v3 use case is fully normalized, it will be available for any channel that implements normalized v3 request-response model including TV related data.

Currently, MH and STB channels in ES are already available for channelData V3 version and MP is available for channelData V1. But for these channels, time entity recognition: ent.time_length_hour is not yet available. It would be available for STB in Brazil.

Display features

Currently, the normalized TV move forwards use case includes basic move forwards features for some entities:

• Move the TV content forwards
• Move forwards by specifying the desired time

This UC also includes specific verbs without entities. For AP repository the key verbs are: “avanzar” and “adelantar”. For Brazil, they are “adiantar” and “avançar”.

Therefore, the answer could be of this type: “Ok, I’ll fast forward the content a little”

Use case development

The TV move forwards use case development includes these components:

Understanding features

• TV move forwards use case intent: intent.tv.move_forwards

• TV move forwards use case entities:

⚠️ Other entities in the user’s request are not taken into account in the move forwards process.

In order to understand users’ requests (utterances), Aura is trained with:

• NLP expression to recognize the user’s utterance and detect the user’s intention.

Use case logic

Once Aura has recognized the user’s utterance based on NLP components, the use case should be resolved based on:

• Aura Bot dialog:

  TV move forwards is built over the generic dialog v3.

  • Check the section Configuration of the generic dialog for TV move forwards use case in order to know the required configuration for the TV move forwards experience.

5.1 - Dialog configuration

Configuration of the generic dialog for TV move forwards use case

Specific configuration

The TV move forwards use case is triggered by the generic dialog v3. For this use case, the required specific configuration is set below:

• Configuration for Spain OB in MP, MH and STB channels. In this configuration, there is still a default value of 60 seconds if no time entity is identified. Only the minutes and seconds entities are handled.

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "suggestions": false,
    "triggerConditions": [
        {
            "intent": "intent.tv.move_forwards",
            "settings": {
                "locales": {
                    "success": [
                        "tv:tv.moveForwards"
                    ],
                    "error": [
                        "core:flc.answer.error"
                    ]
                },
                "actions": [
                    {
                        "name": "SEND_KEY",
                        "params": {
                            "keyCode": "MOVE_FORWARD",
                            "levels": "60"
                        }
                    },
                    {
                        "name": "MAKE_SOUND"
                    }
                ],
                "payloadType": "tv",
                "functions": {
                    "params": [
                        "currentIntent",
                        "persistentData"
                    ],
                    "algorithm": "currentIntent.entities.map((ent) => { if (!isNaN(ent.entity)) { persistentData.dialogData.actionParams.SEND_KEY = { levels: ent.type === 'ent.time_length_sec' ? Number(ent.entity) : Number(ent.entity) * 60}}})"
                }
            }
        }
    ],
    "onlyIn": [
        "movistar-plus",
        "set-top-box"
    ]
}

• Configuration for Brazil OB in STB channel. In this configuration, no default value is defined, as the STB device will resolve it when receiving an empty value in the parameter levels. A new entity is now recognized: ent.time_length_hour. Additional recognition was required by the aura-bot in order to obtain the total number of seconds to be returned in the parameter levels. To obtain that convertion into seconds, a new function has been created in utiles called: getSecondsLevelsWithTimerRecognizer.

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "suggestions": false,
    "triggerConditions": [
        {
            "intent": "intent.tv.move_forwards",
            "settings": {
                "locales": {
                    "success": [
                        "tv:tv.moveForwards"
                    ],
                    "error": [
                        "core:flc.answer.error"
                    ]
                },
                "actions": [
                    {
                        "name": "SEND_KEY"
                    },
                    {
                        "name": "MAKE_SOUND"
                    }
                ],
                "payloadType": "tv",
                "functions": {
                    "params": [
                        "currentIntent",
                        "persistentData",
                        "genericUtils",
                        "configuration"
                    ],
                    "algorithm": "return new Promise(async (resolve, reject) => { try { const params = { levels: await genericUtils.getSecondsLevelsWithTimerRecognizer(currentIntent, configuration) }; persistentData.dialogData.actionParams['SEND_KEY'] = params; resolve(); } catch (error) { reject(error); } });"
                }
            }
        }
    ],
    "onlyIn": [
        "set-top-box"
    ]
}

5.2 - TV move forwards resources

TV move forwards use case resources

The TV move forwards use case will use two different types of resources:

• Aura Platform global resources
• Common resources for video use cases

5.3 - NLP configuration by OB

NLP configuration by OB

Introduction

The current document includes the configuration of the NLP model for the TV move forwards use case in the OBs where it is available.

Brazil

The aura-nlpdata repository structure in Brazil is organized by channel: aura-nlpdata-br-[channel]. Each repository will contain the files for the available use cases in this channel.

The following configuration corresponds to the STB channel, which is included in the repository: https://github.com/Telefonica/aura-nlpdata-br-stb

Intent

intent.tv.move_forwards

Entities

• ent.audiovisual_genre
• ent.time_length_sec
• ent.time_length_min
• ent.time_length_hour
• ent.time_instant

Pipeline stages

The following stages of STB’s pipeline have been used to develop this UC:

• PygrapeGrammarWrapper
• EntityTaggerAdapterWrapper

The whole pipeline.jsonfile is available at: https://github.com/Telefonica/aura-nlpdata-br-stb/blob/master/data/pt-br/stb/pipeline.json

6 - TV VOD EPG information use case

TV VOD EPG information use case

Introduction

The TV VOD EPG information use case is a global experience designed and developed by Aura Global Team that allows Telefónica customers to ask Aura about what they are watching on TV at that specific moment using a vocal interface. The use case answers with the name of the TV content being broadcasted.

• A user interacts with Aura through a normalized video channel
• She asks about the content currently playing: “What am I watching?”, “What’s on?”
• Aura recognizes the request and provides back to the channel the information required to answer the request

Find additional information in following the documents:

• Discover the TV VOD EPG information specifications and the particularities of the use case development.

• Learn how to configure the generic dialog for TV VOD EPG information use case.

• Find out the NLP configuration for each OB for the TV VOD EPG information use case.

Specifications

Kernel API

In order to resolve the user’s request, Aura uses Video Contents normalized Kernel API.

Request-response model

TV VOD EPG information use case is adapted to the new request-response normalized model v3.

Available channels

TV VOD EPG information use case could be available for any channel that implements normalized v3 request-response model including TV related data.

Currently, STB channels in BR are already available.

Display features

Currently, the normalized TV VOD EPG information use case includes basic VOD EPG information features for content:

• VOD EPG information by content

Therefore, the questions could be of this type: “What am I watching?” “Which actors are involved?”

Use case development

The TV VOD EPG information use case development includes these components:

Understanding features

• TV VOD EPG information use case intent: intent.tv-vod_epg_information

• TV VOD EPG information use case entities:

In order to understand users’ requests (utterances), Aura is trained with:

• NLP expression to recognize the user’s utterance and detect the user’s intention.

Use case logic

Once Aura has recognized the user’s utterance based on NLP components, the use case should be resolved based on:

• Aura Bot dialog:

  TV VOD EPG information is built over the generic dialog v3.

  • Check the section Configuration of the generic dialog for TV VOD EPG information use case in order to know the required configuration for the TV VOD EPG information experience.

6.1 - Dialog configuration

Configuration of the generic dialog for TV VOD EPG information use case

Specific configuration

The TV VOD EPG information use case is triggered by the generic dialog v3. For this use case, the required specific configuration is set below:

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "triggerConditions": [
        {
            "intent": "intent.tv.vod_epg_information",
            "settings": {
                "locales": {
                    "error": [
                        "core:flc.answer.error"
                    ]
                },
                "payloadType" : "tv",
                "functions" : {
                    "params" : [
                        "currentIntent",
                        "persistentData"
                    ],
                    "algorithm" : "const entityType = currentIntent?.entities?.[0]?.type; switch (entityType) { case 'ent.device_tv': case 'ent.device_mobile': case 'ent.device_phone': persistentData.dialogData.dialogSetting.forcedIntentResult = { name: 'MEDIA.SHEET_TV', entities: [ { type: entityType, entity: currentIntent.entities?.[0]?.entity } ] }; break; default: persistentData.dialogData.dialogSetting.forcedIntentResult = { name: 'MEDIA.SHEET_SECOND_SCREEN', entities: [] }; break; }"
                }
            }
        }
    ],
    "onlyIn": [
        "set-top-box"
    ]
}

Specific values

6.2 - TV VOD EPG information plugin

TV VOD EPG information plugin

Introduction

The TV VOD EPG information plugin resolves the request from a user getting information about the TV content broadcasted in this specific moment

It includes some key steps described in the following sections.

Validate input request

This step validates that the input request fulfills all the requirements from the input schema.

If the input data has an error, the resource returned is:
tv:video.model-validation.request.error.

Get VOD EPG information about a playing content

The VOD EPG information about a playing content is based in the catalog type and content id.

To retrieve content information stage follows the steps set below:

Video query API

We will make a query to Video Contents normalized Kernel API to retrieve content.

To make this API call, several parameters are needed, which are described below:

• user_id: Input data[aura_user][user_id]
• access_token: Input data[aura_user][access_token]
• catalog_type: Input data[app_context][playing][catalog_type] where “vod” is “VOD”, “l7d” and “record” is “L7D”, and “live” is “LIVE”.
• administrative_number: Input data[app_context][user][account_number]
• content_id: Input data[app_context][playing][content_id]
• scopes: Input data[aura_user][scopes]
• purposes: Input data[aura_user][purposes]
• device_type: Input data[app_context][device][type]

VOD EPG information response

When a user requests for getting playing EPG information about a specific content, the following possible scenarios can occur for the response:

a. Receive a content with the EPG information and the request contain devices entities (ent.device_tv, ent.device_mobile, ent.device_phone). The returned resource is tv:tv.moreInfoTvDetail

b. Receive a content with the EPG information and the request does not contain any devices entities (ent.device_tv, ent.device_mobile, ent.device_phone). The returned resource is tv:carousel.info.contentDetail

c. Not received or not found in API any content with the EPG information and the request does not contain any devices entities (ent.device_tv, ent.device_mobile, ent.device_phone). The returned resource is tv:tv.moreInfoTvNotAllowed

d. Not received or not found in API any content with the EPG information and the request contain devices entities (ent.device_tv, ent.device_mobile, ent.device_phone). The returned resource is tv:tv.more_info.notAllowed

e. Receive an API error. The returned resource is tv:video.api.answer.error

Response

The response follows this response schema.

Where:

• intent: input intent.

• entities: input entities.

• result_intent: This field is always MEDIA.SHEET_TV except when the resource is tv:carousel.info.contentDetail or tv:tv.more_info.notAllowed. In this case this field is MEDIA.SHEET_SECOND_SCREEN.

• resources: List of response resources that includes three main parameters:

  • type: Type of the response resource.
  • name: Name of the response resource. Example: tv:tv.moreInfoTvDetail
  • params: This field returns any required parameter in the resource.

• payload: Information provided by the Kernel API, when we make the VOD EPG information request. For this case, If we receive a response, it is a value and then this field includes the following parameters:

  • type: details
  • data: It returns the information provided by the Kernel API.

• status: Final status request. This field includes the following parameters:

  • code: Status code.
  • message: Status message, which describes the status code.
  • params: Parameter that sends details of status. This field does not appear if it is empty.

• actions: Actions to follow with the result of request.

• conditions: Condition for the actions to be applied.

6.3 - TV VOD EPG information resources

TV VOD EPG information use case resources

The TV VOD EPG information use case will use three different types of resources:

• Aura Platform global resources
• Common resources for video use cases
• Specific resources for the use case: tv.vod_egp_information

Specific resources for the use case: tv.vod_epg_information

The resources associated to the TV VOD EPG information plugin are defined below:

6.4 - NLP configuration by OB

NLP configuration by OB

Introduction

The current document includes the configuration of the NLP model for the TV VOD EPG information use case in the OBs where it is available.

Brazil

The aura-nlpdata repository structure in Brazil is organized by channel: aura-nlpdata-br-[channel]. Each repository will contain the files for the available use cases in this channel.

The following configuration corresponds to the STB channel, which is included in the repository: https://github.com/Telefonica/aura-nlpdata-br-stb

Intent

intent.tv.vod_epg_information

Entities

• ent.device_tv
• ent.device_mobile
• ent.device_phone

Pipeline stages

The following stages of STB’s pipeline have been used to develop this UC:

• “ExactMatchRecognizerWrapper”
• “PygrapeGrammarWrapper”
• “EntityTaggerAdapterWrapper”

The whole pipeline.jsonfile is available at: https://github.com/Telefonica/aura-nlpdata-br-stb/blob/master/data/pt-br/stb/pipeline.json

7 - TV none use case

TV none use case

Introduction

The TV none use case is a global experience designed and developed by Aura Global Team that allows Telefónica customers to ask Aura using a vocal interface.

Find additional information in following the documents:

• Discover the TV none specifications and the particularities of the use case development.
• Learn how to configure the generic dialog for TV none use case.
• Access to the TV none plugin.
• Discover which are the resources used by the TV none use case.
• Find out the NLP configuration for each OB for the TV none use case.

Specifications

Kernel API

In order to resolve the user’s request, Aura uses Video Contents normalized Kernel API.

Request-response model

TV none use case is adapted to the new request-response normalized model v3.

Available channels

Once TV none v3 use case is fully normalized, it will be available for any channel that implements normalized v3 request-response model including TV related data.

Currently, STB channels in BR are already available.

Display features

Currently, the normalized TV none use case includes basic search features for content/channels:

• none search content/channels with user normalized utterance

Therefore, the answer could be any provided by the recognized intent: intent.tv.none

Use case development

The TV none use case development includes these components:

Understanding features

• TV none use case intent: intent.tv.none

• TV none use case entities: Ignore the entities for search content/channels, use normalized utterance for contigency search.

In order to understand users’ requests (utterances), Aura is trained with:

• NLP expression to recognize the user’s utterance and detect her intention.
• TV catalog in order to understand TV content (channels) in the user’s utterance and detect them as Aura entities.

Use case logic

Once Aura has recognized the user’s utterance based on NLP components, the use case should be resolved based on:

• Aura Bot dialog:

  TV none is built over the generic dialog v3.

  • Check the section Configuration of the generic dialog for TV none use case in order to know the required configuration for the TV none experience.

• CLF Plugin:

  Complex Logic Framework is used for the recognition of the user’s request.

  • Check here the TV none plugin.

7.1 - Dialog configuration

Configuration of the generic dialog for TV none use case

Specific configuration

The TV none use case is triggered by the generic dialog v3. For this use case, the required specific configuration is set below:

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "triggerConditions": [
        {
            "intent": "intent.tv.none",
            "settings": {
                "locales": {
                    "error": [
                        "core:flc.answer.error"
                    ]
                },
                "needTvResolution": true
            }
        }
    ],
    "onlyIn": [
        "set-top-box"
    ]
}

Specific values

7.2 - TV None plugin

TV none plugin

Introduction

The TV none plugin resolves the request from a user getting information about channel.

It includes some key steps described in the following sections.

Validate input request

This step validates that the input request fulfills all the requirements from the input schema.

If the input data has an error, the resource returned is:
tv:video.model-validation.request.error.

Contingency Search

The contingency search is a more in-depth search to get, at least, one response. This search uses the entire utterance in every search field.

Contingency search is based on the following steps:

Normalization section

When a request is made by the user, it is possible to find certain words with no real value for Aura, so the system is not able to redirect them to obtain a response. For this reason, a list of forbidden words known as “ignore-words” will be declared, which will be eliminated.

The first step is to transform the entire utterance received as input to lowercase, removing all non-alphanumeric characters and separators. Once the utterance has been normalized, the words that belong to the list of “ignore-words” are eliminated.

This list is declared in a resource file called normalizer_rules.json. This file can be found in the following path: src.aura_clf_video.resources.[language].normalizer_rules.json Where [language] must be replaced by each language, for example: es-es.

If the language does not have the normalizer rule defined, it will be redirected to a default folder: src.aura_clf_video.resources.default.normalizer_rules.json

If, for example, the language is Spanish, the path to the resource where the normalization rules are defined will be: src.aura_clf_video.resources.es-es.normalizer_rules.json

• Normalizer rules structure:
  It is a dictionary where all the items are declared in a list as shown below:

  {
    "ignore_items": [
      "ignore item 1",
      "ignore item 2"
    ]
  }
  

• Validation of resource content:
  The normalization is done sequentially, a previous rule cannot affect a succeeding one.

  For example:

  • The utterance is “ok aura some”.
  • We define “aura” and also “ok aura” in the “ignore-words” list.
  • If we remove “aura” firstly from the original utterance, we obtain the following normalized utterance: “ok some”. In this case, “ok aura” does not have any effect.
  • In short, the correct order should be: first, remove “ok aura” and, after that, remove “aura”. In this case, we will obtain the final utterance as “some”.

“Ignore-words” will be automatically validated in order to prevent this behavior in every Pull Request.

If after normalization the normalized phrase is empty, the resource returned is: tv:video.search.contingency.no-results

API video query

After normalizing, we will query the Telefonica Kernel video API by searching through all possible fields with the remaining words.

To make this API call, a series of parameters are going to be needed, which are described below:

• user_id: Input data[aura_user][user_id]
• administrative_number: Input data[app_context][user][account_number]
• access_token: Input data[aura_user][access_token]
• scopes: Input data[aura_user][scopes]
• purposes: Input data[aura_user][purposes]
• device_type: Input data[app_context][device][type]
• catalog_types: List that is made by VOD, LIVE and L7D.
• search_query: Is a joint of the normalized phrase by OR operator. Use this format to search by any fields. Example: “La resistencia Shameless” the search_query is “(La OR resistencia OR Shameless)”.
• show_series: series.
• profile: Input data[app_context][user][video_profile_name]. This field may not be implemented in some cases and this could give the error 501 Not Implemented in the video API according to the documentation. To prevent this problem, we should send this field only when input data has this value.
• commercialization_types: List made by SVOD.
• max_quality: Input data[app_context][device][max_quality]
• order: personal
• current_region: Input data[app_context][location][currentRegion] if exists. Otherwise, do not use this param.

Contingency search response

When performing a contingency search, there are four possible scenarios for the response received by the search:

a. Receive an API error. The returned resource is tv:video.api.answer.error

b. Receive no results at all. The returned resource is tv:video.search.contingency.no-results

c. Receive a single result. The returned resource is tv:video.search.contingency.single-result

d. Receive several results. The returned resource is tv:video.search.contingency.multiple-results

Response

The response follows this response schema.

Where:

• intent: input intent.

• entities: input entities.

• result_intent: This field is always MEDIA.SEARCH because it is the response associated to this domain.

• resources: List of response resources that includes three main parameters:

  • type: Type of the response resource.
  • name: Name of the response resource. Example: tv:video.search.contingency.single-result
  • params: This field returns any required parameter in the resource.

• payload: Information provided by the Kernel API, when we make the search request. If we receive a response. This field includes the following parameters:

  • type: The value of this field depends on the type of data included in the field data (info returned by the API):
    • If it is a value: details
    • If it is a list: content_list
  • data: It returns the information provided by the Kernel API.

• status: Final status request. this field includes field the following parameters:

  • code: Status code.
  • message: Status message, which describes the status code.
  • params: Parameter that sends details of status. This field does not appear if it is empty.

• actions: Actions to follow with the result of request.

• conditions: Condition for the actions to be applied.

7.3 - TV none resources

TV none use case resources

The TV none use case will use three different types of resources:

• Aura Platform global resources
• Common resources for video use cases
• Specific resources for the use case: tv.none

Specific resources for the use case: tv.none

The resources associated to the TV none plugin are defined below:

7.4 - NLP configuration by OB

NLP configuration by OB

Introduction

The current document includes the configuration of the NLP model for the TV None use case in the OBs where it is available.

Brazil

The aura-nlpdata repository structure in Brazil is organized by channel: aura-nlpdata-br-[channel]. Each repository will contain the files for the available use cases in this channel.

The following configuration corresponds to the STB channel, which is included in the repository: https://github.com/Telefonica/aura-nlpdata-br-stb

Intent

intent.tv.none

Entities

• No use specific entities to obtain results.

Pipeline stages

The following stages of STB’s pipeline have been used to develop this UC:

• CluRecognizerWrapper

The whole pipeline.jsonfile is available at: https://github.com/Telefonica/aura-nlpdata-br-stb/blob/master/data/pt-br/stb/pipeline.json

8 - Audiovisual App Opening use case

Audiovisual App Opening use case

Introduction

The Audiovisual App Opening use case is a global experience designed and developed by Aura Global Team that allows Telefónica customers to open different third-party apps that are considered audiovisual apps.

• A user interacts with Aura through a normalized video channel
• The user requests: “I want to put this <app> on the TV”, where <app> is a third-party app
• Aura recognizes the request and provides back to the channel the information required to open this app

For example:

• “Open Amazon Prime Video app”
• “Access TikTok”
• “Put Disney on TV”

Find additional information in the following documents:

• Discover the Audiovisual App Opening specifications and the particularities of the use case development.

• Learn how to configure the generic-dialog for Audiovisual App Opening use case.

• Discover the resources used by the Audiovisual App Opening use case

• Find out the NLP configuration for each OB for the Audiovisual App Opening use case.

Specifications

Kernel API

In order to resolve the user’s request, Aura uses Video Contents normalized Kernel API.

Request-response model

Audiovisual App Opening use case is adapted to the request-response normalized model v3.

Available channels

• STB (aura-nlpdata-br-stb)
• GVP (aura-nlpdata-ap)

Use case development

The Audiovisual App Opening use case development includes these components:

Understanding features

• Audiovisual App Opening use case intent: intent.tv.app_open

• Audiovisual App Opening use case entities:

In order to understand users’ requests (utterances), Aura is trained with:

• NLP expression to recognize the user’s utterance and detect its intention.
• TV catalog in order to understand audiovisual apps in the user’s utterance and detect them as Aura entities.

Use case logic

Once Aura has recognized the user’s utterance based on NLP components, the use case should be resolved based on:

• Aura Bot dialog:

  Audiovisual App Opening is built over the generic-dialog-v3.

  • Check the section Configuration of the generic-dialog for Audiovisual App Opening use case in order to know the required configuration for the experience.

8.1 - Dialog configuration

Configuration of the generic-dialog for the Audiovisual App Opening use case

Specific configuration

The Audiovisual App Opening use case is triggered by the generic-dialog-v3.

For this use case, the required specific configuration is set below:

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "triggerConditions": [
        {
            "intent": "intent.tv.app_open",
            "settings": {
                "locales": {
                    "error": [
                        "tv:video.section.not_available"
                    ]
                },
                "actions": [
                    {
                        "name": "GOTOAPP"
                    },
                    {
                        "name": "MAKE_SOUND"
                    }
                ],
                "sound": "positive",
                "needPlayingContent": false,
                "payloadType": "tv"
            }
        }
    ],
    "onlyIn": [
        "set-top-box"
    ]
}

8.2 - Audiovisual App Opening resources

Audiovisual App Opening use case resources

Introduction

The Audiovisual App Opening use case will use three different types of resources:

• Aura Platform global resources
• Common resources for video use cases
• Specific resources for the use case

Specific resources for the use case

The resources associated to the Audiovisual App Opening plugin are defined below:

8.3 - NLP configuration by OB

NLP configuration by OB

Introduction

The current document includes the configuration of the NLP model for the Audiovisual App Opening use case in the OBs where it is available.

Brazil

The aura-nlpdata repository structure in Brazil is organized by channel: aura-nlpdata-br-[channel]. Each repository will contain the files for the available use cases in this channel.

The following configuration corresponds to the STB channel, which is included in the repository: https://github.com/Telefonica/aura-nlpdata-br-stb

Intent

intent.tv.app_open

Entities

ent.audiovisual_app

Pipeline stages

The following stages of STB’s pipeline have been used to develop this UC:

• PygrapeGrammarWrapper
• EntityTaggerAdapterWrapper

The whole pipeline.jsonfile is available at: https://github.com/Telefonica/aura-nlpdata-br-stb/blob/master/data/pt-br/stb/pipeline.json

9 - Change language use case

Change language use case

Introduction

The Change language use case is a global video experience designed and developed by Aura Global Team that allows Telefónica customers to change the language on TV.

• A user interacts with Aura through a normalized video channel

• The user requests: “Change subtitles to English”

• Aura recognizes the request and provides back to the channel the information required

For example:

• “Change subtitles to English”

• “Put the movie in the original version”

Find additional information in the following documents:

• Discover the Change language specifications and the particularities of the use case development.

• Learn how to configure the generic-dialog for Change language use case.

• Discover the resources used by the Change language use case.

• Find out the NLP configuration for each OB for the Change language use case.

Specifications

Kernel API

In order to resolve the user’s request, Aura uses Video Contents normalized Kernel API.

Request-response model

Change language use case is adapted to the request-response normalized model v3.

Available channels

• STB (aura-nlpdata-br-stb)
• GVP (aura-nlpdata-ap)

Use case development

The Change language use case development includes these components:

Understanding features

• Change language use case intent: intent.tv.language_change

Use case logic

Once Aura has recognized the user’s utterance based on NLP components, the use case should be resolved based on:

• Aura Bot dialog:
  Change language is built over the generic-dialog-v3. Check the section Configuration of the generic-dialog for Change language use case in order to know the required configuration for the experience.

9.1 - Dialog configuration

Configuration of the generic-dialog for Change language use case

Specific configuration

The Change language use case is triggered by the generic-dialog-v3.

For this use case, the required specific configuration is set below:

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "triggerConditions": [
        {
            "intent": "intent.tv.language_change",
            "settings": {
                "locales": {
                    "error": [
                        "tv:tv.error.fpaOrCognitive"
                    ]
                },
                "actions": [
                    {
                        "name": "REMOTEON_AUDIO_SUBTITLES"
                    },
                    {
                        "name": "MAKE_SOUND"
                    }
                ],
                "payloadType": "tv"
            }
        }
    ],
    "onlyIn": [
        "set-top-box"
    ]
}

9.2 - Change language resources

Change language use case resources

Introduction

The Change language use case will use three different types of resources:

• Aura Platform global resources
• Common resources for video use cases

9.3 - NLP configuration by OB

NLP configuration by OB

Introduction

The current document includes the configuration of the NLP model for the TV Change language use case in the OBs where it is available.

Brazil

The aura-nlpdata repository structure in Brazil is organized by channel: aura-nlpdata-br-[channel]. Each repository will contain the files for the available use cases in this channel.

The following configuration corresponds to the STB channel, which is included in the repository: https://github.com/Telefonica/aura-nlpdata-br-stb

Intent

intent.tv.language_change

Entities

No entities are handled for this intent.

Commands

Currently, the commands that trigger this intent are:

        "Audio em língua estrangeira",
        "Colocar legendas em espanhol",
        "Legendas em inglês",
        "Som em original"

Pipeline stages

Since there is a closed list of commands that could trigger this UC, the stage involved in its recognition is a deterministic one:

      "ExactMatchRecognizerWrapper",

The whole pipeline.jsonfile is available at: https://github.com/Telefonica/aura-nlpdata-br-stb/blob/master/data/pt-br/stb/pipeline.json

10 - Section Show

Section Show use case

Introduction

The Section Show use case is a global experience designed and developed by Aura Global Team that allows Telefónica customers to open different sections and navigate through them.

• A user interacts with Aura through a normalized video channel
• The user requests: “I want to put this <section> on the TV”
• Aura recognizes the request and provides back to the channel the information required to open this section

For example:

• “Open aventura”
• “Access Kids”
• “Put films on TV”

Find additional information in the following documents:

• Discover the Section Show specifications and the particularities of the use case development.

• Learn how to configure the generic-dialog for Section Show use case.

• Discover the resources used by the Section Show use case.

• Find out the NLP configuration for each OB for the Section Show use case.

Specifications

Kernel API

In order to resolve the user’s request, Aura uses Video Contents normalized Kernel API.

Request-response model

Section Show use case is adapted to the request-response normalized model v3.

Available channels

• STB (aura-nlpdata-br-stb)
• GVP (aura-nlpdata-ap)

Use case development

The Section Show use case development includes these components:

Understanding features

• Section Show use case intent: intent.navigation.section_show

• Section Show use case entities:

In order to understand users’ requests (utterances), Aura is trained with:

• NLP expression to recognize the user’s utterance and detect its intention.
• TV catalog in order to understand audiovisual sections in the user’s utterance and detect them as Aura entities.

Use case logic

Once Aura has recognized the user’s utterance based on NLP components, the use case should be resolved based on:

• Aura Bot dialog:

  Section Show is built over the generic-dialog-v3.

  • Check the section Configuration of the generic-dialog for Section Show use case in order to know the required configuration for the experience.

10.1 - Dialog configuration

Configuration of the generic-dialog for Section Show use case

Specific configuration

The Section Show use case is triggered by the generic-dialog-v3.

For this use case, the required specific configuration is set below:

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "triggerConditions": [
        {
            {
                "intent": "intent.navigation.section_show",
                "settings": {
                    "locales": {
                        "error": [
                            "tv:tv.error.fpaOrCognitive"
                        ]
                    },
                    "actions": [
                        {
                            "name": "NAVIGATION_SECTION_SHOW"
                        },
                        {
                            "name": "MAKE_SOUND"
                        }
                    ],
                    "sound": "positive",
                    "needPlayingContent": false,
                    "payloadType": "tv"
                }
            }
        }
    ],
    "onlyIn": [
        "set-top-box"
    ]
}

10.2 - Section Show resources

Section Show use case resources

Introduction

The Section Show use case will use three different types of resources:

• Aura Platform global resources
• Common resources for video use cases
• Specific resources for the use case

Specific resources for the use case: tv.display

There are no specific resources for TV section show in V3. For v1, the resources associated are defined below:

10.3 - NLP configuration by OB

NLP configuration by OB

Introduction

The current document includes the configuration of the NLP model for the Section Show use case in the OBs where it is available.

Brazil

The aura-nlpdata repository structure in Brazil is organized by channel: aura-nlpdata-br-[channel]. Each repository will contain the files for the available use cases in this channel.

The following configuration corresponds to the STB channel, which is included in the repository: https://github.com/Telefonica/aura-nlpdata-br-stb

Intent

intent.navigation.section_show

Entities

ent.section

Pipeline stages

The following stages of STB’s pipeline have been used to develop this UC:

• PygrapeGrammarWrapper
• EntityTaggerAdapterWrapper

The whole pipeline.jsonfile is available at: https://github.com/Telefonica/aura-nlpdata-br-stb/blob/master/data/pt-br/stb/pipeline.json

11 - Subtitles remove use case

Subtitles remove use case

Introduction

The Subtitles remove use case is a global experience designed and developed by Aura Global Team that allows Telefónica customers to remove the subtitles.

• A user interacts with Aura through a normalized video channel
• The user requests: “Remove subtitles from the film”.
• Aura recognizes the request and provides back to the channel the information required

For example:

• “Remove subtitles from the movie”
• “Remove subtitles from this episode”

Find additional information in the following documents:

• Discover the Subtitles remove specifications and the particularities of the use case development.

• Learn how to configure the generic-dialog for Subtitles remove use case.

• Discover the resources used by the Subtitles remove use case.

• Find out the NLP configuration for each OB for the Subtitles remove use case.

Specifications

Kernel API

In order to resolve the user’s request, Aura uses Video Contents normalized Kernel API.

Request-response model

Subtitles remove use case is adapted to the request-response normalized model v3.

Available channels

• STB (aura-nlpdata-br-stb)
• GVP (aura-nlpdata-ap)

Use case development

The Subtitles remove use case development includes these components:

Understanding features

• Subtitles remove use case intent: intent.tv.subtitles_remove

Use case logic

Once Aura has recognized the user’s utterance based on NLP components, the use case should be resolved based on:

• Aura Bot dialog: Subtitles remove is built over the generic-dialog-v3. Check the section Configuration of the generic-dialog for Subtitles remove use case in order to know the required configuration for the experience.

11.1 - Dialog configuration

Configuration of the generic-dialog for Subtitles remove use case

Specific configuration

The Subtitles remove use case is triggered by the generic-dialog-v3.

For this use case, the required specific configuration is set below:

{
    "id": "generic-dialog-v3",
    "channelDataVersion": "v3",
    "triggerConditions": [
        {
            "intent": "intent.tv.subtitles_remove",
            "settings": {
                "locales": {
                    "error": [
                        "tv:tv.error.fpaOrCognitive"
                    ]
                },
                "actions": [
                    {
                        "name": "REMOTEON_AUDIO_SUBTITLES",
                        "params": {
                            "subtitles": "None"
                        }
                    },
                    {
                        "name": "MAKE_SOUND"
                    }
                ],
                "payloadType": "tv"
            }
        }
    ],
    "onlyIn": [
        "set-top-box"
    ]
}

11.2 - Subtitles remove resources

Subtitles remove use case resources

Introduction

The Subtitles remove use case will use three different types of resources:

• Aura Platform global resources
• Common resources for video use cases

11.3 - NLP configuration by OB

NLP configuration by OB

Introduction

The current document includes the configuration of the NLP model for the TV Subtitles remove use case in the OBs where it is available.

Brazil

The aura-nlpdata repository structure in Brazil is organized by channel: aura-nlpdata-br-[channel]. Each repository will contain the files for the available use cases in this channel.

The following configuration corresponds to the STB channel, which is included in the repository: https://github.com/Telefonica/aura-nlpdata-br-stb

Intent

intent.tv.subtitles_remove

Entities

No entities are handled for this intent.

Commands

Currently, the commands that trigger this intent are:

        "Desativar legendas",
        "Remova as legendas"

Pipeline stages

Since there is a closed list of commands that could trigger this UC, the stage involved in its recognition is a deterministic one:

      "ExactMatchRecognizerWrapper",

The whole pipeline.jsonfile is available at: https://github.com/Telefonica/aura-nlpdata-br-stb/blob/master/data/pt-br/stb/pipeline.json

12 - Global resources for TV use cases

Global resources for TV use cases

Introduction

Apart from the specific resources for each TV-related use case, there are two types of global resources that can be used by any global experience for TV channels, which are described below:

• Aura Platform global resources
• Common resources for video use cases

Aura Platform global resources

The Aura Platform global resources that can be used by global TV experiences are:

Common resources for video use cases

The general video use cases resources that can be used by global TV experiences are:

13 - Legacy Video API for Spain

Legacy Video API for Spain

14 - Adapter request-response model v1 to v3

Adapter request-response model v1 to v3

Introduction

Adapter use cases allow to work with request-response model v1 to adapt to systems that do not support v3 yet.

Mainly, this adapter receives a request in v1 format and internally transforms it to v3 format to process it with the corresponding TV CLF plugin. Then, the response in v3 format is transformed back to v1 format to send the response.

Dialog Configuration

Specific configuration

The adapter use case is triggered by the generic dialog v1. For this use case, the required specific configuration is set below:

• Configuration for Spain OB in STB channel.

{
    "id": "generic-dialog-v1",
    ...
}

Adapter use cases

The adapter use case is intended to work with the following TV use cases:

• TV search use case
• TV none use case
• TV search LLM use case
• TV Recommend use case