Updated: 2006-02-01

Editor: Dan Brickley <[email protected]> (SWIG Chair)

This is a basic RDF vocabulary that provides the Semantic Web community with a namespace for representing lat(itude), long(itude) and other information about spatially-located things, using WGS84 as a reference datum.

The vocabulary is getting significant usage, both (as intended) within RDF documents, but also as a namespace used within non-RDF XML documents, such as RSS 2.0 (see below).

The Locative packets format uses this vocabulary, as do Map Bureau's RDF mapping tools. The geocoder.us site, provides a free geocoding service for the US, based on TIGER data, and accessible via an RDF Web service that uses this vocabulary. Other applications include blogmapper and openguides. The WordKit system also uses it for geocoding RSS 1.0 (i.e., RDF), RSS 2.0 (non-RDF) and Atom (non-RDF). The Yahoo! Maps service also makes use of this namespace, although apparently only within a RSS 2.0 context. See the ESW:GeoInfo Wiki entry for links to other uses of this work.

This document was created as an informal collaboration within W3C's Semantic Web Interest Group. This work is not currently on the W3C recommendation track for standardization, and has not been subject to the associated review process, quality assurance, etc. If there is interest amongst the W3C membership in standards work on a location/mapping RDF vocabulary, this current work may inform any more formal efforts to follow.

This vocabulary begins an exploration of the possibilities of representing mapping/location data in RDF, and does not attempt to address many of the issues covered in the professional GIS world, notably by the Open Geospatial Consortium (OGC). Instead, we provide just a few basic terms that can be used in RDF (eg. RSS 1.0 or FOAF documents) when there is a need to describe latitudes and longitudes. The motivation for using RDF as a carrier for lat/long info is RDF's capability for cross-domain data mixing. We can describe not only maps, but the entities that are positioned on the map. And we can use any relevant RDF vocabularies to do so, without the need for expensive pre- coordination, or for changes to a centrally maintained schema.

A basic, standalone example:

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">

    <geo:Point>
        <geo:lat>55.701</geo:lat>
        <geo:long>12.552</geo:long>
    </geo:Point>
</rdf:RDF>

An example that combines Geo, Dublin Core and FOAF vocabularies:

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
    xmlns:dc="http://purl.org/dc/elements/1.1/" 
    xmlns="http://xmlns.com/foaf/0.1/">

    <Person>
        <name>Dan Brickley</name>
        <homepage dc:title="Dan's home page" rdf:resource="http://danbri.org/"/>
        <based_near geo:lat="51.47026" geo:long="-2.59466"/>
        <rdfs:seeAlso rdf:resource="http://danbri.org/foaf.rdf"/>
        <!-- more RDF here, using any RDF vocabularies -->
    </Person>
</rdf:RDF>

An example (from WorldKit) of geo-coding with RSS 1.0:

<?xml version="1.0"?>
<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" 
    xmlns="http://purl.org/rss/1.0/">

    <item rdf:about="http://example.com/geo">
        <title>An example annotation</title>
        <link>http://example.com/geo</link>
        <description>Just an example</description>
        <geo:lat>26.58</geo:lat>
        <geo:long>-97.83</geo:long>
    </item>
    ...
</rdf:RDF>

The origin of this workspace was the 2003-01-09 discussion in the RDF Interest Group IRC channel. We are taking a similar approach to the exploration of RDF vocabulary for calendars, although that work is more mature. See the RDF Calendar Workspace for more information.

See the SchemaWeb site for an overview of classes and properties, or the underlying RDFS/OWL vocabulary description.

Currently we specify only a very minimalistic RDF vocabulary for describing Points with latitude, longitude, and altitude properties from the WGS84 reference datum specification.

This design allows for basic information about points to be described in RDF/XML, and augmented with more sophisticated or application-specific metadata.

The vocabulary also defines a property lat_long, but this should probably be removed, as few commentators have valued it.

The vocabulary defines a class Point, whose members are points. Points can be described using the lat, long and alt properties, as well as with other RDF properties defined elsewhere. For example, we might use an externally defined property such as bornNear or withinFiveMilesFrom, or perhaps other properties for representing lat/long/alt in non-WGS84 systems.

The lat and long properties take literal (i.e., textual values), each in decimal degrees. The alt property is decimal metres about local reference ellipsoid.

Whitespace in property values is insignificant, and discouraged. We do not use RDF's datatyping mechanism in the vocabulary's schema to note that the rdfs:range of the lat,long, and alt properties are XML Schema float datatypes. Instead, from RDF's point of view, the properties are simply strings.

This reduces the syntactic burden on RDF/XML documents using our vocabulary, since we write lat and long information as strings. The string representation of lat and long should follow the rules for XML Schema float, even though we do not indicate explicitly in RDF that we are representing floating point numbers. A future version of this document may be stricter about whitespace when marking up float values, so it is probably best to avoid any whitespace in your lat/long/alt markup.

The semantics of the lat/long/alt properties are unaffected by xml:lang values, if present.

While it is quite possible to use the namespace in non-RDF XML documents, developers should note that this reduces the availability of such data within the Semantic Web, since specialist knowledge of each XML tag-set is needed before data can be safely interpreted. The GRDDL specification offers an XSLT-based mechanism for mapping such data into RDF.

As this is an RDF vocabulary, we define properties of a kind of thing, a Point, rather than the structure and characteristics of an XML document type. XML Schemas and DTDs typically adopt the latter approach, and thus provide more guarantees about the information content of each document of some type. By contrast, our RDF vocabulary provides no guarantee about which things will be described in any particular RDF/XML document. For example, it may turn out that many point descriptions omit the altitude property, alt. This doesn't make those documents invalid in any sense; they are merely less informative.

We can note some rules for reasoning about the identity conditions for points. If we encounter a description of a Point, call it ?X, and another, call it ?Y, and ?X and ?Y have identical values for their lat, long, and alt properties, we can conclude that ?X == ?Y, i.e., that ?X and ?Y represent the self-same thing. Anything that has any lat, long, or alt properties will be a Point. In our RDF Schema for the vocabulary, we indicate this using the rdfs:domain property.

A Point has only one lat, only one long, and only one alt; we could use W3C's Web Ontology Language (OWL) to express this. OWL allows us to note that these RDF properties are functional properties.

• An RDF vocabulary for WGS84 latitude/longitude/altitude markup (namespace uri: http://www.w3.org/2003/01/geo/wgs84_pos#).
• 2003-01-10 #rdfig links, including test data.
• SWIG Basic Geo (WGS84 lat/long) Vocabulary (this document).

Regarding the http://www.w3.org/2003/01/geo/wgs84_pos# vocabulary: it is pretty simple and should hopefully stay that way, i.e., short and simple enough to memorise and use. There may be some need to extend it, based on deployment experience, test cases etc. Time will tell.

Interested SWIG members meet occasionally in the #swig IRC channel on FreeNode. The IRC logs and weblogs generally serve as meeting records. At the time of writing, no meetings are scheduled.

For related work and further discussion and collaboration, see the GeoInfo entry in the ESW Wiki.