[Fiware-iot] [Fiware-ngsi] how to represent associations

[Raihan Ul-Islam]

Hi Fermin,

Thanks for your feedback. Please find our view below respectively on the feedback

·         Associations are both ways. It is not only B to A. It can be also A to B. For better understanding I am adding an example of update scenario in the attached document.

·         About the second feedback. We are  suggesting a ScopeType named "IncludeAssociations". Details about is also described in the attached document.

Thanks
Raihan
==========================================================
Raihan Ul Islam        Software Engineer
NEC Europe Ltd.        NEC Laboratories Europe
Kurfürsten-Anlage 36   D-69115 Heidelberg, Germany
Phone:  +49 (6221) 4342 - 256
Fax:    +49 (6221) 4342 - 155
Mobile: +49 (0) 17679030334
EMail:  raihan.ul-islam at neclab.eu<mailto:raihan.ul-islam at neclab.eu>
http://www.netlab.nec.de
==========================================================
| NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014

From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: 05 April 2013 16:06
To: Raihan Ul-Islam
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] how to represent associations

Dear Raihan,

Just to check if I'm understanding correctly your proposal (please, tell me otherwise):

  *   Apart from registerContext and discoverContextAvailability it doesn't affect any other NGSI operation.
  *   For registerContext, the NGSI server processing the request has to record the association expressed in the metadata
  *   For discoverContextAvailability on entity/attribute B (assuming that A->B association has been previously created with registerContext), the NGSI server process the request of in the following way:

     *   If B is not the end of an association, then B is returned (standard NGSI behavior)
     *   If B is the end of an association, then the start of the association (A) is returned along with association information as metadata.

Now, assuming that above is correct, this is our (TID's) feedback:

  *   The usual semantics for an A->B association (e.g. a UML-like association) is that navigability goes from A to B. I mean, that from A I'm able to reach B. Thus, we think is a bit strange that a discoverContextAvailability on B results in A. In our opinion, the natural way should be in the opposite way, so the algorithm for discoverContextAvailability should be as follows:

     *   For discoverContextAvailability on entity/attribute B (assuming that B->A association has been previously created with registerContext), the NGSI server process the request of in the following way:

        *   If B is not the start of an association, then B is returned (standard NGSI behavior)
        *   If B is the start of an association, then the end of the association (A) is returned along with association information as metadata.

     *   How this would affect to the scenario is shown in the attached file, using Word change control.

  *   An orthogonal problem (no matter if your original algorithm or our modified version in the previous bullet) is how to retrieve the "entity itself" when it is the end (in your original algorithm) or the end (in our modified version) of the association. For example, in your scenario, which discoverContextAvailability request (I mean, the XML) should the client send in the case it wants to get house_3 (not the associated sensor_5)? How to solve this problem? Maybe using the Scope field within discoverContextAvailability request Restriction?

I hope this feedback be useful.

Best regards,

------
Fermín
El 02/04/2013 14:14, Raihan Ul-Islam escribió:


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

________________________________

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/old-fiware-iot/attachments/20130410/4846b3e2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AssociationScenarioExample.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 582650 bytes
Desc: AssociationScenarioExample.docx
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20130410/4846b3e2/attachment.docx>