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.
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.
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:
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:
Example:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ex: <http://example.org/> .
@prefix ngeo: <http://geovocab.org/geometry#> .
ex:path ngeo:geometry ex:way_1 .
ex:way_1 rdf:type ngeo:LineString .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:
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.
Example:
@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ex: <http://example.org/> .
@prefix ngeo: <http://geovocab.org/geometry#> .
ex:point_1 rdf:type ngeo:Point .
ex:point_1 geo:lat "52.516262" .
ex:point_1 geo:long "13.377717" .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.
Example:
@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ex: <http://example.org/> .
@prefix ngeo: <http://geovocab.org/geometry#> .
ex:way_1 rdf:type ngeo:LineString .
ex:way_1 ngeo:posList (
[geo:lat "-34.622148"; geo:long "-58.380603"]
[geo:lat "-34.591532"; geo:long "-58.381960"]
) .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.
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.
Example:
@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ex: <http://example.org/> .
@prefix ngeo: <http://geovocab.org/geometry#> .
_:polygon rdf:type ngeo:Polygon ;
ngeo:exterior [
rdf:type ngeo:LinearRing ;
ngeo:posList (
[ geo:lat "-29"; geo:long "16" ]
[ geo:lat "-28"; geo:long "33" ]
[ geo:lat "-34"; geo:long "27" ]
[ geo:lat "-35"; geo:long "19" ]
[ geo:lat "-29"; geo:long "16" ]
)
] ;
ngeo:interior [
rdf:type ngeo:LinearRing ;
ngeo:posList (
[ geo:lat "-29.5"; geo:long "27" ]
[ geo:lat "-28.5"; geo:long "28.5" ]
[ geo:lat "-29.5"; geo:long "29.5" ]
[ geo:lat "-31"; geo:long "28" ]
[ geo:lat "-29.5"; geo:long "27" ]
)
] .The NeoGeo Vocabulary supports the definition of composite geometries, which represent a set of aggregated simple geometries of a given kind. The composite geometries supported are listed below:
Represents an aggregation of points. It may be useful to represent, for example, different locations of a same event.
Example:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ngeo: <http://geovocab.org/geometry#> .
_:multipoint rdf:type ngeo:MultiPoint ;
ngeo:pointMember _:point_1, _:point_2 .
_:point_1 rdf:type ngeo:Point .
_:point_2 rdf:type ngeo:Point .A collection of LineString resources. For example, this type of geometry may be useful to describe the boundaries of a river.
Example:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ngeo: <http://geovocab.org/geometry#> .
_:multilinestring_1 rdf:type ngeo:MultiLineString ;
ngeo:lineStringMember _:linestring_1, _:linestring_2 .
_:linestring_1 rdf:type ngeo:LineString .
_:linestring_2 rdf:type ngeo:LineString .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.
Example:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ngeo: <http://geovocab.org/geometry#> .
_:multipolygon_1 rdf:type ngeo:MultiPolygon ;
ngeo:polygonMember _:polygon_1, _:polygon_2 .
_:polygon_1 rdf:type ngeo:Polygon .
_:polygon_2 rdf:type ngeo:Polygon .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.gmlIn the same way, some content types for common spatial representations are presented below: