[Fiware-ngsi] Association in NGSI

[fano.ramparany at orange.com]

Hi Tobias and all,

Hi Tobias and all,

This is a good idea to discuss/agree on the concepts first. The reason I based my questions on the example is that the descriptions and definitions were too abstract for me and wasn't sure I've understood them correctly.

So to sum up:

-          The semantics of an entity association between entityA and entityB is that: any (attribute,value) pair of entityA could be considered as an (attribute, value) pair for entityB

-          The semantics of an attribute association between entityA.attributeA and entityB.attributeB is that: if entityA.attributeA has the value X than entityB.attributeB has the same value X

-          Other types of association is out of the scope of your proposal
Let me know if I get it right before I express my opinion on this.

Thank you

Fano

De : Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Envoyé : mardi 5 mars 2013 13:46
À : RAMPARANY Fano OLNC/OLPS
Cc : fiware-ngsi at lists.fi-ware.eu
Objet : RE: Association in NGSI

Hi Fano, all,

To make things easier, I would like to distinguish in the discussion between the abstract concepts of association and how to express them in NGSI. So I start with the abstract discussion....

So, abstractly

-          we propose to introduce concepts for entity association and attribute associations.

-          the semantics of associations is that attribute values can be reinterpreted like described on the wiki page

-          but: any further semantics of associations (like e.g. expressing an "inside-of" or "owned-by" relationship) are out of scope

Question goes of course to all in the ngsi list: would you agree to that, or would you prefer to have it in another way?

Best regards
Tobias


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

Thank you for your feedback Tobias. Please find mine inline tagged [FR]

De : Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Envoyé : mardi 5 mars 2013 09:33
À : RAMPARANY Fano OLNC/OLPS
Cc : fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Objet : RE: Association in NGSI

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> [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<mailto: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.
[FR] yes



-          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.
[FR] I didn't find the concept of metadata type in the xsd files. In your example, this association is the "physical placement" of an entity in another entity, but what about the "possession" (car_13 belongs to john_87), if you used "locatedIn" instead of "entityAssociationA" as the metadata name, it would be easier for the system processing the XML description to know what to do with this information.


-          What is the relationship between Room_A and Room_B if any
The above associations do not express any relationship between these rooms.
[FR] But if we consider the case you developed above where: "... When this sensor is physically placed in Room A, it measures temperature, humidity and air pressure of that room... " and "...value of attribute "measurement1" or "Sensor_123" can be interpreted as a value of attribute "temperature" of "Room_B". ...", should Room_A and Room_B be the same?


-          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?
[FR] this question and the previous question correspond to (a) and (b)

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.
[FR] Here again, I can't imagine a case where RoomB and RoomC are not the same room. Or may be RoomB and RoomC share a common door and the Sensor_123 is located right at this door?


-          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.
[FR] From the example, I've got the impression that these sections are redundant, but may be I need to understand why RoomA, RoomB and RoomC are not  necessarily the same room to realize that they finally are'nt.


-          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.
[FR] Thank you. I'll try this.

Fano

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.

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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