Dear Ricardo, There was a dedicated meeting on standards discussion. Minutes here: https://forge.fi-ware.eu/docman/view.php/11/534/IoT-API-Taskforce-25102011.docx Conclusion document still here: https://forge.fi-ware.eu/docman/view.php/11/550/v04-API-Conclusion.docx I'm sorry Ricardo, but I don't want to open the API discussion on the list again. If you disagree with the conclusions please organize a meeting with the participants of the taskforce. Best, Dénes From: ext Ricardo de las Heras [mailto:rheras at tid.es] Sent: Wednesday, November 23, 2011 12:21 PM To: Bisztray, Denes (NSN - HU/Budapest) Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] T5.2 Resource management - Work Items 1 & 2 - Dear Dénes, all, yes, I had read the minutes when I came back of my holidays, but that report only explained a recommendation where TID was not completely involved as you know that week. That was 'only a recommendation', not a final decission. The next conf.call we had on 2nd Nov, I remember we said, extracted from the minutes, based on that report: ---------------------- ETSI M2M is good for device level primitives. It is thus recommended for that. SWE has good sensor management information data. Information model. ETSI m2m has container resources, it is a black box, can have everything. It make sense to use the OGC ? Thierry : At this moment we do not have time to discuss this in more detail. We have this as a vision now, and do those parts when we can. For device management we need further discussion, we take more time for that. ---------------------- NGSI seems OK, agreed, but in the low level (ETSI/OGC) it seems it was not definitively agreed, isn't it? --- So, I'm sorry for coming to this point again, but at that time after the call and after reading those minutes for me was not definitively closed this decision. Anyway, I'm not saying the combination of ETSI-M2M and OGC-SensorML-SWE would not be a good solution, indeed as you know IDAS platform manages the sensor observations using OGC SensorML, we only would need to modify the API envelope for achieve an ETSI-M2M standard compliant, I only say that the idea I had in mind was that it was not completely agreed, the same for the assets selection. At this time none of the assets are ETSI-M2M compliant, so this point, as API 'envelope standard' is not a differentiate point for the set of assets. IMHO both issues, asset selection and final standards selection should converge in the same decision regarding the asset selection. Anyway, my previous email was one step further, now how we proceed for the asset selection and for the Resource Directory API specification? thanks Dénes, br, Ricardo. ------------------------------------------- >From v04-API-Conclusion.docx: Device/Resource-level API The Device/Resource -level API is directly connected to the IoT platform and used to perform device management functionalities, i.e. device configuration, firmware update and generic FCAPS functionality. Functional Model: Since NGSI is a thing-level API, it cannot perform all tasks on the lower levels. Since ETSI M2M offers the most extensive support for device-level primitives, we recommend it for the low-level primitives. The support for SWE is still under discussion, as it provides more functionality on the resource level that ETSI M2M does, in particular a semantic model of sensor and measurement information. Information Model: The actual data exchange in ETSI M2M takes places by writing into and reading from so-called container resources in the Service Capability Layer. These containers accept generic data, the format of which has to be agreed upon by the applications and the service provider side. We recommend to model sensor information and sensor observations using OGC SWE SensorML and OGC SWE O&M, respectively. Bisztray, Denes (NSN - HU/Budapest) wrote: Dear Ricardo, The API taskforce discussion was closed weeks ago. The conclusion document can be found here: https://forge.fi-ware.eu/docman/view.php/11/550/v04-API-Conclusion.docx We decided to use ETSI M2M for device - backend communication. TID agreed. From OGC we ONLY use the O&M for data description. You were on holiday that week, please read the document. Best, Dénes From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of ext Ricardo de las Heras Sent: Tuesday, November 22, 2011 5:19 PM To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] T5.2 Resource management - Work Items 1 & 2 - Dear partners involved in T5.2, as you know during these two weeks we are tackling the first sprint of this release. In this way, we had defined two work items that in the short term should help us to establish the priorities of our future developments, i.e.: https://forge.fi-ware.eu/tracker/index.php?func=detail&aid=960&group_id=11&atid=193 https://forge.fi-ware.eu/tracker/index.php?func=detail&aid=959&group_id=11&atid=193 The first one is the selection of the final asset that will cover the Resource Directory component of this task. So far, we had defined the photo attached, defining mainly 3 assets as strong candidates: IDAS, Fosstrak and Cumulocity. We should take a decision about that, before starting the directory's interface definition (work item nº 2). I would like to open the discussion with you about this point, defining the list of points we have to take into account for the final decision . Requirements, maturity of the asset and protocols managed could be one of the most relevant points for taking into account. What do you think? Any other? Maybe the effort of every of the partners involved in T5.2 could be relevant for this decision now? At the same time, we should have also to clarify which protocol will finally be selected for the communication between resources and the resource directory. IMHO OGC SWE could be one of our best options according to results of the analysis we did some weeks ago. I see NGSI more in the upper side, for applications interface. What's your opinion? thanks, looking forward to receiving your feedback, best, R. -- ------------------------------------- Ricardo de las Heras M2M Research Technological Specialist E-mail: <mailto:rheras at tid.es> rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telefónica I+D <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 -- ------------------------------------- Ricardo de las Heras M2M Research Technological Specialist E-mail: <mailto:rheras at tid.es> rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telefónica I+D <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/20111123/08d050bb/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy