Distributed AffordanceAn Open-World Assumptionfor Hypermedia

Ruben Verborgh, Michael Hausenblas,Thomas Steiner, Erik Mannens,Rik Van de Walle

The three princes of Serendip

RESTarchitectural style

different?

What makes the

HATEOASHypermedia As The Engine

Of Application State

Representations containthe links to next steps.

How can the server knowwhat the client’s next steps are?

Distributed AffordanceAn Open-World Assumptionfor Hypermedia

Problem statement

Concept and Architecture

Demo

Distributed AffordanceAn Open-World Assumptionfor Hypermedia

Problem statement

Concept and Architecture

Demo

Hypertext [is] the simultaneous presentation

of information and controls such that

the information becomes the affordance

through which the user (or automaton)

obtains choices and selects actions.

— Roy T. Fielding

Hypertext [is] the simultaneous presentation

of information and controls such that

the information becomes the affordance

through which the user (or automaton)

obtains choices and selects actions.

— Roy T. Fielding

Hypertext [is] the simultaneous presentation

of information and controls such that

the information becomes the affordance

through which the user (or automaton)

obtains choices and selects actions.

— Roy T. Fielding

Hypertext [is] the simultaneous presentation

of information and controls such that

the information becomes the affordance

through which the user (or automaton)

obtains choices and selects actions.

— Roy T. Fielding

A handle affords opening a door.

The handle is an affordancethrough which you can open the door.

…the information becomes the affordance…

Hypertext [is] the simultaneous presentation

of information and controls such that

the information becomes the affordance

through which the user (or automaton)

obtains choices and selects actions.

— Roy T. Fielding

Hypertext [is] the simultaneous presentation

of information and controls such that

the information becomes the affordance

through which the user (or automaton)

obtains choices and selects actions.

— Roy T. Fielding

SC SC

RPC REST

1

2

3

SC

SC

SC

SC

SC

REST

SC

SC

Loose conversational coupling

Enabling clients to discover

at runtime how to correctly

interact with a service is

a loosely coupled design practice— Cesare Pautasso & Erik Wilde

SC

REST

SC

SC

The server has to provide

the affordance towards

next steps the client can take.

It is impossible

for the server to know all steps

any client might want to take.

Tight affordance coupling

SC

SC SC SC

closed world open world open world

“today’s weather in Rio”

“tomorrow’s weather in Rio” “plane tickets to Rio” “hotels in Rio”

Weather API

Distributed AffordanceAn Open-World Assumptionfor Hypermedia

Problem statement

Concept and Architecture

Demo

C

P

S

user

publisher

provider

distributedaffordance

S

Publishers offer representationsthat contain semantic annotations.

HTML&

Microdata

Providers offer semantic descriptionsof the actions they support.

RESTdescP

Based on the semantic annotations,matching service descriptions are instantiated.

P

P

P

HTML&

Microdata+ =

Based on the semantic annotations,matching service descriptions are instantiated.

+ =Rio

Rio

Rio

Based on the semantic annotations,matching service descriptions are instantiated.

Rio

Rio

* 1*

1

Representation RepresentationEnricher«use»

ResourceExtractor

«use»

Resource«instantiate»

APICatalogAPIDescription«instantiate»

PreferenceManager

ActionGeneratorAction«instantiate»

«use»

Figure 1: The resources inside a representation are extracted 1 and combined with api descriptions 2 ,based on the user’s preferences 3 , into actions 4 , for which affordances are added to the representation 5 .

4. ARCHITECTURE

4.1 Components

The model architecture consists of five groups of compo-nents, as displayed in Figure 1, which we discuss in moredetail below.

1 Information extraction Given a resource with non-actionable information items, a ResourceExtractor extractsthose items as resources with properties. These resources arestructured as key/value pairs, for example as json [31], ormore formally, as rdf triples [21]. The benefit of the latteris that the properties are uris, which gives them universalmeaning across different applications. ResourceExtractoritself is only an interface, as many implementations are pos-sible. For example, for html representations, we can defineimplementations that extract resources from rdfa [2] orhtml� microdata [38]. For (partly) textual representations,extractors could for instance use named-entity recognitiontechniques [23]. In any case, the possible extractors dependon the media types of the available representations.

2 Provider knowledge The knowledge about actionsoffered by a provider can be generalized in api descriptions.The information in these descriptions should be structuredin such a way that, given certain resource properties, it issimple to decide which apis support actions on that resource.Different APICatalog implementations can support differentapi description methods, such as rell [3] or restdesc [35].It is important to note that the resource extraction methodis independent from the api description method, i.e., apicatalogs allow to search for apis based on resources andtheir relationships, regardless of how these resources wereextracted. This prevents coupling between information de-scription and api description, allowing instead to exploreall combinations thereof, which results in a more valuableaffordance for the user.

3 User preferences A PreferenceManager keeps trackof a user’s preferences and thereby acts as a kind of filteron the APICatalog, typically selecting only certain apis andsorting them according to appropriateness for the user. Var-ious models are possible, such as explicitly asking a userto indicate his preferences or learning from previously usedaffordances. In simpler implementations of the architecture,

the role of the PreferenceManager can be taken care of bythe APICatalog, which then only includes api descriptionsthat match the user’s preferences.

4 Action generation Based on a user’s preferences,an ActionProvider instantiates possible actions, which arethe application of a certain api on a specific set of resources.Thereby, every action is associated with one or more resourcesinside the representation, which makes the actions specificfor the representation instead of merely related to its context.

5 Affordance integration A final category of compo-nents are RepresentationEnricher implementations, whichadd affordances for the generated possible actions to a hy-permedia representation that is sent to the user. Throughthese affordances, the user can chose and execute the de-sired actions directly. Implementations depend on the mediatype of the desired representation as they need to augmentits affordance in a specific way. Technically speaking, thismedia type could be different from the media type whosenon-actionable information was extracted, e.g., resourcescould have been extracted from a json representation whilethe result is presented as html.

4.2 Deployment

Two main deployment strategies exist: the componentscan be deployed inside the client or offered as a service.

Client-based The architecture that provides the dis-tributed affordance can be implemented directly in a hyper-media client, or as a plugin thereof. In the common case ofa Web browser, it can be programmed as a browser extension.The benefit is that some of the client’s functional blocks canbe reused, such as the representation parser. When the clientrequests a representation, the extractor will be triggered tofind resources therein, which will prompt the action providerto combine these resources with relevant api descriptionsinto actions. Affordances for these actions can then be addedin the interface. In graphical clients, they could become partof the user interface or the hypermedia browsing space. Formachine clients, they are added to the existing affordance set.

Affordance as a service The drawback of the aboveapproach is that users need a supporting client to profitfrom the augmented affordance. This assumption can leadto a bootstrapping problem. Therefore, the architecture can

Distributed AffordanceAn Open-World Assumptionfor Hypermedia

Problem statement

Concept and Architecture

Demo

<div id="book" itemscope itemtype="http://schema.org/Book">

<span itemprop="name">The Catcher in the Rye</span> - by <a itemprop="author" href="#salinger">J.D. Salinger</a>

<div itemprop="aggregateRating" itemscope> <span itemprop="ratingValue">4</span> stars - <span itemprop="reviewCount">3077</span> reviews </div>

<div class="affordances" data-for="book"> <em>the browser will insert affordances here</em> </div>

</div>

centralized affordance

distributed affordance

publisher-driven

mostly within application

user-driven

on the entire Web

tight

affordance coupling

loose

affordance coupling

Hypermedia as the engine of application state

only works to the extent by which the publisher

can predict what affordance the client needs.

Distributed affordance uses semantic technologies

to generate the needed affordance at runtime.

Distributed AffordanceAn Open-World Assumptionfor Hypermedia

@RubenVerborgh

distributedaffordance.org