Software Infrastructure:

Context and Location via

the Personal Datastore
Contact: Richard Mortier & Chris Greenhalgh
firstname.lastname@nottingham.ac.uk
26/Feb/2010

1
 Contents
• Personal Datastore
– Roles
– Working schema
– Support for “context”
• A concrete geospatial example

2
 Personal Datastore: Roles
• Personal archive
– Durable record of an individual’s activities for their
own reference
• Personal digital activity coordinator
– Common point to push messages to before routing
them to email, twitter, &c, and archiving them
• Personal data guardian
– Allows fine-grained control over release of personal
information, e.g., location, social network

3
 Personal Datastore: Working Schema
Main durable entities
• Person
• Service account
– E.g., a particular email account, including email address
• Thing
– A message, document or other durable data
• Attachment
– A file or similar raw data associated with a Thing or Person
• Place
– A “significant” location, e.g., where something happens
• Event
– E.g., taking a picture
– I.e., a person creating a thing in a place

4
Personal Datastore: Working Schema
Main durable entities
Service
from/to has Tag
accounts
has (e.g. email
addr.) “Thing”
(e.g. email
message, photo) has
Person
Attachments
(i.e. blobs – data)
subject object has

Event Place
(e.g. creation,
(e.g. lat, long,
viewing) at elevation, error)

Current first-class relationships (can be added to) In working schema as of Jan 2010 (Anil)

Possible general metadata references Added to working schema Feb 2010 (infra. pilot)

5
 Personal Datastore: Working Schema
Ephemeral entities
• Credentials
– E.g., username/password, for background services
• Fine-grained sensor readings
– For subsequent filtering to places, things, events
– E.g., computing routes as things
• Datastore updates
– For eventing, distribution and synchronisation
• Access control permissions
– For managing publishing
6
 Personal Datastore:
Support for “Context”
• The personal datastore is a live archive of personal
“context”
– Including location, interaction(s), social contacts, …
• Access to personal context will be via managed plugins
– To support application-specific use of context
– To manage privacy/permission issues
• Use of personal context is application’s responsibility
– Common requirements should migrate into infrastructure
– Initially as domain specific facilities
– Subsequently as generalised infrastructure capabilities

7
 Architecture: Geospatial Aspects
3 3 4
sensors Location, context
Geospatial Inc. OGC
Cloud services as
Mobile Device view plugin
Mobile Device Datastore required
Application
Mobile Device
client

1 RAMP S External
H Geospatial
Note: Personal I Services
datastore client M E.g., geocoding
also on mobile
device
2
Geospatial
Application Geospatial
OGC Services
E.g., routing
interfaces can
be provided if 1
OGC/other
required
bridges
as required 1 8
 Geospatial Support (1)
• RAMP will be incorporated to provide a common
gateway/shim layer over existing services
– Includes geospatial and OGC services as required
• Interactions between infrastructure components
will use current “best of breed” technologies
– By default, HTTP/HTTPS, JSON, …
– Other types of interfaces can be provided as needed,
subject to resourcing

9
 Geospatial Support (2)
• Geospatial and other context-related services
will be added to the infrastructure over time
– Either as self-contained services, or as shims to
existing services
• Likely examples include:
– Geocoding
– Routing
–…

10
 Geospatial Support (3)
• Personal Datastore schema has place as first-class
– Initial place-holder using lat/long/elev/error (WGS-84)
– Derived data, e.g., routes, included as things or
attachments
– Can raise to first-class as and when required
• Initial applications will demonstrate recording of
location and annotation of events with location
• Personal context, including location, can be accessed
via device or the cloud datastore
– Controlled release, typically application-specific
– Access by applications, including data mining/modelling

11
 Geospatial Support (4)
• Personal Datastore plugin approach enables geospatially
optimised plugins, supporting e.g.,
– Geospatial queries
– Geospatial indexing
– Domain-specific anonymisation of personal data
– Sensor data fusion for hybrid positioning
• Many engineering issues in addition to conceptual
challenges
– E.g., privacy preservation, managed release
• As a result, addition of features likely to be by via “pull”
from projects rather than “push” from infrastructure
– Cf., Urban gaming (requiring location services)
– Cf., Car sharing (requiring location, routing, geocoding services)

12