1. Introduction

Currently numerous datasets provide GeoData as Linked Data. However, no consense had been achieved for developing an
RDF vocabulary with enough descriptive power to satisfy most requirements of these datasets. For this reason,
nowadays every dataset uses its own vocabulary to describe GeoData. In order to address this matter, some of the best known datasets representing
complex georeferenced geometries contributed its experiences and from this requirements, it was possible to develop a common vocabulary for the representation of
GeoData and propose a way of exposing different serializations of this data, enhancing the compatibility with GIS systems.

The NeoGeo Vocabulary is based on the GML Simple Features Profile, from the
Open Geospatial Consortium. Simple geometries are described (along with its coordinates) explicitly in RDF,
and composite geometries are described as an aggregation of simple geometries. This approach allows reasoning and querying on these geometries, as well
as making shared borders more explicit, as it will be described in Section 2.

In order to provide support for GML, and thus direct compatibility with GIS systems, content negotiation through MIME media types is used. In other words,
when an HTTP request with the "Content-Type: application/vnd.ogc.gml" header field is sent, a GML representation of the feature should be received. In the
same way, when an XML serialization of the RDF representation of the feature using the NeoGeo Vocabulary is received when sending a reaquest with the
"Content-Type: application/rdf+xml" header field.

In order to enhance consistency along the different representations, the convertion between the RDF data
and other serializations, such as GML and
KML and
WKT, can be performed in the background.

2. Related Work

The foundational ground to the represantation of GeoData 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 GeoData, 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 take over 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.

3. Vocabulary

In the NeoGeo Vocabulary, everything is represented as an RDF resource, maximizing the vocabulary's expresivity. For example, the list of nodes
which form a polygon is an RDF Collection containing an RDF resource for each node. Some of the advantages of this approach include:

RDF Collections allow to define closed lists.

The ability to reference meaningful points by giving them a specific URI.

It is easy to identify points which are shared between shapes. This implies that whenever a shared border is updated, it won't be necessary
to check on consistance since every shared border will be automatically updated.

Whenever using the NeoGeo Vocabulary, it is also recommended to separate a given feature from its geometric representation as distinct resoruces
by using the 'geometry' predicate provided, as shown in the example below:

This allows to describe properties belong to the geometrc representation itself, and not to the feature (e.g. area, delineation date, etc.). This also
makes the content negotiation of different serializations of the geometric shape clearer, as it will be seen on Section 4.

The diagram presented below shows the main classes and relations of the NeoGeo Vocabulary:

3.1 Point

In the NeoGeo Vocabulary, points are represented as decimal degrees in the WGS 84 coordinate reference system and are described by reusing the
W3C Geo predicates. The following example shows the location of the Brandenburg Gate in Berlin, Germany.

3.2 LineString

A LineString resource is a collection of points, connected by straight lines. The collection of points is represented by an RDF Collection. The
example below shows an RDF representation of the Av. 9 de Julio in Buenos Aires, Argentina by using the LineString class of the vocabulary.

3.3 LinearRing

LinearRing resources are a particular case of LineString resources, where the last point is the same as the same point, thus defining a circular list
of points. LinearRings are not intended to represent geometries by themselves, but to be used as foundational blocks for the construction of Polygon
resources as seen in the following section.

3.4 Polygon

Polygons are described in the NeoGeo Vocabulary by using Polygon resources. As said in the previous section, Polygons are closed areas which are
described by its bounding LinearRing elements. A polygon will always have exactly one exterior boundary, and may optionally have a number of interior
boundaries, which define empty spaces within it or "holes". The following example shows a simplified version of the borders of South Africa, which have
an interior boundary with the country of Lesotho.

3.5.3 MultiPolygon

Describes a set of polygons. This kind of geometry allows the definition of separate polygons as a single geometry, which may be the case when
defining, for example, an administrative region with several islands on the sea.

4. Content Negotiation

It is sometimes useful to maintain a representation of the geometry in a format other than RDF (e.g. to provide direct compatibility with GIS systems).
In order to do this, it is recommended to use MIME Media Type negotiation in order to access the different supported serializations.

For example, whenever it is needed to access a GML representation of a given geometry, an HTTP Request with the following Content-Type header field
should be sent:

Example:

Content-Type: application/vnd.ogc.gml

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