This Version: 1.0
Current Version: 1.1
Previous Version: 0.91
Chris Goad, April 2003
RDFMap is compliant with the recommendations for RSS 1.0 modules.
RDFMap does not include any geometry primitives. Instead, the values of properties relating to geometry are defined using the companion RDFGeom2d vocabulary. An earlier version of this specification took the alternative approach of including its own geometry primitives, as have other XML and RDF languages such as SVG, GML, and RDFIG Geo. However, there is a simple but compelling reason to separate out geometry into its own vocabulary. Namely, if separated, the many applications involving geometry can make use of the shared vocabulary without needing to reinvent and rename the wheel. This will save much effort both in vocabulary development, and in sharing information between applications. Note that, as the geometry vocabulary is extended, no change in RDFMap is required to use new geometric primitives in the description of geography. Also, nothing prevents the use of a 3D geometry vocabulary with RDFMap when the three-dimensional structure of geographic features is relevant.
Here is an RDFMap file containing one RSS item.
<?xml version="1.0" encoding="iso-8859-1"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:map="http://nurl.org/0/geography/map/1.0/" xmlns:geom2d="http://nurl.org/0/geom2d/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rss="http://purl.org/rss/1.0/" > <rss:item about="http://fabl.blogspot.com#item1056"> <dc:coverage> <geom2d:Point> <map:srs resource= "http://nurl.org/0/geography/SRSCatalog/wgs84"> <geom2d:x>-123.817</geom2d:x> <geom2d:y>46.183</geom2d:y> </geom2d:Point> </dc:coverage> </rss:item> </rdf:RDF>
This RDF signifies that the specified RSS item pertains to a particular point on the earth's surface, namely the point in the WGS84 spatial reference system with x (longitude) equal to -123.817, and y (latitude) equal to 46.183. See below for details about the srs (spatial reference system) property.
Note that the namespace for RDFMap is http://nurl.org/0/geography/map/1.0/. "nurl" stands for "Not a URL". nurl.org serves as a root for URIs that denote entities - like geographical properties and geometric points - that are not web resources. Of course, in real life, the URI might (or might not) resolve to a web page as well, but this does not affect the intended denotation of the URI when used in RDF.
Note also that dc:coverage is defined as follows in http://dublincore.org/documents/1999/07/02/dces/:
"Coverage will typically include spatial location (a place name or geographic coordinates), ..."
So, in this example, the RDFMap vocabulary was only needed to specify a spatial reference system for a point; other vocabularies did the rest of the work.
Now, here is the list of properties and classes making up RDFMap.
An Open GIS standard for defining spatial reference systems is available. However, the specification (and the subject matter which it formalizes) is complex, and the great majority of applications can be served adequately by the use of standard names for the commonly used projections. As part of this specification, we designate the URI
as the parent beneath which SRSs are named. The most commonly used SRS's can be specified via their EPSG (European Petroleum Survey Group) codes. The SRS with EPSG code <N> is named "epsg<N>". (A listing of EPSG codes can be found at http://www.inovagis.org/giserver/epsg.asp.) For example,
denotes UTM zone 10N, the universal transverse mercator zone for points in the northern hemisphere between 120 and 126 degrees west longitude (eg San Francisco). The UTM projections are suitable for maps that cover areas of up to a few hundred miles on a side (except at latitudes near the poles). We also specify that UTM zone <N> is designated by "utm<N>n", or "utm<N>s" for the northern and southern hemispheres, respectively (eg utm10n for the zone which includes San Francisco), and that "wgs84" denotes the WGS84 datum.
Programmers who use RDFMap will rarely have any need to understand the intricate details of these spatial reference systems, but will sometimes need access to a library of functions for transforming points between them. End users of systems based on RDFMap normally won't need to concern themselves with spatial reference systems at all.
The srs property can be applied to such geometric entities as Points and Boxes, with the effect that the coordinates of the entities in question are to be interpreted as points on the earth under the specified projection. The example appearing above illustrates this.
Following SVG terminology, the map is visualized as a viewport onto an infinite two-dimensional surface called the "canvas". Most maps will also have an srs property, which specifies the datum and projection used for representing points on the earth that are depicted by the map. Determining the point on a map corresponding to a point on the earth is a matter of first computing its coordinates in the SRS of the map, and then perfoming an affine transformation (scaling and offset) to render the point in canvas coordinates. For projections whose axes approximately align with lines of longitude and latitude, the x coordinate is taken to mean longitude and y latitude. The output of the affine transformation is in a right-handed coordinate system with x pointing to the right and y up. (Most graphics applications need to flip y before display, since screen coordinates usually have y pointing down).
The affine transformation is described by the following properties:
The coverage of a map specifies the range of points on the earth that the map covers, using the map's srs, and the extent is the box representing the map's viewport onto the canvas.
RDFMap can be used in conjunction with either RSS 1.0 or RSS 2.0 (but not RSS 0.9*). RSS 1.0 is an RDF vocabulary, so assigning RDFMap properties to RSS 1.0 resources presents no obstacle. RSS 2.0 allows inclusion of elements not defined in the RSS 2.0 specification, as long as those elements are defined in namespaces. RDFMap properties may be asserted of RSS 2.0 channels or items simply by including the relevant property elements. Here is a legal RSS 2.0 fragment of this kind:
<item> <description>In golden gate park</description> <dc:coverage> <geom2d:Point> <map:srs rdf:resource= "http://nurl.org/0/geography/SRSCatalog/utm10n"/> <geom2d:x>545806</geom2d:x> <geom2d:y>4180610</geom2d:y> </geom2d:Point> </dc:coverage> <pubDate>Wed, 31 Jul 2002 17:07 +0000</pubDate> </item>
In either RSS 1.0 or RSS 2.0, a channel can be assigned a map:useMap property which specifies how its items are to be mapped. As illustrated more than once above, each item or channel may have a dc:coverage property belonging to a geometric class such as geom2d:Point indicating the geometry that should be displayed when that item is mapped.
It is common for RSS items to have other properties that are relevant to mapping. For example, the dc:type property may specify the category of entity described by an item. The map implementation is free to exploit this category information in defining map layers.
The following convention is a part of this specification: whenever a container of some kind is assigned an srs (resp. canvas), its contents are to use that srs (resp. canvas) as the default. For example, if a channel is assigned an srs, then its items may be assigned locations which fail to specify srss individually. Then, the srs of the channel is used to interpret these locations.
These techniques are illustrated by Blogmapper, an application which uses RDFMap and RSS to map the contents of weblogs.
Here's an example of an RDFMap file that describes a map of Astoria, Oregon.
(1) Separated out geometry primitives into RDFGeom2d. (2) Removed auxilliary non-RDF specification for RSS 0.9* (since RSS 2.0 admits foreign elements), (3) Minor changes to the Map class: now the basemap image is specified explicitly, as is a thumbnail. (4) Deleted the location property in favor of the Dublin Core coverage property.