[Fiware-iot] NGSI 9 and Exposure Interface explanation

[Farkas, Lorant (NSN - HU/Budapest)]

Dear Martin, Tobias,

 

The question for the thing level API was rather the clarification of the
role of this GE than the clarification of what the thing level API does.
In the architecture we have the interfaces between thing level API and
configuration management, observation handler and publish/subscribe
broker and thing level API and publish/subscribe broker, so the role of
the thing level API GE is a question.

In the meeting we guessed that the thing level API GE could have a role
of some kind of message broker towards these other GE-s.

This should be clarified.

Another topic to clarify is the pub/sub broker from Ricardo: a component
part of a GE, which one, a standalone GE - then we need an update in the
tracker, "materializing..." wiki etc because it is a new GE.

Third topic is the merger of the 2 GE-s in resource management to one
GE, this should be reflected in the tracker (features, work items, user
stories repositioned for this one GE), "materializing..." wiki etc.

 

I can create a work item for every item mentioned above and the progress
can be reported there.

 

Thanks & Br,

 

Lorant

 

From: fiware-iot-bounces at lists.fi-ware.eu
[mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of ext Tobias
Jacobs
Sent: Tuesday, February 07, 2012 11:43 AM
To: fiware-iot at lists.fi-ware.eu; jhierro at tid.es
Cc: Salvatore Longo
Subject: [Fiware-iot] NGSI 9 and Exposure Interface explanation

 

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-Min
utes-Telco-06022012.docx
<https://forge.fi-ware.eu/docman/view.php/11/782/IoT-coordinator-sync-Mi
nutes-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/20120208/fa7e7734/attachment.html>