Abstract

The concept of location has become very popular in many applications on the Web, in particular for those which aim at connecting the real world with resources on the Web. However, the Web as it is today has no overall location concept, which means that applications have to introduce their own location concepts and have done so in incompatible ways. By turning the Web into a location-aware Web, which we call the Locative Web, location-oriented applications get better support for their location concepts on the Web, and the Web becomes an information system where location-related information can be more easily shared across different applications and application areas. We describe a location concept for the Web supporting different location types, its embedding into some of the Web's core technologies, and prototype implementations of these concepts in location-enabled Web components.

Location on the Web

• Many location-based services have Web interfaces
  • standard Web-based interfaces can be built for any location-based service
  • Google Maps has turned maps into popular Web UIs
• Limitations for server-side applications
  • no standardized way of communicating with location-enabled services
  • it is impossible to access the client's location without external help
• Limitations for client-side applications
  • XMLHttpRequest's same-origin policy makes is hard to build map mashups
  • it is impossible to access the client's location from within scripting code
  • no standardized way of communicating with location-enabled services
• Limitations of the Web
  • no standardized way to identify or represent locations
  • no standardized way to associate location metadata with resources
  • no standardized way to use location information for interactions

Web Surface Technologies

Web Evolution

Web Evolution Examples

1. New surface technologies for existing areas
   • XML was intended for documents on the Web
2. Providing additional surfaces
   • SVG for publishing vector graphics on the Web
   • MathML for publishing mathematics on the Web
   • supporting location concepts as part of the Web
3. Adding more depth to the surface
   • Semantic Web
4. Improving surface technologies
   • HTML/CSS have evolved over various generations

GIS & WebGIS

WebGIS

• Building Web UIs for GIS
  • Web access to GIS data provides ubiquitous access
  • Ajax supports dynamic interfaces and UI-driven access to server data
  • RIA platforms provide even richer development environments
• Beyond Web UIs for GIS
  • exposing GIS as Web services makes them reusable on the Web
  • using common concepts for GIS data allows aggregation and filtering
  • location support in interactions support location-based services
• WebGIS should refer to Web Services
  • our focus is on RESTful services for location-based services
  • Atom as foundation for representing geo-entries
  • GeoRSS as a way to add geospatial information to Atom
  • extensions to Atom for querying geo feeds (server-side filtering)
  • AtomPub for interacting with collections of geo-entries
  • required GeoRSS metadata when posting a geo-entry

WebGIS as Web Services

Spaces and Places

• Location has spatial and social facets
  • location may be purely spatial (GPS coordinates as location fix)
  • location may be purely social (I am on vacation)
  • frequently, locations have both facets (I am in my office ≅ 37.8714,-122.2585)
• Spaces and places need reference systems
  • spaces need some reference coordinate system, such as WGS84
  • places need social context that establishes shared understanding
• Social locations often need contextualization and privacy
  • places need context
  • disclosure of location information is sensitive data and should be controlled
  • locations that people talk about are a mix of spaces and places

Location Identification

• Places have names which should be identifiers
  • in many cases, names are not proper identifiers
  • geocoding often uses heuristics to determine the most likely match
• Well-defined places must use names which are identifiers
  • identifiers always identify within a certain context (the place name vocabulary)
  • our approach proposes to use a standard for vocabulary identifiers
  • the vocabulary format is not standardized
  • the must be a placename/vocabulary syntax for location identifiers
• Geocoding also fits into this framework
  • geocoding essentially is a resolution process
  • different geocoders often resolve the same name differently
  • a geocoding vocabulary identifies a particular resolution method

Location URI

• geoloc as a new URI scheme for identifying locations
• Three different identification methods are supported
  • spatial identification through WGS84 coordinates (points only)
  • symbolic identification through ISO country codes (two-letter codes)
  • place names using names from some vocabulary
• Location vocabulary identification can be done in two ways
  • explicitly by using a vocabulary identifier (a URI)
  • implicitly by assuming a context identifying the vocabulary
• Vocabulary identifiers are URIs
  • they do not need to refer to an existing resource (but they can)
  • there is no standardized format for vocabulary descriptions
  • there is no standardized format for vocabularies themselves

Descriptions vs. Definitions

• Location vocabularies can be implicit or explicit
  • social groups often have not a well-defined vocabulary for their locations
  • vocabularies can have simple structures and just list location names
  • vocabularies can be highly structured and contain rich location metadata
• geoloc URIs use vocabulary identifiers to disambiguate names
  • this introduces the same structure as for XML namespace
  • it is advisable to provide a description for the location namespace
  • if applicable, it might be useful to publish the location vocabulary

Place Name Vocabularies

PlaceML Example

<placeml xml:lang="en">
  <name>UC Berkeley Campuses</name>
  <place id="MainCampus">
    <name>Main Campus</name>
    <description>The main campus has all important buildings and starts right in downtown Berkeley. It can be easily reached by BART from San Francisco and other bay area locations.</description>
    <location>
      <polygon type="include">
        <point long="-122.266182" lat="37.874039"/>
        <point long="-122.265602" lat="37.869637"/>
        <point long="-122.266098" lat="37.868755"/>
        <point long="-122.265770" lat="37.867943"/>
        <point long="-122.252556" lat="37.869686"/>
        <point long="-122.252937" lat="37.871075"/>
        <point long="-122.252876" lat="37.871670"/>
        <point long="-122.253967" lat="37.872620"/>
        <point long="-122.255516" lat="37.873787"/>
        <point long="-122.256844" lat="37.875397"/>
        <point long="-122.266182" lat="37.874039"/>
      </polygon>
    </location>
  </place>
  <place id="ClarkKerrCampus">
    <name>Clark Kerr Campus</name>
    <description>Clark Kerr Campus only has student housing and sports facilities. It is about 1km from the main campus.</description>

Place Markup Language

• Simple representation of location vocabularies
  • targeted at social settings and similar use cases
• Potentially a surface view of a location vocabulary
  • complex location management may have a much richer data model
  • PlaceML exposes the most basic data (names and spatial information)
• Location vocabularies are map overlays (+ structure)
  • Google Maps My Maps as editor for location vocabularies
  • KML export and conversions to and from PlaceML
  • manual process because currently there is no API for My Maps
• PlaceML and KML have a different focus
  • KML has more features for drawing map overlays
  • PlaceML has more features for defining place hierarchies
  • spatial definitions in PlaceML are optional

Talking about Location

• HTTP is the standard protocol on the Web
  • requests and responses are exchanged in stateless message exchanges
  • messages have header fields (metadata) and optional payload
  • header fields depend on a mutual understanding of their semantics
• HTTP content negotiation is used to match client needs and server capabilities
• Geoloc and Accept-Geoloc headers for location information
  1. client sends request to a location-based service
  2. response indicates which location types are accepted by the server
  3. client repeats the request with location information (based on types and privacy rules)
  4. server processes the location information and sends customized response
• Privacy handling in this setting is a usability challenge
  • the data types and protocol mechanics are not too hard
  • exposing that information in a usable and useful way is very hard

Geo-Enabled Browser

Location Intermediary

• Hacking browsers is hard and client-dependent
• Location-based services are based on location information in HTTP
• An intermediary (a.k.a. proxy) can be used to handle location information
• Location Proxy (LocProxy) is a prototype for handling location in HTTP
• Managing LocProxy is similar to using FireEagle
  • signing up and getting an identity (a user name)
  • configuring the mobile browser to send requests via LocProxy
  • proxy authentication makes requests identifiable
  • LocProxy has a user interface for setting the location information
  • in theory, LocProxy could also handle content negotiation

LocProxy

The Locative Web

• Location should be made explicit as a concept
• URIs for identifying locations (spaces or places)
• WebGIS should expose RESTful Web services
• Atom/AtomPub for interacting with collections of geo-entries
• Location should be supported by browsers (geoDOM)