Dear Ricardo, Thank you for your email and the comments. You are right; OMA NGSI only provides high level descriptions and does not include detailed attributes to describe IoT resources; however, it has an attribute for advance feature that can be used to link the semantically described detailed attribute to the main description. The proposal to use NGSI is based on NEC and Telecom Italia's previous work which is also uses ideas from SENSEI information model. During the meeting, I suggested if we are going to use NGSI then IOT-A information model can be used to define the advanced attributes; With regards to the SensorML, it provides some of the semantics for the modelling purpose but in principal, SensorML describes "geometric, dynamic, and observational characteristics of sensors and sensor systems" and in FI-WARE IOT we need a more boarder scope than only Sensors and O&M data; So one option could be adopting IoT-A models for FI-WARE and representing the model attributes in a semantic form according to NGSI model (as a template); The SensorML description can be then annotated using the proposed model. Regarding your second comment, I also share your views; we also need to consider the compatibility between different assets and solutions that we select. Thanks and regards, Payam ________________________________________ From: Ricardo de las Heras [mailto:rheras at tid.es] Sent: 25 November 2011 13:23 To: Barnaghi P Dr (Electronic Eng); fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] T5.2 Resource management - Work Items 1 & 2 - Dear Payam, @ll, one clarification please, I read the minutes and you said yesterday: " Payam: we discussed f2f in Turin that we use semantic description based on OMA NGSI - why go back to that discussion? 2nd: if data is stored in a format, it will impact the discovery." sorry but I don't understand it, as far as I know NGSI doesn't define a semantic description, I'm not an expert on it, but when I had a look to the specification, it only provides very high concepts for interchanging context information between entities, maybe I ignore some parts of the specification, please could you clarify for me this point? BTW, SensorML seems to provide semantic capabilities, adding tags for including semantic annotations, maybe this could be a good option for solving the problem with your discovery process, if it only works with RDF. Could we explore it? what do you think? Furthermore, a personal reflection now, and a open question I leave for all the partners involved on WP5, not only for you Payam: If we are proposing an IoT solution in Fiware based on our previous assets, it is supposed that we only would have to apply 'slight' modifications for including them in Fiware, isn't it? So, now, if we are proposing in the final solution new standards and requirements not covered by any of the assets available, and them implies developments almost starting from the scratch..., my question: who will develop them? because the current budget assigned to all of us can only cover the 'light' modifications needed in Fiware, not the development of a new system. So please, let's put our feet on the ground and let's try to define feasible and realistic solutions, otherwise maybe we will achieve a good final solution but very far of the current set of assets we are managing as candidates, and then, the next step will probably be that none of us will be dispose to tackle the required developments with the current budget we have here. So, do you honestly think my exposition is realistic or not? Thanks in advance for your answer, and sorry but I'm a little bit confused with the current situation we have regarding all those issues now, I'll try to arrange a conference call soon about this topics, as we agreed yesterday, but previously I would like to define with you what would be the concrete focus of the discussion there, have a nice week-end, R;) P.Barnaghi at surrey.ac.uk wrote: Hi Ricardo, Thank for your reply and comments. - SensoerML is more a sensor description language and I think what is planned here are more generic IoT resources and as we agreed the descriptions it will be provided based on OMA NGSI and IoT-A information models and those descriptions will be stored in the Resource Directory. - for registration we need a common interface (to publish the data according to the designated models) and it seems the implementation technology for the interface will be Restful. So I don't see how SensorML fits here. - if the data is not in RDF form, our discovery engine won't work! Simply because we use logical reasoning and probabilistic machine learning that process semantic data that describe the resources/services; I understand that our information model should support legacy data, but that's another issues that how we annotate legacy data and still should not affect our model (so SnesorML is seen separate from our description model here). Please see: http://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/#Semantic_Markup PS. However, if the group has agreed on any of the items or if it is decided to use SensorML and stored it in the resource directory, then we will follow the group's decision. But unfortunately we then won't be able to provide the discovery mechanism. Best regards, Payam ________________________________________ From: Ricardo de las Heras [mailto:rheras at tid.es] Sent: 23 November 2011 11:44 To: Barnaghi P Dr (Electronic Eng) Cc: fiware-iot at lists.fi-ware.eu; Elsaleh T Mr (Electronic Eng) Subject: Re: [Fiware-iot] T5.2 Resource management - Work Items 1 & 2 - HI Payam, I'm going to answer to your three questions, under my personal point of view: - Discovery mechanisms should retrieve the information from the resource directory, so I understand the information about the registered sensors would be stored in the OGC-SensorML format, because NGSI and M2M-ETSI only provide an envelope for the information, not a data/registering description. I don't know if you could adapt the search mechanism for using this format instead of RDF. I don't know if it would have a direct conversion way. - Yes, we need a protocol for register the sensors on the directory, using a SensorML (OGC) standard as Dénes explained, that's the meaning of this communication protocol between resources and resource directory. - I'm not sure about how you could access to the resource directory from the discovery engine, how flexible could be your discovery engine for managing data not stored in RDF format. Maybe the question is if we would have to store the information in the resource directory using RDF format or OGC-O&M. At this time I had personally assumed it would be in O&M, but we can discuss it of course. It would depend again of the final asset selected there. regards, Ricardo. P.Barnaghi at surrey.ac.uk wrote: Hi Ricardo, all, Can you please clarify the following points: - What will the discovery mechanism is going to retrieve and where it will refer to? We can provide a query and search mechanisms but assuming the data is stored as OWL/RDF data that can be accessed via SPARQL end-points. - The data models as we discussed will be according to OMA NGSI and IoT information models and we will use Restful interface to publish/access the description. But again I don't know what is meant by the communication protocol between resources and resource directory. Our understanding is the resources will publish their description (according to an agree description framework) in a resource directory, the resource descriptions then will be accessible via a common enabler (a restful interface) and/or can be queried using a query/search enabler (SPARQL-end point interface). - We are not also clear that according to the descriptions, how our linked data platform should be integrated in this design, if the resource directory and discovery engines are considered using two different designs. Thanks, Payam ________________________________________ From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Ricardo de las Heras Sent: 22 November 2011 16:19 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: rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telefónica I+D ------------------------------------- ________________________________________ 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: rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telefónica I+D ------------------------------------- ________________________________________ 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: rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telefónica I+D ------------------------------------- ________________________________________ 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
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy