Update index.html

Few minor editorial changes, as discussed with Timo.

bp/index.html

@@ -1340,7 +1340,7 @@ <h4 class="subhead">Possible Approach to Implementation</h4>
             <aside class="example" id="ex-amsterdam-station-uri">
               <p>This URI identifies the Amsterdam Central train station: </p>
               <p><code>https://brt.basisregistraties.overheid.nl/top10nl/id/gebouw/102625209</code></p>
-              <p>This URI was minted using the recommendations in the Dutch URI strategy. Although minted by the Kadaster, they chose to use the domain ‘basisregistraties.overheid.nl’ (which translates to ‘base registries . government . nl’) because this is expected to be a more persistent name than ‘kadaster.nl’. Even though the Kadaster is over a 100-years old, organization names are not considered persistent in general as organizations may merge or their names may change. ‘top10nl’ is the name of the dataset, and ‘gebouw’ means ‘building’ – giving the human reader of this URI a clue of what is being identified. The last part of the URI is the building number from the dataset.</p>
+              <p>This URI was minted using the recommendations in the Dutch URI strategy. Although minted by the Kadaster, they chose to use the domain ‘basisregistraties.overheid.nl’ (which translates to ‘base registries.government.nl’) because this is expected to be a more persistent name than ‘kadaster.nl’. Even though the Kadaster is over a 100-years old, organization names are not considered persistent in general as organizations may merge or their names may change. ‘top10nl’ is the name of the dataset, and ‘gebouw’ means ‘building’ – giving the human reader of this URI a clue of what is being identified. The last part of the URI is the building number from the dataset.</p>
             </aside>
 
             <p>[[DWBP]] <a href="https://www.w3.org/TR/dwbp/#UniqueIdentifiers">Best Practice 9: Use persistent URIs as identifiers of datasets</a> cites the European Commission's Study on Persistent URIs [[PURI]] as a good source from which to gain insights about designing persistent URIs.</p>
@@ -2369,7 +2369,7 @@ <h4 class="subhead">Possible Approach to Implementation</h4>
                 <li>Height = 0 meters (i.e. we are standing on the surface of the <a>ellipsoid</a>); or</li>
                 <li>The height is given by a digital elevation model (i.e. we are standing on the surface of the planet).</li>
               </ul>
-              <p>That said, we note that there are several open source software implementations are available to help users do such conversions. These include: the <a href="http://www.gdal.org/">Geospatial Data Abstraction Library</a> (GDAL), the <a href="http://proj.osgeo.org/">Cartographic Projections Library</a> (PROJ.4), its associated <a href="http://proj4js.org/">JavaScript implementation</a> (PROJ4.JS) and the <a href="http://sis.apache.org/">Apache Spatial Information System Library</a> (SIS).</p>
+              <p>That said, we note that there are several open source software implementations available to help users do such conversions. These include: the <a href="http://www.gdal.org/">Geospatial Data Abstraction Library</a> (GDAL), the <a href="http://proj.osgeo.org/">Cartographic Projections Library</a> (PROJ.4), its associated <a href="http://proj4js.org/">JavaScript implementation</a> (PROJ4.JS) and the <a href="http://sis.apache.org/">Apache Spatial Information System Library</a> (SIS).</p>
             </aside>
 
           </section>
@@ -2422,7 +2422,7 @@ <h4 class="subhead">Possible Approach to Implementation</h4>
 
             <aside class="note">
               <p>There is a predominant view that "I just need to use <a>Lat</a> and <a>Long</a> &mdash; and I'm done".</p>
-              <p>Although the clear majority of <a>spatial data</a> published on the Web uses WGS 84 Long/Lat (as used by GPS), we <em>strongly</em> recommend that spatial data is published with all the necessary information to interpret coordinate values. Even where the use of <a>latitude</a> and <a>longitude</a> angular measurements is obvious; the choices of <a>datum</a> and units of measurement have an impact. In particular, angular measurements appearing as floating point numbers are most likely to be provided in decimal degrees, but could also  be in radians or gons (also known as grads).</p>
+              <p>Although the clear majority of <a>spatial data</a> published on the Web uses WGS 84 Long/Lat, we <em>strongly</em> recommend that spatial data is published with all the necessary information to interpret coordinate values. Even where the use of <a>latitude</a> and <a>longitude</a> angular measurements is obvious; the choices of <a>datum</a> and units of measurement have an impact. In particular, angular measurements appearing as floating point numbers are most likely to be provided in decimal degrees, but could also  be in radians or gons (also known as grads).</p>
               <p>The problem is that the assumption of a "predominant view" leads to ambiguity. For example, many spatial data users work entirely with information provided in their national <a>coordinate reference system</a> (such as the <em>Dutch Amersfoort / RD</em> <a href="https://epsg.org/crs_28992/Amersfoort-RD-New.html">EPSG:28992</a> or <em>British National Grid</em> <a href="https://epsg.org/crs_27700/OSGB-1936-British-National-Grid.html">EPSG:27700</a>) which make all coordinates in WGS 84 Long/Lat (especially the negative numbers) utterly perplexing.</p>
               <p>In practice, a publisher not documenting their <a>CRS</a> and presuming that <a>latitude</a> and <a>longitude</a> can be treated as cartesian is often bailed out by fuzzy use cases and software that takes care of projections. However, CRS and coordinate <a>axis order</a> ambiguity leads sooner or later to serious and avoidable errors, while ignorance of <a>datums</a> and <a>map projections</a> leads to broken applications. Furthermore, these practices will also become less and less tenable as new applications such as Augmented Reality require higher data precision and accuracy.</p>
             </aside>