Open Services, Interoperability, and Hypermedia: A possible Future (TRANSCRIPT)

Overview

Status: Delivered 2018-11-05 at OSLC Fest 2018 Stockholm, Sweden
Home: HTML
Slides: PDF
Prepared Talk: NA
Video: MP4
Audio: MP3
Transcript: HTML

Transcript (Unedited)

Mike: Hello, I work in a group called, as I mentioned, API Academy. So I’m actually very excited to be here. I love Stockholm. I love the Scandinavian area. I’ve been coming here on and off to visit customers and do work for almost 15 years. So it’s fantastic to be back. And, it’s fantastic that I’m meeting you for the very first time.

So I’ll just say this is me. This is how you find me on GitHub and LinkedIn and Twitter. And that’s actually the best place to find me. I travel a lot, forty weeks a year maybe, last year. It’s a lot. I’m cutting back, maybe 35. So I travel a lot. I travel around the world and talk to all sorts of enterprises, all sorts of companies, large and small, public and private, banks and hospitals, startup companies in Silicon Valley, all sorts of organizations. And I do that through this group called API Academy, which is a group of about half a dozen people scattered around the northern hemisphere, based in Paris and Zurich and London and Vancouver. And I’m in Kentucky, in the United States. So when I’m not here, I’m in my backyard. There are no horses in my backyard, but I get to relax.

But we travel around and we focus a lot on this notion of Services and APIs. Most of my customers are trying to figure out how to increase the rate of change, while maintaining or improving safety and stability, and reducing cost. That’s all. It’s a simple thing. But here’s the key. They cannot negotiate the rate of change. The customers I have, they can’t say, "No, we’ll slow down. We won’t add features. We won’t add customers. We won’t do what customers want." They can’t do that. They can negotiate some of the other things. Most of them negotiate stability. In other words, they move faster and their products are unstable. And that means they’re more costly. So the challenge, the opportunity, is to figure out, how to, what we say, harmonize speed and safety at scale. So that’s kind of what we do.

Carl Milles, a sculptor. This is a sculptor that I love. He’s Swedish. And when I grew up in the Midwest in the United States, I got to see lots and lots of his work, in Michigan. All sorts of places, in Detroit and all sorts of cities around it. So, when I come here I always visit some of his sculptures. And some of my favorite pieces are the one down by the parliament area, and then I love this one in front of the opera house. One of the things that amazes me about his work is how, it’s difficult to see from here, but it’s how his characters seem to move, they’re in action. They even seem to be floating around. I just find this really amazing, that he does such a great job in metal, in copper, in stone, to make things look like they move. And that’s just really, really impressive. It’s also fun that one of his pieces are right out in front of KTH as you first come in to the main campus area. This is his "Well of Industry", or "Bowl of Industry". I know it’s a little bit difficult to see here. There’s a great story behind this. If we have time, we’ll talk about it later. This was proposed in 1909. It wasn’t installed until 1926. There was a lot of up front design work, and a lot of arguments, and a lot of complaints, until he could finally build one. The project took a while. So I think some of us may relate to that.

So, the topic I suggested when we were talking, was this notion of how open services and interoperability and hypermedia interact with each other. Because we have a limited amount of time, I’m going to focus on the hypermedia side. How many people have heard this word? Okay. I think this is probably a good idea then. And see if we can’t provoke some thoughts, find some connections, as I describe things from the point of view where I’m working. I’m hoping that a lot of this will make sense even if you use different terms. "Oh you mean so and so", you might tell me. So I thought I would start with this notion of definitions that are common in the space I work in, and see how that intersects with yours.

Typically, this gentleman Ted Nelson is credited with creating the word, the actual word "hyperlink", or "hyperdata", or "hypermedia". And this goes all the way back to 1965. So when he’s writing, he’s doing his first initial writings about how he thinks computers will affect the world, he thinks that computers will be the thing that we all use to communicate with each other, to change the way we communicate. He’s doing this while he’s living in California, in Sausalito California. When he’s not musing about his sort of hippie ideas of how the world will be, he’s out surfing. And he basically says that in computers, we’re going to be able to "surf" the web. We get "surf the web" from his ideas about how he would describe the feeling of working in computers at the time. So hypertext, and hyperdata, hyperlink come from him in 1965.

Many people also talk about Vannevar Bush’s projects. When he was working on the bomb projects in the U.S., he got a bunch of people together. They were really brilliant and really smart. And he noticed something. When they worked together, they often fired off ideas from each other. He writes this article up called "As We May Think". And he says we think in leaps. We think in connections. Someone mentions a paper, and then another person says, "Oh I read that paper." And that relates to that thing that I did. And he makes this notice that people make connections through their brain. So, he comes up with this, what he thinks is going to be the future workstation, in 1945. He describes it’s table. It has microfiche and other things. And oh yes, there’s a little thing that you wear on your head, which is the pointing device, which points to a word, and then you can hit a button, say go look this word up somewhere else. He has this interactive experience described, in 1945. Long before we had the technology. Some people kind of refer to this as a "steampunk version of a workstation." Right?

Turns out Vannevar Bush was echoing things that Paul Otlet of Belgium had talked about 10 years earlier. Paul Otlet had thought of this notion, as we get electronics, as we get radio and television and movie and sound, he has this idea that you can bring all of this together in what he calls a "World Wide Network". Isn’t that amazing? 1934. And this is his version of a workstation, which has, you can’t really tell here, but here’s a radio. Here’s a telephone device. You might be able to call up on your telephone device to the central information station, and say, "Broadcast to me this movie." or "Broadcast to me this radio show." so that I can consume it right now. In fact, in order to fund his ideas, Paul Otlet runs an amazing business. He hires a bunch of people to read articles, and break them into small pieces, and put them onto cards. And he invents a card indexing system, very similar to the Dewey system, but much more sophisticated, that has all sorts of relationships in the ids and everything that explain where the providence is, and where this comes from. So he’s breaking all of these papers, all of these monographs, down into little cards. Then, he tells people, "If you write down a request, a search request, in a letter, and post it to us in Belgium, our team will gather together all these cards and send you a copy of them, a built monograph customized for you, on the subject, and we will post it back to you." He’s invented search. In the twenties and thirties he’s actually doing this work. And he has this idea that we’re going to build this city, this actual city, where all of the domain experts come. And the domain experts work with all the technical people. And they create these huge libraries of monographs and cards and interrelationships. And that’s how we build the information system. And this was in the 1930s. It’s really quite amazing.

But getting back to the point, hypertext is this notion that there is not a linear connection. Right? There’s this ability which we can move things around. We can connect things in various ways, and we do it through links. Originally, Ted thought of this idea that the links were separate metadata from the actual data. In other words, it was an overlay. We had the data, then we had the links, the active elements that we added to it. That’s not how it actually turned out. It turned out that when Tim Berners-Lee is reading all this material, he decides to make the links part of the data, part of the information itself. Right? So now when you’re reading the source of the HTML, what you’re really reading is a mixture of the link and action information, as well as the data itself. This annoys Ted to this day. If you get Ted Nelson on a room, you get Ted to talk about it, this is one of the things that he will focus on, this notion that we have mixed up the notion of the action items and the data in such ways that they can’t easily be separated. We’ve mixed them up too much. But that’s for Ted to worry about.
Person: Mike?
Mike: Yes.
Person: Can we ask questions?
Mike: Yeah.
Person1: Because this is one of the discussions we’ll be having in the community all the time. Is the link a primary object, or is it part of the data, one inside of the other? Is there, in your world, is this really decided already? Or is there also a gray area where you also establish links as primary objects?
Mike: Yeah. So, that’s a great question. So this notion of, are links primary, do links belong in the experience, or are they an overlay? And most of the people we work with in the authorship space, or the document management space, actually like the idea that the links are an overlay, that they are metadata about the data. Most of the people in the machine or the API space, like that the links are part of the information. Roy Fielding has a comment. He says, "where the information becomes the affordance", where the message I get has everything I need inside in order to take action. So both of those things work for different reasons. One of the reasons Ted likes this notion of links as separate is because he wants you to be able to have your links on the same Shakespeare sonnet that I have. Right? For him, Ted has a really different view of what links are for. Whereas, in the machine side or in the application side, when you think of link binding and you think of the way the early OSLC products worked, right, I want to be able to know that right here, a link sort of serves like a call, like a piece of functionality. So it works in both ways.
Person: Right. And there is a practical reason as well to have links separate, because you may not own the data on the side you want to connect to, so you do not have the right to add the link information to the data because they are owned by someone else.
Mike: Yeah. That’s right.
Person: Separate, you can own the repository where the links reside and you can do your own link work.
Mike: That can be…That’s right. It can also be very difficult to do as you change your scope, as you widen your scope to more and more things. I may not know what’s even at the other end. Right. So I mean, not only do I not know if I have rights, I will discover those rights when I get there. But I may not even know if I should show the link at all. So there is a combination of that as well. We sometimes talk about [inaudible 00:11:45] link. Right? I don’t really know, until I look, what’s really going to happen. Right? So that’s a big part of the development. That’s good. So we normally see authorship folks focusing on links as meta, and machine and API folks focusing on links as information.

So, hypermedia offers this power, as I mentioned, to do what Allen Kay used to call "extreme late binding". One of the advantages of hypermedia is, I can put a link here, and we’ll let John solve that problem when we get there. Right? I don’t have to know today what’s going to happen at the other end, because that’s going to be a different UI and that’s going to be a different experience. One of the powers of time is that it changes what we want. Right? So time is actually an architectural element in an information system. So I can put a link here today, and not have to solve the problem until tomorrow. I can put a link here today that solves today’s problem, but it might solve another problem tomorrow. In other words, I don’t have to know everything first. One of the powerful elements of linking is that I don’t have to know all the answers, but I do have to know a few questions. And that becomes a big part of what…We’ll see if some of that makes sense a little bit longer, a little bit sooner.

So I thought, instead of being very prosaic, I’d just show some real simple examples of hypermedia that we use in our work, and see how that fits for you. None of this is hypermedia. Right? Nothing. There’s nothing here about hypermedia.

That’s hypermedia. Right? So the hypermedia is not the link. That’s just data. I don’t know what that means. I don’t know why I would use it, or what’s going to happen. That’s hypermedia, in HTML. That anchor tag. What does that anchor tag say? What does that anchor tag mean? What is the idiom? Who can tell me what the anchor tag means? Yes.
Person: It’s a reference to a resource.
Mike: Yes. And it says "Go there." Right? The anchor tag says, "You can go here." Right? That’s hypermedia. And it gives us some information. Where is here? It’s this reference, that you mentioned. It gives a little information for humans, if I want, as well, about how they might interpret it, or perceive it. This doesn’t say why you would go there? This does. Right? So the actual activity is different from its meaning or its purpose. It’s simply an activity. And we’ll talk about it a little bit more.

This is another one. This is hypermedia. What does this hypermedia say? Anybody. Yes.
Person: Go to an image.
Mike: No.
Person: No.
Person: Add an image and embed it.
Mike: Yes. It says "Go get that image and bring it here."
Person: Bring it in my…
Mike: Bring the image. Right? What Ted Nelson would call "transclusion". Let’s include, from some distance away, the thing that goes here. iframes, right? iframe is the same idea. Right? Take all of that stuff, and bring it and put it here. That’s hypermedia. All right?

What’s this one? It’s missing a link here, I apologize for the error. But what does this one say? This one’s a little bit more sophisticated.
Person: It says interactivity.
Mike: Yes. What is the…Describe to me exactly what this interactivity is. What is this saying must be done?
Person: You put your input here. You may…
Mike: It says "Collect some data." First. And then, I’m sorry, again I have a bug. I don’t have a URL here. There should be a URL here. Then what does it say should be done? Once you collect the data, what should be done?
Peson: Send it.
Mike: How do you send it?
Person: [inaudible 00:15:49]
Mike: How do you send it? How do I fashion it? How do I construct it? How do I construct this query? Again, I give you a hint. I have a bug. I’m missing something. Yes?
Person: Well actually, it’s not a bug. So I think HTTP, HTML allows you to…
Mike: It does.
Person: …not send the URI. So it will submit a GET request to the same page where that form was fetched from.
Mike: And…It will submit a GET request. So tell me the details. Yes. Go ahead. Assume it’s the same page. Tell me more.

Person: As soon as the event of submission happens, basically identified with this input, with the submit.

Mike: No no no. You need to tell me, so what did I do with the input?
Person: I mean, there are two things. First you render a form, and second you submit a form.
Mike: All we’re worried about is what is this telling me to do. Right? What it’s saying is, take a URL, add a question mark, add the input id, give an equal sign, the input value. Now do the same thing that you did up here. Right? Right? So this turns out to be a mutable link. Right? It’s a changeable link. The only difference between this one and this one is it allows me to actually change some of the URL. Hmm?
Person: Add my own [inaudible 00:17:01].
Mike: Yeah. To add some more input. Right? You’re correct also about the notion about rendering and so forth. But, there’s a lot of assumption here. There’s a lot of things that must be worked out, agreed, ahead of time. Right?

So how about this one? What does this one say? Quite different than the previous one. Anyone? Yes.
Person: He sends a separate package to…
Mike: Right.
Person: …[inaudible 00:17:32] destination.
Mike: Take the input. Matter of fact, it happens to be the same input, doesn’t it? But this time I’m not going to attach it to the end of the URL. As you mentioned, I’m going to create a body, a package, and send it that way. And I’ll also be using this method, this POST method. Right? That’s hypermedia. Hypermedia is telling you what’s possible, and what it would take to properly form a request, and all of the details that goes along. Do I collect input? How do I arrange the input? Where do I go? Whether I put that in the body. And there’s some other things about the difference between the POST and GET. Who can tell me what the difference in HTTP language, the difference between POST and GET is?
Person: Which way is the information going?
Mike: Which way is the information going is interesting. One is safe. Right? GET is safe. It’s making a promise, a network level promise. It says, "You can do this and I’m not going to delete anything or alter anything that shouldn’t be, that would be impactful." POST says something different. POST says, "I’m going to be writing some data." There also is another difference between these two. It’s a thing called idempotency. In GET I can repeat it over and over again and get essentially the same semantic result. So I can request it seven times, and I get the same answer back. In POST, it’s non-idempotent. So I do it seven times, I’m going to get seven things done. Does that make sense? PUT is a little bit different. PUT is idempotent. I can repeat the same PUT. It’s like a SQL update, whereas POST is like a monotonic insert. Right? If I keep doing it over, I keep inserting. These are guarantees on hypermedia. Right? I guarantee you this is safe and repeatable. I guarantee you this is not safe and it is not repeatable. There’s a lot of information stored up in these hypermedia elements.

As a matter of fact, there’s a series of elements, both control elements and link elements, that can be used to kind of find a signature for media types. So this is a sort of a signature pattern that I worked up to analyze formats and analyze responses. Where’s the hypermedia? What kind of responses can I do? Do I link embed, like we saw the image? Can I do link outbound, like we saw for A? Is there a link template, like a search form? Is there a link non-idempotent update, like the POST? Is there a link idempotent update? Is there some form of DELETE or PUT or PATCH? Right? And there are also control elements, controlling what links I can see, the responses I want back, what response I should use on update, how I control the actual method of the protocol. There are lots and lots of these elements that we can start to think of. And we can start to match message models with the kind of hypermedia factors we’re looking for. If I’m doing SVG, I’m not going to be writing any data, I don’t need any templates, but it would be nice to have some links. Right? If it turns out that it’s really important that I have idempotent updates, native HTML’s not going to work. There have been several attempts in the last 25 years to add idempotent updates, but they’re always rejected. However Atom, or OData or several other languages, offer them. So now we can start to think about how we would judge a message model for its power.

All right. Let’s take another run at this. So where’s the hypermedia in this message?
Person: There is none.
Mike: There is none. Right? This is usually the message my customers get back from a service. Right? So, how do I know where this can be found?
Person: In some human-readable documentation?
Mike: Yes. There’s probably human-readable documentation that will get translated into code. Right? And that human-readable documentation will say something like, "Use this base URL for this service, and then find the id element and add the id element to the base URL. And that’s how you find it." Right? And if the base URL changes, my code’s bad. So then I might configure it, right, to make it easier. So when the base URL changes, my code’s misconfigured.

Okay. Better. Right? Better? Yes?
Person: Most people would react to this, "Oh, let’s not put this IP out on the example form, because we might want to change the domain names." even though they could do that…
Mike: Yes. Yes.
Person: …would choose to do this.
Mike: Yes. Because…You would choose to do this because you want to change it?
Person: You don’t want to commit to where that location is, you know? I mean, it’s just…
Mike: This is a response, right? This is not a database. This is a response.
Person: Yeah.
Mike: So I don’t, when I give responses, my responses have the real one, not one that they had 6 months ago.
Person: Right.
Mike: Right? So my response will always be correct.
Person: Yeah. But my…I would be curious, when you give them that, is that the…I mean your customer, say, the people that want to build the system, they would say, "Let’s…But can we avoid adding this API, but we can add that in the code, so that this…"
Mike: I see. They want to optimize out the change. Right? They want to make it static.
Person: Relocate where the location, [inaudible 00:22:52] where the actual server is.
Mike: It’s up to them. It breaks their code, if they want to do that, but they can do that. Right? Because I cannot control how the consumer behaves. Right? Yeah. I might be able to find them, maybe. Maybe [inaudible 00:23:05] them.
Person: It is a general struggle to try to promote this having this location, this URL in the actual data.
Mike: Not in the data, in the response. Right? There’s a difference, right? There’s a big difference. Big difference. Where did this data come from?
Person: [inaudible 00:23:22] the response, the request you made.
Mike: Where did this data come from?
Person: Some database [inaudible 00:23:26] ?
Mike: Two databases, actually. Right? So the assumption that the response actually maps directly to storage is a really simplistic assumption. It’s hardly ever true in my space. You were going to say something. Yes.
Person: I think the issue that John was raising. I think it’s bigger one, of URL stability. Because I think what John was trying to say is that people don’t want to put URLs into responses so that they don’t have to commit to URL stability in their systems.
Mike: Wait a minute.
Person: It’s a common…Yeah.
Mike: So wait a minute. You don’t want the response to actually contain where it came from?
Person: We do. We are just…
Mike: Okay. So who is it that doesn’t want this?
Person: Whoever is giving you that response. Whoever is dealing with…Whoever is trying…I mean I’m thinking tool integration here. If you are trying to integrate and trying to link between two systems, they prefer a more generic id, than committing to what that location is. So that way people [inaudible 00:24:23].
Mike: So I still don’t understand why that would be. Is that because they don’t want you to know how to go get it?
Person: It’s because they’re probably not web kind of based people. They’d like to keep [crosstalk 00:24:31].
Mike: So, no no, I’m actually trying to understand the positive aspect of not including the providence. What is the positive asset they’re afraid that it won’t win?
Person: I think it’s more resistance issue because to store a URL cost a lot more than storing only a simple id. And so…
Person: We need to know that. Yeah.
Mike: Yeah.
Person: We believe that.
Person: That’s more comfort feature, I would say.
Mike: Yeah. Now I think we’re getting to the heart of it. Right?
Person: It’s one aspect. I wouldn’t say it’s a main. Many people understand that storage doesn’t cost so much.
Mike: Okay. So storage and [inaudible 00:25:04] . What’s another aspect?
Person: You know, committing to the IP on the example .com.
Mike: Who’s committing to that? Who’s committing to that?
Person: Whoever’s providing that response. They have to register that API with their IT system, and that server’s going to be up.
Mike: No no no. Oh, I see. You think this promise is forever.
Person: Well, I guess. Yeah.
Person: For the time…
Person: I would say it’s in the beginning, but I mean.
Mike: Ah. Okay. No. No. For instance, I will tell you right now I got this one back because I was actually an administrator. But someone else would get a different URL.
Person: Now you’re causing more trouble.
Mike: No, I’m actually causing less trouble. Right? Because now, the application doesn’t have to understand all of that information, including how it changes 5 years from now. All right? I understand. Often the motivation is, oh, there’s too much data. I think that’s what you were getting to. Sometimes the motivation is, this is supposed to accurately reflect something that I might save for 6 years, right, so I don’t want to commit to that. Right? That’s a different kind of persistence. Right? And it’s usually because we think of this not as a response, but as a thing. Does that make sense, what I just said? We don’t think of it as a transient response. We think of it as a permanent thing.
Person: Okay. Yeah.
Mike: Right? And in the web, none of them are permanent things. They’re all transient responses.
Person: That’s maybe like a difference between your community and ours, a bit. Because in our community, when we bid the systems with [inaudible 00:26:42] we need like a [inaudible 00:26:43] of the links. So I mean, it is [inaudible 00:26:46] if you want you have like full traceability of the design process in the past you cannot afford to break these links. You have to keep them.
Mike: So, you have no redirection possibilities.
Person: We haven’t really thought about it. I mean it’s like an issue…
Mike: Wow. Really?
Person: Yes.
Mike: Okay. Interesting. You live in a world that never changes. That’s amazing.
Person: Once it’s committed and it has been reviewed, somehow it’s not open world any more, it’s closed world.
Mike: Wow. Yeah. Not is it closed world, but it’s frozen.
Person: That’s not quite true, because you have redirection built in the HTTP services and [inaudible 00:27:25] the first place. And you may not make use of them enough that this API example all point to one place today and another place tomorrow, which is the one we want to go.
Person: The interesting question is what is deemed more stable than URIs.
Mike: Yes. I love this.
Person: I mean that, if you don’t get your DNS on your intranet or some say control the URLs anyway. Right? I mean the best thing we have to identify things in the World Wide Network is a URI.
Person: I think that our community, that my experience is that it’s not web-based. It’s not sort of…It’s database tool people. They like things in a database. And they don’t realize this, it will track [crosstalk 00:28:16]
Person: We are discussing today and tomorrow that we are changing in that regard, and that people are thinking of APIs and they’re connecting over the internet. And in this on-site, on-premise, my [inaudible 00:28:30] hostname. Right?
Mike: We’ll do one more and then we’ll…Yes.
Person: I think if you want to be sure that the data you need at the end of the link are still there, something you have to do is process those data for yourself, take what you need and store it in your system. I mean, if you are interacting with external system that is not supposed to be there forever. So if you want to have those data forever, you just follow the link today, take the other data you need, because you don’t need anything, you just need some of them, and store them in your system. I don’t think the problem is, you know, having the URL, is how you pretend to use it.
Mike: Yeah. How you intend to use it. Right? And there are lots of features in network protocols like HTTP that give you information about the rules about storing, and how long you can store it, and where to go to refresh it, and how often you can refresh it. So there is lots of help in this space as well. I think this is a really good point. I love that we’re talking about this. There was another question. Oh.
Person: I just have annotation to that point. Where do you want to stop in storing [inaudible 00:29:43] because if you have linked .com that can be linked further and further and further. So you want to store all of the link traces till the end, then you need a really big database.
Mike: You need only one database though. Do you know this comedian? He says, "I have a life size map of the world. It’s really hard to fold." Right? So if I follow every link and every link and every link, I only need one database. All right? But shall we all have the same copy…We have a copy of the same? Or shall we link them in time, right, and when we need them. Right? Okay.
Person: That is sometimes a requirement for business, that you have all the information, at this time, frozen.
Mike: At this time. Right?
Person: That you will have documentation requests.
Person: That’s different.
Mike: At this time.
Person: And you have to prove that you think on all aspects that are that time known.
Mike: Yeah. Sure. I understand. Let’s have this discussion some more and I want to kind of cover a few other things as well. I like some of these discussions. Okay. So now we have two URLs, two hypermedia controls. What does the second control tell us? What does this control tell us?
Person: It can change?
Person: We can change something. Right? We have a URL. Right? What else does it tell us? Does it tell us what method to use, what protocol to use, what data to pass? Yeah. This is the next level of what my customers do. They say, "Oh, okay. So more than just this implied GET." There’s also this thing you can edit. But they don’t say anything about how. Meh. Right? It’s not really very helpful. Here’s another one.
Person: [inaudible 00:31:36]
Mike: Right?
Person: Same as before.
Mike: Approve. What do we do?

How about this? What is this? A little bit more information, maybe. Right? But apparently…do you pass any data? This is often the next level that my customers do. They sort of figure out that I need to use this name as a data element, not as a structural element. So remember it moves from structure to data. So now I can use it as part of my vocabulary. Right? And they figure out that I do need to indicate something when I can imply the protocol. But they forget about data, until finally they can start adding data. Now it explains two values that I need to pass, maybe the current value and whether or not it’s required, and all these other things. All of the things I’ve shown you are all late bound. All the things I’ve shown you can be handled by algorithms, not by programming any sequential way. Right? Yes.
Person: Quick question. In your example, you mentioned before you have links and control elements.
Mike: Yeah. Yeah.
Person: So in this example, the control elements would be the method value?
Mike: So that’s a good question. So what do I call a control here? So I actually refer to action as the control…
Person: Okay.
Mike: …and this as the control, in this case. So these are elements of a particular action. And these are all structural level elements in the way this has been arranged on the page. And these are all data level elements. Right? So as a human I can sort this out, but as a machine, I would have to memorize all of these. I’d have to code all of these in. The good news is I can use them millions of times over. Right? I would also have to code this in in some way. This becomes the context. This is the brain. This is the choice part. I wouldn’t have to code this. Right? I wouldn’t have to code this or this or this. I would have to code this. Does this make sense, what I’m saying? There are certain parts I have to know ahead of time. There are lots of parts I don’t. Okay.

So the thing is, right, that’s an awful lot more information. Right? So often my customers will say, "Well now wait a minute. There’s actually more meta than there is data." Yeah. Yeah.

So hypermedia adds information to the message, information that lets us write algorithms so that either humans or machines can start to handle problems on their own, as long as they understand the context. It’s very difficult to encode context. How am I doing? I got 10 minutes?

So what I’ve just described are things called affordances. Has anyone heard this word before? Right? An affordance. An affordance is something that was created by this man, James Gibson. In 1977, he imagines this idea, "Affordances of the environment are what it offers, what it provides or furnishes, either for good or ill." So this affords maybe working the projector. Right? It also affords throwing. I can bean somebody with it. That’s an unintended use, unintended affordance, but yes, there it is. All right? There are affordances all around us. We manipulate our world through affordances. By adding information to messages…I’m sorry. By adding information to messages, we place affordances in the environment that someone can manipulate. They don’t have to. I don’t have to throw this at you. But it is an opportunity. We’ll see how it goes.

So Gibson thinks of this notion that humans interact in their world through affordances. And they actually receive signals. They actually see light. And they notice, "Oh there’s food." "Oh there’s a monster." "There’s a predator." "There’s a place I can hide." So on and so forth. "There’s a chair I can sit down in." And it turns out the affordances are actually very much in context. So this chair affords me sitting. It does not afford my 3-year-old to sit in this chair, because he’s too short. He needs a different chair. All right? So he lives in a slightly different environment. It’s all big and it’s hard to deal with. Even though we’re both in the same room, our views of the world are how we find the affordances. And thinking of views in the world will be very valuable to us.

Donald Norman. Do we know this Donald Norman? He writes this wonderful book called "The Design of Everyday Things". Really encourage you to read it. Yes. It’s a wonderful description about using this notion of affordances in interaction in the real world. He’s coined this thing called a "Norman door". Anyone ever seen a "Norman door" before? It’s the door that has the handle on it that goes like this. Right? And you pull on it and it doesn’t work. It doesn’t work, until finally someone comes along and somebody pushes. The door lied to you, right? Right? We thought it was a pull door and now it’s a push door. Right? Or, Norman doors are glass doors. You see people walk into glass doors because they can’t tell. There’s nothing there. There’s no affordance. It doesn’t afford an opening. Well how does it work? We don’t understand. Donald Norman has lots of great observations about the way we interact with things. And it drives him to start working in this human computer interaction space. We know a lot about human computer interaction because of the work of Donald Norman.

Lo and behold, in 2008, Roy Fielding confesses that he too thinks about affordances, when he thinks about his REST dissertation and all these other things, where there is a "simultaneous presentation of information and controls the information becomes the affordance for making choices." The message has the environment that tells you what’s possible. This was one of the key elements of Roy’s REST notion, that the message should have the affordances in it. This goes directly to your question. In Fielding’s world, the links and the forms are actually native. They’re not meta. They’re not added data, for him. He does talk about some other ways you can apply it as well. But, when he talks about it, this is what he talks about. When I talked to him about this, he said he suspects he was probably reading Donald Norman at the time he wrote this.

So one other power of hypermedia is that it affords dis-coordinated change over time. In other words, I can make changes to my web page, I can move the links, I can add the links, and I don’t need to get permission from you. Right? I don’t need to [inaudible 00:38:21] it. One of the things we talk about in enterprises when they’re talking about change, one of the things they like to talk about is this notion of decoupling change over time, having decoupled services that can change independently. How do I know they can change independently? They can change, and they don’t have to have a meeting. They can change and they don’t have to wait for the other team to update their service before I can change my service. They can just change. This is exactly how nature works all the time. Right? We manage change all the time in our lives. But in computer systems we usually try to make it a pretty big ritual. We get a lot of people around, a lot of expensive folks. We cancel holidays for the weekend. Everybody comes in on Friday night. We buy beer and pizza. Maybe it’s just a party really. And then we sort of flip the switch on on Sunday morning, and hope it all works by Monday. But most of my customers don’t do that. Most of my customers can’t even control parts of the system they interact with. They can’t get them to change on their schedule. Right? So it’s a big deal.

All right. So I have just kind of a few things. I’ve tried to kind of generate some discussion, some conversation here. I’ve kind of last track. I think I’m about out of time. Right? Am I out of time? I think I’m pretty close. Yes.
Person: Thanks a lot for some provocative messages. Could you please go back to the slide where you showed how [inaudible 00:39:52] response with actions changes to add the nested object for the type of action?
Mike: Is it this one?
Person: Yes. This one. So I think that exactly goes back to [inaudible 00:40:07] question involving links. And I think anchors is the same. So I think an anchor in what we would be discussing as a link. It would be a proper object. And it would have a ref, an HREF attribute. So I think…
Mike: So this is something you’ve been discussing, you’ve been talking about. Yes.
Person: I’m trying to bridge the notions. Even in the world where links are embedded in the documents, in the HTML…
Mike: In the response. Yeah.
Person: …[inaudible 00:40:39] there is still place for links that are not bare links, but typed objects.
Person: Sure.
Person: Sure, yeah. So this comment we’re having is, if you introduce links as a primary object, of course you have embedded links to this primary object in order to make the connection there. So the question is, and it leads to all falling out questions as well. For example the one, do you have full specified URIs in there. If you have separate links, you may be able to manage those changes in your link repository as well, and so on. So this is still in question. I’m glad that we are having the same discussions here, that it’s not modeled one way hypermedia, as you had said. If you only have embedded links and so on…
Mike: Yeah. Also, I should point I think to kind of continue that level of discussion. There are a whole series of formats that have been generated over the last 5 or 6 years on the API side that are exploring designs for this. So Adam and OData and HAL and Collection JSON and UBER and Mason and Siren. There’s a whole series. And all of them approach this problem differently. Some of them may have this notion of, there’s a general link. Even this one would be…even if it’s just a GET, it would have the same action structure. Others have named links much more similar to this, and they have some data specifications, or some metadata specifications about what you design. Some of them actually use a URI as a definer for all of the meta, but they don’t send it in the message. There’s a whole range. These are all design questions. There’s one called UBER, where there’s only one link type. And every possibility, transclusions, and exclusions and GETs and POSTs and all that other stuff are all described as meta of the one link type. There are others that are like HTML where there are various link types. So these are all design elements.

Let me just end with one thought to kind of get us closed out here. So it turns out the more you place in the message, the less code you have to rewrite. If I change the links and I teach my code to just look for the value of the link, I didn’t have to rewrite the code when the links change. Actually I can promise very few links and use redirections to get people there. If I include all of the form information, about whether or not it’s required and not required, and the regex and all those other things, that’s code I never have to write, I only write once, and I can change over time. If I can say process all of the variables, then it doesn’t matter if there are 1 or 9 or 12 or 13. I don’t have to change the code. So the more information I have in the message, the less code is impacted each time I make a change. The more meaning I have in that message. We haven’t even talked…we skipped all over the notion. I didn’t talk at all about meaning. Why would I use any of these links? How do we determine that? Where is the semantic element stored? And how much context I put in the message. All of these things are the big challenges. We barely scratched the surface when we talked about adding more data or information to the message. We’ve not even discussed how to layer meaning onto the message, semantics onto the message, or how to make sure that the semantics are in the proper context. One of the biggest challenges in AI is we’ve got all of the data and none of the context. So we can do stupid things, and embarrassing things and all sorts of things because we don’t understand the context, we’re deriving some weird meaning from past experience.

I love this quote, and this will be the final quote. Paul Clements worked a lot in military and public sector in the United States. He’s a retired professor. "The best architecture knows what changes often and makes that easy." Making change easy. John talked about making innovation easy. Making change easy is the key to success. Right? Making change hard, then nobody’s excited.
Person: But, you have to be careful about what conclusions you are taking from that statement. Like Geoff had mentioned, so if you avoid the full qualified URI in order to make change easier, you may get trapped by old fashioned thinking.
Mike: It’s how you make it easier. Right?
Person: Yep. That’s the challenge.
Mike: You also need to know who you are optimizing for. Am I optimizing for the person writing the software, or for the person using the software, for the tool vendor that’s going to interact with the software? There’s lots of optimization possibilities.

By the way, this sculpture, the reason it took so long is because originally it looked like this. And it was deemed too abstract. Too many abstractions. People didn’t understand it. It was too difficult. So they argued for years and years until they finally got him to create this. And he hates it. This is not what he meant at all, but that’s what they kept asking for and asking for. And it got more and more specific and more and more specific. And all of the meaning and all of the context and everything was just driven out of it. And now it sits there. Nobody uses it.

Thank you very much. I really appreciate the chance to talk with you. I’ll be here all day today and tomorrow as well.