Self reference and unsolicited operation for events and properties

[tuve]

I wonder if it is possible to include a self reference in a TD like in the example bellow. The use case is that the consumers are connected to a broker (the endpoint part of the uri schema) using websockets or similar transport. The id and path part are part of the envelope format of the messages published on the broker. In this td I have also added an op "unsolicited" to denote that this is an event you may receive unsolicited when connected to the broker endpoint. In this case it is an event but could also be a property value (recent versions of lwm2m has this capability to send unsolicited updates).

I would like to propose that a possible operator "unsolicited" is added to the thing description.

I also have a few question related to in this case self reference. In a more generic form this is referencing a scheme instead of specifying it, however with self referencing it must be referenced to avoid an infinite loop.

1. is the self reference valid as done bellow?
2. is it enough as done bellow to describe that the response is a thing description?
3. should/must .well-known properties be included in the thing description? To me they seems to be redundant if they are well-known.
4. if this is not valid, could it be done in another way?

In this example the uri schema will be

pubsub+payload:{brooker endpoint}:{thing id}:{path}

and an example message would be 

{
  "id":"123456",
  "op":"unsolicited"
  "path":"/event/connect",
  "payload":"{... a thing description of self ...}"
}

thing description

{
    "@context": [
        "https://www.w3.org/2019/wot/td/v1"
    ],
    "@type": [
        "Thing"
    ],
    "id": "pubsub+payload:example.com/ws:123456",
    "title": "Device",
    "securityDefinitions": {
        "no_sec": {
            "scheme": "nosec"
        }
    },
    "security": "no_sec",
    "base": "pubsub+payload:example.com/ws:123456",
    "actions": {},
    "properties": {
        ".well-known": {
            "type": "object",
            "properties": {
                "wot-thing-description": {
                    "@type": "Thing",
                    "forms": [{
                        "href": ":/.well-known/wot-thing-description",
                        "op": "readproperty"
                    }]
                }
            },
            "required": ["wot-thing-description"],
            "forms": [{
                "href": ":/.well-known",
                "op": "readproperty"
            }]
        }
    },
    "events": {
        "connect": {
            "title": "Device connect",
            "data": {
                "@type": "Thing"
            },
            "forms": [
                {
                    "op": "unsolicited",
                    "href": ":/event/connect"
                }
            ]
        }
    }
}

[egekorkan]

Regarding the TD referencing:

Below is an alternative that I had proposed at node-wot: https://github.com/eclipse/thingweb.node-wot/issues/160

Some comments on your approach:

• The TD is not an affordance of the Thing in my opinion, thus not correct to model it as a property.
• You don't have to follow the URI Syntax in your property name or data structure, i.e. no need to have a property called .well-known

It would be also good to separate the two concepts into different issues

[tuve]

Thanks for the feedback. I liked the idea with a link and rel="self instead of having it as part of the property structure.

However I still want to emit a td as an event. The use case is that we do have devices that logs running data into time boxed objects. As objects are created the property structure is modified. When ever a device is connected it will most likely be different from the last time it was connected. The structure can also be modified while connected, both creation of new objects and deleted objects (they are deleted when read to free up memory on the device). I have omitted an update event from the example since it is basically the same as a connect event but I have a use case where the td will change a lot and would be able to emit the td as part of an event.

Should I create another issue for unsolicited?

[egekorkan]

So everything regarding how TDs are communicated with other entities is not part of the work of this group but of the WoT Discovery (https://github.com/w3c/wot-discovery/). There are specific ways that are specified there to do what you want.

The unsolicited use case seems interesting and deserves an issue on its own I would say :)

[egekorkan]

@sebastiankb I am not sure why I am assigned to this.

[lu-zero]

I think this issue should part of the onboarding and advertising Use-Cases:

• the brokers are joined as part of an onboarding process
• the unsolicited updates are a generalization of the mDNS advertising we already support via Discovery