(4) Internet of Things (IoT): So Many Worlds!

(5) Why/How IoT/WoT Change the Web

• IoT makes very many things accessible and possibly actionable
  • Gartner, Inc. forecasts that 4.9 billion connected things will be in use in 2015, up 30 percent from 2014, and will reach 25 billion by 2020. [http://www.gartner.com/newsroom/id/2905717]
• WoT promises to be the connective fabric for IoT resources
  • The Internet's success was greatly accelerated by the Web
  • The Web's main value is to avoid verticals and provide an integration layer
  • Web architecture's model of resources is flexible enough to accommodate IoT
• Innovative/useful applications will increasingly include IoT things
  • Building across verticals can be done more easily with WoT
  • Creating and using patterns for WoT resources will become essential
• WoT in 8 words: WoT is a webby SOA for IoT resources.

(13) Loose Coupling

• Loose Coupling allows clean separation of concerns
  • Ability to use services without the need for shared deep models
  • Domain Driven Design (DDD) [http://www.domainlanguage.com/ddd/] tells us to cleanly and clearly separate domains
• APIs are contracts and should be as simple as possible
  • The Web's basic interaction contract is the Hypertext Transfer Protocol (HTTP)
  • Media types (a.k.a. vocabularies) are similarly important for productive interactions
• Agreement on interaction patterns is a good foundation
  • Hypertext Markup Language (HTML) [http://www.w3.org/html/] for human-facing form-based interactions
  • Atom [https://tools.ietf.org/html/rfc4287] failed (mostly) because of XML's demise, but lives on in pockets such as podcasts [http://www.apple.com/itunes/podcasts/] and OPDS [http://opds-spec.org/]
  • Activity Streams [http://www.w3.org/TR/activitystreams-core/] may become the "JSON-based Atom" of the future
  • Linked Data Platform (LDP) [http://www.w3.org/TR/ldp/] as a starting point for exposing RDF-centric collections

(22) The Case Against World Models

• Bounded Context Concept [http://martinfowler.com/bliki/BoundedContext.html] of Domain Driven Design (DDD)
  • For complex domains, a unified and consistent model is not a feasible goal
  • Instead, focus on shared concepts between domains as the service touch points
• Not every concept should (or can) be universally reusable
  • Only the service surface is something users have to understand
  • All other concepts are hidden and domain-specific (and not part of the contract)
• Information Hiding/Encapsulation is well-established in software engineering
  • It hides implementation (code) as well as non-interface information (hidden attributes)
  • Similar approaches could be taken for large-scale knowledge engineering

(23) Models and the Web

• The Web is a place for exposing interaction models
  • Allows service users to understand as much as they have to understand
• The Web is not a place for exposing implementation models
  • Violates the principles of information hiding and service simplicity

(24) The Web is Hypermedia

• Service Engineering takes the front seat on the Web
  • How are resources and services exposed and how can they be navigated?
• Use the uniform interface when appropriate (make your service visible to everybody)
  • Pushing everything into a representation makes the uniform interface less powerful
  • For example, caching [http://tools.ietf.org/html/rfc4287] works well because it is not specific to a media type
• Always think in the four main steps of generic REST applications
  1. Start with a representation of a hypermedia resource (parsing)
  2. Decide which link to follow based on application goals (navigation decision)
  3. Use representation and client state to initiate interaction (request)
  4. Retrieve representation of a hypermedia resource (response)

(26) No Silver Unicorn

(27) Dare To Think Small

(28) Web Models

• Web models should be as simple as possible
  • Web models should have well-defined extension points
  • Almost always, mustIgnore is a good choice for extension semantics
• Maybe μServices should be based on μVocabularies?
  • Make (exposed) vocabularies narrow and shallow, they are for communication agreement, and not for world description. The less there is to agree on, the easier it is to find agreement.

(29) The 3 Main Sins of Web Models

1. The Abyss of Abstraction
   • Resist the urge to create upper ontologies unless you need to
2. The Expanse of Everything that Exists
   • Resist the urge to try to predict the future
   • Instead, make sure that when the future happens, you can handle it
3. The Illusion of Order
   • Resist the urge to assume that everything is well-defined
   • Tagging may feel weird but sometimes is the way to go

(30) Models Create Value

• Metamodels are tools and shouldn't be overemphasized
  • People make money because of models, not because of representing them in XML, JSON, or RDF
  • Buying (too much) into one metamodel universe is a risk (anybody remember ASN.1?)
• Build good models and help people understand them
  • The less baggage comes with a model the easier it will be to sell
  • JSON's success is a big lesson about simplicity and ease-of-use
• Dare to be a metamodel apostate
  • There is no single true answer to the complex question of how to define a model
  • Models are tools and metamodels are tools, and not a reflection of reality

(31) WoT Service Models

(33) WoT is Happening!

• On the Web, narrow and shallow is beautiful!
• Wide and deep models are useful for implementations
• Reduce coupling by reducing the service surface
• Start from interactions, not from data models
  • The first question is: What can people do with a service?
  • The second question is: What are the resources the service exposes?

(34) Thanks! Q&A