vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Therefore, you must choose which example suggestion is the most accurate. In this example, where the term IBM is used as part of a product name, it is more accurate to label the full phrase as an example of the Product entity type.
* The service might recognize that a term is a possible example of more than one entity type. For example, the word top might mean the best or might mean shirt.



To investigate a suggestion further, click it to see the word in context within the document. Seeing the term in context helps you to decide whether the occurrence is a valid entity example for you to label.







 Importing a Knowledge Studio corpus 

For installed deployments, the import capability was added with the 4.6.2 release.

You can import a corpus of documents that were annotated in IBM Watson® Knowledge Studio to use as the training data for an entity extractor in Discovery.

Entity types that were defined in Knowledge Studio are shown as new entity types in Discovery. You can continue to annotate the imported documents when you customize the entity extractor model.

Entity subtypes and relations from the Knowledge Studio machine learning model are not represented, neither are any custom dictionaries that are associated with the model.

Before you can import a corpus, you must export the document set from Knowledge Studio as a .zip file. Follow the appropriate steps for exporting based on your Knowledge Studio deployment type:



* [IBM Cloud](https://cloud.ibm.com/docs/watson-knowledge-studio?topic=watson-knowledge-studio-exportimportwks_exportimport_expimp_doc)
* [Cloud Pak for Data](https://cloud.ibm.com/docs/watson-knowledge-studio-data?topic=watson-knowledge-studio-data-exportimportwks_exportimport_expimp_doc)



Although you must download both the document set and type system to include annotations in documents that you upload to another Knowledge Studio workspace, the same is not true in this use case. You import only the document set to Discovery. Any annotations in the documents are recreated in Discovery. The Knowledge Studio type system is not needed.

To import a Knowledge Studio corpus, complete the following steps:
--type (string)
: The type of configuration. Value options differ depending on the config_element property that you want to define. Required.

Allowable values are: letsencrypt, letsencrypt-stage, cis, classic_infrastructure, root_certificate_authority, intermediate_certificate_authority, certificate_template. The maximum length is 128 characters. The minimum length is 2 characters.

--config ([ConfigElementDefConfig](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-secrets-manager-cli-v1cli-config-element-def-config-example-schema-v1))
: The configuration to define for the specified secret type. Required.





 Examples 

ibmcloud secrets-manager config-element-create --secret-type=public_cert --config-element=certificate_authorities --name=cis-example-config --type=cis --config='{"cis_crn": "crn:v1:bluemix:public:internet-svcs:global:a/<account-id>:<service-instance>::", "cis_apikey": "cis_apikey_value"}'







 ibmcloud secrets-manager config-elements 

List the configuration elements that are associated with a specified secret type.

ibmcloud secrets-manager config-elements --secret-type SECRET-TYPE --config-element CONFIG-ELEMENT



 Command options 

--secret-type (string)
: The secret type. Required.

Allowable values are: public_cert, private_cert.

--config-element (string)
: The configuration element to define or manage. Required.

Allowable values are: certificate_authorities, dns_providers, root_certificate_authorities, intermediate_certificate_authorities, certificate_templates.





 Examples
ibmcloud cbr rule-create --api-types crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster --description "privateAccess=allowAll, publicAccess=oneIP" --service-name containers-kubernetes --service-instance CLUSTER-ID --context-attributes endpointType=private --context-attributes endpointType=public,networkZoneId=allow-client-ip





 Creating rules from the console 



1. [Review the available contexts](https://cloud.ibm.com/docs/containers?topic=containers-cbr&interface=clicbr-overview) and determine the rules you want to create.
2. Follow the steps to [create context-based restrictions in the console](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create).









 Limitations 



* After you create a rule, it might take up to 10 minutes for the rule to take effect.
* IBM Cloud Kubernetes Service CBR rules that apply to all API types or the cluster API types must not reference network zones that contain IPv6 addresses. The APIs included in the cluster type don't support IPv6.
* If you add IBM Cloud Kubernetes Service resources to private-only network zones, the APIs for getting and listing clusters are still accessible over the public network.
* IBM Cloud Kubernetes Service CBR rules that apply to all API types or the cluster API types must not reference other services like IBM Cloud Object Storage or Key Protect
* IBM Cloud Kubernetes Service CBR rules that apply to all API types or the cluster API type do not support Report-only enforcement for the cluster API type.
* IBM Cloud Kubernetes Service CBR rules that apply to all API types or the cluster API types are limited to no more than 20 IPs/subnets for private rules, and 200 IPs/subnets for public rules. These limits are expected to increase after the backend scalability of our implementation of Red Hat OpenShift on IBM Cloud CBR is updated.
When you train a model, the algorithm can learn from both negative and positive examples, so it's important to mark mentions of both types.









 Relation types 

A relation type defines a binary, ordered relationship between two entities. For a relation mention to exist, text must explicitly define the relation and bind mentions of the two entities together, and must do so within a single sentence. For example, the sentence Mary works for IBM is textual evidence of the employedBy relation type.

For some relation types, the order of entity mentions matters. For example, the employedBy relation type allows the entity type PERSON or PEOPLE as the first mention in the relationship, and ORGANIZATION or GPE as the second mention, but not the other way around. MaryemployedByIBM is a valid relationship. IBMemployedByMary is not. For some relation types, such as spouseOf, colleague, or sibling, order does not matter. When you define a relation type where order is not important, a best practice is to add information to the annotation guidelines to regularize how the relation type is used. A convention for noting such symmetrical relations is to say that the entity mention that occurs first in the text should be the first one in the relation.

Related concepts:

[Uploading resources from another workspace](https://cloud.ibm.com/docs/watson-knowledge-studio?topic=watson-knowledge-studio-exportimport)







 Adding a type system to the workspace 

You must create or upload a type system before you begin any annotation tasks.



 About this task 

The following naming rules apply to type system entries:



* Names cannot contain spaces.
* Use only the following alphanumeric ASCII characters and the underscore character in values that you add to the type system: A through Z, a through z, 0 through 9.
* The first character in an entity or relation type name must be alphabetical.
* Entity type names cannot be longer than 64 characters.
* Relation type names cannot be longer than 128 characters.



By convention, entity type names are specified in uppercase characters (ORGANIZATION) and relation type names are specified in camel case (employedBy). But, this convention is optional.





 Procedure
Specify a descriptive entity type name, keeping in mind that the entity type is a label for annotating important spans of text (mentions) in your domain content. Keep the name short and representative, so human annotators can remember it easily.

You can also optionally define roles and subtypes for the entity type:



* A role helps qualify the entity type in the context in which the mention occurs. For example, the mention Software Engineer might be labeled with the entity type PEOPLE and, in this context, by the role OCCUPATION. See [When to define roles](https://cloud.ibm.com/docs/watson-knowledge-studio?topic=watson-knowledge-studio-typesystemwks_typesystem_roles) for more information.
* A subtype helps further classify the entity type. For example, the entity type GOVERNMENT might have subtypes of MILITARY and CIVILIAN.



By defining a role or subtype for an entity, you are giving more options to the person who will associate type information to mentions at annotation time. The human annotator can apply an annotation that specifies the entity type only, or the entity type plus the role or subtype that you are defining now.

Try to define enough entity types to capture the key concepts that you want to annotate, but not so many entity types that it becomes cumbersome for human annotators to apply the labels accurately.
3. Click Mention Classes and Mention Types to view the default mention classes and mention types. You cannot edit these values.

The purpose of an attribute is to help label each mention by the type of thing that it is. A mention type indicates whether the mention is a name, nominal, or pronoun, and a mention class indicates whether the mention is specific, generic, or negated.
4. Open the Assets> Relation Types page and specify how two mentions can relate to each other.

Order between the first and second entities in a relation type is usually relevant. For example, a PERSON entity can be an employee of an ORGANIZATION entity or a geo-political entity (GPE), such as MaryemployedByIBM, but organizations and geo-political entities cannot be employed by a person.
2. Modify the default name for the event type.
3. Under Schedule, set the frequency of the event.
4. Edit the event payload.
Edit the sample JSON payload by adding properties and their corresponding values or use [functions](https://cloud.ibm.com/docs/services/IoT?topic=IoT-sim_device_datafunctions) to add dynamically generated data points.
You can also upload a [CSV event payload file](https://cloud.ibm.com/docs/services/IoT?topic=IoT-sim_device_datacsv) to set up the payload.



4. Click New Event Type to add and configure more event types for the device type.
5. Enable Save events as historical data to make your simulated device state data available for later access.
With historical data enabled, the Watson IoT Platform [data management ![External link icon](https://cloud.ibm.com/docs-content/v1/content/dc2670e9228a1dbe562d3d2c7ee63f7a48ba27c3/icons/launch-glyph.svg)](https://www.ibm.com/support/knowledgecenter/SSQP8H/iot/platform/GA_information_management/ga_im_definitions.html) components are created and the simulated device state can be accessed from the associated logical interface.
Important: After you enable the device type to save historical data, you cannot add or remove event types, nor can you modify the fields present in the event payloads.
6. Click Save to create the device type.
You are now ready to create one or more simulated devices.
7. Click Create Simulated Device to create a device and start sending data.
Tip: To create more than one device, click 1 x and select the number of devices to create.
8. To create more simulations, click New Simulation and repeat the configuration steps for each device that you want to apply custom settings to.
The message in the lower-right corner of the screen shows the number of active simulations.
9.
When your application is compatible with the new type system, change the version date parameter in your requests to 2018-09-21 to use the new model.





 June 2018 



 26 June 2018 

Added support for Japanese entities and keywords.
: For Japanese input, the following entities are not yet supported:



* Number
* Percent
* PhoneNumber
* URL



IPv6 addresses in Japanese input are not yet detectable as IPAddress entities.





 12 June 2018 

IAM used for US East region
: As of 12 June 2018, new service instances created in the US East region use [Identity and Access Management (IAM) authentication](https://cloud.ibm.com/docs/natural-language-understanding?topic=natural-language-understanding-release-notesiam-auth-process).





 6 June 2018 

Korean categories improvement
: Minor improvements for Korean categories results.







 May 2018 



 29 May 2018 

IAM used in Sydney region
: As of 29 May 2018, new service instances created in the Sydney region use [Identity and Access Management (IAM) authentication](https://cloud.ibm.com/docs/natural-language-understanding?topic=natural-language-understanding-release-notesiam-auth-process).





 9 May 2018 

German entities improvement
: Improved German entities.





 4 May 2018 

Bug fixes and performance improvements
: Added support for Japanese sentiment and semantic roles.
: Improved performance for metadata requests.
: Fixed a bug that caused NAN relevance scores to appear in some entities results.
: Fixed a bug that returned 400 error codes in German and Korean keywords requests when 500 error codes were more appropriate.







 April 2018 



 19 April 2018 

Bug fixes and performance improvements
: Added support for Japanese relations.
: Improved German keywords.
: Fixed a bug that caused incorrect entity mention text to be returned.
: Fixed a bug that could cause poor results for targeted sentiment.
: Fixed a bug that caused the returned analyzed_text to include characters that were not analyzed.





 5 April 2018 

Webpage improvements
: Improved webpage content fetching.
"mentionType":null,
"subtypes":["PATIO","LIVING","DINING"],
"roles":["b9d6caa2-90ac-47ff-91f6-2149b8ffcf20","93ba1f27-173f-4714-b31e-77bdd8cb9932"],
"clazz":null,
"color":"black",
"hotkey":"m",
"backGroundColor":"00FFFF",
"active":true,
"roleOnly":false},
"creationDate":1610611788484,
"source":null,
"modifiedDate":0,
"typeType":null,
"typeClass":null,
"typeVersion":null,
"typeDesc":null,
"typeSuperType":null,
"typeSuperTypeId":null,
"typeCreateDate":null,
"typeUpdateDate":null,
"typeProvenance":null,
"alchemyAPITypes":null,
"nluAPITypes":null},
Show more

To convert the subtypes to new root-level types, make the following change:

{
"id":"b9d6caa2-90ac-47ff-91f6-2149b8ffcf20",
"label":"FURNITURE_NONE",
"sireProp":{
"mentionType":null,
"subtypes":null,
"roles":["b9d6caa2-90ac-47ff-91f6-2149b8ffcf20","93ba1f27-173f-4714-b31e-77bdd8cb9932"],
"clazz":null,
"and so on"
}
},
{
For more information about creating a rule-based model, see [Creating the rule-based model](https://cloud.ibm.com/docs/watson-knowledge-studio?topic=watson-knowledge-studio-wks_rule_train).





 Procedure 



1. Select Rule-based Model > Versions and click the Rule-based model type mapping tab.
2. Map the RuleDate class to the DATE entity from the type system.



1. Find the DATE entity, and click Edit.

![Shows the user clicking Edit for the "DATE" entity type in the "Rule-based model type mapping" tab.](images/rule-anno2.png "Shows the user clicking Edit for the "DATE" entity type in the "Rule-based model type mapping" tab.")
2. Choose the RuleDate class from the list and click Save.

![Shows the user choosing the "RuleDate" class from the list.](images/rule-anno3.png "Shows the user choosing the "RuleDate" class from the list.")



3. To pre-annotate document sets or annotation sets with the rule-based model:



* On the Machine Learning Model > Pre-annotation page, click Run Pre-annotators.
* Select Rule-based Model, then click Next.
* Select the document set that you added to the corpus, documents-ml.csv, and click Run.



Attention: Run the rule-based model as a pre-annotator only on documents that were not already annotated by humans.









 Tutorial summary 

While learning about Knowledge Studio, you created a rule-based model.



 Lessons learned 

By completing this tutorial, you learned about the following concepts:



* Classes
* Regular expressions
* Rules
settings:
- name: TF_VERSION
value: 1.0
Show more



 Global preface 

Following are the supporting parameters that can be used to configure a template



 name 

Type: string

Required: true

An identifier for this blueprint template. The name given to a blueprint environment is defined at create time.





 type 

Type: string

Required: true

Required blueprint template file type identifier.

Value: blueprint





 schema_version 

Type: number

Required: true

Blueprint schema version used by this template definition. Only 1.0 is in effect at this time.

Options: 1.0

Example

schema_version: "1.0"





 description 

Type: string

Default: []

A string used to describe the template to provide users with more information about its usage and the solution it describes. This is internal to the template. The blueprint environment description is defined at create time.

Example

description: "Project to provision Application Service."





 tags 

Type: list

Default: []

An optional list of user tags to be attached to all deployed cloud resources, workspaces and the blueprint resource created using this template. These tags are additional to any tags defined at the module level or on the Terraform IaC resource definitions. All environments deployed using this template will have these tags. Environment specific tags can be specified at config create time, to uniquely identify the instance of environment deployed, e.g dev, stage, prod.

An immutable service tag with the blueprint_id for an environment is attached to all deployed resources and can be used to identify all resources associated with the environment.

Example

tags:
- "blueprint:trial_dev"





 inputs 

Type: list

Default: []

A list defining all the inputs that are required to configure the template.
.name("resourceType")
.value(exampleResourceType)
.operator("stringEquals")
.build();

ResourceAttribute resourceResourceAttribute = new ResourceAttribute.Builder()
.name("resource")
.value(exampleResourceId)
.operator("stringEquals")
.build();

PolicyResource policyResources = new PolicyResource.Builder()
.addAttributes(accountIdResourceAttribute)
.addAttributes(serviceNameResourceAttribute)
.addAttributes(serviceInstanceResourceAttribute)
.addAttributes(resourceTypeResourceAttribute)
.addAttributes(resourceResourceAttribute)
.build();

CreatePolicyOptions options = new CreatePolicyOptions.Builder()
.type("authorization")
.subjects(Arrays.asList(policySubjects))
.roles(Arrays.asList(policyRoles))
.resources(Arrays.asList(policyResources))
.build();

Response<Policy> response = service.createPolicy(options).execute();
Policy policy = response.getResult();

System.out.println(policy);

policy_subjects = PolicySubject(
attributes=[SubjectAttribute(name='accountId', value=example_account_id),
SubjectAttribute(name='serviceName', value=example_source_service_name),
SubjectAttribute(name='serviceInstance', value=example_source_service_instance_id)])
policy_roles = PolicyRole(
role_id='crn:v1:bluemix:public:iam::::serviceRole:Reader')
account_id_resource_attribute = ResourceAttribute(
Built-in enrichments have a type value of System.
5. Choose one or more fields to apply the enrichment to.

You can apply enrichments to the text and html fields, and to custom fields that were added from uploaded JSON or CSV files or from the Smart Document Understanding (SDU) tool.
6. Click Apply changes and reprocess.



Enrichments that you enable are applied to the documents in random order. For information about how to remove an enrichment, see [Managing enrichments](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-manage-enrichments).





 Entities 

Identifies entities. Entities are terms that typically represent proper nouns such as people, cities, and organizations that are mentioned in the data collection. Discovery can recognize entities that are part of an entity type system that is defined by the Watson Natural Language Processing (NLP) service.

If you want to be able to identify uncommon terms that are significant to your business, you can train your own model to recognize custom entities. For more information, see [Entity extractor](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-entity-extractor).

The Watson NLP entity extractor service that is used by Discovery is called the NLU type system. The name originates from the fact that the type system is used by the Watson Natural Language Understanding (NLU) service in addition to the Watson Discovery service. However, it is the Watson NLP implementation of the type system that is used directly by Discovery, not the Watson NLU implementation. As a result, the two implementations can produce different results. To get a general idea of the types of entities that are recognized by the service, see [Entities](https://cloud.ibm.com/docs/natural-language-understanding?topic=natural-language-understanding-entity-types-version-2).

The following screen capture shows that the Entities enrichment recognizes the terms Systems of Government and King of Great Britain (among others) and tags them as entity mentions.

Zoom

![Shows the declaration with the terms Governments and King of Great Britain highlighted.]
If you expect customers to typically make a request about a specific type of claim, such as auto, home, or medical, you might not want to ask another question about what type. They might say I need to file an auto claim or I want to make a home claim.

Although you still need a step that collects the answer about the type of claim, you might not want or need to ask that explicit question, especially if your assistant is used with the phone integration. Instead, you can create a step with the claim options, but set it to never ask.

This table shows how you might set up the steps. The last step is a catch-all in case the customer doesn't mention the claim type initially.



Example using the never ask response setting

 Step Conditions Assistant says Customer response Customer response setting And then 

 1 None What kind of claim? Options: Automobile, Homeowner, Medical Never ask Continue to the next step 
 2 Step 1 is Automobile None Click here to file an automobile claim Skip (default) End the action 
 3 Step 1 is Homeowner None Click here to file a homeowner claim Skip (default) End the action 
 4 Step 1 is Medical None Click here to file a medical claim Skip (default) End the action 
 5 Step 1 is not defined (no claim type) None Click here to file an insurance claim Skip (default) End the action 











 Customer response types 

The configuration information that you must provide varies by response type.



 Options 

An options response presents customers with a list of choices to select from. How these options are presented depends upon how your customers connect to the assistant. In the web chat integration, the options are shown as clickable buttons (for 4 or fewer options) or as a drop-down list (for more than 4 options).

There are two ways to create the list:



* Enter a list of options and synonyms
* Generate a dynamic list from a variable





 Entering a list of options and synonyms 

Enter each choice in the Option fields. You can click Add synonyms to enter variations of an option value that customers might type. You can enter multiple synonyms in a comma-separated list.

For example, you might define the following options and synonyms:



Options example

 Option value Synonyms