[Fiware-ngsi] Association in NGSI

[Tobias Jacobs]

Hi Fermin,

Thanks for your comments. I will address them in a separate email.
Here I would like to explain the background of this whole activity:

The general idea of translating between sensor-level and thing-level entities has been proposed by Telefonica more than one year ago, and we identified that this ability is what distinguishes IoT Things Management (including Configuration Management and IoT Broker) from what the pub/sub broker does.

We had very passionate discussions with Juanjo and Ricardo about this topic, as NEC had been more in favor of a different architecture (one that is more in line with the reference architecture from the IoT-A project). So our proposed concept is actually a specification that is in line with the result of that discussion.

Best regards
Tobias


From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Fermín Galán Márquez
Sent: Dienstag, 5. März 2013 20:23
To: fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] Association in NGSI

Dear Tobias, all,

Sorry for the delay sending the answer. It has take some time to read in deep your proposal and having a look to the discussion that followed it in the list (unfortunately, I haven't follow in deep so far the discussion by email, in the hope any relevant conclusion will be re-injected to the wiki page at the end).

We will need to discuss internally in TID the implications of this proposal (mainly in the implication side). However, in the meanwhile, let me ask some questions to clarify some points:

  *   Do the entities/attributes referred by the association registerContext (at both ends of the association) need to have been registered before? I mean, in your example, the Sensor_123-temperature, RoomB-temperature and RoomA elements need to have been previously registered? Otherwise, you will create an association between elements that does't "exists" in the database managed by the NGSI9 server...
  *   You describe basically association creation and query, but what about association modifications and deletion? Are these cases considered in the scope of your proposal?
  *   Could you detail the example of discoverContextAvailability introduced in the "Usage in NGSI9 operations" section in the wiki? I mean, what should be sent as discoverContextAvailabilityResponse in the following cases:

     *   discoverContextAvailability on <entityId_1>.<attributeName_1>
     *   discoverContextAvailability on <entityId_2>.<attributeName_2>

  *   Is NGSI10 out of the scope of your proposal?

Thanks!
Best regards,

------
Fermín

El 01/03/2013 12:09, Tobias Jacobs escribió:
Dear all,

As promised, we have worked out a concept to represent associations between context entities in NGSI.

This is an important feature of the IoT Backend, and in particular relevant for the interaction between Configuration Management and IoT Broker.

If you are interested in this topic, please read our draft at
https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept.
It is a rather short document.

I am looking forward to the discussion about this topic :)

Best regards
Tobias



_______________________________________________

Fiware-ngsi mailing list

Fiware-ngsi at lists.fi-ware.eu<mailto:Fiware-ngsi at lists.fi-ware.eu>

http://lists.fi-ware.eu/listinfo/fiware-ngsi

________________________________

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/fiware-ngsi/attachments/20130306/e9365d5b/attachment.html>