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:<mailto:rheras at tid.es> rheras at tid.es<mailto: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/ab763705/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy