Subject: [Iotsi] New IoT effort at schema.org

From: Ted Hardie <[email-masked]>
Date: Mon, 22 Aug 2016 12:22:50 -0700

Howdy,

As you may remember from the IOTSI workshop, there was some discussion
about setting up a "Rosetta stone" site for schemas and ontologies related
to IoT devices and systems.  Some of the folks in that conversation have
had some further discussion about the prospect with the folks at schema.org,
which does a similar thing for web-based schemas.   That resulted in
schema.org folks volunteering to set up an "iot.schema.org", which is meant
to help both "things" and services interoperate on a semantic level, as a
common look-up site for types, properties, and enumerated values for
structured data found in IoT.

*There is a short paper outlining the initial work here
<https://docs.google.com/document/d/1mE2hN83lXzqXA-RQYMURJxIlEktcZkFB252BQCCnkKk/edit?pref=2&pli=1#>
and a mailing list <https://groups.google.com/forum/#!forum/sdo-iot-sync>. *
*If you are interested, *please do join the mailing list.  (Since some of
the folks were not part of IOTSI or other IAB efforts, it might be good
when you do to introduce yourself)
*.*
regards,

Ted

---

From: David Janes <[email-masked]>
Date: Mon, 22 Aug 2016 16:19:55 -0400

Hi Ted, everyone,

Great idea.

I'd just like to strong suggest that IOTDB would get mentioned, which is
built exactly upon the concepts being mentioning - i.e. core indivisible
concepts "atoms" related to IoT (such as turning things on and off, setting
the temperature, changing the color, "am I measuring", "am I sensing",
etc), and building on top of schema.org

Here's the position paper submitted to the IAB

https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-02-IOTDB-
Interoperability-Through-Semantic-Metastandards.pdf

And here's the vocabularies

https://iotdb.org/pub/iot-purpose.html
https://iotdb.org/pub/iot-purpose.jsonld
https://github.com/dpjanes/iotdb-vocabulary/tree/master/
src/iot-purpose/Purpose

Regards, etc....
David

On Mon, Aug 22, 2016 at 3:22 PM, Ted Hardie <[email-masked]> wrote:

> had some further discussion about the prospect with the folks at
> schema.org, which does a similar thing for web-based schemas.   That
> resulted in schema.org folks volunteering to set up an "iot.schema.org",
> which is meant to help both "things" and services interoperate on a
> semantic level, as a common look-up site for types, properties, and
> enumerated values for structured data found in IoT.
>
>
>
>
> _______________________________________________
> Iotsi mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/iotsi
>
>

---

From: Tim Coote <[email-masked]>
Date: Tue, 23 Aug 2016 09:58:26 +0100

Hullo

Based on practical experience, one of the biggest challenges is to have a view of the overall system state. This is partly covered in the concepts of interim (interstitial?) states in this paper, but bugs and potential bugs in composed components need to be accounted for (I think). This degree of uncertainty can be modelled, but probably not in the hardware scope of Things themselves as they tend to be under-powered.*

However, there is a significant issue that the deployed Things do not necessarily tell (or know) the truth about what they are or their current state.

*Is there a taxonomy for the different types of ‘Thing’: I’ve previously distinguished between the real-world, the sensors/actuators that interact with the real world, the software representations of the sensors/actuators and compositions of such software representations (which must still support minimal behaviours such as re-initialise).

tc 
> On 22 Aug 2016, at 21:19, David Janes <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Ted, everyone,
> 
> Great idea.
> 
> I'd just like to strong suggest that IOTDB would get mentioned, which is built exactly upon the concepts being mentioning - i.e. core indivisible concepts "atoms" related to IoT (such as turning things on and off, setting the temperature, changing the color, "am I measuring", "am I sensing", etc), and building on top of schema.org <http://schema.org/>
> 
> https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-02-IOTDB-Interoperability-Through-Semantic-Metastandards.pdf <https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-02-IOTDB-Interoperability-Through-Semantic-Metastandards.pdf>
> 
> https://iotdb.org/pub/iot-purpose.html <https://iotdb.org/pub/iot-purpose.html>
> https://iotdb.org/pub/iot-purpose.jsonld <https://iotdb.org/pub/iot-purpose.jsonld>
> https://github.com/dpjanes/iotdb-vocabulary/tree/master/src/iot-purpose/Purpose <https://github.com/dpjanes/iotdb-vocabulary/tree/master/src/iot-purpose/Purpose>
> 
> Regards, etc....
> David
> 
> On Mon, Aug 22, 2016 at 3:22 PM, Ted Hardie <[email-masked] <mailto:[email-masked]>> wrote:
> Howdy,
> 
> As you may remember from the IOTSI workshop, there was some discussion about setting up a "Rosetta stone" site for schemas and ontologies related to IoT devices and systems.  Some of the folks in that conversation have had some further discussion about the prospect with the folks at schema.org <http://schema.org/>, which does a similar thing for web-based schemas.   That resulted in schema.org <http://schema.org/> folks volunteering to set up an "iot.schema.org <http://iot.schema.org/>", which is meant to help both "things" and services interoperate on a semantic level, as a common look-up site for types, properties, and enumerated values for structured data found in IoT.
> 
> There is a short paper outlining the initial work here <https://docs.google.com/document/d/1mE2hN83lXzqXA-RQYMURJxIlEktcZkFB252BQCCnkKk/edit?pref=2&pli=1#> and a mailing list <https://groups.google.com/forum/#!forum/sdo-iot-sync>.  
> 
> If you are interested, please do join the mailing list.  (Since some of the folks were not part of IOTSI or other IAB efforts, it might be good when you do to introduce yourself).
> 
> regards,
> 
> Ted
> 
> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/iotsi <https://www.iab.org/mailman/listinfo/iotsi>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/iotsi <https://www.iab.org/mailman/listinfo/iotsi>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Aug 2016 12:52:44 +0200

Hi Tim,

On 8/23/16 10:58 AM, Tim Coote wrote:
> Hullo
>
> Based on practical experience, one of the biggest challenges is to
> have a view of the overall system state. This is partly covered in the
> concepts of interim (interstitial?) states in this paper, but bugs and
> potential bugs in composed components need to be accounted for (I
> think). This degree of uncertainty can be modelled, but probably not
> in the hardware scope of Things themselves as they tend to be
> under-powered.*
>
> However, there is a significant issue that the deployed Things do not
> necessarily tell (or know) the truth about what they are or their
> current state.

This is the exact use case we have focused on in our work.  The approach
we take to address that is MUD+802.1AR so that assertions are made by
the manufacturer of the Thing and not the Thing itself.  I'll have more
to say about the latter later.

Eliot

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Aug 2016 10:56:50 +0000

Eliot, Tim,

I believe you are talking about two different types of states.

The information you are talking about, Eliot, is rather static and does not change whereas my reading of the email Tim sent was more about information that sensor and actuators exhibit.

Is my understanding correct? Tim, maybe you can elaborate a bit more about the ' overall system state' you are referring to.

Ciao
Hannes

-----Original Message-----
From: Iotsi [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: 23 August 2016 12:53
To: Tim Coote; David Janes
Cc: [email-masked]; Ted Hardie; Internet Architecture Board
Subject: Re: [Iotsi] New IoT effort at schema.org

Hi Tim,

> necessarily tell (or know) the truth about what they are or their

This is the exact use case we have focused on in our work.  The approach we take to address that is MUD+802.1AR so that assertions are made by the manufacturer of the Thing and not the Thing itself.  I'll have more to say about the latter later.

Eliot

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Aug 2016 13:06:46 +0200

Hi Hannes,

> necessarily tell (or know) the truth about what they are or their

It's the "who they are" part below that I'm working on now.  That's what
MUD+802.1AR gives you.  In that case, as I wrote, the assertion is from
the manufacturer of the Thing, and not the Thing itself.  As to the
device's operational state, that gets us into other areas that is not
unique to Things, and leads us toward the age old question: “how do you
know whether a device is sane or has been hacked?”  And there are ways
to address that, imperfect though they may be.

Eliot

---

From: Tim Coote <[email-masked]>
Date: Tue, 23 Aug 2016 12:26:37 +0100

Hullo

I’ll write up a simple example later today to illustrate the sorts of issues that I’m trying to describe.
> On 23 Aug 2016, at 12:06, Eliot Lear <[email-masked]> wrote:
> 
> Hi Hannes,
> 
> 
There’s a commercial asymmetry here, which means that Thing Makers may not know what they have released (their focus is on shifting boxes) and any assertion, unless backed up by a legal contract is worth little. Whoever is dropping in hardware based Things may put in a new version or a replacement from a different supplier that claims to be the same as something else. But isn’t. 

My conclusion was that the owner of the service delivered to the customer must define automated tests and behaviour categorisations that are used to accept new components and to identify rogues in production. Testing Hardware Things should have the same sorts of dependency injection as is common in s/w test approaches. Any uncertainty of what’s in the overall configuration needs to be flagged to relevant users as soon as it is identified.

Although ‘is a device sane’ is an old problem, IoT types of systems have many more degrees of freedom than traditional areas where this question has arisen and the markets are being addressed by firms with varying engineering capabilities. I have seen Things where a firmware bump was a/ not identifed by the Thing and b/ caused a failure on Thursday’s with specific configuration combinations.

tc

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Aug 2016 13:32:35 +0200

Going down...

> There’s a commercial asymmetry here, which means that Thing Makers may not know what they have released (their focus is on shifting boxes) and any assertion, unless backed up by a legal contract is…

I think what you are saying is that there are white label products out
there.  It is true that one might simply not ask the question.  I don't
find that particularly satisfying, and I know my enterprise friends are
even less enthralled.  They need a way to identify what is accessing
their networks.

>
> My conclusion was that the owner of the service delivered to the customer must define automated tests and behaviour categorisations that are used to accept new components and to identify rogues in production.

Sure.  That amounts to NEA, perhaps with a protocol tweak here or
there.  But the challenge is getting Things to divulge ANY information
in a way that doesn't actually place them on shodan.io.

Eliot

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Aug 2016 12:03:09 +0000

Eliot,

I would like to hear your view on why NEA has been a failure.

Ciao
Hannes

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
Sent: 23 August 2016 13:33
To: Tim Coote
Cc: Hannes Tschofenig; David Janes; [email-masked]; Ted Hardie; Internet Architecture Board
Subject: Re: [Iotsi] New IoT effort at schema.org

Going down...

> There’s a commercial asymmetry here, which means that Thing Makers may not know what they have released (their focus is on shifting boxes) and any assertion, unless backed up by a legal contract is…

I think what you are saying is that there are white label products out there.  It is true that one might simply not ask the question.  I don't find that particularly satisfying, and I know my enterprise friends are even less enthralled.  They need a way to identify what is accessing their networks.

> My conclusion was that the owner of the service delivered to the customer must define automated tests and behaviour categorisations that are used to accept new components and to identify rogues in…

Sure.  That amounts to NEA, perhaps with a protocol tweak here or there.  But the challenge is getting Things to divulge ANY information in a way that doesn't actually place them on shodan.io.

Eliot

---

From: Tim Coote <[email-masked]>
Date: Tue, 23 Aug 2016 13:51:44 +0100

> even less enthralled.  They need a way to identify what is accessing
Not just white label products. Most consumer oriented IoT like systems only focus on the happy-path. As there’s no integration and the owners are early adopters, that’s fine.  Industrial Thing Makers tend to be domain experts in the industry, and have very immature s/w engineering awareness. The question needs to be asked. There may be an answer. For some usecases, it will be possible to trust the answer.
> in a way that doesn't actually place them on shodan.io.
Never seen shodan before. Seems to confuse Address, Name and Identity.  NEA sounds like a good idea to me. But I’ve not read it (yet). Thanks for introducing that, too.

---

From: Tim Coote <[email-masked]>
Date: Tue, 30 Aug 2016 13:23:28 +0100

> On 23 Aug 2016, at 12:26, Tim Coote <[email-masked]> wrote:
> 
> Hullo
> 

Sorry, "Planning Fallacy".

My intention here is to highlight that key aspects of devices do not relate to the obvious AD and DA conversions to and from the real world.  Encoding the simple measurements and controls that a sensor/actuator handles may, IMO, give the impression of a more complete solution than such encoding can handle. The easy answer may just be to note the gap.

Let’s take something to control the environment of the home to keep it comfortable without wasting energy. For simplicity, I’ll just describe one dimension: keeping it warm enough, and ignoring location prediction, etc. Such a system has sensors (thermometers t[1-n]), which may be located in fixed places or be moved around. Let’s call this system Homes.

Some of the h/w thermometers may be composed into what I’d call Synthetic Things (st[1-m]) which measure the temperatures of the living spaces using some integration of the individual hardware components. (e.g. harmonic mean of the reported temperatures within each room).

There will also be at least one actuator to turn on the heating (a[1-n]).

If the designer’s smart, the UI to the state of the system will be maintained in one place and made rendered on a phone or similar. Part of the UI is also the living environment (are the radiators on? Does it feel comfortable, etc). More typically, the UI also extends into wall based thermostats with embedded systems. Such a model often confuses end-users as it tends to give inconsistent information depending on the channel. The attractiveness of this anti-pattern is that the devices can be easily sourced and will work stand-alone.

The digital interface to all actuators and sensors is a low power, high latency, meshed network with 6LoWPAN mapping (PHY1). [this assumes that the application level aspects of most such networks are ignored in favour of enabling device interoperability]

A typical system like this would have one application for controlling the temperature, configured and used by, say, a million homes, with 1.5M users. Configuration would include providing the metadata on device disposition and a model of the home.  The typical commercial model has no direct relationship between makers of t[1-n] and the application that controls the home.

The types of issue that I’m concerned about include:
- standardised approaches to associating t1 - tn with the network, so that the system and the user have the same view as to which is which
- when t2 gets a firmware update, the change to this Configuration Item [in the ITIL sense] is not reported by t2. However, the behaviour of t2 does change.
- when the user introduces tn+1 using an off-the-shelf product from the hardware store, it declares that it’s the same as some recognised thermometer. But it isn’t and behaves oddly.
- introducing tn+1 changes the behaviour of PHY1.
- st1 has to understand how current the values reported to it are and to spot gaps so that it can raise alarms if one of the t’s that it is taking input from has disappeared. Such reports and timeliness need to be consistent across all components that are listening to each t (or st).
- changes in the house change the timings of PHY1, so the expected behaviours of PHY1 need to be codified.
- the vast variation of numbers and timing variations of devices need to be handled consistently and tested for by the application, and the application must have some awareness of to what extent each in-home configuration has been tested.
- calibration variation between physical thermometers, including how they are positioned for measuring a temperature.

hth

Tim

---

From: Eliot Lear <[email-masked]>
Date: Thu, 1 Sep 2016 08:32:45 +0200

Hi Tim,

I'm responding to both this and your other message.

> There’s a commercial asymmetry here, which means that Thing Makers may not know what they have released (their focus is on shifting boxes) and any assertion, unless backed up by a legal contract is…

You are raising two issues:

  * One is the old “I'm a Vendor X inkjet cartridge” problem.  As we
    have seen in the market, Vendor X has an incentive to prevent
    counterfeiting.  IEEE 802.1AR provides the standards basis to
    address that very problem.
  * The second issue is the old “I am a VT100” trick, which is also the
    less old “I am browser X” trick, done not so much to counterfeit,
    but to indicate compatibility and interoperability.

These two are related.  In a business sense, a vendor has an incentive
to see that only published interfaces are used, so that they can make
changes to private interfaces.  From a vendor perspective typically they
will publish interfaces for the components they don't want to build,
themselves.  That includes integration with other control systems.  In
the example you gave in the other message of a heating control system,
that might be the temperature sensor if the margins are sufficiently
low, but playing against that are service assurance concerns.  Systems
integrators can step into that market if it is what the vendor
wishes/needs.  At that point it will be the SIs who do the testing. 
That's their value add.  For less critical systems there are
certification systems such as the WiFi Alliance (as an example) and
CableLabs.  We will see IoT versions of those, I'm sure, for the
consumer space, but they may be granular.  The one that has bedeviled
consumers has been the entertainment system remote control.  Various
HDMI standards provide for *some* integration, but who among us has but
one remote control?

> My conclusion was that the owner of the service delivered to the customer must define automated tests and behaviour categorisations that are used to accept new components and to identify rogues in…

If the SIs from above want to do that testing, then a mechanism like NEA
may be helpful, and it may even be desirable from a vendor perspective
if they want to open interfaces and address service assurance.  But I
think it has to be combined with 802.1AR or something similar.  That
provides for some accountability as well as some limits: if it's
counterfeit the vendor can wash his hands of the matter or better yet
make a sale.

> Although ‘is a device sane’ is an old problem, IoT types of systems have many more degrees of freedom than traditional areas where this question has arisen and the markets are being addressed by fi…

Yes, and I would say that the market is highly immature.  A good thing. 
It means there's lots of room for growth and development of approaches.

Eliot