Data Model

From Points of Interest

Domain model


XML Schema

informational only (updated December 1, 2011)

[XML schema file]

Data model for a POI

  1. An anchor
  2. An extent (described either by a vector set or by an MBR)
  3. A URI
  4. A category / type (possibly referring to a place ontology or gazetteer)
  5. An address (although the larger the place the less meaningful this becomes)
  6. An end point, referring to an authoritative source
  7. Contact information (if applicable)
  8. Suggestion for temporal information for 1) logging and 2) transient POIs

POI Administrative metadata

Many systems keep track of (and share) info about POI data items, as well as about the 'thing itself'.

  1. Can we consider adding a time field to the POI data model, e.g. "date created", "date updated" to cover these please? -- Sara-Jayne Farmer


A POI's anchor describes where the POI is located. Some POIs (the classical ones on a world map) are most easily described by a lat,lon,alt triple. Other anchors could be on a smaller scale and more easily described by coordinates on a grid or an image that is to be recognized. Below are examples of possible anchor types; this list is not yet definitive and not all will probably be part of the first specification this WG creates.

Types of anchors

  • centroid (latitude, longitude, altitude in a widely adopted CRS e.g. WGS 84)
  • (x,y) locations on a 2D grid / (x,y,z) locations on a 3D grid

Use case: situations where lat/lon/alt are impractical, such as in buildings where dimensions are usually measured in meters. Allows for much easier and faster authoring

  • fiduciary markers or images

Use case: Augmented Reality experiences obviously, but could also be applied to virtual worlds

  • buildings

Use case: again, easier authoring than looking up lat/lon coordinates for everything you want to describe. Also, it conveys a string connection between the POI and the real-world entity that is being described. This allows for smarter and nicer user interfaces; for example see [[1]] by Nokia's Petros Belimpasakis et al for some functional AR examples of tying POIs and buildings together, but the same usability holds for maps and virtual worlds.

  • dynamic entities, such as a person or a car

Use case: as computer vision improves, computers can track and recognize more and more of the world around us. The AR use case is again obvious, but what if you could dsignate your favourite football player as a POI? Apply some CSS-like "outer-glow: 3pt yellow;" effect to your POI, link it to the WebTV stream you're watching and you'll never lose track of him again.

Relative anchoring

There are a lot of use cases where relative anchoring makes more sense than absolute anchoring, such as describing points inside of a building. The building is a POI itself with a centroid as its anchor. Placing POIs within the building is then a matter of referencing the building's POI and providing an (x,y,z) offset.









End point


Contact Information


Temporal Annotations

Some use cases contain POIs that are transient in nature, such as traffic jams, refugee camps (see also Use Cases). Note: this notion has not been discussed yet but was put here by User:Jdesmit as a reminder for discussion.


Data model seems to be in two main flavours:

  1. the data describing the physical placement of the POI (e.g. lat/lon/alt/x-rot/y-rot/z-rot).
  2. the content the POI is linked to (e.g. title, description, type, keywords, favicon/thumbnail, 3D model, etc.).
  • NOTE: These are just indicative and are not meant to be a complete or limiting set. Just a reference for discussion.

Basic structures

The phrase 'data model' is also used in W3C circles to refer to the underlying representational structures being used; for example we might express our domain modelling using XML's "infoset data model" (essentially a tree of attributed markup elements), or RDF's "edge-labelled graph data model" (essentially a collection of 3-part triples using URIs); or perhaps JSON's "object serialization data model". A domain model expressed in an abstract data model (eg. UML or RDF) could have multiple syntactic representations (eg. RDF/XML vs RDF-in-JSON, RDFa-in-HTML in the RDF case, @@todo in the UML case).

Triples in a compact XML format

<tag k="meta:type" v="static"/>
<tag k="meta:author" v=" Jean Dupont"/>
<tag k="meta:timestamp" v="2010-11-01T18:17:44Z"/>
<tag k="meta:author:contact:phoneNumber" v="+33476031525" />
<tag k="meta:author:contact:email" v=""/>
<tag k="meta:author:contact:address" v="baptistere,place Notre Dame,38000 Grenoble,France"/>
<tag k="geolocation:coordinates:latitude" v="45.1927119"/>
<tag k="geolocation:coordinates:longitude" v="5.7318029"/>
<tag k="geolocation:coordinates:altitude" v="200.345672"/>
<tag k="link:content:text" v=""/>
<tag k="link:content:audio" v=""/>
<tag k="poi:update:frequency" v="0.01"/> 
<tag k="action:tracking" v=""/>
<tag k="action:location" v=""/>

Triples in RDF format