Edits for consistency and continuity

HeidiSteen · HeidiSteen · commit e31916258cc6 · 2022-09-14T14:41:19.000-07:00
diff --git a/articles/search/cognitive-search-output-field-mapping.md b/articles/search/cognitive-search-output-field-mapping.md
@@ -1,5 +1,5 @@
 ---
-title: Map skill output fields
+title: Map enrichments in indexers
 titleSuffix: Azure Cognitive Search
 description: Export the enriched content created by a skillset by mapping its output fields to fields in a search index.
 
@@ -30,15 +30,15 @@ In contrast with a [`fieldMappings`](search-indexer-field-mappings.md) definitio
 
 Output field mappings are required if your indexer has an attached [skillset](cognitive-search-working-with-skillsets.md) that creates new information, such as text translation or key phrase extraction. During indexer execution, AI-generated information exists in memory only. To persist this information in a search index, you'll need to tell the indexer where to send the data.
 
-Output field mappings can also be used to [flatten nested data structures]() during indexing. A regular [fieldMapping definition](search-indexer-field-mappings.md) doesn't support target fields of a complex type. If you need to set up field associations for hierarchical or nested data structures, you can use a skillset and an output field mapping to create the data path.
+Output field mappings can also be used to retrieve specific nodes in a source document's complex type. If you don't need the full complex structure, you can [flatten individual nodes in a nested data structures](#flattening-information-from-complex-types) into a string collection.
 
 Output field mappings apply to:
 
 + Content that's created by skills or extracted by an indexer. The source field is a node in an enriched document residing in memory.
 
 + Search indexes. If you're populating a [knowledge store](knowledge-store-concept-intro.md), use [projections](knowledge-store-projections-examples.md) for data path configuration.
 
-Output field mappings always occur after [skillset execution](cognitive-search-working-with-skillsets.md), although it's possible to processing an output field mapping if no skillset is defined. See 
+Output field mappings are applied after [skillset execution](cognitive-search-working-with-skillsets.md) or after document cracking if there's no associated skillset. 
 
 ## Define an output field mapping
 
@@ -48,7 +48,7 @@ Output field mappings are added to the `outputFieldMappings` array in an indexer
 "fieldMappings": []
 "outputFieldMappings": [
   {
-    "sourceFieldName": "document/path-to-a-node-in-an-enriched-document",
+    "sourceFieldName": "/document/path-to-a-node-in-an-enriched-document",
     "targetFieldName": "some-search-field-in-an-index",
     "mappingFunction": null
   }
@@ -57,14 +57,14 @@ Output field mappings are added to the `outputFieldMappings` array in an indexer
 
 | Property | Description |
 |----------|-------------|
-| "sourceFieldName" | Required. Specifies a path to enriched content. See [Reference annotations in an Azure Cognitive Search skillset](cognitive-search-concept-annotations-syntax.md) for path syntax. |
-|  "targetFieldName" | Optional. Specifies the search field that receives the enriched content. This is always a single top-level field or a collection. Target fields must be top-level simple fields or collections. It can't be a path to a subfield in a complex type. Although a target field can't resolve to subfield, you can [flatten a nested source structure into a string collection](#flatten-information-from-complex-types) in memory, and then send it to a string collection in your index. |
-| "mappingFunction" | Optional. Adds extra processing provided by [mapping functions](search-indexer-field-mappings.md#mappingFunctions) supported by indexers. In the case of enrichment nodes, encoding and decoding are the most commonly used functions. |
+| sourceFieldName | Required. Specifies a path to enriched content. An example might be `/document/content`. See [Reference annotations in an Azure Cognitive Search skillset](cognitive-search-concept-annotations-syntax.md) for path syntax and examples. |
+| targetFieldName | Optional. Specifies the search field that receives the enriched content. Target fields must be top-level simple fields or collections. It can't be a path to a subfield in a complex type. If you want to retrieve specific nodes in a complex structure, you can [flatten individual nodes](#flatten-information-from-complex-types) in memory, and then send the output to a string collection in your index. |
+| mappingFunction | Optional. Adds extra processing provided by [mapping functions](search-indexer-field-mappings.md#mappingFunctions) supported by indexers. In the case of enrichment nodes, encoding and decoding are the most commonly used functions. |
 
 You can use the REST API or an Azure SDK to define output field mappings.
 
 > [!TIP]
-> Indexers created by the [Import data wizard](search-import-data-portal.md) include output field mappings generated by the wizard. If you need examples, run the wizard over your data source to see the full definition.
+> Indexers created by the [Import data wizard](search-import-data-portal.md) include output field mappings generated by the wizard. If you need examples, run the wizard over your data source to see the rendered definition.
 
 ### [**REST APIs**](#tab/rest)
 
@@ -102,7 +102,7 @@ api-key: [admin key]
 }
 ```
 
-For each output field mapping, set the location of the data in the enriched document tree (sourceFieldName), and the name of the field as referenced in the index (targetFieldName). Assign any [mapping functions](search-indexer-field-mappings.md#field-mapping-functions-and-examples) that you require to transform the content of a field before it's stored in the index.
+For each output field mapping, set the location of the data in the enriched document tree (sourceFieldName), and the name of the field as referenced in the index (targetFieldName). Assign any [mapping functions](search-indexer-field-mappings.md#mappingFunctions) that you require to transform the content of a field before it's stored in the index.
 
 ### [**.NET SDK (C#)**](#tab/csharp)
 
@@ -132,13 +132,15 @@ await indexerClient.CreateIndexerAsync(indexer);
 
 ---
 
-<a name="flatten-information-from-complex-types"></a>
+<a name="flattening-information-from-complex-types"></a>
 
 ## Flatten complex structures into a string collection
 
-If your source data is composed of nested or hierarchical JSON, you can't use field mappings to set up the data paths. Instead, your search index must mirror the source data structure for at each level for a full import. 
+If your source data is composed of nested or hierarchical JSON, you can't use field mappings to set up the data paths. Instead, your search index must mirror the source data structure for at each level for a full import.
+
+This section walks you through an import process that produces a one-to-one reflection of a complex document on both the source and target sides. Next, it uses the same source document to illustrate the retrieval and flattening of individual nodes into string collections.
 
-Sample source JSON document in Cosmos DB with nested JSON:
+Here's an example of a document in Cosmos DB with nested JSON:
 
 ```json
 {
@@ -171,7 +173,7 @@ Sample source JSON document in Cosmos DB with nested JSON:
 }
 ```
 
-Sample index definition in Cognitive Search, where names, levels, and types are reflected as a complex type:
+If you wanted to fully index the above source document, you'd create an index definition where the field names, levels, and types are reflected as a complex type. Because field mappings aren't supported for complex types in the search index, your index definition must mirror the source document.
 
 ```json
 {
@@ -200,7 +202,7 @@ Sample index definition in Cognitive Search, where names, levels, and types are
 }
 ```
 
-Sample indexer definition that runs the import (notice there are no field mappings and no skillset):
+Here's a sample indexer definition that executes the import (notice there are no field mappings and no skillset).
 
 ```json
 {
@@ -214,7 +216,7 @@ Sample indexer definition that runs the import (notice there are no field mappin
 }
 ```
 
-Sample search document, post-import, is similar to the original in Cosmos DB:
+The result is the following sample search document, similar to the original in Cosmos DB.
 
 ```json
 {
@@ -253,9 +255,9 @@ Sample search document, post-import, is similar to the original in Cosmos DB:
 }
 ```
 
-An alternative rendering in a search index is to flatten the source's nested structure to a string collection in a search index.
+An alternative rendering in a search index is to flatten individual nodes in the source's nested structure into a string collection in a search index.
 
-To accomplish this task, you'll need an `outputFieldMapping` that maps an in-memory node to a string collection in the index. Although output field mappings primarily apply to skill outputs, you can also use them to address nodes after "document cracking" where the indexer opens a source document and reads it into memory.
+To accomplish this task, you'll need an `outputFieldMapping` that maps an in-memory node to a string collection in the index. Although output field mappings primarily apply to skill outputs, you can also use them to address nodes after ["document cracking"](search-indexer-overview.md#stage-1-document-cracking) where the indexer opens a source document and reads it into memory.
 
 Below is a sample index definition in Cognitive Search, using string collections to receive flattened output:
 
diff --git a/articles/search/search-indexer-field-mappings.md b/articles/search/search-indexer-field-mappings.md
@@ -1,5 +1,5 @@
 ---
-title: Field mappings in indexers
+title: Map fields in indexers
 titleSuffix: Azure Cognitive Search
 description: Configure field mappings in an indexer to account for differences in field names and data representations.
 
@@ -16,19 +16,20 @@ ms.date: 09/14/2022
 
 ![Indexer Stages](./media/search-indexer-field-mappings/indexer-stages-field-mappings.png "indexer stages")
 
-When using an [Azure Cognitive Search indexer](search-indexer-overview.md) to push content into a search index, the indexer can often detect and assign source-to-destination field mappings. Implicit field mappings occur when field names and data types are compatible. 
+When using an [Azure Cognitive Search indexer](search-indexer-overview.md) to pull content into a search index, the indexer can often implicitly detect and assign source-to-destination field mappings. Implicit field mappings occur when field names and data types are compatible. 
 
-If inputs and outputs don't match, you can define explicit *field mappings* to set up the data path, as described in this article. Field mappings can also be used to provide light-weight data conversion, such as encoding or decoding, through [mapping functions](#mappingFunctions). If more processing is required, consider [Azure Data Factory](../data-factory/index.yml) to bridge the gap.
+If inputs and outputs don't match, you can define explicit *field mappings* to set up the data path, as described in this article. Field mappings can also be used to introduce light-weight data conversion, such as encoding or decoding, through [mapping functions](#mappingFunctions). If more processing is required, consider [Azure Data Factory](../data-factory/index.yml) to bridge the gap.
 
 Field mappings apply to:
 
-+ Physical data structures on both sides of the data stream (that is, between a [supported data source](search-indexer-overview.md#supported-data-sources) and a [search index](search-what-is-an-index.md)). If you're importing enriched content created by skills, use [outputFieldMappings](cognitive-search-output-field-mapping.md) instead.
++ Physical data structures on both sides of the data stream (between a [supported data source](search-indexer-overview.md#supported-data-sources) and a [search index](search-what-is-an-index.md)). If you're importing skill enriched content that resides in memory, use [outputFieldMappings](cognitive-search-output-field-mapping.md) instead.
 
 + Search indexes only. If you're populating a [knowledge store](knowledge-store-concept-intro.md), use [projections](knowledge-store-projections-examples.md) for data path configuration.
 
 + Top-level search fields only, where the "targetFieldName" is either a simple field or a collection. A target field can't be a complex type.
 
-  If you're working with complex data (nested or hierarchical structures), and you'd like to mirror that data structure in your search index, your search index must match the source structure exactly (same field names, levels, and types) so that the default mappings will work. Optionally, you can flatten incoming data into a string collection (see  [outputFieldMappings](cognitive-search-output-field-mapping.md) for this workaround).
+> [!NOTE]
+> If you're working with complex data (nested or hierarchical structures), and you'd like to mirror that data structure in your search index, your search index must match the source structure exactly (same field names, levels, and types) so that the default mappings will work. Optionally, you might want just a few nodes in the complex structure. To get individual nodes, you can flatten incoming data into a string collection (see  [outputFieldMappings](cognitive-search-output-field-mapping.md#flatten-complex-structures-into-a-string-collection) for this workaround).
 
 ## Supported scenarios
 
@@ -56,9 +57,9 @@ Field mappings are added to the "fieldMappings" array of an indexer definition.
 
 | Property | Description |
 |----------|-------------|
-| "sourceFieldName" | Required. Represents a field in your data source. |
-|  "targetFieldName" | Optional. Represents a field in your search index. If omitted, the value of "sourceFieldName" is assumed for the target. Target fields must be top-level simple fields or collections. It can't be a complex type or collection. |
-| "mappingFunction" | Optional. Consists of [predefined functions](#mappingFunctions) that transform data. You can apply functions to both source and target field mappings. |
+| sourceFieldName | Required. Represents a field in your data source. |
+| targetFieldName | Optional. Represents a field in your search index. If omitted, the value of "sourceFieldName" is assumed for the target. Target fields must be top-level simple fields or collections. It can't be a complex type or collection. If you're handling a data type issue, a field's data type is specified in the index definition. The field mapping just needs to have the field's name.|
+| mappingFunction | Optional. Consists of [predefined functions](#mappingFunctions) that transform data.  |
 
 Azure Cognitive Search uses case-insensitive comparison to resolve the field and function names in field mappings. This is convenient (you don't have to get all the casing right), but it means that your data source or index can't have fields that differ only by case.  
 
@@ -84,7 +85,7 @@ api-key: [admin key]
 }
 ```
 
-Map a single source field to multiple target fields ("one-to-many" mappings). The following example shows how to "fork" a field, copying the same source field content to two different index fields that will be analyzed or attributed differently in the index.
+This example maps a single source field to multiple target fields ("one-to-many" mappings). You can "fork" a field, copying the same source field content to two different index fields that will be analyzed or attributed differently in the index.
 
 ```JSON
 
