[Fiware-ngsi] Association in NGSI

[Tobias Jacobs]

Hi Fermin and Fano,

I try to address both your emails inside this answer.

It seems to me that the conceptual questions of entity and attribute associations have been resolved, and we are now discussing more the details of the NGSI 9 representation. Cool :).

Please find my comments inline below.

Best
Tobias
[Fermin: ]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...
[Tobias:] No, in my opinion it should not be assumed that the entities have been registered before, as this would be a severe restriction. Think of the following scenario:

1)      Someone registers the association "sensor_1 --> room_2"without knowing the network address of any provider of information from sensor_1

2)      An application subscribes for "room_2" via NGSI10

3)      Someone sends some attribute value of sensor_1 using NGSI10 update operation. This should trigger a notification of the application using this attribute value as one of room_2.

  *   [Fermin: ]You describe basically association creation and query, but what about association modifications and deletion? Are these cases considered in the scope of your proposal?
[Tobias:] I think the standard NGSI9 mechanisms for registration deletion and update can be used, so there is no need to explicitly mention them. Just send another association with the same registration Id, or send an empty one with the same Id.

  *   [Fermin: ] 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>
[Tobias:] If the association <entityId_1>.<attributeName_1> -->  <entityId_2>.<attributeName_2> has been registered, then this association should be returned for both discoverContextAvailability requests. You get exactly the same ContextRegistration.

  *   [Fermin:] Is NGSI10 out of the scope of your proposal?
[Tobias:] Yes and No. Yes, because there is no need to define any special metadata to be used in any NGSI 10 message. No, because with association concepts you can ask for things and get results that have been assembled from sensor-level information in the backend.


[Fano:] I also didn't understand very well the semantics of lists of entity associations and attribute associations:

-          If for example, the list of entity associations contains entity1, entity2, entity3... I presume that each of these entities is linked to the entity of reference in the context document through an entity association. Does it also mean that entityi is linked to entityj through an entity association?

[Tobias:] If entity1, entity2, entity3 appear as metadata of type EntityAssociation and entityA appears in the EntityIdList of the ContextRegistration, then this expresses the associations entityA --> entity1, entityA --> entity2, entityA --> entity3. But it does not express any association like e.g. entity1 --> entity2.

This is expressed by the sentence
"Let in a ContextRegistration structure M be the set of EntityIDs appearing in such a type of metadata, and let E be the set of EntityIDs appearing in the EntityIdList. Then this ContextRegistration represents all associations of the form <entityId_1> --> <entityId_2>, where <entityId_1> is contained by E and <entityId_2> is an element of M."
But maybe the language is too mathematical to be understandable? Would you express it differently?


-          [Fano:]  A list of attribute associations is easier to understand though, if it is a way to express in one registration several independent attribute associations (one for each element of the list). Is there something else to understand about a list of attribute associations?

[Tobias:] Not sure if I understand your question right.
You can register more than one association in the same contextRegistration structure. but you the sets of associations cannot be chosen arbitrarily. This is because e.g. expressing
sensor1.measurement1 --> room1.temperature and
sensor2.measurement2 --> room2.temperature
in the same contextRegistration structure is not possible without at the same time expressing the associations
sensor2.measurement1 --> room1.temperature and
sensor1.measurement2 --> room2.temperature.
Of course it is still possible to register exactly the first two associations, but two different contextRegistration structures are needed for this.







From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto: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<mailto: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/20130307/fe2aa53c/attachment.html>