Wot-thing-description: Vocabulary change: InteractionPattern to Affordance

[vcharpenay]

In particular, td:Property seems too much overloaded. Proposals where:

• "property interaction pattern"
• "property resource"
• ... others?

The term of "affordance" was also suggested for td:InteractionPattern.

[vcharpenay]

as far as I am concerned:

• "property interaction pattern" is maybe not accurate enough, since property definitions in a TD have a different role (~instance) than action and event definitions (~schema)
• "property resource" does not tell whether the property definition is an _information_ resources (representing numeric or symbolic data) or a _semantic_ resource (used to identify physical-world entities)
• affordance is a rather good match for "interaction pattern" (by the way, this echoes the term of "intent" used by the Alexa conceptual framework: an affordance to the user agent should match their intent to trigger an action)

[vcharpenay]

@mariapoveda, @maximelefrancois86

[mkovatsc]

Somehow the actual words picked do not matter so much, but how we use them. Often I see synonyms, and synonyms that have not been used before.

InteractionPattern

I agree that the term "Interaction Pattern" does not fit for what we use it. The term still makes sense to describe what an abstract WoT Property, Action, or Event is (each is a particular way (pattern) to interact with a Thing). In the ontology, however, we use it to describe what interaction possibility a Thing provides. "Affordance" came in through https://github.com/w3c/wot-thing-description/issues/179 from @hibaymj's vocabulary, I think. Anyone else using the term? Anyhow, it fits well for what we use it.

However, will it be clear when we have Thing capabilities and Thing affordances? How do they relate linguistically?

Property

In the Scripting API, we use ThingProperty to differentiate from JavaScript properties.

[mariapoveda]

In case the decision is to use "affordance" for InteractionPattern, would it also solve the problem extending the decision to PropertyAffordance, EventAffordance and ActionAffordance?

[vcharpenay]

Sure. How about even reusing the terms used to describe operations/types of interactions in the binding template spec (1.1.1)? We could have someting like ReadWritePropertyAffordance, InvokeActionAffordance and SubscribeToEventAffordance.

[takuki]

iot.schema.org introduction material uses the term "affordances" for what TD call "interaction patterns" The book “The Design of Everyday Things” (1988) explains the original meaning, and it seems to match what we are providing with TD. Coincidentally, I also have recently thought about using the term in TD instead of "Interaction Patterns".

[hibaymj]

@vcharpenay wrote:

"property resource" does not tell ...

This is where my relationship maturity model comes into play. I suggest that affordance and composite resources aren't actually any different. Both express the relationship between two contexts, if the contexts are self descriptive as they should be then you don't need to artificially separate the two. I further assert splitting them up unnecessarily is of negative value to the whole solution ultimately.

@vcharpenay wrote:

affordance is a rather good match for "interaction pattern"

It's a good match, but with different cardinality. An intent is 1 to many affordances. In my system intent is better analogous to the Goal concept than a single affordance.

Do properties really need to be strongly defined? It seems like that would contribute to increased fragility.

@mkovatsc wrote:

However, will it be clear when we have Thing capabilities and Thing affordances?

I agree this would be odd because affordance is both.

@mariapoveda @takuki @vcharpenay Regarding reusing of affordance, I agree it could add to some clarity to be consistent but I wonder if it would simultaneously cloud the issue on where certain items should be defined. It seems like a lot of excellent work went into identifying ways to compartmentalize different types of relationships into independent sets e.g. the InteractionPattern's, however it's less clear how to distinguish from Action and Event for example.

My hypothesis here is this because of this design time ambiguity there would be issues with definitions being put in the wrong bucket. For this reason I chose to keep them in the same container and have each one explicitly define itself. This doesn't protect from using the wrong type, but it does protect from it not being found e.i. an Action defined as Event in the event bucket would never be found by a client looking for actions, but it could be found by duck typing or lenient processing on a single collection.

[egekorkan]

From Princeton Testfest with @mkovatsc's presentation:

• What is won by changing to assertion is not widely accepted/understood.
• This needs to be discussed further but everyone is aware of the problem

[vcharpenay]

Note: simply calling the class Affordance is maybe to broad. The links a TD includes are also affordances but of a different kind. My first idea was to use InteractionAffordance.

[mlagally]

I tried to find a clear definition for "Affordance" and found the following at Wikipedia:
https://en.wikipedia.org/wiki/Affordance

The affordances of the environment are what it offers the animal, what it provides or furnishes, either for good or ill. The verb to afford is found in the dictionary, the noun affordance is not. I have made it up. I mean by it something that refers to both the environment and the animal in a way that no existing term does. It implies the complementarity of the animal and the environment.

— Gibson (1979, p. 127)[3]

I'm not sure we should pick up a term that was made up in 1979 in the context of visual perception in the field of Psychology. I consider the definition very fuzzy and unspecific and would prefer to stay with InteractionPattern or pick something more descriptive, such as Interface pattern.

[vcharpenay]

@mlagally, that Wikipedia page is probably not the best in terms of structure but a few sections below, it also says that Donald Norman re-defined "affordance" in the context of human-machine interaction. He says (see source):

the term affordance refers to the perceived and actual properties of the thing, primarily those fundamental properties that determine just how the thing could possibly be used.

Isn't that closer to what we want to express? In fact, the word "affordance" has also regularly been used for machine-machine interactions, in particular on the Web to characterize _hyperlinks_ in RESTful APIs. The designer of REST, Roy Fielding, writes in his thesis (see source):

Hypertext (or hypermedia) mean 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.

The sense we want to give to that "interaction pattern" class is really that it allows clients (automata, in his words) to "obtain choices and select actions", isn't it? Maybe there can be a reference to Fielding's thesis in the TD spec?

[takuki]

I have done iot.schema.org and WoT presentation one after another a couple of months ago, and it was very confusing that the two use a difference term for the same concept. Either iot.schema.org should use "interaction pattern", or TD should use "affordance" (or "interaction affordance" as @vcharpenay suggests).

[mkovatsc]

The term affordance is used by interaction designers, the micro-service community, and REST advocates in general. I think this is a very good overlap for the Web of Things.

The concrete proposal is to have:

• InteractionAffordance
  
  
  
  • PropertyAffordance
  
  
  • ActionAffordance
  
  
  • EventAffordance
  
  

The term "interaction" can then refer to a concrete exchange of messages using an affordance. To me this makes good sense and resolves the cognitive dissonance around "InteractionPattern".

[mkovatsc]

These terms could then also be used in the Scripting API, where we currently have ThingProperty, ThingAction, and ThingEvent, which is not fully aligned with the TD spec.

[mlagally]

@mkovatsc I'm not sure that the term is widely understood outside of some specific communities.
If you poll 100 developers, how many would be able to give a definition?

@vcharpenay You are right that there are other definitions, however Wikipedia is the reference that pops up first at google search, and that is what most people tend to read.

Do we have a clear definition that we can agree on?

[mlagally]

Perhaps this can help?

http://mamund.site44.com/talks/2017-04-craftconf/2017-04-craftconf.pdf

[sebastiankb]

in today's TD web meeting we decided to go for 'InteractionAffordance'. As reference we should link to Roy Fielding thesis.

[sebastiankb]

@mkovatsc @mlagally
please note, this should be also aligned with the architecture document

[mkovatsc]

What about PropertyAffordance, ActionAffordance, and EventAffordance?

[sebastiankb]

btw: https://www.w3.org/wiki/AffordanceReferences

[sebastiankb]

@mkovatsc

What about PropertyAffordance, ActionAffordance, and EventAffordance?

yes, is covered in the latest commit

It seems that the reference to the Roy Fielding thesis of 2000 makes no sense since he mentioned this term "affordance" in a presentation in 2008.
Is it appropriate to refer to a presentation in the standard specification?

[takuki]

There is a book "Linked Data for Libraries, Archives and Museums" (Seth van Hooland and Ruben Verborgh, ISBN 9780838912515) on page 217 explains the concept of "affordance" citing Roy Fielding's presentation.

[sebastiankb]

Thank you. I'm not 100% sure if this book is a perfect reference either.

@mkovatsc @mlagally
Are you introducing the term into the architecture document? If so, I would make a reference to it.

[sebastiankb]

oh, I just see it here: https://w3c.github.io/wot-architecture/#interaction-affordances

I will make this reference to the architecture document.

[mlagally]

It seems that the reference to the Roy Fielding thesis of 2000 makes no sense since he mentioned this term "affordance" in a presentation in 2008.
Is it appropriate to refer to a presentation in the standard specification?

It is important to have stable references - the worst thing that can happen is that a normative reference can no longer be found. This can lead to a lot of confusion, so I'd recommend to only use ground solid references.

[mlagally]

There's a background section at https://www.w3.org/wiki/AffordanceReferences
which again refers Wikipedia and does not give a clear definition.

Unfortunately the term "affordance" is fuzzy and so far I have only seen descriptions that don't provide the clarity I would hope.

[takuki]

@mlagally , what about the description in the architecture document (written by @mkovatsc ?) that @sebastiankb just used as a reference?

[sebastiankb]

I think WoT can further establish the term "affordance" and the WoT architecture document can become the favored reference for this term in the furture.

[mlagally]

@takuki it is not in the terminology section yet, and if it is used it should go there. From the section that was written by @mkovatsc we can extract the following definition:

The Web of Things defines Interaction Affordances as the description elements of a Thing that show the possible choices to clients, thereby suggesting how clients may interact with the Thing.

However this talks about "description elements", "choices" and "suggestions", which again (perhaps only for me?) are not precise enough.

[takuki]

I suggest to further expand and clarify the definition of Affordance, such as the following.

"The hypermedia principle that is one of the bedrock foundations of the REST principle demands that any piece of information available on the Web be linked to other pieces of information so that the consumer of the information gets explicit knowledge about how to navigate the Web and control the Web applications, thereby the information on the Web becomes actionable, serves as an interface that affords people and software clients the means to drive Web applications. Drawn from this hypermedia principle, the Web of Things defines Interaction _Affordances_ as the description elements of a Thing that show the possible choices to clients, thereby suggesting how clients may interact with the Thing."

[sebastiankb]

I just see that we have also to update the ttl files from interaction patterns to interaction affordance

[vcharpenay]

Instead of Roy Fielding's presentation, we can cite the following book:

Cesare Pautasso, Erik Wilde and Rosa Alarcon (_edited by_), REST: Advanced Research Topics and Practical Applications, 2013, Springer.

The book references again Gibson, Norman and Fielding but it applies these concepts on current technologies (see Chapter 6 - _APIs to Affordances: A New Paradigm for Services on the Web_). Some of the authors even contributed to research on WoT.

[vcharpenay]

I like @takuki's proposal. I assume it would replace the 2nd and 3rd paragraphs of Section 5.3.1. I would suggest the following extension:

The hypermedia principle that is one of the bedrock foundations of the REST principle demands that any piece of information available on the Web be linked to other pieces of information so that the consumer of the information gets explicit knowledge about how to navigate the Web and control Web applications. The simultaneous presentation to Web clients of information and control, provided in the form of hyperlinks, is a mechanism that affords clients the means to drive Web applications. In this context, an affordance is the description of a hyperlink (e.g. via a link relation type or link target attributes) suggesting clients how to act on the linked resource. Drawn from this hypermedia principle, the Web of Things defines Interaction _Affordances_ as the description elements of a Thing that link to resources providing a representation of (parts of) the Thing's state, thereby suggesting how clients may interact with the Thing.

[mkovatsc]

To align with this definition, you should make sure there is no information about method and other request fields in the affordances. Remove forms and also put links there, otherwise the definition makes no sense.

Also, there should be assertions that Things must include TD elements in their operational data, otherwise they cannot present information and control simultaneously to Web clients.

[mjkoster]

I think we're getting hung up on the text of dictionary style definitions to try to make various points.

It is well known in the design community that an affordance is an external control or indicator on a thing. There is very little ambiguity around the concept.

So, it's natural to expand the idea to hyperlinks, or the things that hyperlinks point to.

It also makes sense IMO in our context to define affordances as the components of the application level interaction model, e.g. properties, events, and actions. This doesn't mean that we are forced to turn them into hyperlinks.

Of course a capability is also an affordance, in the more general sense, constructed of other affordances, but that does not necessarily invalidate or force our formal definition.

I think it's perfectly fine to define a semantic category of "affordance" to refer to the events, actions, and properties of a thing.

I also think it doesn't get much better than "EventAffordance", PropertyAffordance", and "ActionAffordance" in the context of existing definitions from the hypermedia and design communities.

An "PropertyAffordance" provides the mechanism for interacting with the thing through a property abstraction. An "ActionAffordance" provides the mechanism for interacting with the thing through an action abstraction, etc.

IOW, I think the term "affordance" is well defined for our use, and at the same time general enough to work as a semantic term.

[vcharpenay]

As PR w3c/wot-architecture#92 was merged, this issue can be closed, right?

[sebastiankb]

I will put it off of the WIP table.