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.
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.
@prefix geom: <http://geovocab.org/geometry#> .
@prefix spatial: <http://geovocab.org/spatial#> .
@prefix : <http://example.org/> .
:Karlsruhe a spatial:Feature .
:Karlsruhe geom:geometry <http://example.org/geo/kageo> .
<http://example.org/geo/kageo> 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).
@prefix spatial: <http://geovocab.org/spatial#> .
@prefix : <http://example.org/> .
:Buenos_Aires_City spatial:PP :Buenos_Aires_Province .
:Buenos_Aires_Province spatial:PP :Argentina .
:Buenos_Aires_Province spatial:EC :Entre_Rios, :Santa_Fe, :Cordoba, :La_Pampa, :Rio_Negro, :Uruguay, :Buenos_Aires_City .
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.
@prefix spatial: <http://geovocab.org/spatial#> .
@prefix : <http://example.org/> .
:Argentina spatial:TPP :South_America .
:Argentina spatial:EC :Uruguay, :Brazil, :Paraguay, :Bolivia, :Chile .
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.
It is often useful to maintain a representation of the geometry in a format other than RDF (e.g., to provide direct compatibility with other 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.gmlAssuming 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.gmlIn the same way, some content types for common spatial representations are presented below:
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.
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.
We have identified a set of initial mappings(for example, to parts of GeoSPARQL and the U.K. Ordenance Survey Spatial Relation Ontology), however, how to make use of these mappings is still open.
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.