diff --git a/docs/Data_Standardization/index.md b/docs/Data_Standardization/index.md
index 130cfbb..145bd30 100644
--- a/docs/Data_Standardization/index.md
+++ b/docs/Data_Standardization/index.md
@@ -51,7 +51,7 @@ The above points focus on standardising project data for **discovery**.  Additio
 Its important to stress that researchers shouldn't have to take on the bulk of standardization work since it does involve a number technical skills and general awareness of controlled vocabularies and standardized data formats that take time to aquire.  Ideally agency data management/scientist/analyst staff are available to help with standardizing data schemas or exported data projects. 
 
 * **Data naming convention**: Regardless of whether a data schema is reusing elements from other schemas, it is very beneficial to impose data naming conventions on its home-grown components.  This is done mainly to avoid issues in applying or developing software scripts for validation, transformation, and/or database interaction.
-  * **Coding name**: Have a "coding name" for a field or variable name that is safe for use in most programming languages and analytic tools.  This avoids problems where some programs or databases can't handle spaces, dashes, slashes or dots etc..  Data schema frameworks like LinkML have been guided by [Python](https://peps.python.org/pep-0008/#naming-conventions) / [R and SQL compatible](https://bookdown.org/content/d1e53ac9-28ce-472f-bc2c-f499f18264a3/names.html) field names, and standardized table / object names.
+  * **Coding name**: Have a "coding name" for a field or variable name that is safe for use in most programming languages and analytic tools.  This avoids problems where some programs or databases can't handle spaces, dashes, slashes or dots etc. in a name.  Data schema frameworks like LinkML have been guided by [Python](https://peps.python.org/pep-0008/#naming-conventions) / [R and SQL compatible](https://bookdown.org/content/d1e53ac9-28ce-472f-bc2c-f499f18264a3/names.html) field names, and standardized table / object names.
      * **PascalCase** for table, object and picklist names.
      * **lower_camel_case** for record field names (object properties).
   * **Plain names**: Ensure that a separation of concern is established in the schema between the title or label that a field or variable might have in some context, and its coding name. Enabling the title or label to have language variants also paves the way for other multilingual interfaces.