Links to devices managed by a device (e.g. a gateway)

[benfrancis]

As suggested in WebThingsIO/gateway#947 we could create a web thing type for Web of Things gateways which includes in its Thing Description links to the things it manages. The gateway web thing type can have actions (such as putting it in pairing mode) and events (such as thingAdded and thingRemoved).

What should this web thing type be called? Is it always a "gateway" (bridging one type of network to another) or is "directory" a better term? (sometimes it may just be a directory of native web things).

Another thing I'm not sure about is whether it's better to have an explicit top level things member in the Thing Description, or to add link(s) to the links section with either a single link to a Things Resource or multiple links to individual Thing resources. I suspect using the links member may be easier to get through standardisation than adding a special new things member, although we may need to invent another new link relation type for that purpose, e.g.:

{
  "links": [
    {
      "rel": "things",
      "href": "/things"
    }
  ]
}

Creating a things link relation would be an obvious addition to the proposed properties, actions and events link relations, although to be honest none of these are great link relation names.

If each managed thing was provided as a separate link, the existing item link relation from RFC 6573 could be used for this purpose, e.g.:

{
  "links": [
    {
      "rel": "item",
      "href": "/things/thing1"
    },
    {
      "rel": "item",
      "href": "/things/thing2"
    }
  ]
}

Alternatively, the CoRE (Constrained RESTful Environments) specification (RFC 6690, used by CoAP) specifies a hosts link relation type for this purpose, e.g.:

{
  "links": [
    {
      "rel": "hosts",
      "href": "/things/thing1"
    },
    {
      "rel": "hosts",
      "href": "/things/thing2"
    }
  ]
}

This might be something to discuss at the W3C. There's already an example of a controlledBy link relation in the Thing Description specification.

[YonasJ]

I need to address this for my current project. My requirements are:

1. send a message to the gateway to trigger a reboot.
2. send an over-the-air firmware.
3. get some log messages from the gateway
4. have the capability to show which devices are connected to a specific gateway.
5. detect when a thing is added to the gateway (dynamically).

Since the host portion of the URL implies the gateway, I was thinking of creating a Thing for the gateway device, and then assume that any things on the same host were from that gateway. And then I was going to use the API's in the usual way to interact with the gateway.

But it may be more orthogonal to have a "gateway" object at the root, that has a list of things, which in turn have lists of properties/actions/events. But right now the API is not chatty and nice and simple.

[benfrancis]

Example from gateway schema being discussed in WebThingsIO/schemas#35

  "links": [
    {
      "rel": "item",
      "href": "/things/thing1"
    },
    {
      "rel": "item",
      "href": "/things/thing2"
    }
  ]

Questions:

1. Is there an existing registered link relation type which could be used for these links? e.g.

• hosts
• item

2. If not, what name should we use for these link relations?

• manages
• parentOf
• gatewayFor

[mrstegeman]

Hmmmm... hosts kind of makes sense, especially given its intent, but it seems wrong to hijack a term and not use the rest of the spec. For item, it seems like you're also supposed to use a collection link in each child to point back to the parent.

If you want to stick with the current naming scheme (even though it's not quite right), you could use thing. If not, maybe something like child. Then, each thing could potentially have a gateway or parent link.

Generally speaking, the names don't tend to be verbs, so manages doesn't seem to fit. The names also seem to describe the document that is being linked, rather than the current document, so that cuts out parentOf.

[benfrancis]

@mrstegeman wrote:

Hmmmm... hosts kind of makes sense, especially given its intent, but it seems wrong to hijack a term and not use the rest of the spec.

It's very interesting that hosts comes from the CoRE specification because Michael McCool from Intel today suggested that the Web of Things discovery/directory mechanism defined in the next charter period could be based on CoRE Resource Directories. So maybe we could use the rest of the spec in some way...

[benfrancis]

Oh I see, RFC 6690 defines its own file format and a /.well-known URL. We probably don't want to use that. But maybe we can just steal the hosts link relation :)

[mrstegeman]

I'm actually not opposed to using a /.well-known/thing-description (or similar) redirect. Those are actually really helpful for other services, e.g. CalDAV.