[Fiware-ngsi] Association in NGSI

[Tobias Jacobs]

Hi Fano,

Thanks for starting the discussion about this. Please find my answers inline below.
In general, I am also happy about comments regarding the understandability of the descriptions.

Best
Tobias

From: fano.ramparany at orange.com [mailto:fano.ramparany at orange.com]
Sent: Montag, 4. März 2013 18:12
To: Tobias Jacobs
Cc: fiware-ngsi at lists.fi-ware.eu
Subject: RE: Association in NGSI

Thank you for your proposal Tobias,

I've got few questions about the "Sensor_123->Room_A" association example:

I assume that you refer to the example given on https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept at the end of the page.



-          What is are the semantics of the associations "Sensor_123->Room_A" and "Sensor_123->Room_B".
In the example on that page the association Sensor_123->Room_B is not described as an entity association. What is described is

a)      The entity association Sensor_123 -> Room_A. The semantics is that any attribute value of Sensor_123 can be interpreted as a value of an attribute of the same name of Room_A. Think for example that Sensor_123 represents a hybrid sensor that can deliver attributes "temperature", "humidity", "air pressure". When this sensor is physically placed in Room A, it measures temperature, humidity and air pressure of that room. This is expressed by an entity association.

b)      The attribute association Sensor_123.measurement1 --> Room_B.temperature. Here the semantics is that any value of attribute "measurement1" or "Sensor_123" can be interpreted as a value of attribute "temperature" of "Room_B".

Is there a reason why you don't capture this semantics in the name of the metadata?
The reason is that I do not see the necessity of doing that, and I find it more natural to introduce new types of metadata than to reserve certain metadata names.


-          What is the relationship between Room_A and Room_B if any
The above associations do not express any relationship between these rooms.


-          In this example there is a single element in the entityIdList. In case there are multiple elements, should they all be temperature sensors.
There can be multiple, in which case the association holds for any of these entites. In the wiki page it is written "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."
There is no reasons that all these sensors should be temperature sensors. There could for example be a temperature sensor providing an attribute "temperature", plus a sensor providing "humidity" mentioned in the list. When then the Entity "room_A" appears in an entity association metadata, it means that these two sensors provide "temperature" and "humidity" of this room.


-          In this example there is a single contextMetaData element in the metaData "section".  In case there are multiple contextMetaData elements, would they represent different type of measurements that the "sensor_123" could yield (sensor producing multiple readings)
Are you referring to the metadata section of the (a) contextRegistration, or to the metadata section of the (b) contextRegistrationAttribute?

a)      In the first case, multiple metadata elements of type "entityAssociation" would mean that multiple thing-level entities are associated to the given sensors. E.g. Room_A and Room_B both get there temperature from sensor_123. In other words, any individual temperature reading from the sensor is interpreted as the temperature of these two rooms.

b)      In the second case and attribute association is expressed. In there are two of them, this would e.g. express the assocations Sensor_123.measurement --> RoomB.temperature and Sensor_123 --> RoomC.indoor_temperature. Again, any temperature reading from the sensor is interpreted both as an attribute value of RoomB.temperature and one of RoomC.indoor_temperature.



-          In this example there is a single contextMetaData element in the registrationMetatData "section". In which cases several contextMetaData elements could be necessary?
Some examples of multiple association metadata entries have been given above. Of course there could be in addition any other metadata that has nothing to do with associations, e.g. accuracy, timestamp, etc.

Is there a reason for distinguishing the registrationMetaData section from the contextRegisrationAttributes.metaData section?

Yes, it is because we distinguish between entity associations and attribute associations, as written (but maybe not in an understandable way) in the introductory part in the wiki page.


-          Which Java API do you use to process NGSI XML messages. In particular, we've got problem in understanding how JAXB handles the "anyType" type declaration of the "value" element for the "ContextMetaData" type. (this echoes a previous mail I posted on this list)

We also use JAXB, and I remember that this question turned up at some point. Up to now we simply use "Object" to represent "anyType" types, and when we need to look inside the object we do explicit casts.

Thank you,

Fano

De : 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] De la part de Tobias Jacobs
Envoyé : vendredi 1 mars 2013 12:10
À : fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Objet : [Fiware-ngsi] Association in NGSI

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

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130305/19f85660/attachment.html>