Update data.Rmd (#1085)

removes duplicate word 'section' from text as read aloud (e.g. reads 'Section 7.2' instead of 'section Section 7.2'

data.Rmd

@@ -29,22 +29,22 @@ The practical details differ depending on who needs access to the data, how ofte
 -   If you want to store R objects and make them available to the user, put them in `data/`.
     This is the best place to put example datasets.
     All the concrete examples above for data in a package and data as a package use this mechanism.
-    See section @sec-data-data.
+    See @sec-data-data.
 
 -   If you want to store R objects for your own use as a developer, put them in `R/sysdata.rda`.
     This is the best place to put internal data that your functions need.
-    See section @sec-data-sysdata.
+    See @sec-data-sysdata.
 
 -   If you want to store data in some raw, non-R-specific form and make it available to the user, put it in `inst/extdata/`.
     For example, readr and readxl each use this mechanism to provide a collection of delimited files and Excel workbooks, respectively.
-    See section @sec-data-extdata.
+    See @sec-data-extdata.
 
 -   If you want to store dynamic data that reflects the internal state of your package within a single R session, use an environment.
     This technique is not as common or well-known as those above, but can be very useful in specific situations.
-    See section @sec-data-state.
+    See @sec-data-state.
 
 -   If you want to store data persistently across R sessions, such as configuration or user-specific data, use one of the officially sanctioned locations.
-    See section @sec-data-persistent.
+    See @sec-data-persistent.
 
 ## Exported data {#sec-data-data}
 
@@ -484,7 +484,7 @@ This lets you refer to the objects inside in a very natural way, such as `the$to
 It is also important to specify `parent = emptyenv()` when defining an internal environment, as you generally don't want the environment to inherit from any other (nonempty) environment.
 
 As seen in the example above, the definition of the environment should happen as a top-level assignment in a file below `R/`.
-(In particular, this is a legitimate reason to define a non-function at the top-level of a package; see section @sec-code-when-executed for why this should be rare.) As for where to place this definition, there are two considerations:
+(In particular, this is a legitimate reason to define a non-function at the top-level of a package; see @sec-code-when-executed for why this should be rare.) As for where to place this definition, there are two considerations:
 
 -   Define it before you use it.
     If other top-level calls refer to the environment, the definition must come first when the package code is being executed at build time.