From W3C Wiki
An RDF compatible profile for geo information (points, lines and polygons)
ChrisGoad's suggestion for how GeoRDF as a flexible standard might be presented (in principle all the software projects in the informal ecology would have to implement both a simpler and a more complex profile...):
a vocab with three profiles, might emerge from our discussions: 1) a point profile/vocab (== the current rdfig geo), 2) a polyline/polygon profile/vocab (same in content as Mikel's geo:polygon or geoRSS, but perhaps with a point sequence option added), and 3) something along the general lines of rdfgeom.
RDFIG defined a simple vocabulary for expressing points on the earth in WGS84 form.
<geo:Point> <geo:lat>51.4</geo:lat> <geo:long>-0.02</geo:long> </geo:Point>
Lines and Polygons
Mikel's extension of the geo schema for [mapufacture] uses lists of comma-separated lat,long pair values to describe both lines and polygons.
<geo:line>50,-0.2,100 54,3,442 59,2.56,0</geo:line> <geo:polygon>30,-120 30,-100 20,-100 30,-120</geo:polygon>
However the standard GML representation, and the "Well Known Text" representation used in SQL based geometry storage, has a list of space-separated points, marked by commas: the inverse of the WorldKit formulation.
e.g. <geo:line>50 -0.2, 54 3, 59 2.56</geo:line> or <geo:line>50 -0.2 100, 54 3 442, 59 2.56 0</geo:line>
It could be left to the consumer to 'guess' which format was being used, but the case of lists of 3-dimensional points would make it more complex to infer. If the WKT form was 'standardised' on, some consumers, specifically WorldKit, would have to be able to support both and 'guess' but this would be preferable to asking the world to do it...
Chris Goad's more complex formulation uses an rdf:Seq to express a list of points that are a line, a polyline or a polygon. It also separates abstract geometry from geospatial representations.
Here are a few details:
The vocabularies RDFGeom, and its 2d companion, RDFGeom2d, provide an RDF framework that is extensible via subclassing to all kinds of geometric data, although the class hierarchy is currently only sparsely populated. The class hierarchy is loosely based on the geometric part of SVG.
Since lines, curves, and transformations are geometric, not specifically geographical, notions, RDFGeom and RDFGeom2d formulate geometry without reference to any particular application. Properties that connect geometry to intended interpretations are asserted by application-specific vocabularies. For example, under the stipulation that geo:where (transplanted from georss) takes values interpreted in wgs84:
<geo:SpatialThing rdf:about="http://example.org/places/us/oregon/astoria"> <geo:where> <geom2d:Point><geom:x>-123.82</geom:x><geom:y>46.18</geom:y></geom2d:Point> </geo:where> </geo:SpatialThing>
In contrast to the coordinate-string approach of the simple profile, RDFGeom points appear as separate resources within sequences, illustrated by this example. The result is more verbose than the coordinate-string approach, but allows properties (including, eg, descriptions and topological relations) to be asserted of individual points - a crucial attribute for many applications (consider annotated GPX tracks).
Question: wouldn't it be better to transpose the geometric class hierarchy from GML 3.1 into RDF? (See these notes on the relationship between RDF and GML.) Yes, perhaps. But there is still a place for a geometric profile at RDFGeom's scale, requiring a dozen rather than a hundred pages of exposition, but covering enough territory beyond the simple profile to handle routine GIS applications.
It could be desirable to include a description of solids, possibly as a series of polygons which are faces:
<geom:shape> <geom:face> <geom:polygon> </geom:face> etc.
One can represent spatial queries (places / things meeting certain criteria near a point) using either profile; the simple one as part of a HTTP GET request; the more complex one as the contents of a URI POSTed to a query service.
[bbox] has a HTTP based spatial query interface returning RDF of aggregated things that will support this query method and it would be nice to include a simple spec like this as a parcel with suggestions for and implementations of a vocabulary.
Mikel Maron coined geo:line and geo:polygon predicates, which are just comma separated lists of lat-lon pairs. worldKit docs on geo:line, geo:polygon
Also, defined a way to specify lat/long within the content of an XML element (like <description> in RSS, or <dc:subject> in del.icio.us, flickr), for users without access to the structure of machine readable output. http://brainoff.com/worldkit/doc/rss.php#within
- IndexingSail adds support for geometry literals in Well Known Text format and use of OpenGIS functions to the SPARQL query engine of Triple Stores that implement the Sesame Sail API.
- georss site by Raj Singh, Josh Lieberman, Allan Doyle: a GML compatible profile designed for embedding in Atom and RSS2 but yet lacking an RDF compatible profile.
- Wikipedia entries, eg GML for RSS, started by Ron Lake
- DanBri gml/rdf tests and queries
- geobloggers reads and emits geo-tagged markup
- KML, ...