W3C home > Mailing lists > Public > public-wot-ig@w3.org > May 2015

Re: Basic Terms and Definitions

From: 전종홍 <hollobit@etri.re.kr>
Date: Fri, 1 May 2015 03:51:10 +0000
To: "Dave Raggett <dsr@w3. org>" <dsr@w3.org>
CC: "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-ID: <93210B2B-D8AC-468A-9C78-1678DB495E0A@etri.re.kr>

2015. 5. 1., 오전 2:52, Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>> 작성:

On 30 Apr 2015, at 13:20, 전종홍 <hollobit@etri.re.kr<mailto:hollobit@etri.re.kr>> wrote:

Dear all,

I have gathered some key terminologies on wik[1]i. I’d like to propose the definitions that we need to use together as below. Please let me know how do you think about it.

Thanks for taking the initiative on this.  I think you may be making things more complicated than necessary.

Thanks for your comments.  I don’t want also complicate something. we can simplify it :)

- WoT Server
  : WoT Server is a component resident in the WoT device and is the entry point to the WoT Application and Service for all the requests coming from other component.

I am not sure about that. I would down play “WoT Device” after the questions it stirred up in Munich. The key to the web of things architecture are the web of things servers. These essentially just host “things” with the bindings to a variety of protocols. Things are proxies for physical or abstract entities, but as far as a client of the server, it really doesn’t matter.

- WoT Device
  :a WoT device is a "Thing" which enabled WoT connectivity. a “Thing” in Web of Things (WoT) can be any object that has a unique identifier and which can send/receive web resources (including information and data) over a network.

In Munich, the idea I presented was that of an IoT device that embedded a web of things server.  This is fuzzy since from an architectural point of view we don’t really care whether the sensors/actuators are directly integrated into that device, or are accessed via some kind of gateway. Perhaps we should avoid talking about WoT devices and instead talk about what is needed in the way of device abstraction for different kinds of devices, e.g. medical instruments.

I think we can categorize three types of WoT Devices by role.

Type 0 - Client. It just a WoT client. they just request WoT Resource.
Type 1 - Server. This device act WoT server. They can provide WoT Resources. If a small sensor device provide sensing data via WoT connectivity(HTTP and URI), It  can also classify as a WoT Server.
Type 2 - Gateway/Bridge. This device acts as a communication broker between a set of devices and other connected IoT components, typically by translating data traffic between different link protocols or communication methods, for example between short-range (ZigBee, Z-Wave, and so on) and long-range networks.

    WoT devices are connected any devices to the Web and provide information about themselves or about their surroundings (e.g. information sensed by the connected sensors) over a network (to other devices or servers/storage) or allow actuation upon the physical entities/environment around them remotely.

- WoT Client
  :a logical entity that accesses an WoT Resource on an WoT Server

Except for the most part the client will also be a server. Moreover, it depends upon the protocol. For example, when using HTTP, the server hosting a proxied thing would act as a client to the server hosting the proxy when it comes to sending event notifications and property updates. On the other hand, when a property on the proxy is updated, the roles of the two servers are the reversed with the server hosting the proxy acting as a client to the server hosting the proxied thing.   I think it is simpler to talk about proxies and proxied things, and the protocol bindings to support them.

- WoT Functionality
  :the base/core functionality contained in any WoT Device

- WoT Resource
  :Anything that might be identified by a URI or IRI.

[1] https://www.w3.org/WoT/IG/wiki/index.php?title=Terminology

Best Regards,

— Jonathan Jeon

   Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>

Received on Friday, 1 May 2015 03:51:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:33 UTC