<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.26 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no"?>

<rfc ipr="trust200902" docName="draft-koster-t2trg-hypertext-language-00" category="exp">

  <front>
    <title>Model-Based Hypertext Language</title>

    <author initials="M." surname="Koster" fullname="Michael Koster">
      <organization>SmartThings</organization>
      <address>
        <postal>
          <street>1281 Lawrence Station Road</street>
          <city>Sunnyvale</city>
          <code>94089</code>
          <country>USA</country>
        </postal>
        <phone>+1-707-502-5136</phone>
        <email>michael.koster@smartthings.com</email>
      </address>
    </author>

    <date year="2016" month="February" day="20"/>

    <area>Internet</area>
    <workgroup>Thing-to-Thing Research Group</workgroup>
    <keyword>T2TRG, Web of Things, Hypermedia, Semantic Interoperability</keyword>

    <abstract>


<t>Interoperability for connected things is improving in a number of important areas, converging around Internet Protocol (IP) and internet design patterns. Hypermedia is becoming more common with web linking becoming part of a number of important standards.</t>

<t>However, there is still an interoperability gap in how application semantics are defined and used. Many organizations and industry alliances are defining vocabulary and taxonomy for application domains, independent of each other. These vocabularies are often bound to particular conceptual models, and are often semantically incompatible with each other. While it may be possible to adapt protocols and convert representations, it is difficult to develop a common application framework that works across ecosystems and domains.</t>

<t>This article proposes a method that can be reused across application domains and across ecosystems, to define a shared conceptual model and common vocabulary. A public resource is described which does for connected things what schema.org does for web commerce, to provide a community driven vocabulary and simple ontology that enables web scale interoperability between applications and connected things.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Interoperability for connected things is improving with the adoption of Internet Protocol (IP) in a number of emerging standards and ecosystems. <xref target="OCF"/>, <xref target="Thread"/> and <xref target="ZigBee"/>, <xref target="BT-SIG"/>, <xref target="LWM2M"/>, <xref target="IPSO"/>, <xref target="Weave"/>, and WiFi connected devices.</t>

<t>Consolidation is being seen in the adoption of HTTP and CoAP <xref target="RFC7252"/> by these ecosystems. Many emerging standards support some form of web linking or resource directory <xref target="OCF"/>, <xref target="LWM2M"/>, <xref target="RFC6690"/>, <xref target="I-D.ietf-core-resource-directory"/>). Use of <xref target="REST"/> is becoming common, particularly for web integration and more recently at the device API and local network level <xref target="OCF"/>, <xref target="LWM2M"/>. There is ongoing work in providing hypermedia support <xref target="I-D.ietf-core-interfaces"/>, <xref target="OCF"/>, <xref target="W3C-WoT"/>, <xref target="T2TRG"/>. Hypertext based systems can use link attributes to incorporate application semantics.</t>

<t>For application semantics, many organizations and alliances are creating new vocabularies bound to their own models. This can result in application incompatibility, for example an identifier like temperature may appear to be well known but is semantically incompatible across ecosystems and application domains.</t>

</section>
<section anchor="conceptual-models-and-domain-specific-language" title="Conceptual Models and Domain Specific Language">

<t>The proposed approach to semantic interoperability is to develop a common semantic structure and language upon which to develop domain specific vocabularies that can be used for semantic annotation of resources and services.</t>

<t>For the purpose of this discussion, a language is assumed to consist of a vocabulary which is bound to a conceptual model. Such a conceptual model constrains and defines the grammar and semantics of the language.</t>

<t>Conceptual models are layered, with core concepts forming a basis on which to build more sophisticated models. In the case of human language, we are used to a set of conceptual fragments like nouns, verbs, adjectives, and so on to express thoughts and feelings when we interact with one another.</t>

<t>For interacting with connected things, there is a conceptual model in common use that is proposed by <xref target="W3C-WoT"/>.  Using this model a connected Thing is defined by and interacted with through its Events, Actions, and Properties. Events can be considered to be state changes within the thing we may be interested in. Actions can be invoked when we want the thing to change its state or the state of its environment, like turn on a light. Properties are like the current state of a thing or its static attributes.</t>

<t>Events, Actions, and Properties can form the basis of a simple, consistent conceptual framework upon which to build a general interaction language for things. We can ask a thing about it’s properties, we can observe events that change the state of the thing or indicate changes in its environment, and we can ask it to perform actions for us to change its state or its environment.</t>

<t>Semantic interoperability may be achieved through common definitions of cross domain meta models and domain specific models, and shared vocabulary to describe the events, actions, and properties of connected things. For example, in the connected lighting domain, we may model a luminary as a thing that has various optional capabilities, like brightness control, color control, on/off control, and measurement of energy consumed. A common set of events, actions, and properties can be defined for all connected lights that have particular capabilities. By doing so, we enable control of any light using a common set of application level controls and affordances.</t>

</section>
<section anchor="reference-architecture" title="Reference Architecture">

<t>Figure 1 shows an example system architecture for broad interoperability at web scale.</t>

<figure title="Reference Architecture" align="left" anchor="fig-arch"><artwork><![CDATA[
                                           +--------------+
          +------------------------------->| Applications |
          |                                +--------------+
          |                                |   Protocols  |
          |                                +--------------+
          |                                |   Hypertext  |
    +-----------+     +--------------+     +--------------+
    |  Schemas  |---->| Domain Model |---->|    Things    |
    +-----------+     +--------------+     +--------------+

]]></artwork></figure>

<t>Schemas are publicly available domain specific meta-models, built through community consensus by domain experts and industry users. A working example of this today is <xref target="schemaorg"/>, which is a public vocabulary and ontology for interoperable web commerce. Applications use schemas to develop machine comprehensions of the hypertext controls and affordances exposed by connected things.</t>

<t>Domain Models are built from schemas by manufacturers or data suppliers. Domain Models represent instances or specific types of products or information assets. A Domain Model would generally be used to construct a virtual thing or an interface to a thing.</t>

<t>Hypertext is exposed or referenced by things, and is used to bind vocabulary terms from the schema to instances of the Domain Model. Hypertext is made available in-band through the application protocol, for example CoAP or HTTP.</t>

<t>Protocols represent common network capability, for example <xref target="Thread"/>, WiFi, Internet, and underlying protocols TCP/IP, UDP, and common application protocols CoAP, HTTP, as well as ecosystem protocol layers like <xref target="OCF"/> and <xref target="LWM2M"/>.</t>

<t>Applications are the external logic and programs used to remotely control and orchestrate the activities of connected things. Domain specific vocabulary is exposed directly to applications through hypertext exposed through the application protocol.</t>

<t>Application level interoperability is achieved by applications understanding the semantics of the common underlying conceptual model and interpreting the vocabulary that describes domain specific instances of that conceptual model. In the context of common application semantics, network and application protocols are relatively easy to adapt between ecosystems.</t>

<t>A reference implementation of the above architecture is described at <xref target="HypermediaDemonstrator"/>.</t>

</section>
<section anchor="terminology" title="Terminology">

<t><list style="hanging">
  <t hangText='Ecosystem'><vspace blankLines='0'/>
  Referring to a standard or platform supported by a corporate entity or an industry alliance or consortium.</t>
  <t hangText='Semantic Interoperability'><vspace blankLines='0'/>
  The ability for data sources and applications to exchange state information in a meaningful way without prior detailed knowledge.</t>
  <t hangText='Hypertext, Hypermedia'><vspace blankLines='0'/>
  Meta-data that identifies the location and attributes of resources.</t>
  <t hangText='Conceptual Model'><vspace blankLines='0'/>
  A High level model that defines a set of semantic characteristics.</t>
  <t hangText='Schema:'><vspace blankLines='0'/>
  A meta-model that defines how models are structured and annnotated.</t>
  <t hangText='Domain Model'><vspace blankLines='0'/>
  A model of a product or type that defines the expected configuration of a specific instance or type.</t>
  <t hangText='Application Domain'><vspace blankLines='0'/>
  A group of applications that share common attributes and characteristics, for example connected automobiles.</t>
</list></t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor='RFC6690' target='http://www.rfc-editor.org/info/rfc6690'>
<front>
<title>Constrained RESTful Environments (CoRE) Link Format</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<date year='2012' month='August' />
<abstract><t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links.  Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type.  &quot;RESTful&quot; refers to the Representational State Transfer (REST) architecture.  A well-known URI is defined as a default entry point for requesting the links hosted by a server.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6690'/>
<seriesInfo name='DOI' value='10.17487/RFC6690'/>
</reference>



<reference anchor='I-D.ietf-core-links-json'>
<front>
<title>Representing CoRE Formats in JSON and CBOR</title>

<author initials='K' surname='Li' fullname='Kepeng Li'>
    <organization />
</author>

<author initials='A' surname='Rahman' fullname='Akbar Rahman'>
    <organization />
</author>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<date month='November' day='1' year='2015' />

<abstract><t>JavaScript Object Notation, JSON (RFC7159) is a text-based data format which is popular for Web based data exchange.  Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT).  For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats.  Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link.  In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690).  Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR.  This specification defines a common format for this.  Group Communication for the Constrained Application Protocol (RFC7390) defines a number of JSON formats for controlling communication between groups of nodes employing the Constrained Application Protocol (CoAP).  In a similar vein, this specification defines CBOR variants of these formats.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-links-json-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-links-json-04.txt' />
</reference>



<reference  anchor='RFC3986' target='http://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>



<reference  anchor='RFC5988' target='http://www.rfc-editor.org/info/rfc5988'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2010' month='October' />
<abstract><t>This document specifies relation types for Web links, and defines a registry for them.  It also defines the use of such links in HTTP headers with the Link header field.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5988'/>
<seriesInfo name='DOI' value='10.17487/RFC5988'/>
</reference>



<reference  anchor='RFC7252' target='http://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>



<reference anchor='I-D.ietf-core-interfaces'>
<front>
<title>Reusable Interface Definitions for Constrained RESTful Environments</title>

<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
    <organization />
</author>

<author initials='M' surname='Vial' fullname='Matthieu Vial'>
    <organization />
</author>

<author initials='M' surname='Koster' fullname='Michael Koster'>
    <organization />
</author>

<date month='October' day='19' year='2015' />

<abstract><t>This document defines a set of reusable REST resource design patterns suitable for use in constrained environments, based on IETF CoRE standards for information representation and information exchange.  Interface types for Sensors, Actuators, Parameters, and resource Collections are defined using the "if" link attribute defined by CoRE Link Format [RFC6690].  Clients may use the "if" attribute to determine how to consume resources.  Dynamic linking of state updates between resources, either on an endpoint or between endpoints, is defined with the concept of Link Bindings.  We also define conditional observation attributes that work with Link Bindings or with simple CoAP Observe [RFC7641].</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-interfaces-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-interfaces-04.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-interfaces-04.pdf' />
</reference>



<reference anchor='I-D.ietf-core-resource-directory'>
<front>
<title>CoRE Resource Directory</title>

<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
    <organization />
</author>

<author initials='M' surname='Koster' fullname='Michael Koster'>
    <organization />
</author>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<author initials='P' surname='Stok' fullname='Peter Van der Stok'>
    <organization />
</author>

<date month='October' day='19' year='2015' />

<abstract><t>In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources.  This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resources descriptions.  Furthermore, new link attributes useful in conjunction with an RD are defined.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-resource-directory-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-05.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-05.pdf' />
</reference>


<reference anchor="REST" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf">
  <front>
    <title>Architectural Styles and the Design of Network-based Software Architectures</title>
    <author initials="R." surname="Fielding" fullname="Roy Thomas Fielding">
      <organization>University of California, Irvine</organization>
    </author>
    <date year="2000"/>
  </front>
  <seriesInfo name="Ph.D." value="Dissertation, University of California, Irvine"/>
  <format type="PDF" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf"/>
</reference>
<reference anchor="HypermediaDemonstrator" target="https://github.com/connectIOT/HypermediaDemo">
  <front>
    <title>Demonstration of a HATEOAS based system architecture for the Web of Things</title>
    <author initials="M." surname="Koster">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="W3C-WoT" target="https://www.w3.org/WoT/IG/">
  <front>
    <title>W3C Web of Things Interest Group</title>
    <author initials="." surname="WoT IG">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="T2TRG" target="https://datatracker.ietf.org/rg/t2trg/charter/">
  <front>
    <title>IRTF Thing to Thing Research Group</title>
    <author initials="." surname="IRTF">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="OCF" target="http://openconnectivity.org/">
  <front>
    <title>Open Connectivity Foundation</title>
    <author initials="." surname="OCF">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="Thread" target="http://www.threadgroup.org/">
  <front>
    <title>Thread Group</title>
    <author initials="." surname="Thread Group">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="ZigBee" target="http://www.zigbee.org/download/standards-zigbee-cluster-library/">
  <front>
    <title>ZigBee Cluster Library</title>
    <author initials="." surname="ZigBee Alliance">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="BT-SIG" target="https://www.bluetooth.com/">
  <front>
    <title>Bluetooth SIG</title>
    <author initials="." surname="BT SIG">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="LWM2M" target="http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0">
  <front>
    <title>OMA LWM2M</title>
    <author initials="." surname="OMA">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="IPSO" target="http://www.ipso-alliance.org/ipso-community/resources/smart-objects-interoperability/">
  <front>
    <title>IPSO Smart Object Guidelines</title>
    <author initials="." surname="IPSO Alliance">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="Weave" target="https://developer.nest.com/documentation/weave/weave-overview/">
  <front>
    <title>Nest Weave Overview</title>
    <author initials="." surname="Nest">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="schemaorg" target="http://schema.org">
  <front>
    <title>Schema.org</title>
    <author initials="Schema." surname="org">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>


    </references>




  </back>
</rfc>

