Hi Ricardo, Thanks for the clarification. 1. So I guess when you describe pub/sub broker in your figure, you mention the one from the DCM chapter, right? 2. Martin, Salvatore, your clarifications should find a place in this Wiki page, IMHO. I would not create a task for you do do this, I believe you will do it even without that J Thanks & Br, Lorant From: ext Ricardo de las Heras [mailto:rheras at tid.es] Sent: Wednesday, February 08, 2012 9:19 AM To: Farkas, Lorant (NSN - HU/Budapest) Cc: ext Tobias Jacobs; fiware-iot at lists.fi-ware.eu; JUAN JOSE HIERRO SUREDA; Salvatore Longo Subject: Re: [Fiware-iot] NGSI 9 and Exposure Interface explanation Dear Lorant, all, we can discuss it later on the phc, I recommend you anyway to read the current description of D2.3 at https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FIWARE.OpenSpecification.IoT.Backend.ThingsAndResourcesManagement Thing level API provides information to the Applications through NGSI-9 regarding the Things/Resources, their associations and properties. Publish/Subscribe broker provides basically information about the observations collected from the Resources using NGSI-10. You are right, we need to update the tracker with these components, br, Ricardo. Farkas, Lorant (NSN - HU/Budapest) wrote: 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-Minutes-Telco-06022012.docx <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 -- ------------------------------------------- Ricardo de las Heras Technological Specialist Enabling Platforms E-mail: <mailto:rheras at tid.es> rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telefónica Digital <http://www.tid.es> ------------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120208/fae74275/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy