[Fiware-iot] T5.2 Resource management - Work Items 1 & 2 -

[P.Barnaghi at surrey.ac.uk]

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<mailto: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> [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<mailto: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

--
-------------------------------------
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/fc5f0c68/attachment.html>