The Physical Web is a generic term describes interconnection of physical objects and web. The Physical Web lets present physical objects in a web. There are different ways to do that and we will discuss them in our paper. Usually, the web presentation for a physical object could be implemented with the help of mobile devices. The basic idea behind the Physical Web is to navigate and control physical objects in the world surrounding mobile devices with the help of web technologies. Of course, there are different ways to identify and enumerate physical objects. In this paper, we describe the existing models as well as related challenges. In our analysis, we will target objects enumeration and navigation as well as data retrieving and programming for the Physical Web

1. On Physical Web models
Manfred Sneps-Sneppe
Ventspils University College, Latvia
manfreds.sneps@gmail.com
Dmitry Namiot
Lomonosov Moscow State University, Russia
dnamiot@gmail.com
SIBCON 2016
12.05.2016

2. What is Physical Web
•The Physical Web: describes interconnection
of physical objects and web.
•The basic idea: to navigate and control
physical objects in the world surrounding
mobile devices with the help of web
technologies.
•The target: objects enumeration and
navigation as well as data retrieving and
programming for the Physical Web.

3. How to enumerate physical
objects
• QR-code
• RFID
• Wireless tags:
iBeacons, EddyStone
• Hotspot on mobile
phone can play a role
of tag

4. Context
• Context is anything we can add to location
• Models for context-aware systems:
• Data exchange depending on the context
• Situational awareness
• Context-aware data discovery and data
search

5. Network proximity
• A special model for context-aware
services
• Context described as a set of wireless
networks (nodes)
• Wi-Fi access points, Bluetooth nodes,
Bluetooth tags
• Data could be directly associated with
network nodes.

6. Network proximity
• Describe data models based on the detection of
surrounding network nodes.
• Lets us build mobile computing systems based
on the detection of physical objects via network
proximity.
• The proximity is a very conventional way for
context-aware programming in the mobile world.
• The idea is to allow mobile web pages
dependencies on proximity of physical objects
(wireless nodes)

7. Why network nodes?
• Wi-Fi (Bluetooth) devices are everywhere
• Wi-Fi (Bluetooth) is presented in every
mobile phone
• Easy to measure (existing standards)
• We can reuse existing infrastructure
• There is no connection with location (geo-
coordinates). Data are linked to nodes
“visibility” instead of location

8. Metrics
• The basic element: fingerprint
• A list of “visible” nodes: ID, MAC-address,
RSSI (signal strength)
• Occurrence counting
• RSSI-based “distance”

9. QR-Code for Physical Web
• QR-code contains
some URL
• The modified QR-
code reader adds
parameters about
context
• The final URL
contains information
about surrounding
wireless nodes

10. iBeacons

11. Google Physical web
• Google own protocol for Bluetooth low energy
(BLE).
• Eddystone defines a BLE message format for
proximity beacon messages.
• The general idea is the same as with the
“classical” iBeacons: tags broadcast some ID, an
application uses ID for getting data from the
cloud.

12. Google Physical Web
Application on the mobile device automatically discovers nearby
objects, obtains associated data (URLs in this case) and pushes
this information to the user.

13. Software architecture
• Data base for network proximity rules and content
• Rules editor
• Application server (API for developers)
• Mobile application for access to content (context-aware
browser)
The business process could be presented as a set of
productions (rules).
Each of the rules depends on some available data, on
some global variables (states).

14. Data model
Rules: productions
If (fingerprint condition) then { present some content }
RETE algorithm
REST API with JSON output:
[
{ “type”:”some_type”,”data”:”some_data”},
{“type”: ...},...
]
The data availability always assumes the presence of data
for any finite set of timestamps.
The application makes conclusions (actions) depending on
some window of measurements.

15. Google Nearby API
• Tag’s attributes:
advertised ID, current
status, expected stability,
geo-coordinates (latitude,
longitude pair), ID for
Google Places, indoor
floor level and text
description
• Nearby API: create
features based on
proximity.
• Exposes simple publish
and subscribe methods
that rely on proximity

16. Bluetooth Data Points (BDP)
• BDP: link (associate) user-
defined data with existing
wireless networks nodes.
• The BDP project targets
Bluetooth nodes in the
discoverable mode
• Any mobile users should be
able to create (open) Bluetooth
node right on the own mobile
phone, associate some data
with this node and so, make
them available for other mobile
users in the proximity.
• Bluetooth node in the car: car’s
owner can attach data to the
own node.