forked from w3c/web-roadmaps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathrepresent.html
92 lines (92 loc) · 10.3 KB
/
represent.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Represent spatial data</title>
</head>
<body>
<header>
<h1>Represent spatial data</h1>
<p>There are a lot of formats, encodings, and vocabularies for representing spatial data and geometry on the Web. This roadmap gives an overview of those that are well-deployed on the Web or under development, but also those that are well-deployed in the geospatial community but less so on the Web. These are in the "Features not covered by ongoing work" section.</p>
</header>
<main>
<section class="featureset well-deployed">
<h2>Well-deployed technologies</h2>
<!--to represent spatial data: vocabularies / encodings-->
<div data-feature="Encoding any spatial data">
<p>There are several generic options for representing spatial data which are established standards: </p>
<ul>
<li><a data-featureid="rfc7946">GeoJSON</a> is a widely used format which is serialized in JSON and easy for browser-based Web applications to process, but supporting only one coordinate reference system (CRS84 - i.e., WGS 84 longitude/latitude), and geometries up to 2 dimensions (points, lines, surfaces).</li>
<li><a data-featureid="gml">Geography Markup Language (GML)</a> provides the ability to express any type of geometry, in any coordinate reference system, and up to 3 dimensions (from points to solids) but is typically serialized in XML.</li>
<li><a data-featureid="gml-sf">GML Simple Features</a> offers a profile of GML: a subset of the myriad of possibilities GML itself offers. The profile contains the most common geometry types as well as restricting the XML structures that may be used.</li>
<li><a data-featureid="geosparql">GeoSPARQL</a> is an extension of SPARQL, offering geographic query operators, but it also defines a basic ontology for geography, which can be used for publishing spatial linked data.</li>
<li><a data-featureid="ogc-georss">GeoRSS</a> is a lightweight way to extend existing RSS feeds with simple geographic information. It is an OGC-endorsed community standard. </li>
<li><a data-featureid="kml">Keyhole Markup Language (KML)</a> can be used to represent spatial things and 0D-3D geometries, mainly focussed on spatial data visualization and interaction in so-called 'earth browsers'.</li>
</ul>
</div>
<!-- to represent sensor data-->
<p data-feature="Sensor description">The <a data-featureid="vocab-ssn">Semantic Sensor Network Ontology (SSN)</a> is an ontology for describing sensors and their observations, the involved procedures, the studied features of interest, the samples used to do so, and the observed properties, as well as actuators. SSN includes a lightweight core ontology called SOSA (Sensor, Observation, Sample and Actuator) that is able to support a wide range of applications and use cases, including satellite imagery, large-scale scientific monitoring, industrial and household infrastructures, social sensing, citizen science, observation-driven ontology engineering, and the Web of Things. SOSA can be used without any reference to the full SSN ontology, which adds numerous classes, properties and axioms to SOSA and can be used for advanced linked data use cases.</p>
<!-- to represent temporal data-->
<p data-feature="Temporal data representation">The <a data-featureid="owl-time">Time Ontology</a> contains concepts for describing the temporal properties of resources in the world or described in Web pages, including relations between time instants and intervals, information about durations, and temporal position including date-time information. Not only the conventional (Gregorian) calendar and clock can be used: other temporal reference systems are also possible.</p>
<!-- to represent geometry-->
<p data-feature="Representation of geometry"><a data-featureid="sfa/wkt">Well Known Text (WKT)</a> is a compact format to represent geometry literals, used in GeoSPARQL and other spatial data representation formats, and supported in most triple stores and some web libraries. <a data-featureid="geohash">Geohash</a> is a convenient way to express a location using a short alphanumeric string. It only supports 0-dimensional geometries (points). </p>
<!-- to reference a location-->
<p data-feature="Reference a location by name">There are different ways to reference a location. One is by providing coordinates as can be done using any spatial data representation in which geometry can be represented. If the location is a spatial thing with a name and an identifier, it can be referenced instead of having to provide its coordinates. There are many popular repositories containing sets of identifiers for Spatial Things such as <a data-featureid="geonames">Geonames</a>, <a data-featureid="dbpedia">DBpedia</a>, and <a data-featureid="wikidata">Wikidata</a>.</p>
</section>
<section class="featureset in-progress">
<h2>Specifications in progress</h2>
<!--WoT Thing Description-->
<p data-feature="Description of Web-connected devices">The <a data-featureid="wot-thing-description">Web of Things Thing Description</a> specification can be used for lightweight and common representation of 'Things' which are connected to the Web. It lets you describe their metadata and interfaces. The encoding is JSON-LD. The set of terms defined is small, but it is possible to re-use terms from other models such as schema.org or SOSA/SSN. </p>
<!--to represent spatial data: vocabularies / encodings-->
<div data-feature="Encoding any geospatial data">
<p>Not an established standard, but well known, the <a data-featureid="schema.org">Schema.org vocabulary</a> is being defined as an ongoing community activity and is used to add meaningful markup to web pages and email messages. It can be used with many different encodings including RDFa, Microdata and JSON-LD. The vocabulary defines relevant concepts for spatial data such as Place and Event. </p>
</div>
</section>
<section class="featureset exploratory-work">
<h2>Exploratory work</h2>
<!--to represent spatial data: vocabularies / encodings-->
<div data-feature="Encoding coverages">
<p><a data-featureid="covjson">CoverageJSON (CovJSON)</a> is a data format for describing "coverage" data in JSON: many kinds of data whose properties vary with space, time and other dimensions, including (but not limited to) satellite imagery, weather forecasts and river gauge measurements. </p>
</div>
<div data-feature="Encoding data about cities">
<p><a data-featureid="cityjson">CityJSON</a> is a JSON-based format for encoding a subset of the <a href="http://www.opengeospatial.org/standards/citygml">CityGML</a> data model, aimed at representing 3D models of cities and landscapes. A CityJSON file represents both the 3D geometry and the semantics of the city features of a given area, such as buildings, roads, rivers, the vegetation, and the city furniture.</p>
</div>
<div data-feature="Encoding location">
<p>The <a data-featureid="locn">ISA Programme Location Core Vocabulary</a> is a common RDF-based vocabulary to describe the address or location of a spatial thing. It defines a set of general terms for describing location information that can be extended based on domain-specific requirements and covers geographical names, geometries, and postal addresses.</p>
</div>
<div data-feature="Encoding location of people and organizations">
<p><a data-featureid="vcard-rdf">The vCard Ontology</a> is an RDF-based ontology for describing people and organizations. It includes terms for describing postal addresses and 0D geometries (points, WGS 84 only).</p>
</div>
<!-- omitted WebVMT here, as it is already listed in the Capture group -->
</section>
<section class="not-covered">
<h2>Features not covered by ongoing work</h2>
<!-- many of these are OGC standards we consider not 'webby' -->
<dl>
<!--to represent spatial data: vocabularies / encodings-->
<dt data-feature="Compact spatial data representation"><a data-featureid="topojson">TopoJSON</a></dt>
<dd>A community-defined extension of GeoJSON which reduces redundancy in the description of a geometry, by splitting it into segments (referred to as "arcs") that can be re-used.</dd>
<!-- to represent sensor data-->
<dt data-feature="Representation of observations"><a data-featureid="iso-19156-2011">Observations & Measurements</a></dt>
<dd>An ISO and OGC standard for describing observations and measurements made by sensors. The format is based on XML.</dd>
<!-- to represent temporal data-->
<dt data-feature="Representation of time series">Timeseries</dt>
<dd>An OGC standard for describing measurements of the same thing that occur many times over time. There is a <a data-featureid="tsprofile">Timeseries Profile of Observations and Measurements</a> and a <a data-featureid="tsml">TimeSeriesML XML encoding</a>. </dd>
<!-- to represent moving features-->
<dt data-feature="Representation of moving features"><a data-featureid="movingfeatures">Moving features</a></dt>
<dd>An OGC standard for encoding representations of movement of geographic features. The primary use case is information exchange.</dd>
</dl>
<!-- LvdB: want to mention the Building Ontology, which the Linked building data community group (https://www.w3.org/community/lbd/) are proposing to create, here; but there is nothing yet to point at.-->
</section>
<section class="discontinued">
<h2>Discontinued features</h2>
<dl>
<!--to represent spatial data: vocabularies / encodings-->
<dt data-feature="Encoding any geospatial data"><a data-featureid="w3c-basic-geo">Basic Geo</a></dt>
<dd>A basic RDF vocabulary for representing lat(itude), long(itude) and other information about spatially-located things, using WGS84 as a reference datum. It was designed as an exercise and has not had careful review.</dd>
</dl>
</section>
</main>
<script src="../js/generate.js"></script>
</body>
</html>