index.html 39.1 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head>
<!-- saved from url=(0022)http://internet.e-mail -->


  <meta http-equiv="content-type" content="text/html; charset=UTF-8" />


  <title>W3C Geospatial Vocabulary</title>
  <link rel="Home" href="http://www.w3.org/2005/Incubator/geo/Overview.html" />


  <style type="text/css">
html, body, h2, h3, h4, div, p, ul, li, input {
font-family: "Gill Sans", "Trebuchet MS", "Gill Sans MT", sans-serif;
}
pre {
margin: auto;
background-color: #FFC;
padding: 1em;
border-color: #FC3;
border-width: 1px;
border-style: solid;
white-space: pre;
overflow:auto;
text-align: left;
}
pre strong { color: #F00;
font-weight: bold;
}
ol.req {
list-style-type: lower-alpha;
}
ol.req li {
margin-bottom: 1em;
}
dd.space {
margin-bottom: 1em;
}
.glossTerm {
background-color: rgb(255, 255, 153);
}
.mono {
font-family: monospace;
}
.caption {
text-align: center;
font-weight: bold;
font-size: 0.8em;
}
.example {
padding: 0.5em;
background-color: rgb(204, 255, 204);
}
.imgHolder {
text-align: center;
}
.oq {
border-style: dotted;
border-width: 1px;
background-color:#ccffcc;
}
td, th {
border:thin solid black;
padding: 0.5em
}
th {
text-align:left
}
  </style>

  <style type="text/css">
<!--
.style1 {color: #FF0000}
-->
  </style>

  <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-XGR" />
</head>


<body>


<div id="headings" class="head"> <a href="http://www.w3.org/"><img alt="W3C" src="http://www.w3.org/Icons/w3c_home" height="48" width="72" /></a> <a href="http://www.w3.org/2005/Incubator/XGR/"> <img alt="W3C Incubator Report" src="http://www.w3.org/2005/Incubator/images/XGR" height="48" width="160" /></a>
<h1>W3C Geospatial Vocabulary</h1>


<h2>W3C Incubator Group Report 23 October 2007</h2>


<dl>


  <dt>This version:</dt>


  <dd><a href="http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023/">http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023/</a></dd>


  <dt>Latest version:</dt>


  <dd><a href="http://www.w3.org/2005/Incubator/geo/XGR-geo/">http://www.w3.org/2005/Incubator/geo/XGR-geo/</a></dd>


  <dt>Authors:</dt>


  <dd><a href="http://www.traversetechnologies.com">Joshua
Lieberman</a></dd>


  <dd><a href="http://www.opengeospatial.org/">Raj
Singh</a></dd>


  <dd><a href="http://www.platial.com/">Chris Goad</a></dd>


</dl>


<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
&copy; 2007 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&reg;</sup>
(<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>,
<a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All
Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply.</p>


</div>


<hr />
<div id="abstract">
<h2>Abstract</h2>


<p>This is a report of the W3C Geospatial Incubator Group
(GeoXG) as specified in the Deliverables section of its charter.</p>


<p>In this report we define a basic ontology and OWL vocabulary
for representation of geospatial properties for Web resources.</p>


<p>Specifically the report:</p>


<ul>


  <li>discusses the need for updating the <a href="http://www.w3.org/2003/01/geo/">W3C 2003 geo</a>
vocabulary,</li>


  <li>presents a model for basic feature properties of Web
resources,</li>


  <li>presents realizations of these feature property elements as
XML and as OWL/RDF vocabularies,</li>


  <li>describes use of the XML elements in Web feeds such as RSS
and Atom,</li>


</ul>


<p>The report identifies futher applications of this vocabulary
which require additional discussion and specification. The intention is
that it form input for a subsequent W3C geospatial activity.</p>


</div>


<div id="status">
<h2>Status of this document</h2>


<p><em>This section describes the status of this document
at the time of its publication. Other documents may supersede this
document. A list of <a href="http://www.w3.org/2005/Incubator/XGR/">Final
Incubator Group Reports</a> is available. See also the <a href="http://www.w3.org/TR/">W3C technical reports index</a>
at http://www.w3.org/TR/.</em></p>


<p>This document was developed by the <a href="http://www.w3.org/2005/Incubator/geo/">W3C Geospatial
Incubator Group</a>. It represents the consensus view of the
group, in particular those listed in the <a href="#ack">acknowledgements</a>,
on the use cases, requirements and general approach that should be
taken in meeting the identified needs.&nbsp; The&nbsp;
vocabulary as
presented is a complete update to the 2003 geo vocabulary and is
recommended to supercede it, but does retain backwards compatibility
with the essential properties of the earlier vocabulary. Earlier
informal drafts of this
report are <a href="http://www.w3.org/2005/Incubator/wcl/XGR-report-20060811/">archived</a>.</p>


<p>Publication of this document by W3C as part of the <a href="http://www.w3.org/2005/Incubator/">W3C Incubator
Activity</a> indicates no endorsement of its content by W3C, nor
that W3C has, is, or will be allocating any resources to the issues
addressed by it. Participation in Incubator Groups and publication of
Incubator Group Reports at the W3C site are benefits of <a href="http://www.w3.org/Consortium/join">W3C Membership</a>.</p>


<hr /></div>


<div>
<h2><a name="toc" id="toc">Table of Contents</a></h2>


<ul class="toc">


  <li>1&nbsp;<a href="#intro">Introduction</a>

    <ul>


      <li>1.1 <a href="#examples">Examples</a></li>


      <li>1.2 <a href="#detailedRequirements">Detailed
Requirements</a></li>


      <li>1.3 <a href="#participants">Participants</a></li>


    </ul>


  </li>


  <li>2 <a href="#model">The GeoRSS Model</a></li>


  <li>3&nbsp;<a href="#encodings">GeoRSS
Encodings</a>

    <ul>


      <li>3.1&nbsp;<a href="#xml">GeoRSS XML</a></li>


      <li>3.2&nbsp;<a href="#owl">Geo OWL</a></li>


    </ul>


  </li>


  <li>4&nbsp;<a href="#XGRsummary">Summary</a></li>


  <li>5&nbsp;<a href="#glossary">Glossary</a></li>


  <li>6&nbsp;<a href="#refs">Links and References</a></li>


  <li>7&nbsp;<a href="#ack">Acknowledgements</a></li>


  <li>Appendix&nbsp; <a href="#appendix1">Original
Use Cases &amp; Requirements</a></li>


</ul>


<hr /></div>


<div>
<h2><a name="intro" id="intro">1 Introduction</a></h2>


<p>The geospatial incubator group was <a href="http://www.w3.org/2005/Incubator/geo/charter">chartered</a>
to begin addressing issues of location and geographical properties of
resources for the Web of today and tomorrow, by taking a concrete step
to update the W3C GEO vocabulary, laying the groundwork for a more
comprehensive geospatial ontology, and formulating a proposal for a
W3C&nbsp; Working Group to develop recommendations to further the
Web representation of physical location and geography.</p>


<p>The Incubator's work has been greatly influenced by the work
of the <a href="http://www.opengeospatial.org">Open
Geospatial Consortium (OGC)</a>,<a href="http://www.isotc211.org/"> ISO/TC 211,</a> and <a href="http://www.georss.org">georss.org</a>. While the
rigor of the OGC and ISO/TC 211 General Feature Model is essential for
clarity of spatial representations, the&nbsp;breadth and depth of
geographic
information handling developed by those organizations is considered to
be beyond the needs of most Web
use cases. The Incubator has followed the lead of GeoRSS in seeking to
complement those efforts with a
simpler baseline implementation of geospatial resource description for
the Web.</p>


<p>A set of <a href="http://www.w3.org/2005/Incubator/geo/charter#cases">use
cases</a> demonstrates the aims in more detail. A set of high
level requirements was derived from the use cases that were then
formalized for the work presented in this report.&nbsp;A model has
been developed that encapsulates the issues discussed and
discovered during the XG's work. Comments are also made on possible
system architectures for geotag use, and a detailed glossary is
provided.&nbsp;Throughout the Incubator Activity, decisions have
been taken
via consensus during regular telephone conferences, online
collaboration, and face to face meetings.</p>


<p>The Incubator Group is now considering the approach of
re-forming as a W3C geospatial interest group to further the activity
of developing geospatial foundation vocabularies and considering the
geospatial aspects of other W3C activities.</p>


<div id="examples">
<h3><a name="examples">1.1 Examples</a></h3>


<p>For continuity, these examples follow the general pattern of
those from the <a href="http://www.w3.org/2003/01/geo/#example">
Basic Geo Vocabulary</a>.</p>


<p>A basic <a href="W3C_XGR_Geo_files/example1.rdf">example</a> showing one way to assign location to a person
that combines Geo and <a href="http://www.foaf-project.org/">FOAF</a>
vocabularies:
</p>


<pre>&lt;rdf:RDF xmlns="http://xmlns.com/foaf/0.1/" <br /> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <br /> <span style="color: rgb(255, 0, 0);">xmlns:geo="http://www.georss.org/georss/"</span>&gt;<br /> &lt;Person&gt;<br /> &lt;name&gt;Josh Lieberman&lt;/name&gt;<br /> <span style="color: rgb(255, 0, 0);">&lt;geo:point&gt;42.34 -71.21&lt;/geo:point&gt;</span><br /> &lt;/Person&gt;<br />&lt;/rdf:RDF&gt;</pre>


<p>A similar <a href="W3C_XGR_Geo_files/example2.rdf">example</a> using Geo's GML syntax that increases the
semantic meaning of the location using <a href="http://www.foaf-project.org/">FOAF</a>'s
based_near concept:
</p>


<pre>&lt;rdf:RDF xmlns="http://xmlns.com/foaf/0.1/" <br /> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <br /> <span style="color: rgb(255, 0, 0);">xmlns:gml="http://www.opengis.net/gml</span>/"&gt;<br /> &lt;Person&gt;<br /> &lt;name&gt;Josh Lieberman&lt;/name&gt;<br /> &lt;based_near&gt;<br /> <span style="color: rgb(255, 0, 0);">&lt;gml:Point&gt;</span><br style="color: rgb(255, 0, 0);" /><span style="color: rgb(255, 0, 0);"> &lt;gml:pos&gt;42.34 -71.21&lt;/gml:pos&gt;</span><br style="color: rgb(255, 0, 0);" /><span style="color: rgb(255, 0, 0);"> &lt;/gml:Point&gt;</span><br /> &lt;/based_near&gt;<br /> &lt;/Person&gt;<br />&lt;/rdf:RDF&gt;</pre>


<p>An <a href="W3C_XGR_Geo_files/example3.rdf">example</a> of geo-coding with RSS 1.0:
</p>


<pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;<br />&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <br /> <span class="style1">xmlns:geo="http://www.georss.org/georss/"</span> <br /> xmlns="http://purl.org/rss/1.0/"&gt;<br /><br />...<br /><br /> &lt;item rdf:about="http://example.com/geo"&gt;<br /> &lt;title&gt;A walk in the park&lt;/title&gt;<br /> &lt;link&gt;http://example.com/geo&lt;/link&gt;<br /> &lt;description&gt;Just an example&lt;/description&gt;<br /> <span class="style1">&lt;geo:line&gt;40.73158 -73.999559 40.732188 -73.999079 40.732688 -74.0234&lt;/geo:line&gt;</span><br /> &lt;/item&gt;<br /><br /> ...<br /><br />&lt;/rdf:RDF&gt;</pre>


</div>


<div id="detailedRequirements">
<h3><a name="detailedRequirements">1.2 Detailed
Requirements</a></h3>


<p>Based on the <a href="http://www.w3.org/2005/Incubator/geo/charter#cases">use
cases</a> and the original high level requirements that were
derived from them, a set of more detailed requirements was established.
The group decided to adopt the GeoRSS feature model, allowing the
description of <strong>rectangles, points, lines, and polygons</strong>
as geometric representation properties of discerned geographic
features.
This is slightly different and substantially reduced from the <a href="http://www.opengeospatial.org/standards/sfs">OpenGIS&reg;
Simple Features</a> model, which is widely used in spatial
databases. Simple Features' geometric representations consist of point
and multipoint, curve (a.k.a. line) and multicurve, surface (polygon)
and multisurface. Note that Simple Features does specify a rectangle. A
rectangle is a specialization of a surface, but for clarity and
simplicity this group felt it worthwhile to follow the example of
georss.org and define it separately. In all cases, however, the
essential nature of the ISO General Feature Model is preserved, which
separates the discernment of a feature object such as a city from the
particular coordinate geometry property such as a point or a polygon by
which it may be represented. </p>


<p>At this point, the Incubator has completed work on the
geometric model described above, along with its instantiation in RDF
and OWL. The group was not able to get as far with a model for spatial
relationships. The most common spatial relationships in use are <strong>equals,
disjoint, intersects, touches, crosses, within, contains, and overlaps</strong>.
These can be tremendously useful in many of the group's <a href="http://www.w3.org/2005/Incubator/geo/charter#cases">use
cases</a>. For example, in use case 4 the researcher wants to
find county-level recycling programs. One would need to describe the
fact that a recycling program is <strong>within</strong> a
particular county; or that a semantic model of a facility would want to
describe that a printer was <strong>within</strong> a
certain room, and that the room <strong>touches</strong>
hallway A-14. While these core spatial relationships are well
established
within the geographic sciences, this group was not able to validate
them as a necessary and sufficient representation in the Web context,
nor develop
specific semantic encodings in the
initial time frame.</p>


<p>In summary, the Geo XG has successfully developed a basic
geography model that can update the W3C GEO vocabulary, as stated in
its charter. The group identified a core set of spatial relationships
as well as other significant <a href="http://www.w3.org/2005/Incubator/geo/GeoOntology.html">geospatial
ontology components or categories</a>,
but implementation of these in W3C is an item for future work.</p>


</div>


<div>
<div id="participants">
<h3><a name="s1_1">1.3 Participants</a></h3>


<p>The companies and organizations that participated in or
supported GEO XG are as follows:</p>


<ul>


  <li>Open Geospatial Consortium</li>


  <li>SRI</li>


  <li>USC ISI</li>


  <li>Stanford University</li>


  <li>Oracle Corporation</li>


  <li>Traverse Technologies</li>


  <li>Platial</li>


  <li>High Earth Orbit</li>


</ul>


</div>


</div>


<h2><a name="model" id="model">2 The GeoRSS
Model</a></h2>


<p>Such a discussion leads us to the GeoRSS Feature Model as
shown in Figure&nbsp;1. The model provides a general feature
property which can be used to characterize any appropriate content as a
geographic feature. Specific subproperties such as
&lt;where&gt; associate the discerned feature with one of a
limited number of&nbsp; geometry types which provide a numerical
representation for analysis and visualization. Other subproperties
describe additional commonly used feature attributes such as feature
name and feature type.&nbsp;</p>


<p><img style="width: 640px; height: 326px; float: right;" alt="GeoRSS Feature Model" title="GeoRSS Feature Model" src="W3C_XGR_Geo_files/georss_model.png" /></p>


<p></p>


<p>While this model is consistent in essence with ISO standards,
it supports a subtle difference in emphasis, providing a Web-like
feature view or aspect to existing content rather than a database-like
content-specialized subclass to an existing abstract feature. The
latter is suitable and effective for many geographic information
applications but is too constrained for working with Web resources in
general.</p>


<div> Specific model objects shown in Figure 1 are described
below
<h4> <a name="where" id="where">&lt;where&gt;</a></h4>


<p style="margin-left: 40px;">Ths is the general geometry
property for&nbsp;GeoRSS GML. The GeoRSS Simple properties combine
this property with the corresponding geometry and coordinate property
to produce single-tag geometry properties.</p>


</div>


<h4><a name="point"></a>
&lt;point&gt;</h4>


<p style="margin-left: 40px;">A point contains a single
coordinate pair. The coordinate pair contains a latitude value and a
longitude value in that order. The preferred serialization of this uses
a space to separate the two values.</p>


<h4><a name="line"></a>&lt;line&gt;</h4>


<p style="margin-left: 40px;">A line contains two or more
coordinate pairs. Each pair contains a latitude value and a longitude
value in that order. The preferred serialization of this uses a space
to separate the two values. Pairs are separated from each other by a
space.</p>


<h4><a name="polygon"></a>&lt;polygon&gt;</h4>


<p style="margin-left: 40px;">A polygon contains at least
four coordinate pairs. Each pair contains a latitude value and a
longitude value in that order. The preferred serialization of this uses
a space to separate the two values. Pairs are separated from each other
by a space. The last coordinate pair must be identical to the first.</p>


<h4><a name="box"></a>&lt;box&gt;</h4>


<p style="margin-left: 40px;">A box contains exactly two
coordinate pairs. Each pair contains a latitude value and a longitude
value in that order. The preferred serialization of this uses a space
to separate the two values. Pairs are separated from each other by a
space. The first coordinate pair (lower corner) must be a point further
west and south of the second coordinate pair (upper corner) and the box
is always interpreted as not containing the 180 (or -180) degree
longitude line other than on its boundary and not containing the North
or South pole other than on its boundary. A box is generally used to
roughly demarcate an area within which other data lie.</p>


<h4><a name="featuretypetag"></a>&lt;featuretypetag&gt;</h4>


<p style="margin-left: 40px;">GeoRSS geometry is meant to
represent a real feature of the Earth's surface. The GeoRSS model
allows for a single string containing a featuretypetag. No constraints
are placed on this string. The intent is to allow a Feature Type
folksonomy to emerge. The default is "location".</p>


<h4><a name="featurename"></a>&lt;featurename&gt;</h4>


<p style="margin-left: 40px;">A GeoRSS geometry may
represent a well-known feature with a well-known name. The GeoRSS model
allows for a single string containing a feature name.&nbsp;</p>


<h4><a name="relationshiptag"></a>&lt;relationshiptag&gt;<br />


</h4>


<p style="margin-left: 40px;">GeoRSS is a way of relating
Web content to Earth features. The GeoRSS model allows for a single
string containing a relationshiptag. No constraints are placed on this
string. The intent is to allow a relationship folksonomy to emerge.The
default relationship, "is-located-at" simply indicates that the subject
of the content is located at the GeoRSS feature. </p>


<h4><a name="elev"></a>&lt;elev&gt;</h4>


<p style="margin-left: 40px;">Elev is meant to contain
"common" GPS elevation readings, i.e. height in meters from the WGS84
geoid, which is a reading that should be easy to get from any GPS
device.</p>


<h4><a name="floor"></a>&lt;floor&gt;</h4>


<p style="margin-left: 40px;">Floor is meant to contain
the floor number of a building. In some countries the numbering is
different than in other countries, but since we'll know the location of
the building, it should be fairly unambiguous.</p>


<h4><a name="radius"></a>&lt;radius&gt;</h4>


<p style="margin-left: 40px;">Since a GeoRSS geometry is
only one representation of a given feature, coordinate precision may
not give a clear idea of the precision of representation. The radius
property is a distance in meters expressing that precision, e.g. within
1000 meters of the given point rather than exactly on the point.</p>


<div>
<h2><a name="encodings" id="encodings">3
Serializations and Encodings</a></h2>


<p>As shown in Figure 1, GeoRSS feature properties may be applied
to a range of content in a variety of Web resource contexts. This has
led to development of alternative serializations. Specifically, GeoRSS
Simple collapses the object structure of GeoRSS GML to support
single-element feature properties but is exactly equivalent in meaning
to the GeoRSS GML serialization.&nbsp;</p>


<p>The primary encoding presented in this report is OWL RDF but
the definition of this encoding has been intended to support XML
elements as close as possible to those defined by the GeoRSS XML
Schema&nbsp; which in turn has been developed for use with RSS and <a href="#atom">ATOM</a>.&nbsp;</p>


<h3><a name="xml" id="xml">3.1 GeoRSS XML</a></h3>


For an XML encoding of the GeoRSS model, an XML Schema definition is
contained in two files. The first file is a strict and valid <a href="http://www.georss.org/xml/1.1/gmlgeorss.xsd">GeoRSS GML
profile</a> which includes only the elements of the larger GML
schema required to support GeoRSS GML. This schema profile is a
convenience only: by definition any XML document which validates
against the profile schema will also validate against the full
schema. Nevertheless it is useful for constraining what GML elements
are compatible with the GeoRSS model. The latest version will be
available from georss.org and OGC for this purpose.<br />


<br />


The second file defines those <a href="http://www.georss.org/xml/1.1/georss.xsd">GeoRSS
XML</a>
elements belonging to georss itself which in turn derive from or
include GML elements from the profile schema. The latest version of
this schema will be available from georss.org.<br />


<br />


Perhaps needless to say, but important to mention, XML Schema is not
sufficiently expressive to fully constrain the expresssions and usage
of GeoRSS XML, particularly within RSS and Atom but also in other
contexts. The full definition of GeoRSS XML includes text explanations
maintained at georss.org.&nbsp;
<h3><a name="owl" id="owl">3.2 Geo OWL</a></h3>


<p> <a href="W3C_XGR_Geo_files/geo_2007.owl"><strong>Geo
OWL</strong></a>
provides an ontology which closely matches the GeoRSS feature model and
which utilizes the existing GeoRSS vocabulary for geographic properties
and classes. The practical consequence is that fragments of GeoRSS XML
within RSS 1.0 or Atom which conform to the GeoRSS specification
will also conform to the Geo OWL ontology (front-matter aside).
Thus, the ontology provides a compatible extension of GeoRSS practice
for use in more general RDF contexts.</p>


<p>The ontology consists of a root
property <strong>_featureproperty</strong> which takes as
its domain any OWL/RDF class that it makes sense (after ISO 19109) to
cast as a geographic feature. The property&nbsp;<strong>_featureproperty&nbsp;</strong>&nbsp;has
a series of
subproperties. A particular subproperty is <strong>geo:where</strong>
which takes as its range the abstract class <strong>_geometry</strong>.</p>


<span class="anchor" id="line-17"></span>Subclasses
of <strong>_geometry</strong> include <strong>gml:Point</strong>,
<strong>gml:Linestring</strong>, <strong>gml:Polygon</strong>,<strong></strong>
and <strong>gml:Envelope</strong> after the corresponding <a class="http" href="http://schemas.opengis.net/gml/3.1.1/">GML</a>
objects. The
properties of these classes are a subset of the corresponding
properties defined in the GML model and schema. This
represents <em><strong>GeoRSS GML</strong></em>.<span class="anchor" id="line-18"></span>
<p class="line862">Other subproperties of <strong>geo:where</strong>
represent <em><strong>GeoRSS Simple</strong></em>
and include <strong>geo:Point</strong>, <strong>geo:Line</strong>,
<strong>geo:Polygon</strong>, <strong>geo:Circle</strong>,
and <strong>geo:Box</strong>. These
properties each take a literal list of doubles as their range, but are
equivalent in definition to (are a shorthand for) <strong>geo:where</strong>
plus the corresponding GeoRSS GML classes and their properties.</p>


<p class="line862">For backwards compatibility, <span style="font-weight: bold;">geo:lat</span> and <span style="font-weight: bold;">geo:long</span> are
retained as subproperties of geo:where, but are taken together as the
equivalent of geo:where plus gml:Point plus gml:pos, or of geo:Point.
<span class="anchor" id="line-23"></span><span class="anchor" id="line-24"></span></p>


<p class="line862">Another set of subproperties of <strong>_featureproperty</strong>
further define the "featureness" of whatever class the geometry
properties are applied to. They
include <strong>geo:featurename</strong>, <strong>geo:featuretype</strong>,
<strong>geo:relationship</strong>, <strong>geo:elev</strong>,
<strong>geo:floor</strong>, and <strong>geo:radius</strong>.
The
nominal ranges of the first three properties are literal strings (for
the latter three, doubles), but are envisioned to represent or evolve
first
into "folksonomies" and later into more formal ontology concepts. <span class="anchor" id="line-27"></span><span class="anchor" id="line-28"></span></p>


<p class="line862">The Geo OWL vocabulary is nominally
classified as OWL Lite, but what this designation means for
decidability in terms of spatial reasoning is at present uncertain. <span class="anchor" id="line-29"></span><span class="anchor" id="line-30"></span><span class="anchor" id="line-31"></span></p>


</div>


<div>
<h2><a name="XGRsummary" id="XGRsummary">4&nbsp;Summary</a></h2>


<p>The Geospatial Incubator Group began with a simple mission and
a
likely candidate vocabulary.&nbsp;</p>


<p>The open questions raised throughout the XG process as
reported in this document are collated and presented below in no
particular order of priority.</p>


<ul>


  <li>Does the present vocabulary represent the best balance
between expressiveness and simplicity for ubiquitous usage?</li>


  <li>How can constraints on the vocabulary and usage be better
expressed? For example, many of the literals in the vocabulary do not
have an appropriate constraint in OWL, RDFS, or XML Schema.</li>


  <li>Would an alternate no-whitespace text encoding of
latitude-longitude+/-altitude be worth its conflict with GML coordinate
encoding?</li>


  <li>Should the vocabulary be extended to include temporal terms
which
reference specifically the temporal extent / validity of features, or
are existing vocabularies such as OWL Time sufficient?</li>


  <li>Should the vocabulary be extended to include address
encoding, or are existing vocabularies such as vCard sufficient? </li>


  <li>How can this vocabulary be used for finer-grained
geotagging,
particularly of HTML? The most straightforward approach seems to be
RDFa, but this is not completely valid in XHTML. Is there a role for
GRDDL in formulating tags, for example, following some microformats
practice, and being able to recover the actual geo vocabulary terms?</li>


  <li>How can the vocabulary be used for searching and querying?
Is it
a matter of just implementing SPARQL, or are specific extensions /
additions needed to enable spatial comparisons.</li>


  <li>What formalizations of the non-geometric property literals,
such
as &lt;relationshiptag&gt; are needed to fully satisfy the
group's use
cases and others like them?</li>


  <li>What is the best way to carry forward the work on these
questions
and stewardship of the geo vocabulary within W3C and elsewhere?</li>


</ul>


</div>


<br />


<div>
<h2><a name="glossary" id="glossary">5&nbsp;Glossary</a></h2>


<p>The following terms are used throughout this report.
Definitions have been collected from <a href="http://www.w3.org/2003/glossary/">W3C glossaries</a>
where possible and provided <em>a priori</em> where
necessary.</p>


<p><strong><a name="gtAssertion" id="gtAssertion">Assertion</a></strong>
Any <span class="glossTerm">expression</span> which
is claimed to be true. [<a href="http://www.w3.org/2003/glossary/subglossary/rdf-mt.rdf/">W3C
definition source</a>]</p>


<p><strong><a name="gtCategory" id="gtCategory">Category</a></strong>
A thematically-related sub-group of <span class="glossTerm">terms</span>
within a <span class="glossTerm">vocabulary</span>.</p>


<p><strong><a name="gtClassification" id="gtClassification">Classification</a></strong>
A specialization of a <span class="glossTerm">description</span>;
one that is pre-defined .</p>


<p><strong><a name="gtResource" id="gtResource">Resource</a></strong>
Anything that might be identified by a URI. [<a href="http://www.w3.org/2003/glossary/subglossary/webarch.rdf/">W3C
definition source</a>]</p>


<p><strong><a name="gtSchema" id="gtSchema">Schema</a></strong>
(pl., schemata) A document that describes an <a href="http://www.w3.org/XML/">XML</a> or <a href="http://www.w3.org/RDF/">RDF</a> <span class="glossTerm">vocabulary</span>. Any document
which describes, in a formal way, a language or parameters of a
language. [ <a href="http://www.w3.org/2003/glossary/subglossary/weaving.rdf/60">W3C
definition source</a>]</p>


<p><strong><a name="gtVocab" id="gtVocab">Vocabulary</a></strong>
A collection of <span class="glossTerm">vocabulary terms</span>,
usually linked to a document that defines the precise meaning of the <span class="glossTerm">descriptors</span> and the domain in
which the vocabulary is expected to be used. When associated with a <span class="glossTerm">schema</span>, attributes are
expressed as URI references. [This definition is an amalgam of those
provided in <a href="http://www.w3.org/2003/glossary/subglossary/CCPP-struct-vocab.rdf/">Composite
Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0</a>
and <a href="http://www.w3.org/2003/glossary/subglossary/owl-guide.rdf/20">OWL
Web Ontology Language Guide</a>.]</p>


<p><strong><a name="gtVocabTerm" id="gtVocabTerm">Vocabulary
term</a></strong> An attribute that can describe one or
more <span class="glossTerm">resources</span> using
a defined set of values or data type. Attributes may be expressed as a
URI reference. See also <span class="glossTerm">descriptor</span>
and <span class="glossTerm">expression</span>.</p>


<p><strong><a name="gtWellFormed" id="gtWellFormed">Well-formed</a></strong>
Syntactically legal. [<a href="http://www.w3.org/2003/glossary/subglossary/rdf-mt.rdf/20">W3C
definition source</a>]</p>


</div>


<div>
<h2><a name="refs" id="refs">6&nbsp;Links
and References</a></h2>


<dl>


  <dt><a name="dc" id="dc">Dublin Core</a></dt>


  <dd><a href="http://dublincore.org/">http://dublincore.org/</a></dd>


  <dt><a name="foaf" id="foaf">Georss.org</a></dt>


  <dd><a href="http://www.georss.org/">http://www.georss.org/</a></dd>


  <dt><a name="date" id="date">OWL Time</a></dt>


  <dd>Defined in the&nbsp;<a href="http://www.isi.edu/%7Epan/OWL-Time.html">http://www.isi.edu/~pan/OWL-Time.html</a></dd>


  <dt><a name="vcard" id="vcard">vCard</a></dt>


  <dd><a href="http://www.imc.org/pdi/">IMC
specification</a>; <a href="http://www.w3.org/TR/vcard-rdf">W3C
Note on encoding vCard in RDF/XML</a></dd>


  <dt><a name="rdf" id="rdf">RDF</a></dt>


  <dd><a href="http://www.w3.org/RDF/">http://www.w3.org/RDF</a></dd>


  <dt><a name="atom" id="atom">ATOM</a></dt>


  <dd><a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">http://www.atomenabled.org/developers/syndication/atom-format-spec.php</a></dd>


  <dt><a name="RSS1.0" id="rss1.0">RSS 1.0</a></dt>


  <dd><a href="http://web.resource.org/rss/1.0/spec">http://web.resource.org/rss/1.0/spec</a></dd>


  <dt><a name="RSS2.0" id="rss2.0">RSS 2.0</a></dt>


  <dd><a href="http://cyber.law.harvard.edu/rss/rss.html">http://cyber.law.harvard.edu/rss/rss.html</a></dd>


  <dt><a name="rdfa" id="rdfa">RDFa</a></dt>


  <dd><a href="http://www.w3.org/TR/xhtml-rdfa-primer/">http://www.w3.org/TR/xhtml-rdfa-primer/</a></dd>


  <dt><a name="grddl" id="grddl">GRDDL</a></dt>


  <dd><a href="http://www.w3.org/2004/01/rdxh/spec">Gleaning
Resource Descriptions from Dialects of Languages</a></dd>


  <dt><a name="sparql" id="sparql">SPARQL</a></dt>


  <dd><a href="http://www.w3.org/TR/rdf-sparql-query/">SPARQL
Query Language for RDF</a></dd>


</dl>


</div>


<div>
<h2><a name="ack" id="ack">7&nbsp;Acknowledgements</a></h2>


<p>The editors acknowledge significant contributions from:</p>

</div>


<ul>


  <li>John Goodwin, Ordnance Survey</li>


  <li>Andrew Turner, High Earth Orbit</li>


  <li>Mike Liebhold, Institute for the Future</li>


  <li>Satoru Tagaki, YRP Ubiquitous Computing Laboratory</li>


</ul>


<hr />
<div>
<h2><a name="appendix1" id="appendix1">Appendix
</a></h2>


<h2><a name="cases" id="cases"></a>Original
Use Cases</h2>


<p>The demand for flexible and powerful geospatial enablement of
the Web is exemplified in the following use cases.</p>


<h3><a name="use1" id="use1"></a>Use
case 1: Find stuff nearby</h3>


<p>Web publishers have tagged their HTML content with a variety
of
standard geographic properties, including absolute geometries,
well-known placenames, street addresses, and geospatial domain
addresses. Internet search engines have translated and indexed
these geospatial properties according to location and content
relationship. Web user Harold shares his location in a search
request for available sports-related resources within 15 minutes
travel time. An initial search for nearby transportation uncovers
roads, trails, and a commuter rail line which define a travel time
envelope. A second search finds a number of Web pages which refer
to sports-related resources within the envelope. The resources
include a sports bar within walking distance and the segment of a
lake shore recreation area within driving distance. It does
<i>not</i> include the travel blog of Maude, a former
professional
triathlete sitting at a cafe nearby, because the current blog entry
is tagged by a geospatial domain name which can only be resolved to
an absolute location by requests from an identified group of
friends or emergency response organizations. Since the local time
of the search is 9:15 pm and the lake park closes at 9 pm, the home
page of the sports bar is listed first.</p>


<h3><a name="use2" id="use2"></a>Use
case 2: News of the world</h3>


<p>Web news services provide their stories in the form of GeoRSS
feeds. Sven at UNHCR is tasked with monitoring both new and known
areas for refugee issues. He utilizes an aggregator service which
plots on a world map the locations of public news items which also
reference refugee issues. Sven's GeoRSS client also allows him to
visualize private news feeds of current UNHCR activities and
available relief resources. Sven is able to use several map
visualization techniques to look at the combined distribution and
nature of events referenced by the public and private news feeds.
Clicking on a particular entry, he brings up that entry's source
news story or internal report. Once he has identified a significant
collection of events and commented on it, he saves a Web map
context document (WMC) with GeoRSS annotations, specific Web Map
Server requests, and general map tile references to his weblog. UN
colleagues who subscribe to Sven's weblog feed receive a GeoRSS
news item outlining his area of interest and follow it to bring up
the news map he has constructed for them.</p>


<h3><a name="use3" id="use3"></a>Use
case 3: New knowledge from old geography</h3>


<p>A new educational initiative has published to the Web in
geo-enabled form the results of many years of scientific and
cultural study related to Breechcloth National Monument. Joe, a
Park Service volunteer organizes virtual tours by publishing Web
pages which reference those Web resources related to a particular
theme along popular hiking trails. Mary, a park visitor, is able to
assemble her own personal tours by drawing a path of interest on a
visitor center kiosk and searching for resources of a particular
time and theme of interest. Since the wireless connectivity in the
Monument is not yet widespread, she downloads the tour into her
GPS-equipped phone to take along. Her personal tour includes
geoweblog entries and photos posted by visitors two years previous
at a time when heavy rains caused many unusual plants to bloom
along her chosen (and now quite dusty) path. Another tour resource
is a page describing the site of a rare archaeological find. Mary is
able to view the photographs and drawings on her phone, but the
public page is only tagged with a rather large bounding box to
reduce the risk of a visitor finding and damaging the site itself.
Park personnel and researchers have access to a separate page
tagged with the actual GPS coordinates of the site.</p>


<h3><a name="use4" id="use4"></a>Use
case 4: Follow the
geography</h3>


<p>Alice is preparing a grant proposal to support a new recycling
initiative in Nepotist County. She wants to research county-level
recycling programs worldwide. Firing up her semantic search client,
she initiates a SPARQL query which includes among others the
concepts of "county",
"spatialScaleOf", and
"recycling". Referencing a
geospatial ontology, the query agent infers further geospatial
concepts such as county instances and the names of county
equivalents such as "parish" within
the state of Louisiana. Inferred queries are passed on to other
query agents which resolve county locations and synonyms, as well
as concepts related to "recycling"
such as "waste disposal",
"sanitation", and
"reuse". Filter agents reason on
"spatialScaleOf" to eliminate
discovered knowledge which is too limited in scale. Semantic
similarity analysis finally returns to Alice information about a
recycling program only two counties over which is a good model for
her proposal but has been sparsely documented as
"regional resource recovery". The
query agent also processes her personal context with the query and
returns unexpected references to two foundations with new programs
to fund combined recycling and clean government initiatives.</p>


<h3><a name="useSum" id="useSum"></a>Use
case summary</h3>


<p>These use cases serve to illustrate that tagging Web pages
with
latitude-longitude coordinates is only a starting point to the
geospatial representations, relationships, resources, and
interfaces which will form the functional basis of the Local
Web.<a name="ORIGuse1" id="ORIGuse1"><br />


</a></p>


</div>


<div>
<h3><a name="reqs" id="reqs">Requirements</a></h3>


<p>The following requirements have been approved by the group.</p>


<ol>


  <li>

    <p>A consistent vocabulary is needed to identify geospatial
aspects of a variety of Web resources.</p>


  </li>


  <li>

    <p>The geospatial vocabulary should be consistent with OGC
and ISO standards and the General Feature Model, but simple enough for
widespread application.</p>


  </li>


  <li>

    <p>The vocabulary should describe geospatial aspects of
existing resources and not require their reformulation as geodata.</p>


  </li>


  <li>

    <p>The vocabulary should include both highly constrained
single-term properties for ubiquitous use and more configurable terms
from GML for more specialized uses.</p>


  </li>


  <li>

    <p>The vocabulary should be serialized both in XML and as an
equivalent OWL ontology for greatest flexibility.</p>


  </li>


  <li>

    <p>The vocabulary should be backwards compatible (i.e.
include the most commonly used terms) from the 2003 geo vocabulary.</p>


  </li>


  <li>

    <p>The vocabulary should be complete in itself but include
points of extension for future formalization of additional spatial
concepts and knowledge.</p>


  </li>


</ol>


<p><br />


</p>


</div>


<hr /><br />


</div>


</body>
</html>