Directory - How to find things around me?

[danielpeintner]

At the moment the discovery describes its interactions with the means of a TD (see https://github.com/w3c/wot-discovery/blob/main/directory.td.json)
e.g., it offers properties for "retrieveTD", "retrieveTDs", "searchJSONPath", "searchXPath", .. and some other actions/events to interact with a directory.

In the scripting API we used to have the following DiscoveryMethod enumeration (see https://www.w3.org/TR/wot-scripting-api/#the-discoverymethod-enumeration)

• "any"
• "local"
• "directory" and
• "multicast"

and we changed it to the following list (see https://w3c.github.io/wot-scripting-api/#the-discoverymethod-enumeration)

• "direct" and
• "directory"

The more I think about these facts and changes I wonder why we actually need a WoT Discovery conformance class.

For developers there is no real need for doings so IF I can only contact a TD/Thing directly or talk to a directory . One could consume the directory TD and act upon this TD.
OR
directly connect a Thing and retrieve the TD.

What we totally miss now is the case of a runtime that can scan for example the current network and find things around me. The directory does not do that for you. How can I fulfill this use-case?

[zolkis]

Well, we have decided to not support that use case for the moment, partly for privacy reasons, partly because it needs more discussion (define what "local" means, how it could be extended/restricted, etc).

The separate conformance class just means that implementations are not required to implement it.

[relu91]

Well, we have decided to not support that use case for the moment, partly for privacy reasons, partly because it needs more discussion (define what "local" means, how it could be extended/restricted, etc).

Yes exactly and I agree that finding things around me or other discovery magic is nice to have in a script. We will see if we can have something for that shortly. However, I still think that the current APIs are critical just because you really cannot do this without them:

One could consume the directory TD and act upon this TD.
OR
directly connect a Thing and retrieve the TD.

Remember, consume is a local operation and it starts from the precondition of having a thing described. In reality, applications would use just an URL where to fetch the TD and then consume it. Basically, without the direct method developers are left on their own when they try to retrieve a remote TD. As already been argued for a while we could just use Fetch, but fetch does not work for CoAP as far as I know... and it will never work for MQTT. So I strongly advocate for something like the direct method but I can agree with the fact that right now the directory method is just a convenience function that wraps a direct+consume+read calls. Still, I would say that it provides a nice interface quite resilient to future changes. For example: what if we change the TDD thing description?

[zolkis]

As already been argued for a while we could just use Fetch, but fetch does not work for CoAP as far as I know... and it will never work for MQTT.

This is an important point that should probably end up in the spec as well (as an ednote, or note). I agree on the direct method.

About local discovery, let's see how can we mitigate the privacy concerns and how to define locality. Also, we should check how to apply differential privacy in this case and in general in WoT.

[mmccool]

Right now we don't have an official way to support discovery queries limited by geolocation. It is an important issue, shows up in many many use cases, and was in our charter, but we ran out of time to do it right (e.g. in collaboration with other relevant standards orgs) and had to defer it.

HOWEVER, I think that you can get an effect of "locality" by constraining what "introduction" mechanisms are used to perform "first contact" as part of the discovery process. If you use introduction mechanisms that are limited to the LAN (e.g. mDNS-SD) or to physical proximity (e.g. bluetooth beacons) then you will just get local results. However, introductions are intentionally open-ended and it would probably not be a good idea to list a specific fixed set in the scripting API specification. Here are some possible design choices:

1. Have some high-level categories for discovery. I would suggest "proximate" (this would cover things like bluetooth beacons), "local" (would cover methods limited to the local network) and "direct" (a special case, typically for pointing to a directory). I was going to suggest "global" but that's just a little too broad, so you'd need to constrain it by pointing at one or more search services, maybe with some search keywords... which is just "direct".
2. A specific list of introduction mechanisms. Since these can change over time, it might be necessary to have an interface that lets an application retrieve a set of supported mechanisms, then the application can choose the ones it wants to use for a particular round of discovery. Note that some introduction mechanisms are mandatory, including "direct".
3. Some hybrid of the above. You could include both categories and specific mechanisms in the list of support mechanisms. Then if an application did not care about the specifics it could just ask for a category (e.g. local), but if it specifically wanted to use mDNS-SD it could indicate that (and if an application knows this is what it wants to do, this avoids wasting time invoking a bunch of other introduction mechanisms that might also be in the "local" category).

[egekorkan]

Regarding querying a TDD and filtering based on location, this can be already done with SPARQL and probably with JSON Path too. Of course, TDs can have geolocation information in many places and using different vocabularies, making it practically annoying but it is theoretically possible