[Fiware-iot] NGSI 9 and Exposure Interface explanation

[Tobias Jacobs]

Dear Juanjo, all,

please find an answer from NEC side to the two points raised in yesterday's WP sync meeting.

Should we write the information into the wiki as well? And if yes, which one? ;)

Best regards
Martin Bauer and Tobias Jacobs


Role of Thing-level API in task Process Automation
---------------------------------------------------------------------

Without the Thing-level API in the Process Automation subchapter, Applications can obtain Thing-level information from IoT by first going to the "Things/Resources Management GE" to retrieve the Resources that provide the values of the attributes they are interested in. In case that the "Things/Resources Management GE" provides complete resource descriptions, the applications can then go and query directly the relevant resources. In case that the "Things/Resources Management GE" only returns resource identifiers, the applications has to retrieve the corresponding resource description from the "Things/Resources Management GE" in a second step, and access the corresponding resources in the third step.

The process described in the preceding paragraph is a natural candidate for automation, and this is what we are planning to do in Task 5.4. The role of the NGSI-10 interface here is to receive requests on the thing level from applications and deploy the process just described on behalf of the application.

On the capability of NGSI-9 to discover associations between Things and Resources
--------------------------------------------------------------------------------------------------------------

NGSI-9 is for exchanging information about the availability of context information - and it is based on the assumption that all context information can be retrieved from some resource using NGSI-10.
Let us, for example, consider the operation DiscoverContextAvailability. In the request, the Context Consumer specifies a list of EntityIDs and Attributes, possibly including patterns, type specifications, etc. The answer from the Context Management Component is a list of ContextRegistrationResponse objects. Each ContextRegistrationResponse contains Entity identifiers, Attribute identifiers, Metadata and - importantly - the ProvidingApplication URI (note that this URI is NOT optional). In other words, A ContextRegistrationResponse states "the value of these entity/attribute combinations can be retrieved at <ProvidingApplication>".

As already mentioned earlier, the implicit assumption is that the values are provided by the ProvidingApplication via NGSI 10. However, in FI-WARE the assumption that everything is provided via NGSI-10 is not generally valid, because information will be provided by ETSI M2M resources as well. This is why we were skeptical if NGSI-9 is the right interface for doing resolution.



From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Farkas, Lorant (NSN - HU/Budapest)
Sent: Montag, 6. Februar 2012 10:54
To: fiware-iot at lists.fi-ware.eu; jhierro at tid.es
Subject: [Fiware-iot] IoT meeting minutes


Dear All,

Please find under this link the minutes of our bi-weekly WP sync.

https://forge.fi-ware.eu/docman/view.php/11/782/IoT-coordinator-sync-Minutes-Telco-06022012.docx

Dear IoT team, we created some action items to some of you, if there are unclarities please ask.

Thanks & Br,

Lorant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120207/56403f4d/attachment.html>