Re: [T2TRG] Fwd: New Version Notification for draft-robles-t2trg-functionalitydescription-00.txt

[Alessandro Bassi <[e-mail]>]

Hi Ines,

thank you for your reply! please find my comments in line.

On 29. 03. 19 17:44, Ines Robles wrote:
> Hi Alex,
>
> Thank you very much for your feedback, please find the answer in-line 
>
>
> On Thu, Mar 28, 2019 at 9:02 PM <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>     Hi,
>
>     I've read this draft and I have one comment/question.
>
>     Indeed, I believe that a terminology section is very important.
>
>     <quote>
>
>     An IoT device can be considered to be semantically composed as a
>     set of objects, with each object being a set of resources. The
>     resource is an atomic piece of device information that can be
>     managed. This document presents three level of functionalities as
>     shown in Figure 1: Device Functionality, Object Functionality,
>     Resource Functionality, that together delineate the complete
>     functionality of the device. (TODO provides specific definition
>     for each one)
>
>     </quote>
>
>
>     I assume that "IoT device" and "device" in this context means the
>     same.
>
>     In this context, my definition of device is an artifact that
>     mediates between the physical and the digital world; typically, a
>     device is a sensor or an actuator.
>
>
> <ines>
>
>  
>
> we understand that a device can be also a set of sensors and
> actuators. A device can be physical or virtual.
>
> Constrained devices are classified in different classes. [1]
>
>  
>
> [1] https://tools.ietf.org/html/draft-bormann-lwig-7228bis-04#section-3
>
>  
>
> </ines>
>
>  

<alex>

I believe this is very similar, the only difference being the device
being atomic or a set of atomic devices. 

I know about RFC 7228 - I think though that here we are dealing with a
higher abstraction level, and we should not focus on specific
technologies but on semantics.

</alex>

>     My definition of Resource is a software component that provides
>     data from or is used in the actuation of a physical entity.
>
>     Resources can be on-device or not (in the second case, let's call
>     them Network Resources).
>
>     Technically, a Device hosts an on-device resource, which is
>     associated to a virtual entity that is the "digital twin" (or
>     representation) of a physical entity related to the device.
>
>
>  
>
> <ines>
>
> we are aligned with these definitions of resource :
>
>  
>
>  *
>
>     “ Any information that can be named can be a resource: a document
>     or image, a temporal service (e.g. “today’s weather in Los
>     Angeles”), a collection of other resources, a non-virtual object
>     (e.g. a person), and so on. In other words, any concept that might
>     be the target of an author’s hypertext reference must fit within
>     the definition of a resource.” [2]
>
>  *
>
>     “Any component, function, enabler, or application that can send,
>     receive, or process requests” [3]
>
>  *
>
>     “the term "resource" is used in a general sense for whatever might
>     be identified by a URI” [4]
>
>  
>
>  
>
> [2] Fielding, R., "Architectural Styles and the Design of
> Network-based Software Architectures", Ph.D. Dissertation, University
> of California, Irvine, 2000,
> <http://www.ics.uci.edu/~fielding/pubs/dissertation/
> fielding_dissertation.pdf>. [ Section 5.2.1.1 ]
>
>  
>
> [3] Dictionary for OMA Specifications
> http://openmobilealliance.org/documents/dictionary/OMA-ORG-Dictionary-V2_9-20120626-A.pdf
>
>  
>
> [4] RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
>
>  
>
> </ines>
>
>  

<alex>

These definitions are quite different, I believe. The first one is
extremely wide, and I have a hard time thinking of something that is NOT
a resource. I don't think it would be a good fit for the work here as if
we can put in the same basket a person and the weather in Prague, it
would be hard to find meaningful semantic associations.

I find the second one similar to the one I wrote, with the sole
exception that maybe the OMA were focusing more on the digital side,
while on IoT the relation with physical entities should be present.

Regarding the URI definition, again I think it's a bit out of context here.

</alex>

>     For a practical example, a Physical Entity is a cow. A Device is a
>     cow's collar with a GPS sensor. A Resource is a positioning
>     software for the collar. (A Service, in this case, would be a
>     system that sends a signal to a cow if she is standing too long in
>     front of the food or water, so she would move away and the other
>     cows can eat or drink as well). BTW, from a Service point of view,
>     it is quite irrelevant if the Resource is on-device or in the
>     Network: what it needs to know is the position of the cow.  
>
>     Given the above, I have no clue what an object is in the quoted text.
>
> <ines>
>
> We understand, that  “ Resources are logically organized into Objects”
> ([5]-page 9- Figure 1).
>
> For example in the context of IPSO Objects, for your use case I would
> use the IPSO Location Object, having latitud and longitud as the
> resources [6][7].
>
>  
>
> [5]
> http://openmobilealliance.org/documents/whitepapers/OMA-ORG-Guidelines_Creation_Registration_LwM2M_Objects_Resources-V1_0_1-20190115-A.pdf 
>
> [6] http://www.openmobilealliance.org/tech/profiles/lwm2m/3336.xml
>
> [7] http://openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html
>
>  
>
> </ines>
>
>  

<alex>

Thank you for this explanation. I was not familiar with the work from
OMA, so for sure it helped. However, I am still not convinced though for
a number of reasons:

1- In this case, I understand that "Resource" is a piece of information,
while in the resource definition you outline, the concept is aiming
towards code ("Any component, function, enabler, or application that can
send, receive, or process requests"), leaving aside #1 and #3.

2- the word "object" in the IoT space is quite delicate: as we deal with
physical entities, AKA Objects (smart/connected objects?), there is a
meaning overload in this case that can be confusing: using the IPSO XML
you cite, an object is the position of an object, where the first object
refers to a set of data and the second to a physical entity such a car.

3- In the work you cite it seems like the terminology is somehow close
to the Object-Oriented world and, again, the abstraction level seems
different. If there is the need of comparing the semantic properties of
different devices to identify similarities, at this level of abstraction
it doesn't really matter if we use a string or an unsigned short.

In the fire detection example, we can have Temperature Sensors and
Cameras. A Camera might have a hard time to distinguish between my
monitor being on fire or a video of a fire displayed; or else, it may
detect smoke and associate it with fire; however, smoke can be of
different nature. So - if I understand correctly- the work is aimed at
given a similarity note between the camera and the temperature sensor,
saying that both can detect a fire but that the sensor is (probably)
better. I do not see how this can be possible by registering atomic
pieces of data as resources (video frames? temperature measurements?).

Again, I believe that while in the OMA space the definition of Objects
as set of data for the purpose of cataloging can make sense, in this
area it does not help in reaching the objective.

</alex>

>     Furthermore, Functionalities of a system can be grouped and depend
>     on a specific view: we can have communication functionalities, or
>     security, or management, or ... In the example in the text (the
>     fire one), it seems to me that the functionality is related to the
>     Virtual Entity: the physical entity is the fire and a thermometer
>     OR a video share the same capability (let's simplify here) to
>     understand that a fire is going on, and therefore are semantically
>     comparable. 
>
>     Now, neither of them can dim a light - that would be a service
>     that is using different resources on different devices. To fulfil
>     your goal (alert in case of fire) you would actually need two set
>     of resources that have nothing in common (a fire detector and a
>     light).
>
>     I see the point in making the thermometer and the video
>     semantically close in case of detecting a fire, as they can both
>     be fire detectors, but <brainstorming mode> somehow this sounds
>     "almost" like applying fuzzy logic to UML notations (a video IS A
>     "kind-of" fire detector, a thermometer IS A fire detector ... )
>     </brainstorming>
>
> <ines>
>
> We don't depict the light-bulb as a fire detector, but as an alarm
> device. It could be used to alert the user in an emergency case, for
> example, (having configured the lightbulb to turn red when there is
> fire), if the smart home manager entity is aware that there is fire
> somewhere, and the fire alarm device is not able to alert the user, it
> would send a message to the light bulb to turn it red.
>
>  
>
> We understand functionality as a function/goal that a device/resource
> can perform to fulfill a task. A device can present different
> functionalities, for example, some can be defined by the manufacturer,
> some can be defined by the end user. ( we are working to improve this
> definition ).
>
<alex>

Devices indeed have functionalities: my smart phone has a camera. My car
has brakes. Unless functionality is a service, I do not see how it's
possible to have a user-defined functionality within a device. No matter
how hard I try, I cannot take pictures with my car (at least yet :)

Resource-wise, considering resource as code (definition #2), any
user-defined composition of resources is a user-defined functionality
(functionality being a service).

</alex>

thanks!

--alex


On 27. 03. 19 9:51, Ines Robles wrote:

>>     Dear all,
>>
>>     We present in the following draft a way to describe the different
>>     functionalities (from manufacturer and the ones defined by the
>>     user) that an IoT device can present. Additionally, we present a
>>     metric to determinate similar functionalities between devices.
>>
>>     We are trying to figure out a way to define the different
>>     functionalities inside the data-model.
>>
>>     Comments welcome,
>>
>>     Ines and Bill
>>
>>     ------------------------------------------------------------------------
>>     *From:* [e-mail]
>>     <mailto:[e-mail]> <[e-mail]
>>     <mailto:[e-mail]>>
>>     *Sent:* Tuesday, March 26, 2019 4:18:12 PM
>>     *To:* Bilhanan Silverajan; Robles Maria; Robles Maria; Bill
>>     Silverajan
>>     *Subject:* New Version Notification for
>>     draft-robles-t2trg-functionalitydescription-00.txt
>>      
>>
>>     A new version of I-D,
>>     draft-robles-t2trg-functionalitydescription-00.txt
>>     has been successfully submitted by Maria Ines Robles and posted
>>     to the
>>     IETF repository.
>>
>>     Name:           draft-robles-t2trg-functionalitydescription
>>     Revision:       00
>>     Title:          IoT Semantic Functionality Description
>>     Document date:  2019-03-26
>>     Group:          Individual Submission
>>     Pages:          8
>>     URL:           
>>     https://www.ietf.org/internet-drafts/draft-robles-t2trg-functionalitydescription-00.txt
>>     Status:        
>>     https://datatracker.ietf.org/doc/draft-robles-t2trg-functionalitydescription/
>>     Htmlized:      
>>     https://tools.ietf.org/html/draft-robles-t2trg-functionalitydescription-00
>>     <https://tools.ietf..org/html/draft-robles-t2trg-functionalitydescription-00>
>>     Htmlized:      
>>     https://datatracker.ietf.org/doc/html/draft-robles-t2trg-functionalitydescription
>>
>>
>>     Abstract:
>>        This document defines firstly functionality levels for IoT devices
>>        that describe the device capabilities at the granularity of
>>     devices,
>>        objects and resources.  It additionally presents a metric to
>>     measure
>>        the functional similarity between the manageable properties of any
>>        two IoT devices, called Functionality Distance (FD), which is
>>     defined
>>        as the indication of the extent to which one device can be
>>        substituted for the other.
>>
>>                                                                                      
>>
>>
>>
>>     Please note that it may take a couple of minutes from the time of
>>     submission
>>     until the htmlized version and diff are available at
>>     tools.ietf.org <http://tools.ietf.org>.
>>
>>     The IETF Secretariat
>>
>>
>>     _______________________________________________
>>     T2TRG mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.irtf.org/mailman/listinfo/t2trg
>     _______________________________________________
>     T2TRG mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.irtf.org/mailman/listinfo/t2trg
>
>
> _______________________________________________
> T2TRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/t2trg