Dear Raihan,
Thank you for you new update. However, I would like to clarify "for the next release we can go for the basic implementation of associations."
Our interpretation of "basic implementation of associations" is:
* ALL scope not required
* Entity associations not required. Only attribute associations are required.
* Recursive associations not required.
Does that matches your opinion?
In addition, I have one more doubt regarding the .doc example, please.
In the query case, we have the following discovery:
<?xml version="1.0" encoding="UTF-8"?>
<discoverContextAvailabilityRequest>
<entityIdList>
<entityId type="House" isPattern="false">
<id>house_3</id>
</entityId>
</entityIdList>
<attributeList>
<attribute>indoorTemperature</attribute>
</attributeList>
<restriction>
<scope>
<operationScope>
<scopeType> Include Associations </scopeType>
<scopeValue>SOURCES</scopeValue>
</operationScope>
</scope>
</restriction>
</discoverContextAvailabilityRequest>
with the following associated response:
<?xml version="1.0" encoding="UTF-8"?>
<discoverContextAvailabilityResponse>
<contextRegistrationResponseList>
<contextRegistrationResponse>
<contextRegistration>
<entityIdList>
<entityId type="TemperatureSensor" isPattern="false">
<id>Sensor5</id>
</entityId>
</entityIdList>
<contextRegistrationAttributeList>
<contextRegistrationAttribute>
<name>measurement</name>
<isDomain>false</isDomain>
</contextRegistrationAttribute>
</contextRegistrationAttributeList>
<providingApplication>http://myHomeGateway22.org</providingApplication>
</contextRegistration>
</contextRegistrationResponse>
<contextRegistrationResponse>
<contextRegistration>
<registrationMetaData>
<contextMetadata>
<name>association1</name>
<type>Association</type>
<value>[...]</value>
</contextMetadata>
</registrationMetaData>
<providingApplication>http://www.fi-ware.eu/NGSI/association</providingApplication>
</contextRegistration>
</contextRegistrationResponse>
</contextRegistrationResponseList>
</discoverContextAvailabilityResponse>
And the following discovery in the update case:
<?xml version="1.0" encoding="UTF-8"?>
<discoverContextAvailabilityRequest>
<entityIdList>
<entityId type=" TemperatureSensor " isPattern="false">
<id>Sensor5</id>
</entityId>
</entityIdList>
<attributeList>
<attribute>indoorTemperature</attribute>
</attributeList>
<restriction>
<scope>
<operationScope>
<scopeType> Include Associations </scopeType>
<scopeValue>TARGETS</scopeValue>
</operationScope>
</scope>
</restriction>
</discoverContextAvailabilityRequest>
with the following associated response:
<?xml version="1.0" encoding="UTF-8"?>
<discoverContextAvailabilityResponse>
<contextRegistrationResponseList>
<contextRegistrationResponse>
<contextRegistration>
<registrationMetaData>
<contextMetadata>
<name>association1</name>
<type>Association</type>
<value>[...]</value>
</contextMetadata>
</registrationMetaData>
<providingApplication>http://www.fi-ware.eu/NGSI/association</providingApplication>
</contextRegistration>
</contextRegistrationResponse>
</contextRegistrationResponseList>
</discoverContextAvailabilityResponse>
What is interesting to note is that in the first case, the discoverContextAvailability response includes 2 ContextRestristationResponses (one for the Sensor_5 -marked in blue- and other with the metadata describing the associations) while in the second case it includes only one ContextRegistrationResponse (the one with the metadata describing association). I guess that this is due to Sensor_5 has been registered previosly with registerContext (query case 1.a step) while house_3 hasn't. In other words, if a registerContext for house_3 entity has would been done before the discoverContextAvailability, then 2 ContextRegistrations would have been included (one for house_3 and other for the metadata describing the association).
So, if I'm understanding correctly, the behavior of discoverContexAvailability should be returning the following "sum":
* The ContextRegistrationsResponses that would be returned applying NGSI standard default behavior
* If scope is not NONE, the ContextRegistrationsResponses that results of calculating TARGET and/or SOURCE (depending on the scope) associations on the entities in the discoverContextAvailability request.
I understand that probably in your use case it doesn't matters (because you don't have actual providingApplicaitons for house_3, it is only a "logical entity" which makes sense only as association end for sensors) but we are interested in defining precisely the behavior of discoverContextAvailablity.
Thanks!
Best regards,
------
Fermín
El 17/04/2013 11:25, Raihan Ul-Islam escribió:
Hi Fermin,
Please find my remark below marked with ">>"
Thanks
Raihan
From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: 15 April 2013 18:13
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,
Thank you for your document update. Things are getting clearer in each new iteration :)
I have some feedback/comments on the document. I think all them are minor ones.
* In the picture in page 1 you use bidirectional arrows. I think it would be clearer to use uni-directional arrows (from source to target).
>> I modified the bidirectional arrows to unidirectional arrows.
* I understand that you propose "recursive" associations in both senses. I mean, your example only shows that for the "SOURCES" scope, but I understand that if the example also include an association foo1 -> sensor5, then a discoverContextAvailability on room2 will return both sensor5 and foo1, isnt't it?
>>In update scenario I also explained for scope "TARGET". In the scope of discoverContextAvailability request says "SOURCES" then discoverContextAvailability response will return both sensor5 and foo1.
* I understand that the default scope (the one that a NGSI9 server instance will use if no <scope> is included in the <restriction>) is "NONE" to preserver interoperability among NGSI implementations. I mean, the normal behaviour that a client implement standard NGSI but not the association extension we are discussing correspond to the "NONE" case. Right?
>> yes.
* In query case iteration 4 you use SOURCES as scope. However, according to the scope description (if I'm understanding correctly :) this should return the entities to which house_3/indoorTemperature is a source. An house_3/indoorTemperature is not a source of any entity in your example. Thus, I think this is an errata and that to be coherent you should change the document in either one of the following ways:
* Fix the errata in page 1 in the case it works in the oposite way
* Use TARGET scope in XML in iteration 4
* Define the association in the opposite way in registerContext (iteration 2)
>> Sorry for the error in the example of "Concept of scoping" scenario. I have updated it in the attach document
* I think a similar problem happens in update case.
>> As above
In addition, in order to set implementation expectations, I would like to know until which extend your use case needs the following:
* Do you plan to use recursive associations? (query and update cases don't use such recursion)
* Do you plan to use the ALL scope? (query and update cases don't use ALL scope)
* Do you plan to use entity associations (i.e. not using the AttributeAssociationList in registerContext time or AttributeList in discoverContextAvailability with scopes TARGET or SOURCE)? (query and update cases always use attribute associations)
>> for the next release we can go for the basic implementation of associations.
Thanks!
Best regards,
------
Fermín
El 10/04/2013 9:59, Raihan Ul-Islam escribió:
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
________________________________
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/fiware-ngsi/attachments/20130418/57393e39/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy