Contents

1. Introduction

Numerous providers publish geospatial data as Linked Data.
However, no consensus had been achieved for developing a shared RDF vocabulary with enough descriptive power for modelling geographic regions.
Every publisher (and every dataset) uses its own vocabulary, making integration difficult.
The NeoGeo Vocabulary is the result of discussions at numerous VoCamps related to geospatial data.

A common modelling choice in virtually all geospatial formats is a distinction between a Feature (a thing with spatial extent) and a Geometry (a geometric shape).
The NeoGeo Vocabulary thus makes also the distinction, and provides spatial:Feature and geom:Geometry classes.
The relation between a spatial:Feature and a geom:Geometry is geom:geometry.

2. Examples

The following example illustrates the modelling distinction between Feature and Geometry..
:Karlsruhe is a spatial:Feature, and related to http://example.org/geo/kageo, which is a geom:Geometry.

A contentious question is how to represent geospatial shapes.
Given the long tradition of Geographical Information Systems, there are many competing formats.
Providing a single RDF representation that everybody agrees upon proved difficult.
Thus, NeoGeo adopts an approach based on web architecture, namely content negotiation.
A lookup on http://example.org/geo/kageo may yield a variety of content formats.
URIs denoting a geom:Geometry can have any format based on HTTP content negotiation (see Section 4).

A second example makes more use of spatial relations.
We want to model that Argentina is a country in South America, Buenos Aires city is the capital of Argentina, but is also an independent
administrative region within the Buenos Aires province.
The following figures illustrate the example.

We first define Buenos Aires City to be a proper part (spatial:PP) of the Buenos Aires province.
The Buenos Aires province, at the same time is a proper part of Argentina and is externally connected (spatial:EC)
to Entre Ríos, Santa Fé, Córdoba, La Pampa, Río Negro, Uruguay and Buenos Aires city.
Note that spatial:EC is symmetric, and that the containment relations are transitive and always have an inverse relation
(in this case, spatial:PPi).

There are also four more specialised containment relations.
The tangential proper part (spatial:TPP), non-tangential proper part (spatial:NTPP) and
its inverses (spatial:TPPi and spatial:NTPPi respectively) are normally used when working with
the RCC-8 subset of RCC.

In the following example, Argentina is defined to be a tangential proper part of South America, and is externally connected to other countries
like Uruguay, Brazil, Paraguay, Bolivia and Chile.

3. Vocabulary

Apart from the basic classes geom:Geometry and spatial:Feature, related via geom:geometry properties, there are currently several spatial properties defined that related spatial:Features to each other.
While the vocabularies contain some more (unstable) terms, we only list the terms marked "testing" in the following.

We base our spatial vocabulary on the Region Connection Calculus (RCC), a first order theory for qualitative spatial representation and reasoning.
Spatial relations are represented in RCC via a set of binary relations.
All relations are defined in terms of a primitive relation C(x,y), which is axiomatised to be symmetric and reflexive.
C(x,y) is read as ``x is connected to y'' and holds when regions x and y share at least one common point.

The rest of the spatial relations define different degrees of connectivity between the features.
The figure above shows the hierarchy of the RCC relations.
Two spatially related (SR) discrete features (DR) can be connected (C) or disconnected (DC).
If the features are connected, but do not overlap (O), they are said to be externally connected (EC).
Also, two regions are spatially equal (EQ) if they share the same amount of space.

Relation DC(x,y), read as 'x is disconnected from y'. In order to prevent an exponential growth of triples when handling large
amounts of data, a closed world assumption may also be possible. More precisely, by considering not explicitly connected regions as discrete
regions. Moreover, discrete regions, which are not explicitly labelled as externally connected, would be considered disconnected from
each other.

Relation DR(x,y), read as 'x is discrete from y'. In order to prevent an exponential growth of triples when handling large
amounts of data, a closed world assumption may also be possible. More precisely, by considering not explicitly connected regions as discrete
regions. Moreover, discrete regions, which are not explicitly labelled as externally connected, would be considered disconnected from
each other.

Relation EC(x,y), read as 'x is externally connected with y'. This relation holds, when the two regions share at least
one common point of their borders, but share no points of their interiors, i.e. they do not overlap.

Relation NTPP(x,y), read as 'x is a non-tangential proper part of y'. This relation holds, whenever a region x is
labelled as a proper part of a region y, and they do not share common point in their borders.

Relation PP(x,y), read as 'x is a proper part of y', means that the region x is contained within the borders of the
region y, and region y is not contained within the borders of the region y, which means they are not equal.

Relation TPP(x,y), read as 'x is a tangential proper part of y'. This relation holds, whenever a region x is
labelled as a proper part of a region y, and they share at least one common point in their borders, which means that they are
externally connected.

4. Content Negotiation

It is often useful to maintain a representation of the geometry in a format other than RDF (e.g., to provide direct compatibility with GIS systems).
NeoGeo recommends to use MIME Media Type negotiation to provide access to different supported serialisations.

For example, whenever it is needed to access a GML representation of a given geometry, an HTTP Request with the following Accept header field should be sent, e.g.:

Accept: application/vnd.ogc.gml

Assuming the server is able to provide the requested file in the requested format, the HTTP Response contains the following Content-Type header field:

Content-Type: application/vnd.ogc.gml

In the same way, some content types for common spatial representations are presented below:

GML

application/vnd.ogc.gml

KML

application/vnd.google-earth.kml+xml

WKT

application/wkt

5. Related Work

The foundation for the representation of geospatial data in RDF was set in 2003, with the definition of the
W3C Geo Vocabulary. This vocabulary allows the definition of coordinates in the WGS84 coordinate reference
system, using the "latitude", "longitude" and "altitude" predicates. It also defines a "Point" class, which are resources with WGS84 coordinates. Although
the W3C Geo Vocabulary is widely used to describe WGS84 coordinates, it is does not allow the description of geometric shapes, such as the border of a country.

In 2007 the W3C Geospatial Incubator Group attempted to extend the W3C Geo Vocabulary. A set of
deliverables were produced, including a draft vocabulary, which was based on GeoRSS, an XML-Schema based
on the GML Simple Features profile. However, consensus was not achieved and the group was eventually closed.

In 2009, there was another attempt to define a common representation for geospatial data, this time by the NeoGeo
community. This attempt resulted also in a draft vocabulary, which supported the
description of spatial relations and geometries.

We intend to pick up where the first attempt of the NeoGeo community left off. Hence, we provide a new version of the vocabulary, created out of
the experiences gained over the course of the last few years.

6. Open Issues

W3C Geo only models points and does not distinguish between Geometry (lat/long) and Feature.
How to reconcile W3C Geo with NeoGeo is an open question.

NeoGeo implicitly assumes that there exist some sort of functions that are able to calculate spatial relations based on the geometric regions; however, no consensus has been reached on how to include these functions into NeoGeo.