Skip to content

Commit

Permalink
more link fixes
Browse files Browse the repository at this point in the history
  • Loading branch information
@situx
situx authored Aug 23, 2023
1 parent 3302d70 commit 4c71145
Showing 1 changed file with 9 additions and 9 deletions.
18 changes: 9 additions & 9 deletions bp/index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -545,7 +545,7 @@

<p>This document is considered to be complete and is expected to be the final release by the <a href="https://www.w3.org/2015/spatial/">Spatial Data on the Web Working Group</a>. The editors would like to thank everyone for their feedback. Comments received during final review triggered a couple of updates since the previous release on 11 May 2017 (see <a href="#changes" class="sectionRef"></a> for details). This document is published as a <abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note and as an <a href="https://www.ogc.org/standards/bp/"><abbr title="Open Geospatial Consortium">OGC</abbr> Best Practice</a> in accordance with <a href="https://www.w3.org/2017/Process-20170301/#Note" class="sectionRef"><abbr title="World Wide Web Consortium">W3C</abbr> Policy section 6.8 Publishing a Working Group or Interest Group Note</a> and <a href="https://docs.ogc.org/pol/05-020r24/05-020r24.html#83" class="sectionRef"><abbr title="Open Geospatial Consortium">OGC</abbr> Policies and Procedures section 8.6 Best Practices Documents</a>.</p>

<p><strong>For <abbr title="Open Geospatial Consortium">OGC</abbr>:</strong> This document defines an <a href="https://www.ogc.org/standards/bp/"><abbr title="Open Geospatial Consortium">OGC</abbr> Best Practice</a> on a particular technology or approach related to an OGC standard. This document is not an OGC Standard and may not be referred to as an OGC Standard. However, this document is an official position of the OGC membership on this particular technology topic. This document was prepared by the Spatial Data on the Web Working Group (<a href="https://www.ogc.org/projects/groups/sdwwg">SDWWG</a>) &mdash; a joint W3C-OGC project (see <a href="https://www.w3.org/2015/spatial/charter">charter</a>) &mdash; following W3C conventions.</p>
<p><strong>For <abbr title="Open Geospatial Consortium">OGC</abbr>:</strong> This document defines an <a href="https://www.ogc.org/standards/bp/"><abbr title="Open Geospatial Consortium">OGC</abbr> Best Practice</a> on a particular technology or approach related to an OGC standard. This document is not an OGC Standard and may not be referred to as an OGC Standard. However, this document is an official position of the OGC membership on this particular technology topic. This document was prepared by the Spatial Data on the Web Working Group (<a href="https://www.ogc.org/about-ogc/committees/swg/">SDWWG</a>) &mdash; a joint W3C-OGC project (see <a href="https://www.w3.org/2015/spatial/charter">charter</a>) &mdash; following W3C conventions.</p>
</section>
<section id="conformance">
<p> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
Expand Down Expand Up @@ -682,7 +682,7 @@ <h3>FAIR Principles</h3>
<section id="best-practice-criteria">
<h3>Best practice criteria</h3>
<p>The best practices described in this document are compiled based on evidence from real-world
application in production environments. By ‘production environment’ we mean a case where <a>spatial data</a> has been delivered on the Web with the intention of being used by end users and with a quality level expected from such data. Where the <a href="https://www.ogc.org/projects/groups/sdwwg">Working
application in production environments. By ‘production environment’ we mean a case where <a>spatial data</a> has been delivered on the Web with the intention of being used by end users and with a quality level expected from such data. Where the <a href="https://www.ogc.org/about-ogc/committees/swg/">Working
Group</a> has identified issues that inhibit the use or interoperability of spatial data
on the Web, yet no evidence of real-world application is available, the editors present
these issues to the reader for consideration, along with any approaches recommended by the
Expand Down Expand Up @@ -786,7 +786,7 @@ <h3> RDF Namespaces </h3>
<tr>
<td><code>geom</code></td>
<td>http://data.ordnancesurvey.co.uk/ontology/geometry/</td>
<td><a href="https://www.ordnancesurvey.co.uk/">Ordnance Survey's</a> <a href="https://data.ordnancesurvey.co.uk/ontology/geometry/">Geometry Ontology</a></td>
<td><a href="https://www.ordnancesurvey.co.uk/">Ordnance Survey's</a> <a href="https://www.ordnancesurvey.co.uk/products/linked-data/">Geometry Ontology</a></td>
</tr>
<tr>
<td><code>geonames</code></td>
Expand Down Expand Up @@ -1591,7 +1591,7 @@ <h4 class="subhead">Possible Approach to Implementation</h4>

<p>The use of [[SCHEMA-ORG]] for describing spatial information has been also investigated in two studies, concerning, <a href="https://semiceu.github.io/locn-mapping/">the former</a>, the definitions of mappings between [[LOCN]], [[VCARD-RDF]] and [[SCHEMA-ORG]], and, <a href="https://ec-jrc.github.io/dcat-ap-to-schema-org/">the latter</a>, the definitions of mappings between [[GeoDCAT-AP]] and [[SCHEMA-ORG]].</p>

<p>The use of [[SCHEMA-ORG]] for describing spatial information is continually evolving; spatial data publishers should familiarize themselves with current practices. A useful <a href="https://developers.google.com/search/docs/guides/intro-structured-data">Introduction to Structured Data</a> is provided in Google's developer portal.</p>
<p>The use of [[SCHEMA-ORG]] for describing spatial information is continually evolving; spatial data publishers should familiarize themselves with current practices. A useful <a href="https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data/">Introduction to Structured Data</a> is provided in Google's developer portal.</p>
</aside>

</section>
Expand Down Expand Up @@ -3144,7 +3144,7 @@ <h4 class="subhead">Possible Approach to Implementation</h4>
<blockquote>URL of a reference Web page that unambiguously indicates the item's identity. E.g. the URL of the item's Wikipedia page, Freebase page, or official website.</blockquote>
</li>
<li>
<p><a href="http://open.vocab.org/terms/similarTo"><code>ov:similarTo</code></a> defined by <a href="https://vocab.org/open/">Open.vocab.org</a>, with the description:</p>
<p><a href="https://open.vocab.org/terms/similarTo"><code>ov:similarTo</code></a> defined by <a href="https://vocab.org/open/">Open.vocab.org</a>, with the description:</p>
<blockquote>Having two things that are not the owl:sameAs but are similar to a certain extent. It is thought of being used where owl:sameAs is too strong but rdfs:seeAlso is too loose.</blockquote>
</li>
</ul>
Expand Down Expand Up @@ -3404,7 +3404,7 @@ <h4 class="subhead">Possible Approach to Implementation</h4>

<p>Approach (4) is suitable where a <a>Spatial Thing</a> has a small number of attributes that are frequently updated. For example, the GPS position of a runner or when streaming data from a sensor, such as the water level from a stream gauge.</p>

<p>With this approach, the description of the <a>Spatial Thing</a> must include a property that contains a sequentially-ordered set of data points, each of which defines a time-stamp and the values for the time-varying attribute(s). By definition, this property can be considered as a time-series <a>coverage</a>. Standard data encodings are available for time-series data, including: [[TIMESERIESML]] for [[GML]], plus [[COVJSON-OVERVIEW]] and the <a>SensorThings</a> API [[SENSORTHINGS]] for <a>JSON</a> [[RFC7159]]. [[VOCAB-DATA-CUBE]] provides a generic mechanism to express well-structured data, such as time series, in <a>RDF</a> [[RDF11-PRIMER]]. Although not yet widely used enough to be considered <em>best practices</em>, [[EO-QB]] and [[QB4ST]] (developed alongside this best practice Note within the <a href="https://www.ogc.org/projects/groups/sdwwg">Spatial Data on the Web Working Group</a>) illustrate how [[VOCAB-DATA-CUBE]] may be used in this way.</p>
<p>With this approach, the description of the <a>Spatial Thing</a> must include a property that contains a sequentially-ordered set of data points, each of which defines a time-stamp and the values for the time-varying attribute(s). By definition, this property can be considered as a time-series <a>coverage</a>. Standard data encodings are available for time-series data, including: [[TIMESERIESML]] for [[GML]], plus [[COVJSON-OVERVIEW]] and the <a>SensorThings</a> API [[SENSORTHINGS]] for <a>JSON</a> [[RFC7159]]. [[VOCAB-DATA-CUBE]] provides a generic mechanism to express well-structured data, such as time series, in <a>RDF</a> [[RDF11-PRIMER]]. Although not yet widely used enough to be considered <em>best practices</em>, [[EO-QB]] and [[QB4ST]] (developed alongside this best practice Note within the <a href="https://www.ogc.org/about-ogc/committees/swg/">Spatial Data on the Web Working Group</a>) illustrate how [[VOCAB-DATA-CUBE]] may be used in this way.</p>

<aside class="note">
<p>The OGC [[MOVING-FEATURES-XML]] and [[MOVING-FEATURES-CSV]] specifications follow the pattern described above. A <code>trajectory</code> element is used to describe the position of a <a>Spatial Thing</a>, and varying attributes (such as orientation or rotation) can be added alongside the tuples in the trajectory. However, there is limited evidence of adoption outside of Japan.</p>
Expand Down Expand Up @@ -4239,9 +4239,9 @@ <h4 class="subhead">Possible Approach to Implementation</h4>
<aside class="example" id="ex-geodcat-ap-dataset-conformance-with-specification2" title="GeoDCAT-AP specification of a dataset conformance with IHO's S44">
<pre>
a:Dataset a dcat:Dataset ;
dcterms:conformsTo &lt;<a href="https://iho.int/iho_pubs/standard/S-44_5E.pdf">https://www.iho.int/iho_pubs/standard/S-44_5E.pdf#Special</a>&gt; .
dcterms:conformsTo &lt;<a href="https://iho.int/uploads/user/pubs/standards/s-44/S-44_5E.pdf">https://iho.int/uploads/user/pubs/standards/s-44/S-44_5E.pdf#Special</a>&gt; .

&lt;<a href="https://iho.int/iho_pubs/standard/S-44_5E.pdf">https://www.iho.int/iho_pubs/standard/S-44_5E.pdf</a>&gt;
&lt;<a href="https://iho.int/uploads/user/pubs/standards/s-44/S-44_5E.pdf">https://iho.int/uploads/user/pubs/standards/s-44/S-44_5E.pdf</a>&gt;
a dcterms:Standard , foaf:Document ;
dcterms:title "IHO Standards for Hydrographic Surveys"@en ;
dcterms:issued "2008-02-01"^^xsd:date ;
Expand Down Expand Up @@ -5322,7 +5322,7 @@ <h2>Changes since the first public working draft of 19 January 2016</h2>
<ul>
<li>Focusing the document to suit the needs of practitioners: those either publishing spatial data themselves, or developing software tools to support the publication of spatial data (see sections <a href="https://www.w3.org/TR/2016/NOTE-sdw-bp-20161025/#audience">2. Audience</a> and <a href="https://www.w3.org/TR/2016/NOTE-sdw-bp-20161025/#scope">3. Scope</a>)</li>
<li>Addition of new introductory material to explain the fundamentals of spatial data to readers (see sections <a href="https://www.w3.org/TR/2016/NOTE-sdw-bp-20161025/#spatial-things-features-and-geometry">4. Spatial Things, Features and Geometry</a>, <a href="https://www.w3.org/TR/2016/NOTE-sdw-bp-20161025/#coverages">5. Coverages: describing properties that vary with location (and time)</a>, <a href="https://www.w3.org/TR/2016/NOTE-sdw-bp-20161025/#spatial-relations">6. Spatial relations</a>, <a href="https://www.w3.org/TR/2016/NOTE-sdw-bp-20161025/#linked-data">8. Linked Data</a> and <a href="https://www.w3.org/TR/2016/NOTE-sdw-bp-20161025/#why-are-traditional-sdi-not-enough">9. Why are traditional Spatial Data Infrastructures not enough?</a>)</li>
<li>Consolidation of the best practices from 30 down to 17 &mdash; based on merging duplicate or closely related best practices and focusing our scope only on spatial data concerns so that, for example, best practices relating to handling sensor data are removed (we expect these subjects to be included in future iterations of the Sensor Network deliverables of the <a href="https://www.ogc.org/projects/groups/sdwwg">working group</a>)</li>
<li>Consolidation of the best practices from 30 down to 17 &mdash; based on merging duplicate or closely related best practices and focusing our scope only on spatial data concerns so that, for example, best practices relating to handling sensor data are removed (we expect these subjects to be included in future iterations of the Sensor Network deliverables of the <a href="https://www.ogc.org/about-ogc/committees/swg/">working group</a>)</li>
<li>Alignment of the remaining best practices with those from [[DWBP]] &mdash; including organizing them according to the same sub-section headings</li>
<li>As a consequence of the consolidation and [[DWBP]] alignment, the best practices are renumbered (although the fragment-identifiers remain unchanged from those used in the <a href="https://www.w3.org/TR/2016/WD-sdw-bp-20160119/">first public working draft</a>) and the cross-reference to the Requirements from [[SDW-UCR]] (section <a href="https://www.w3.org/TR/2016/NOTE-sdw-bp-20161025/#requirements">C. Cross reference of use case requirements against Best Practices</a>) has been updated</li>
<li>Addition of a new, partially complete section (see <a href="https://www.w3.org/TR/2016/NOTE-sdw-bp-20161025/#how-to-use">10. How to use these best practices</a>) that is intended to help readers understand the steps they should take and the questions they should consider when publishing spatial data on the Web; referencing both the general [[DWBP]] best practices and those specific to spatial data described in this document</li>
Expand Down

0 comments on commit 4c71145

Please sign in to comment.