1. The Talk

  • Last Updated: 2014-04-08

These are my notes and reasarch bits for my WSREST2014 talk in Seoul, SK on 2014-04-07. Below are some additional links you can follow:

1.1. Prologue

Example 1. SLIDE cover

Title, Subtitle & author tag

Thank you for giving me the opportunity to address you today. I am honored to be here and hope to make the most of the short time we have together. I will try to keep my remarks succint and hope what I tell you today will spark ideas and promote discussion.

Example 2. SLIDE The Paper
pic of the PDF paper

I will only briefly mention the paper which I submitted for this workshop; "Follow Your Nose vs. Hold Your Nose." I ask that you read it, if you haven’t already, and to feel free to provide feedback and comment on it. The paper and this talk are ‘partners’ in my conspiracy not twins. So, I will use the contents of the paper as merely a ‘jumping-off point’ for my presentation today.

To that end, I want to focus on the sub title of the paper "Obserations on the state of service description on the Web." And I want to highlight on three things:

Example 4. SLIDE ObservationList
  • The Web

  • Service Descriptions

  • Something Else

Because these three topics are at the heart of the paper. We should be promoting and enhancing the Web. We need to think clearly about how service descriptions are, or are not, doing just that. And I want to offer up another way to look at both the problem and the potential solution.

1.2. Part 1: The Web

It is appropriate to talk about the Web this month because it was 25 years ago that Tim Berners-Lee first began outlining the notion of the WordWidWeb.

It was in 1990 and he and Robert Cailliau (k-eye-you) authored the Proposal that defined the Web that we know today.

Instead of going through the details of that document, I’d like to offer a slightly more whimsical interpretation of the Web.

Play Video

So, two points from the video are worth noting. These are part of what I call the "Disney Dog Rule."

First:

Example 8. SLIDE IHaveJustMetYou
  • "I have just met you and I love you!" - Dug

Or, to take a quote from the Berner-Lee/Cailliau proposal:

Example 9. SLIDE HyperText
  • "HyperText provides a single user-interface to many large classes of stored information…" - Berners-Lee / Cailliau, 1990

One of the key aspects of the Web is the notion that, even if the client (browser) and the server have ‘never met’ they should be able to understand each other. They should be able to interact successfully. This was one of key problems Berners-Lee and Cailliau wanted to solve:

Example 10. SLIDE wePropose
  • "We propose the implementation of a simple scheme to incorporate several different servers of machine-stored information already available." - Berners/Cailliau, 1990

And the second part of this rule is:

Example 11. SLIDE Squirrel
  • "Squirrel!" - Dug

Dug’s sudden realization that there might be something ‘over there’ that would interest him is also an essential aspect of the Web. Again, to take a related quote from the 1990 document:

Example 12. SLIDE aWebOfNodes
  • "[A] web of nodes in which the user can browse at will." - Berners-Lee / Cailliau, 1990

"Browse at will" is, if you will, the client view of the "I have just met you…" idea. We can browse at will when servers can be linked together. And linking is incredibly important here.

And, in a more updated version of the same theme, here is a quote from Ed Summers talking about the power of linking data:

Example 13. SLIDE Nose
Example 14. SLIDE aClient

The Web is not just a way for A client to talk to A server.

Example 15. SLIDE manyClients

Its about creating a way for lots of clients to talk to lots of servers.

And it is important to keep in mind that it is links that are important here.

Example 16. SLIDE timOnLInks
  • "[Links are] necessary to connect the data we have into a web, a serious, unbounded web in which one can find all kinds of things." - Tim Berners-Lee, 2006-09

Note that the talk here is about links, not URLs. URLs are the way we create and express links.

It is links that make the Web go round. Links are the value in the network, not the content on either end.

This notion of link value, first described by Barabasi and Albert in their 1999 paper "Emergence of Scaling in Random Networks" has come to be known as the Power Law of Scale-Free Networks.

And there is no better example of a Scale-Free network than the World Wide Web.

So, the three things that capture the essence of the Web are:

Example 20. SLIDE threeThings
  • I have just met you…

  • Squirrel!

  • Scale-Free Power-Law network

1.3. Part 2: Service Descriptions

And that brings me to point #2: Service Description.

Service Descriptions owe most of their legacy to the notion of Ingterface Description Languages or IDL. The classic IDL formats that helped shape the way developers interact with component software includes:

Name them as they build

These are all standards that describe ‘local’ interfaces; interfaces for components that are all running in the same general ‘clock space.’ These appeared before the Web and have none of the characteristics we talked about earlier ("I have just met you…", "Squirrel!", and "Scale-Free".

And there are a series of Web IDLs, too:

And there are many more. As of this talk there are more than a dozen service description languages for the Web either proposed or in active use. And they all have the same legacay: describing ‘local’ interfaces for code-based components.

And, for that reason, they are all broken.

On the Web…

Example 26. SLIDE webInterfaces

But with Web IDLs…

Example 27. SLIDE webIDLRarely

Rarely support multiple formats and almost always use only HTTP.

They rarely support multiple formats and almost always use only HTTP. I will point out that WSDL is a notable exception to this rule.

On the Web…

Example 28. SLIDE nonHierarchical
  • "This forming of a web of information nodes rather than a hierarchical tree or an ordered list is the basic concept behind HyperText." - Beners-Lee/Cailliau, 1990_

  • http://www.w3.org/Proposal.html

But with Web IDLs…

Example 29. SLIDE resourceHierarchy

Almost all Web IDLs define a hierarchy of resources (nodes).

Hierarchy is actually the central controlling element in Web IDLs. It the resource list and the outline-like relationship between them upon which most all serbvice descriptions for the Web are based.

Finally, on the Web…

Example 30. SLIDE jumping
  • "The texts are linked together in a way that one can go from one concept to another to find the information one wants. The network of links is called a web. The web need not be hierarchical, and therefore it is not necessary to "climb up a tree" all the way again before you can go down to a different but related subject." - Berners-Lee/Cailliau, 1990

  • http://www.w3.org/Proposal.html

But with Web IDLs…

Example 31. SLIDE captiveClients

Clients are led to accept only the pre-defined links from just one service.

Client applications are led into memorizing links and workflows such that the same client application is now tightly bound to that single service model.

Service Descriptions for the Web not only don’t support the "Follow your Nose" principle, these formats actually train developers to write clients based on the "Hold your Nose" rule — to ignore what you don’t recognize and go about your business.

To paraphrase a wise sage: "These are not the squirrels you are looking for."

Pause

In fact, service description on the Web today almost always describe this:

Example 33. SLIDE aClient

Instead of this:

Example 34. SLIDE manyClients

But there may be something else. And that leads to to point #3…

1.4. Part 3: Something Else

So, if service descriptions on the Web are really broken, what would it take to change that?

Example 36. SLIDE questionMark

What would a "unbroken" service description look like?

Example 37. SLIDE questionMark

and how would it support the three things we covered in the first part of the talk?

Example 38. SLIDE threeThings
  • I have just met you…

  • Squirrel!

  • Scale-Free Power-Law network

So, I am a fan of the notion that..

Example 39. SLIDE somethingElse

and service descrptions today are not working — at least not for the Web.

It turns out, service descriptions are providing implementation-specific details. which format to use, which protocol you must support, what data points and workflows are like and so on.

Service descriptions today are describing "The Solution."

Which would be great if everyone’s problem was the same exact size and shape as your solution. But, as we know, that’s not the case at all. Almost every use-case has some unique aspects and it is rare that even people on the same team can agree to the ‘right way’ to solve a problem. Magnify that by the millions of people on the Web who we haven’t met yet and it can be daunting to think we’re all going to love each other as Dug the Disney Dog does.

Luckily there is something else we can more readily agree to — the problem domain. In fact, as software developers and architects, we do this quite often.

We collect information, find the boundaries, and gather the details of the target problem domain. That’s what a good interface description for the Web does: models the problem domain.

And that’s what the Web does, too. It models the way nodes can be linked together and traversed over time. The Web is not a solution, it’s a problem domain where thousands of solutions can (and do) appear.

Stu Charlton alluded to this back in 2007 when he was trying to describe the how re-use works differently on the Web:

Example 43. SLIDE StuCharlton

Serendipity happens when clients are not tightly bound to a single service. When the Power Law is allowed to take over and lead to unexpected links. When clients can ‘meet’ new servers and successfully interact with them.

Example 44. SLIDE soLetsDoThis

So let’s do this…

pause

Example 45. SLIDE noFormat

No Format

Describe the domain without specifying format or protocol. Let clients and server negotiate formats and protocols.

Example 46. SLIDE negotiation
Example 47. SLIDE nodesNotHierarchy

No Hierarchies

Describe the domain as a set of nodes, not a hierarchy.

Allow each client and server to estalbish their own linking and workflow.

And finally…

Example 49. SLIDE scaleFree

Use Scale Free Network

Describe the domain as a scale-free network.

Example 50. SLIDE powerLaw

Encourage clients and servers to link however they wish.

So, let’s go back to our original list and see how we did…

Example 51. SLIDE buildWebAspects

[see previous "I love you..." slide]

  • We can use open formats and protocols to allow clients and server to negotiate these details when they meet.

  • We can get rid of resource-based hierarchies and focus on state-bound nodes servers and clients can select.

  • We can allow open linking within applications (not data, but applications) and take advantage of Scale-Free Power Laws.

And it turns out there is a project that has these as its goal. The Application-Level Profile Semantics or ALPS Project.

Example 52. SLIDE ALPS

Here’s an ALPS document that describes the WebMention pattern from IndeWebCamp;

ALPS sets out to describe ‘real world concepts’ instead of implementation solutions. In fact, an ALPS description does not include any implementation details at all.

In fact, ALPS documents contain only domain-spcific semantics (data and transitions) without any details on protoco, format, or workflow. When a server sends a response to a client, that server can ‘mark’ the response using a Link header with a "profile" link relation value. In the use-case shown here, the link header tells the client ``This server is speaking webMention now."

Example 54. SLIDE webMention

As long as the client recognizes that magic string in the link header, then the client and server have been properly introduced and can now successfully interact.

That covers the first rule.

Example 55. SLIDE I love you

same as previous slide

ALPS documents do not indicate a hierarchy of resources. Instead, ALPS documents list all the possible state transitions in this problem domain. Servers and clients are free to implement or ignore these transitions as thery wish.

And, since ALPS documents are not intended to be exclusive, servers can add other links to their responses for clients to pay attention to. In fact, this WebMention example is nice because some of the transitions and data elements appear in the client representation and others appear in the server representation.

Example 56. SLIDE WebMention in HTML

Note that the added links are not a problem here. Clients can follow them if they like whether they recognize them from some other specification or maybe the client is programmed, like Dug, to perk up whenever something ‘new’ appears in a response.

Example 57. SLIDE Squirrel!

same as previous slide

Finally, you have the idea of variants of the WebMention ALPS implementation. Not all servers and clients need to do it exactly the same but, like the Web today, the more popular and reliable implemementations will start to get the lion’s share of the links. That means the Power Law is in effect and better implementations can rise to the top organically.

And that means we can build a web of applications similar to how we are building a web of data.

Example 59. SLIDE serious web

see previous slide

So, what does it all mean?

1.5. Epilogue

Maybe ALPS can doo all the things we talked about. It’s very early in the going. The spec has not even been released as in Internet-Draft.

Example 60. SLIDE alpsSpec

and even if it becomes a draft or even an RFC, will be people use it?

It may turn out the ALPS solves a problem in which few people are interested. Or, it may turn out the other formats can do a better job of describing services in a Web-like manner. I’d love to talk about it and get your ideas and feedback.

And as a final note to get us started, here are just a few thoughts:

Example 62. SLIDE webIsGreat

"The Web is great", "Service Descriptions are not the Web", "ALPS describes problem domains for the Web"

and, with what we have before us, I think we can work toward…

Example 63. SLIDE LinkedOpenApps

"Let’s build Linked Open Apps (LOA)"

Thank you.

2. Notes

Working notes and left overs that didn’t make it into the talk.

2.1. LOA - Linked Open Applications

Similar to LOD, but instead of a focus on data, a focus on actions or use-cases.

The Web is based on links. [quote].

Not just URLs. URLs are the way we create and share links.

2.3. TimBl Talks

  • http://www.wired.co.uk/news/archive/2014-02/06/tim-berners-lee-reclaim-the-web

  • "[B]uilding new architectures for the web where it’s decentralised." - Tim Berners-Lee, 2014

  • It’s concerning to be "reliant on big companies, and one big server" - Tim Berners-Lee, 2014

  • http://www.w3.org/DesignIssues/Model.html

  • "The interfaces are defined by the data formats and protocols, and the important features to understand about the design I have ranted about in the linked articles in this series. This modularity, ability for different parts of the system, shows up when different specs are independent, such that you could change one without having to change the other." - Tim Berners-Lee, 1998

  • http://www.w3.org/DesignIssues/LinkedData.html

  • "The fourth rule, to make links elsewhere, is necessary to connect the data we have into a web, a serious, unbounded web in which one can find al kinds of things, just as on the hypertext web we have managed to build." - Tim Berners-Lee, 2006-2009

  • http://www.w3.org/Proposal.html

  • "[A] way to link and access information of various kinds as a web of nodes in which the user can browse at will." - Berners-Lee/Cailliau, 1990

  • "HyperText provides a single user-interface to many large classes of stored information…" - Berners-Lee/Cailliau, 1990 === Serendipity The Web relies upon serendipity. Not just re-use, but unexpected re-use.

  • http://www.stucharlton.com/blog/archives/000165.html

  • "Web architecture is all about serendipity." - Stu Charlton, 2007

2.5. Paper

This is the outline of the paper:

1.0 A Brief Tour
1.1 Describing Functionality
1.2 Describing Things
2.0 Shortcomings
2.1 Focused on Objects
2.2 Limited to Instances
2.3 Specifying Protocol
2.4 Constraining Media Types
3.0 A New Way Forward
3.1 Describe Affordances
3.2 Focus on Vocabulary
3.3 Media-Type Independence
4.0 ALPS
4.1 Essential Elements
4.2 Example ALPS Document
4.3 Challenges for ALPS
5.0 Conclusion