Distributed Affordance
-
Upload
ruben-verborgh -
Category
Technology
-
view
1.903 -
download
3
description
Transcript of Distributed Affordance
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