RepositoryWebrefSupportTransferRule

Description

Each SupportTransferRule proto represents a single STBR (go/stbr) rule. These rules are attached to entities (called STBR sources). Each rule attached to an STBR source talks about a single entity (called STBR target). If an STBR source gets annotated, its attached rules result in creation of annotations for corresponding STBR targets. An STBR source might have more than one STBR rule attached to it. STBR rules allow us to address cases where otherwise annotations for what people say do not match what people mean. For example, a query [france vs spain] uses names of countries while in sports context the query would actually be about national sports teams of those countries. In other words, STBR rules have meaning of "in this particular context (see domain + target_collection fields below) a mention of this particular STBR source (the entity this rule is attached to) actually should be treated as that STBR target (see the target field below)". To describe the meaning of STBR settings (proto fields below), we are going to use a hypothetical example of an STBR rule making Search stack treat annotations for /m/France as annotations for /m/Louis_XIV, since he was the one saying "I am the state". In this example /m/France is going to be the STBR source. NOTICE: When adding new fields also update client::support_transfer::SortDeterministically to ensure deterministic sorting of the SupportTransferRule objects. Next available tag: 11. LINT.IfChange

Attributes List

This module has the following attributes (case-insensitive ascending order):

Attributes

1. allowWildcardIntents (type: boolean(), default: nil)
   - If set to true, allow STBR targets to trigger intents like ShowEntity that do not have explicit lists of allowed collections, accepting entities with any collections instead. This setting together with target_collection define what intents are allowed to be triggered by the STBR target. Be careful with setting this option to 'true', as in the case of our example the query [france] would result in the knowledge panel for the monarch. Louis XIV might've wanted such a behaviour, but you are probably not him.
2. domain (type: String.t, default: nil)
   - Name of Aqua grammar domain this STBR rule is restricted to. If the domain is set to anything other than "default", the STBR rule is only going to result in an annotation for the STBR target inside of the Aqua domain of the corresponding name. If there is no such Aqua domain, the rule is going to be ignored. The default value of string "default" for domain makes it possible for the STBR rule to be used inside Loose Parser.
3. isReverseLink (type: boolean(), default: nil)
   - Whether this rule points from an STBR target to its STBR source. This field is an internal implementation detail that is not configurable by customers. Inside QRewrite we have to keep track of relations between entities. Among other things it is useful to remember which STBR target a given STBR source came from. For that purpose we attach an STBR proto to the STBR target, reversing the rule, i.e, putting STBR source's mid as the target etc. For this reversed rule we set is_reverse_link to true.
4. mentionsOnly (type: boolean(), default: nil)
   - STBR doesn't just create annotations for STBR targets. It also can modify search result support (useful in PostRef) in order for web pages supporting the STBR source to also support the STBR target. Otherwise in PostRef annotations for STBR targets are going to be demoted, resulting in the STBR rule potentially not affecting anything. Regarding treatment of this result support, STBR has 3 possible modes that for historical reasons are represented as 2 booleans - mentions_only and support_share. No more than one of these bools is supposed to be set to 'true' for a rule. Setting both to 'true' at once would lead to undefined behaviour. These 3 modes are: 1. (default) All the support gets assigned to the STBR target. The STBR source is left with no support. To be extra sure, interpretations that still managed to get triggered by STBR source are suppressed later unless STBR target has no interpretations of its own. In other words this is "we are pretty sure that if France is mentioned in a query that might be talking about a person, we want to treat the query as if it is about Louis XIV". This mode would result in a query [age of france] being treated as [age of louis xiv], while [population of france] still being about the country unless [population of louis xiv] matches some intents. For this mode both mentions_only and support_share should be set to 'false'. 2. Support is shared between STBR source ans STBR target. That allows both STBR source and STBR target to trigger some intents with KScorer later deciding which intent is better. In other words, this is "when it is not clear whether a query is about France of Louis XIV, provide KScorer with both options and let it decide". For this mode mentions_only should be set to 'false' and support_share should be set to 'true'. 3. While annotations for the STBR target are created, no support is given to those annotations. This is more like "we are mostly sure that a mention of France is about the country, but just for a rare case it is about the monarch, we would like to have Louis XIV annotated". For this mode mentions_only should be set to 'true' and support_share should be set to 'false'.
5. supportShare (type: boolean(), default: nil)
   -
6. target (type: String.t, default: nil)
   - Mid of the STBR target, e.g. "/m/04pwg" for Louis XIV.
7. targetCollection (type: GoogleApi.ContentWarehouse.V1.Model.RepositoryWebrefKGCollection, default: nil)
   - Collection that is going to be assigned to the target when the annotation for the target is created. This setting together with allow_wildcard_intents define what intents are allowed to be triggered by the STBR target. At the moment those annotations get created, we can not afford to fetch information about the STBR target from Topic Server, but the target mid by itself doesn't mean much for the Search stack. Setting up the collection for that annotated mid allows us to provide at least some information to the stack on how to treat the mid. This collection together with domain and allow_wildcard_intents fields (see below) defines what intents can be triggered by annotations created for this STBR target. Intents that accept only entities of specific collections can only be triggered if the value of this field matches one of the allowed collections for that intent. In our example, KGCollection.debug_id might be "/collection/people" if we care about context of the monarch as a person, e.g. if we would like to understand queries like [how many children does france have] as [how many childred does lous xiv have]. Or, if we would like to be more restrictive and to only apply the rule to contexts that only make sense for monarch, e.g. [how long did france reign], we might decide to use more specific "/collection/monarchs" instead.
8. userCountry (type: String.t, default: nil)
   - The user country this rule is for. Rules only take effect if the country is not set, set to an empty string or matches the country that is detected for the user - like the country user issued the query from. E.g. "US" for the United States.
9. userLanguage (type: String.t, default: nil)
   - User language this rule is for. Rules only take effect if the language is not set, set to an empty string or matches the language that is detected for the user's query. E.g. set it to "en" if you want the STBR rule to only work for users working from computers with English being set as the main language. Keep it unset if you want the rule not to depend on local language settings of user's computer.

Type

Function

Data sourced from HexDocs : GoogleApi.ContentWarehouse.V1.Model.RepositoryWebrefSupportTransferRule

• ‹ RepositoryWebrefSubSegmentIndex
• RepositoryWebrefTaskData ›

Possibly related Links