[Fiware-ngsi] how to represent associations

[Raihan Ul-Islam]

Hi All,

For representing the association we are proposing a metadata type "Association". It will have two elements "entityAssociation" and "attributeAssociationList".

The "entityAssociation"  has two elements "sourceEntityId" and "targetEntityId". Usually devices will be used as "sourceEntityId"  and things will be used as "targetEntityId". The elements "sourceEntityId" and "targetEntityId" are of "EntityId" type. But the attribute "isPattern" of "EntityId"  will be omitted. Therefore, it will always have the value false. (As for example, if we consider the below scenario "sourceEntityId" will be he sensor5 and "targetEntityId" will be house_3.)

The  "attributeAssociationList" is a list of "attributeAssociation" element . It also has two elements. These are "sourceAttribute" and "targetAttribute". The elements are a type of "xs:string". The "sourceAttribute" and "targetAttribute" will contain  the attribute of the corresponding "sourceEntityId" and "targetEntityId".

We proposed two types of associations(https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/NGSI_association). These are entity and attribute association.
An entity association will  be represented by "entityAssociation" element of the metadata. "entityAssociation" and "attributeAssociationList" both are needed to represent an attribute association.


For better understanding association the following scenario is considered.
Scenario
In  this scenario, pop/sub broker asks for the indoor temperature of a house(e.g. house_3) and a sensor (e.g. sensor5) available in house_3. The sensor5 provides the indoor temperature as an attribute "measurement".  "indoorTemperature" attribute of house_3 provides indoor temperature. Therefore, to get the indoor temperature of the house_3 there should be an association between "indoorTemperature"  attribute of house_3 and "measurement" attribute of  sensor5.  I am attaching a complete example of an association scenario in the attachment with sample request and response. Also attaching the xsd file for the metadata tag.

I am looking forward for your opinion about this topic.

Thanks
Raihan

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 Tobias Jacobs
Sent: 22 March 2013 09:58
To: Fermín Galán Márquez
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] how to represent associations

Hi Fermin,

Thanks for your feedback.
We will come up with a proposal of a metadata type definition for representing associations in the week before Easter.

I think also from an implementation point of view this approach is easier than the previous ones, because there is a more clear distinction between association registrations and context provider registrations.

Best regards
Tobias


From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Freitag, 22. März 2013 09:00
To: Tobias Jacobs
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: how to represent associations

Dear Tobias,

In principle, it seems more flexible than the original approach. However, in order to get a complete understanding of the idea and its implications (specially from the implementation point of view) we would need to have a look to a more detailed definition and examples (something in the same style as in https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept).

Are you planning to provide that definition/examples?

Best regards,

------
Fermín

El 20/03/2013 16:01, Tobias Jacobs escribió:
Dear Fermin, dear all,

In the IoT F2F meeting last week we have been discussing about how to represent associations using the NGSI ContextRegistration structure, and we had not reached a conclusion yet.

I would like to take the chance to propose a radically new and simplistic concept of doing this. How about we simply define some structured metadata types for associations where both the Thing-level entities/attributes and the Device-level entities/attributes are mentioned. These pieces of metadata are then put into the RegistrationMetadata list of the ContextRegistration structure, and the entityList and attributeList fields can stay empty.

This gives us any flexibility of how to structure the associations. We can start with simple entityAssociations and attributeAssociations as metadata types, but further and more complex associations can be defined later in the same way.

What do you think?

Best
Tobias

________________________________

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/20130402/07b1a1ae/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AssociationScenarioExample.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 462570 bytes
Desc: AssociationScenarioExample.docx
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130402/07b1a1ae/attachment.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NGSIAssociations.xsd
Type: text/xml
Size: 1378 bytes
Desc: NGSIAssociations.xsd
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130402/07b1a1ae/attachment.xml>