[Fiware-iot] Review Comments FiwareDeliverable D2.3 IoT - ThingsAndResourcesManagement

[Haller, Stephan]

All,

I agree with the comments from Martin. In addition:

On the Information Data Model:

·         The definition of resource is wrong ("A Resource is a physical component (hardware)"). A resource is a software component, as defined in the FI-WARE high-level description: "Computational elements (software) that provide the technical means to perform sensing and/or actuation on the device". *DONE*

·         The properties (attributes) of a Thing are NOT equal to the union of the observation values of all associated resources. A Thing might have additional properties that are not measured by any sensors. Simple example: The Thing "strawberry yoghurt" has an expiration date, a list of ingredients etc. *DONE*

·         The relationship between Figures 5.2.1 and 5.2.2 is unclear. Do I understand this correctly that both Things as well as Resources are modeled as Context Elements?

·         What are attribute domains? I cannot find this in Figure 5.2.2

As time is running short, I have taken the liberty to make some corrections directly in the Wiki (plus some editorial changes). I have marked the points I corrected with "*DONE*".

Regards,
-Stephan

From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Martin Bauer
Sent: Mittwoch, 15. Februar 2012 14:48
To: Ricardo de las Heras (rheras at tid.es)
Cc: fiware-iot at lists.fi-ware.eu
Subject: [Fiware-iot] Review Comments FiwareDeliverable D2.3 IoT - ThingsAndResourcesManagement

Hi Ricardo and T5.2 people,

I finally had time to look at the ThingsAndResourcesManagement GE Description in D2.3 and I have the comments and corrections listed below:

FIWARE.ArchitectureDescription.IoT.Backend.ThingsAndResourcesManagement

- "Overview": "Additionally this GE dynamically maintains associations between Things and IoT RESOURCES." *DONE*
- "Overview": "Therefore the IoT Resource Management describes the functional components of a scalable distributed architecture for resolution, discovery and event processing". I do not really understand why "event processing" is mentioned. (Complex) event processing is typically used to combine and derive more high level events. I don't see that as part of the ThingsAndResourcesManagement GE functionality. *DONE*

- "Basic Concepts - Information Data Model": "a Thing denotes a physical object in the real world, being characterized by several properties that represents its state along the time described by couples of value-timeStamp." I think you mean "pair" (as in "key-value pair") instead of "couple". *DONE*
- The alignment of the Thing/Resource Data Model and the NGSI Information Model is not done in a very detailed way and there are inconsistencies. The NGSI data model does not have value-timestamp pairs. Rather you have a more complex structure and the timestamp may be one of the pieces of information that are attached to a value as Meta-Data.

- "Northbound Interfaces": "There are two kind of interfaces, one for context information discovery, another one for context information query/update." "subscription" is missing as an important functionality of the latter.

- "Northbound Interfaces - NGSI-9": "NGSI-9 manages the simple concept of 'Entities and Properties' " - here the Thing and IoT Resources data model and the NGSI data model are mixed. If we talk about NGSI I think we should stick to the latter.
- "Northbound Interfaces - NGSI-9": So, it deals with metadata, i.e. the configuration, management aspects, allowing queries and to trigger events when a new entity or property appear, or the value of a property has changed, ... " The last point is wrong - NGSI-9 cannot be used to subscribe for values, only what information is generally available, so values can be retrieved using NGSI-10.
- "Northbound Interfaces - NGSI-9": "IT is important to remark here that a question to analySe is whether we should go for extending NGSI-9 and fast-track results of such extension to OMA (for define associations between Things and Resources), because these type of definitions are not currently supported by the NGSI-9 API." - Even though the NGSI-9 interface does not have the concept of "associations", most of the information can anyway encoded there. However, NGSI-9 assumes that the "associations" always refer to NGSI-10 components, so only a reference (URI) pointing to the NGSI-10 interface of the component that can provide the information is included in the "association". This is insufficient for general IoT Resources that may have arbitrary interfaces.

- "Northbound Interfaces - NGSI-10":  "When observations are captured by IoT resources (software) running at IoT devices, they have to be notified to the Things Management Layer." - We at NEC do not believe that this should always be / have to be the case. This is not a suitable assumption for a number of IoT scenarios where we are dealing with resource-constraint devices, especially battery-powered devices. Always pushing out notifications without applications currently being interested can unnecessarily drain the energy of these devices.
- "Northbound Interfaces - NGSI-10": The subscription operation is missing, which is an important part of the NGSI-10 interface.

- "Southbound Interfaces - ETSI M2M": "Using ETSI-M2M resources can send registrations and observations, fully supporting the requirements as means to register resources and send observations". This sounds like ETSI M2M supports automatically sending observations to the infrastructure (Observation Handler?).  ETSI M2M has a concept of REST Resources, so there always needs to be an "application component (from the ETSI M2M point of view)" that first explicitly subscribes for this information. It is not clear how this is supposed to be done.

- "Things and Resources Management Architecture -Event Repository": The Event Repository does not appear in the Architecture (Figure 5.2.3). We at NEC do not think that such a component should be part of the "Things and Resource Management GE".

- "Things and Resources Management Architecture -User Portal": We think there should be a differentiation between the interface for registering the entities (which may be used by system components as well as user application components) and the way a user can interact with this. A Web Interface is just one option for user interaction.

- "Things and Resources Management Architecture -Observation Handler" - again there is a reference to the Event Repository, which is not part of the architecture figure. Such a component should be part of data handling T5.3.  As the "Observation Handler" deals with both T5.2 and T5.3 components, we think it fits better into the T5.4 Exposure GE -->see NEC's changed architecture proposal

- "Things and Resources Management Architecture - Subscribing to creation/updates/deletion of Entities (Things or IoT Resources)" - I do not agree with the use of the term entity as a super type of things AND IoT Resources. IoT Resources are functional components that implement interfaces. These need to be properly described and matched.  NGSI-9 only provides information about what entities and attributes can be provided, but not any values - so at most an insufficient amount of information about a resource can be encoded (e.g. as EntityType), which based on a subscription could lead to a huge amount of notifications (e.g. EntityType=temperature resource) and the Resource Description itself anyway would have to be requested in an additional step.

Best regards,

Martin

------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu<mailto:Martin.Bauer at neclab.eu>
http://www.nw.neclab.eu<http://www.nw.neclab.eu/>

*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120216/539dba78/attachment.html>