From raihan.ul-islam at neclab.eu Tue Apr 2 14:14:10 2013 From: raihan.ul-islam at neclab.eu (Raihan Ul-Islam) Date: Tue, 2 Apr 2013 12:14:10 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations Message-ID: 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] 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 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 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: -------------- 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: NGSIAssociations.xsd Type: text/xml Size: 1378 bytes Desc: NGSIAssociations.xsd URL: From thierry.nagellen at orange.com Wed Apr 3 08:26:23 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 3 Apr 2013 06:26:23 +0000 Subject: [Fiware-iot] IoT weekly meeting Message-ID: <23710_1364970384_515BCB90_23710_4226_2_976A65C5A08ADF49B9A8523F7F81925C0CB867@PEXCVZYM13.corporate.adroot.infra.ftgroup> Dear all, We will have this morning a short meeting focusing on the 2nd peer review (Cloud chapter). Do not forget to send me your contributions. We will also discuss guidelines to validate release 2.2. Carlos and Fermin will not be there because they have IoT presentation in Madrid Architect week with phase 2 projects. Best regards. Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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: From thierry.nagellen at orange.com Wed Apr 3 10:05:38 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 3 Apr 2013 08:05:38 +0000 Subject: [Fiware-iot] TR: [Fiware] Guidelines for Release 2 Message-ID: <25124_1364976340_515BE2D4_25124_266_1_976A65C5A08ADF49B9A8523F7F81925C0CB987@PEXCVZYM13.corporate.adroot.infra.ftgroup> De : fiware-bounces at lists.fi-ware.eu [mailto:fiware-bounces at lists.fi-ware.eu] De la part de Miguel Carrillo Envoy? : jeudi 28 mars 2013 02:24 ? : fiware at lists.fi-ware.eu Objet : [Fiware] Guidelines for Release 2 Dear all, Given the importance of the general guidelines for the delivery of the deliverables associated to the software and the absence of key components of the team due to the Easter holidays, this message is directly sent to all the consortium. Be ready for a long but extremely important message. This is strictly about : * Delivery of the Software itself * Installation and Administration manual * User and Programmer manual * Unit Testing Plan and report The date for delivery to the EC is the end of April so we will need to have all complete and ready for review by April, 22 , as agreed in the past WPL/WPA call. The guidelines are available on the private wiki (if you do not have access, ask your WPL or WPA to fix it) . The link to the detailed guidelines is here(you need to this them before editing the deliverables): * https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FiwareDeliverablesR2 Please note that: * The guidelines for the docs are basically the same ones as for Release 1 * The guidelines for the software delivery are completely different and were sent by Ferm?n to this list ages ago Please use the placeholders to edit each document (linked from the guidelines page). Most of the chapters have not started this work, they must use the private wiki following the links under the placeholder section in the guidelines. Exceptionally, if someone has started editing the changes somewhere else (I am only aware of some GEs in WP3), carry on working there but this place must be linked from the placeholders, so make them point at the right location where you actually work . If you start working now you must use the links provided and the private wiki. I will ask to revert any unauthorised changes in the public wiki, I insist that you must use the private wiki (the public wiki should only have definite manuals, not intermediate stuff). Be aware that this time moving pages across different wikis (figures included) is done in a matter of seconds thanks to a tool developed by SAP. Your WPL must have access to it (or can ask for access to it if he has not done so yet) * This will ease the work of copying the definite versions of the manuals to their final destinations. * Also, if you need to use a previous version on the manual as the basis for the coming issue of the docs, this tool can be used to take a copy of the current wiki pages to the private wiki prior to the start of your work. Check with your WPL/WPA if you have any doubts, I will only answer queries routed via the WPL/WPAs to ensure a good synchronisation of the whole process. Best regards, Miguel ________________________________ 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 _________________________________________________________________________________________________________________________ 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00002.txt URL: From sabrina.guerra at telecomitalia.it Wed Apr 3 12:20:17 2013 From: sabrina.guerra at telecomitalia.it (Guerra Sabrina) Date: Wed, 3 Apr 2013 12:20:17 +0200 Subject: [Fiware-iot] R: Architecture peer review: deadline April 4th In-Reply-To: <21915_1364374538_5152B40A_21915_843_1_976A65C5A08ADF49B9A8523F7F81925C0C6DA0@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <21915_1364374538_5152B40A_21915_843_1_976A65C5A08ADF49B9A8523F7F81925C0C6DA0@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5ADCC7015@GRFMBX702BA020.griffon.local> Hi Thierry and Carlos, I attach our peer-review related to the Cloud CE GE. Best regards, Sabrina Da: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di thierry.nagellen at orange.com Inviato: mercoled? 27 marzo 2013 09:56 A: fiware-iot at lists.fi-ware.eu Oggetto: [Fiware-iot] Architecture peer review: deadline April 4th Priorit?: Alta Hi all, The 2nd round for the peer review of architecture document happens now. I fulfill the spreadsheet with some names of partners and sometimes people. I know that some of you will be on vacation for Easter so I will manage the evaluation for 3 GEs from Cloud chapter. Please check that the deadline is the 4th of April and that we will use the same process. Send me your contributions for the related GEs and I will update the cockpit for the 4th of April. Thanks for your contribution BR Thierry De : Alex Glikson [mailto:GLIKSON at il.ibm.com] Envoy? : mardi 26 mars 2013 23:09 ? : CARLOS RALLI UCENDO; NAGELLEN Thierry OLNC/OLPS Cc : Miguel Carrillo; Juanjo Hierro Objet : Fw: [Fiware-wpl] Architecture doc (update + guidelines) Updated Cloud architecture doc is ready for review (https://forge.fi-ware.eu/docman/view.php/27/1997/D232_WP4_v3_generated-2013-03-26.doc) Regards, Alex ==================================================================================================== Alex Glikson Manager, Cloud Operating System Technologies, IBM Haifa Research Lab http://w3.haifa.ibm.com/dept/stt/cloud_sys.html | http://www.research.ibm.com/haifa/dept/stt/cloud_sys.shtml Email: glikson at il.ibm.com | Phone: +972-4-8281085 | Mobile: +972-54-6466667 | Fax: +972-4-8296112 ----- Forwarded by Alex Glikson/Haifa/IBM on 27/03/2013 12:06 AM ----- From: Miguel Carrillo > To: "fiware-wpa at lists.fi-ware.eu" >, "fiware-wpl at lists.fi-ware.eu" >, Date: 26/03/2013 02:12 PM Subject: [Fiware-wpl] Architecture doc (update + guidelines) Sent by: fiware-wpl-bounces at lists.fi-ware.eu ________________________________ Dear all, As agreed in our confcall yesterday, we will continue using the cockpit and the process will be similar to the previous round: * http://www.google.com/url?q=https%3A%2F%2Fdocs.google.com%2Fspreadsheet%2Fccc%3Fkey%3D0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c%23gid%3D0 Calendar: 1) docx second version of chapters ready for peer review: March 27th * Each chapter will upload their contributions to the private docman and will add the link to column E (as the Data chapter has already done) 2) Comments on second draft due by April 4th * Each chapter will upload their reviews to the private docman and will add the link to column F 3) 3rd Final version: April 12th * Each chapter will upload their 3rd version of the architecture to docman and will add the link to column G This is the new assignment: * Data - reviewed by Apps * Cloud - reviewed by IoT * Apps - reviewed by I2ND * IoT - reviewed by Data * I2ND - reviewed by Security * Security - reviewed by Cloud Could those who have a new version please upload it? Security said that they would have yesterday but I cannot see it on the cockpit, maybe they were waiting for this confirmation. Up to each WPL to do the work on the wiki or on the document directly. But it is compulsory to 100% synch the public wiki after the delivery. Best regards, Miguel -- ---------------------------------------------------------------------- _/ _/_/ Miguel Carrillo Pacheco _/ _/ _/ _/ Telef?nica Distrito Telef?nica _/ _/_/_/ _/ _/ Investigaci?n y Edifico Oeste 1, Planta 4 _/ _/ _/ _/ Desarrollo Ronda de la Comunicaci?n S/N _/ _/_/ 28050 Madrid (Spain) Tel: (+34) 91 483 26 77 e-mail: mcp at tid.es Follow FI-WARE on the net Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: http://twitter.com/Fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ---------------------------------------------------------------------- ________________________________ 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_______________________________________________ Fiware-wpl mailing list Fiware-wpl at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-wpl _________________________________________________________________________________________________________________________ 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. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000003 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: D232_WP4_v3_generated_TI Cloud CE V2.doc Type: application/msword Size: 392192 bytes Desc: D232_WP4_v3_generated_TI Cloud CE V2.doc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: From fermin at tid.es Fri Apr 5 16:05:58 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Fri, 05 Apr 2013 16:05:58 +0200 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: References: Message-ID: <515EDA46.6060801@tid.es> 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] 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 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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: AssociationScenarioExample+TID.docx Type: application/x-msword Size: 463451 bytes Desc: not available URL: From Tobias.Jacobs at neclab.eu Mon Apr 8 11:34:30 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Mon, 8 Apr 2013 09:34:30 +0000 Subject: [Fiware-iot] Associations in Release 2.3 of ConfMan GE Message-ID: <8755F290097BD941865DC4245B335D2D38F52326@DAPHNIS.office.hd> Dear Colleagues from TID, Could you provide us some information related to your current plans related to the releases of the Configuration Management GE? 1) We understand that the next release of the ConfMan GE will be 2.3. How does this match with the integration plans that were discussed in the F2F meeting? We planned the integration of the WP5 components, but without the ConfMan GE no integration will be able to work. 2) In the technical roadmap (https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Roadmap_of_Internet_of_Things_%28IoT%29_Services), there is a slight mismatch between the features list in the table and what is described in the bullet points when it comes to association support. We are concerned that there is no feature in the table on association support of the ConfMan GE. As the discussions with Juanjo last year have shown, the ability of translating between device-level and thing-level information is one of the essential abilities of the IoT Backend. The support of associations by ConfMan GE is an essential prerequisite for it. We can also discuss this point in the phone conference this week. Thanks and best regards Ernoe, Martin, Raihan, Salvatore, and Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralli at tid.es Mon Apr 8 15:11:22 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 08 Apr 2013 13:11:22 +0000 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089038280@EX10-MB2-MAD.hi.inet> Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From t.elsaleh at surrey.ac.uk Mon Apr 8 18:17:23 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Mon, 8 Apr 2013 17:17:23 +0100 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B25089038280@EX10-MB2-MAD.hi.inet> References: <1971FF81B8E01C45991F6F92B9E3B25089038280@EX10-MB2-MAD.hi.inet> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789B6862B@EXMB05CMS.surrey.ac.uk> Hello Carlos, Do we make the changes in the wiki or the docx? Best regards, Tarek From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 08 April 2013 14:11 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From ralli at tid.es Mon Apr 8 18:29:33 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 08 Apr 2013 16:29:33 +0000 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA789B6862B@EXMB05CMS.surrey.ac.uk> Message-ID: <1971FF81B8E01C45991F6F92B9E3B250890396EE@EX10-MB2-MAD.hi.inet> Both. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 8 de abril de 2013 18:17 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hello Carlos, Do we make the changes in the wiki or the docx? Best regards, Tarek From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 08 April 2013 14:11 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From Tobias.Jacobs at neclab.eu Tue Apr 9 09:45:23 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Tue, 9 Apr 2013 07:45:23 +0000 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B250890396EE@EX10-MB2-MAD.hi.inet> References: <2AAC0B6FF99A064C853BFB1C9295F3CCA789B6862B@EXMB05CMS.surrey.ac.uk> <1971FF81B8E01C45991F6F92B9E3B250890396EE@EX10-MB2-MAD.hi.inet> Message-ID: <8755F290097BD941865DC4245B335D2D38F53761@DAPHNIS.office.hd> Hi Carlos, all, As far as I understand, the changed doc is what will be submitted as deliverable, right? Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Montag, 8. April 2013 18:30 To: t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Both. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 8 de abril de 2013 18:17 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hello Carlos, Do we make the changes in the wiki or the docx? Best regards, Tarek From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 08 April 2013 14:11 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From ralli at tid.es Tue Apr 9 10:03:31 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 09 Apr 2013 08:03:31 +0000 Subject: [Fiware-iot] FW: [Fiware-wpa] AP from yesterday: putting the links on the private wiki In-Reply-To: <5163CACE.2030002@tid.es> Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508903A723@EX10-MB2-MAD.hi.inet> Hi guys, This is important now. I'll check it today. BR -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Miguel Carrillo > Fecha: martes, 9 de abril de 2013 10:01 Para: "fiware-wpa at lists.fi-ware.eu" >, "fiware-wpl at lists.fi-ware.eu" > Asunto: [Fiware-wpa] AP from yesterday: putting the links on the private wiki Dear all, I see very little activity in the WP lists and we have little time. Yesterday we urged you to make the wiki links of 3 deliverables point at the place where they will edit them. Please instruct your teams to go to * https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FiwareDeliverablesR2 and make them point their links to : * the place where they are editing the 3 documents (in principle, the private wiki) * or alternatively ... if they have not started, point at the place where they will edit the 3 documents If the page is blank because they have not started, put a note there with an "ongoing work" or someting. If we point at a blank page I will never know if it is intentional and this is the future space for the page or that the partner did not update the link! If there are particular circumstances why the doc is not going to be edited on the wiki (very exceptional case), the page must not remain blank. We need an explanatory note there to save us a check with the GE owner. The reason is that there are 40 GEs approximately, and 3 manuals. So 120 checks is too much for anyone if not properly organized. Tomorrow Manuel and myself will start our review of this and will assess it chapter by chapter. I enclose the general guidelines as a reminder. Best regards, Miguel -- ---------------------------------------------------------------------- _/ _/_/ Miguel Carrillo Pacheco _/ _/ _/ _/ Telef?nica Distrito Telef?nica _/ _/_/_/ _/ _/ Investigaci?n y Edifico Oeste 1, Planta 4 _/ _/ _/ _/ Desarrollo Ronda de la Comunicaci?n S/N _/ _/_/ 28050 Madrid (Spain) Tel: (+34) 91 483 26 77 e-mail: mcp at tid.es Follow FI-WARE on the net Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: http://twitter.com/Fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ---------------------------------------------------------------------- ________________________________ 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: From ralli at tid.es Tue Apr 9 16:24:49 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 09 Apr 2013 14:24:49 +0000 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) In-Reply-To: <8755F290097BD941865DC4245B335D2D38F53761@DAPHNIS.office.hd> Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508903B5EB@EX10-MB2-MAD.hi.inet> Hi Tobias, Thanks to raise this point, because it is really quite important and will be part of the agenda in our conf call tomorrow. Actually the case of IoT chapter is a bit special because we are doing deep changes in the Architecture WIKi docs. In the docs we have just applied changes from the peer-reviews and in the Wiki we need to perform all changes => peer-reviews + what we agreed in the F2F meeting. The consequence is that we need to do the changes before Thu 11 EoB in both places (but in the docs only the peer-review comments while in the Wiki all them). Docs will be sent to peer-reviewers because they have a period of time to claim if feedback was actually done. However, I will use the Wiki to generate the docs that we will finally deliver so this is the material that we will deliver to the EC in the end (and thus all changes need to be applied there). Thanks for your understanding. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 09:45 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, all, As far as I understand, the changed doc is what will be submitted as deliverable, right? Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Montag, 8. April 2013 18:30 To: t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Both. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 8 de abril de 2013 18:17 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hello Carlos, Do we make the changes in the wiki or the docx? Best regards, Tarek From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 08 April 2013 14:11 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From Tobias.Jacobs at neclab.eu Tue Apr 9 17:28:50 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Tue, 9 Apr 2013 15:28:50 +0000 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B2508903B5EB@EX10-MB2-MAD.hi.inet> References: <8755F290097BD941865DC4245B335D2D38F53761@DAPHNIS.office.hd> <1971FF81B8E01C45991F6F92B9E3B2508903B5EB@EX10-MB2-MAD.hi.inet> Message-ID: <8755F290097BD941865DC4245B335D2D38F53980@DAPHNIS.office.hd> Hi Carlos, Thanks for your answer. My concern is that some efforts regarding the formatting of the doc file will be lost if the deliverable is generated again from the wiki. I received for example some comments regarding the size of figures. Best Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Dienstag, 9. April 2013 16:25 To: Tobias Jacobs; t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Tobias, Thanks to raise this point, because it is really quite important and will be part of the agenda in our conf call tomorrow. Actually the case of IoT chapter is a bit special because we are doing deep changes in the Architecture WIKi docs. In the docs we have just applied changes from the peer-reviews and in the Wiki we need to perform all changes => peer-reviews + what we agreed in the F2F meeting. The consequence is that we need to do the changes before Thu 11 EoB in both places (but in the docs only the peer-review comments while in the Wiki all them). Docs will be sent to peer-reviewers because they have a period of time to claim if feedback was actually done. However, I will use the Wiki to generate the docs that we will finally deliver so this is the material that we will deliver to the EC in the end (and thus all changes need to be applied there). Thanks for your understanding. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 09:45 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, all, As far as I understand, the changed doc is what will be submitted as deliverable, right? Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Montag, 8. April 2013 18:30 To: t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Both. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 8 de abril de 2013 18:17 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hello Carlos, Do we make the changes in the wiki or the docx? Best regards, Tarek From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 08 April 2013 14:11 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From ralli at tid.es Tue Apr 9 17:45:50 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 09 Apr 2013 15:45:50 +0000 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) In-Reply-To: <8755F290097BD941865DC4245B335D2D38F53980@DAPHNIS.office.hd> Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508903B86B@EX10-MB2-MAD.hi.inet> Hi Tob?as, I understand your concerns. The best procedure for that is the following: 1) Correct the image size in the .docx files as indicated in the peer-review. 2) In the wiki you can play with the size of the image in a very easy manner so the image will be always generated with the right size (and not only this time). Let mw show you an existing example in the Wiki: - URL: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/TID - If you check the source code, you will see how we scale the image to the right size without changing the image source file: [[File:Telefonica-i+d-Logo.jpg|200px]] If you go this way, you're gonna be free in the future from correcting the image size in every .docx generated file :-) Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 17:28 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, Thanks for your answer. My concern is that some efforts regarding the formatting of the doc file will be lost if the deliverable is generated again from the wiki. I received for example some comments regarding the size of figures. Best Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Dienstag, 9. April 2013 16:25 To: Tobias Jacobs; t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Tobias, Thanks to raise this point, because it is really quite important and will be part of the agenda in our conf call tomorrow. Actually the case of IoT chapter is a bit special because we are doing deep changes in the Architecture WIKi docs. In the docs we have just applied changes from the peer-reviews and in the Wiki we need to perform all changes => peer-reviews + what we agreed in the F2F meeting. The consequence is that we need to do the changes before Thu 11 EoB in both places (but in the docs only the peer-review comments while in the Wiki all them). Docs will be sent to peer-reviewers because they have a period of time to claim if feedback was actually done. However, I will use the Wiki to generate the docs that we will finally deliver so this is the material that we will deliver to the EC in the end (and thus all changes need to be applied there). Thanks for your understanding. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 09:45 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, all, As far as I understand, the changed doc is what will be submitted as deliverable, right? Best Tobias From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Montag, 8. April 2013 18:30 To: t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Both. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 8 de abril de 2013 18:17 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hello Carlos, Do we make the changes in the wiki or the docx? Best regards, Tarek From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 08 April 2013 14:11 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From raihan.ul-islam at neclab.eu Wed Apr 10 09:59:23 2013 From: raihan.ul-islam at neclab.eu (Raihan Ul-Islam) Date: Wed, 10 Apr 2013 07:59:23 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <515EDA46.6060801@tid.es> References: <515EDA46.6060801@tid.es> Message-ID: 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 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; 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] 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 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 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: -------------- 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: From ralli at tid.es Wed Apr 10 10:03:51 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 10 Apr 2013 08:03:51 +0000 Subject: [Fiware-iot] GoogleDoc & Agenda for our meeting tomorrow at 10h In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B2508903B5EB@EX10-MB2-MAD.hi.inet> Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508903C1F1@EX10-MB2-MAD.hi.inet> Dear Colleagues, Find here below the link to the Googledoc that we will be using tomorrow. I have included 3 points that I consider relevant for tomorrow, but you may add suggestions at the end (AoB): 1) Status of implementation of changes in the Architecture: 2) Links to the Manuals (Installation, User, unit-tests for R2). 3) Status of implementation of changes in the Architecture: You can add yourself in the attendees list and also complete in advance the roundtables of Agenda items (1) and (2) as I did. Thierry, feel free to modify it today if I am forgetting some priority. Fraunhofer was also to join this time, right? I have set an slot in the end (3, 15min). Maybe they may just join then, as you/they prefer. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From ralli at tid.es Wed Apr 10 10:05:18 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 10 Apr 2013 08:05:18 +0000 Subject: [Fiware-iot] GoogleDoc & Agenda for our meeting tomorrow at 10h In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B2508903C1F1@EX10-MB2-MAD.hi.inet> Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508903C221@EX10-MB2-MAD.hi.inet> https://docs.google.com/document/d/14R1Fc8OJlnxFhty3rZZIlTKfsqCsTfK2_wfQGNquZYM/edit -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Carlos Ralli Ucendo > Fecha: mi?rcoles, 10 de abril de 2013 10:03 Para: "fiware-iot at lists.fi-ware.eu" > Asunto: [Fiware-iot] GoogleDoc & Agenda for our meeting tomorrow at 10h Dear Colleagues, Find here below the link to the Googledoc that we will be using tomorrow. I have included 3 points that I consider relevant for tomorrow, but you may add suggestions at the end (AoB): 1) Status of implementation of changes in the Architecture: 2) Links to the Manuals (Installation, User, unit-tests for R2). 3) Status of implementation of changes in the Architecture: You can add yourself in the attendees list and also complete in advance the roundtables of Agenda items (1) and (2) as I did. Thierry, feel free to modify it today if I am forgetting some priority. Fraunhofer was also to join this time, right? I have set an slot in the end (3, 15min). Maybe they may just join then, as you/they prefer. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From thierry.nagellen at orange.com Wed Apr 10 10:32:52 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 10 Apr 2013 08:32:52 +0000 Subject: [Fiware-iot] Cross chapter architecture picture Message-ID: <2573_1365582772_516523B4_2573_819_1_976A65C5A08ADF49B9A8523F7F81925C0CEAA5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi all Just for your information here is the last high level picture we have drawn to show the whole Fi-Ware architecture. We have decided not to put the links between the different GEs to avoid a very messy picture. This picture will also be part of the final architecture deliverable and we have aligned IoT part with what we discussed in F2F meeting in Paris. BR Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: fiware-cross-chapter_v6.graphml Type: application/octet-stream Size: 78715 bytes Desc: fiware-cross-chapter_v6.graphml URL: From Tobias.Jacobs at neclab.eu Wed Apr 10 11:02:47 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Wed, 10 Apr 2013 09:02:47 +0000 Subject: [Fiware-iot] Cross chapter architecture picture In-Reply-To: <2573_1365582772_516523B4_2573_819_1_976A65C5A08ADF49B9A8523F7F81925C0CEAA5@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <2573_1365582772_516523B4_2573_819_1_976A65C5A08ADF49B9A8523F7F81925C0CEAA5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <8755F290097BD941865DC4245B335D2D38F54A7D@DAPHNIS.office.hd> Hi Thierry, Thanks for the picture. It feels good to have an overall picture :) One minor point: Can the GEs in the IoT Box be vertically reordered such that pairs of corresponding GEs in Gateway and Backend are on the same level? Such pairs are Security B and GW Adv. Connectivity B and GW IoT Broker and Data Handling Device Management B and GW ConfMan and Protocol Adapter are not corresponding but are the only ones that have no obvious counterpart. Thanks! Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of thierry.nagellen at orange.com Sent: Mittwoch, 10. April 2013 10:33 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Cross chapter architecture picture Hi all Just for your information here is the last high level picture we have drawn to show the whole Fi-Ware architecture. We have decided not to put the links between the different GEs to avoid a very messy picture. This picture will also be part of the final architecture deliverable and we have aligned IoT part with what we discussed in F2F meeting in Paris. BR Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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: From thierry.nagellen at orange.com Wed Apr 10 11:05:18 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 10 Apr 2013 09:05:18 +0000 Subject: [Fiware-iot] Cross chapter architecture picture In-Reply-To: <8755F290097BD941865DC4245B335D2D38F54A7D@DAPHNIS.office.hd> References: <2573_1365582772_516523B4_2573_819_1_976A65C5A08ADF49B9A8523F7F81925C0CEAA5@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8755F290097BD941865DC4245B335D2D38F54A7D@DAPHNIS.office.hd> Message-ID: <3973_1365584719_51652B4F_3973_3824_1_976A65C5A08ADF49B9A8523F7F81925C0CEACC@PEXCVZYM13.corporate.adroot.infra.ftgroup> I will check with Thorsten if it is possible (not too late regarding his deadlines) BR Thierry De : Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] Envoy? : mercredi 10 avril 2013 11:03 ? : NAGELLEN Thierry OLNC/OLPS; fiware-iot at lists.fi-ware.eu Objet : RE: Cross chapter architecture picture Hi Thierry, Thanks for the picture. It feels good to have an overall picture :) One minor point: Can the GEs in the IoT Box be vertically reordered such that pairs of corresponding GEs in Gateway and Backend are on the same level? Such pairs are Security B and GW Adv. Connectivity B and GW IoT Broker and Data Handling Device Management B and GW ConfMan and Protocol Adapter are not corresponding but are the only ones that have no obvious counterpart. Thanks! Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of thierry.nagellen at orange.com Sent: Mittwoch, 10. April 2013 10:33 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Cross chapter architecture picture Hi all Just for your information here is the last high level picture we have drawn to show the whole Fi-Ware architecture. We have decided not to put the links between the different GEs to avoid a very messy picture. This picture will also be part of the final architecture deliverable and we have aligned IoT part with what we discussed in F2F meeting in Paris. BR Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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: From ralli at tid.es Wed Apr 10 15:31:49 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 10 Apr 2013 13:31:49 +0000 Subject: [Fiware-iot] UoSurrey Manuals in the Wiki In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA5BC16AE47@EXMB05CMS.surrey.ac.uk> Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508903DAC0@EX10-MB2-MAD.hi.inet> Hi Tarek, After reviewing the pages where R2 manuals are linked I found all yours (for "IoT Discovery Engine") actually point to empty documents. I am fine with it, as long as that is exactly what you wanted to do, and it is not that you made a mistake when editing those links. However, I have updated your "empty pages" with the same clarifying note we are using within IoT for that event. Find it, for example, for the installation manual at: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FI-WARE_Deliverable_%22D3-8.3.2_FIWARE_Installation_and_Administration_Guide%22_WP5_IoT_Contribution Additionally, your GE is mentioned in the "Important notes for traceability" in those 3 pages at the bottom. Should you have any comment on that, let me know. Best Regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 18 de marzo de 2013 20:04 Para: "fiware-iot at lists.fi-ware.eu" > Asunto: [Fiware-iot] on leave Hello, This is to inform that I will be away until the 4th of April. I will have limited access to my email, but will try my best to reply as soon as I can. Best regards, Tarek From: thierry.nagellen at orange.com [mailto:thierry.nagellen at orange.com] Sent: 18 March 2013 10:32 To: Elsaleh T Mr (Electronic Eng) Cc: fiware-iot at lists.fi-ware.eu Subject: RE: [Fiware-iot] Peer review: some docs are missing Hi Tarek Thanks. Everything is up to date on the cockpit. BR Thierry De :t.elsaleh at surrey.ac.uk [mailto:t.elsaleh at surrey.ac.uk] Envoy? : lundi 18 mars 2013 11:22 ? : NAGELLEN Thierry OLNC/OLPS Cc : fiware-iot at lists.fi-ware.eu Objet : RE: [Fiware-iot] Peer review: some docs are missing Hello Thierry, Sorry for the delay. Here you go. Best regards, Tarek From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of thierry.nagellen at orange.com Sent: 18 March 2013 09:38 To: Guerra Sabrina Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Peer review: some docs are missing Thanks Sabrina. I?ve just added your contribution in the right folder and in the cockpit. BR Thierry De : Guerra Sabrina [mailto:sabrina.guerra at telecomitalia.it] Envoy? : lundi 18 mars 2013 10:28 ? : NAGELLEN Thierry OLNC/OLPS Cc : fiware-iot at lists.fi-ware.eu Objet : R: Peer review: some docs are missing Hi Thierry, I attached our contribution related to the Metadata Preprocessor GE. Best regards, Sabrina and Gian Piero Da:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di thierry.nagellen at orange.com Inviato: luned? 18 marzo 2013 10:18 A: fiware-iot at lists.fi-ware.eu Oggetto: [Fiware-iot] Peer review: some docs are missing Priorit?: Alta Hi All Thanks for your support for this peer rewiew of WP6. 2 contributions are missing (Metadata preprocessor - Telecom Italia & Semantic Application Support, Semantic Annotation ? UoSurrey) Could you urgently send me these 2 contributions? I?ve updated the cockpit with the other documents. BR Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. _________________________________________________________________________________________________________________________ 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. ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 677 bytes Desc: image001.gif URL: From fano.ramparany at orange.com Wed Apr 10 17:06:28 2013 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Wed, 10 Apr 2013 15:06:28 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: References: <515EDA46.6060801@tid.es> Message-ID: <26633_1365606390_51657FF5_26633_531_1_DC254E6D1212F24EAE0D7766A11FE2890A0155@PEXCVZYM12.corporate.adroot.infra.ftgroup> Hi Raihan, Fermin and all, One suggestion is to name associations. This is a common practice in object oriented modeling languages and in addition, makes it possible to search/filter objects according to the name of the association they are linked to (as start or end). Best, Fano De : fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] De la part de Raihan Ul-Islam Envoy? : mercredi 10 avril 2013 09:59 ? : Ferm?n Gal?n M?rquez Cc : fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-ngsi] how to represent associations 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 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; 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] 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 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 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 _________________________________________________________________________________________________________________________ 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: From fermin at tid.es Wed Apr 10 18:20:15 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Wed, 10 Apr 2013 18:20:15 +0200 Subject: [Fiware-iot] Cross chapter architecture picture In-Reply-To: <2573_1365582772_516523B4_2573_819_1_976A65C5A08ADF49B9A8523F7F81925C0CEAA5@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <2573_1365582772_516523B4_2573_819_1_976A65C5A08ADF49B9A8523F7F81925C0CEAA5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <5165913F.8080201@tid.es> Dear Thierry, Maybe a silly question but... :) What tool do you use to view .graphml files? I have tried with my browsrs (Internet Explorer, Firefox and Chrome), but it renders to XML, not to a picture... Maybe a PNG/PDF picture may help. Thanks in adavance! Best regards, ------ Ferm?n El 10/04/2013 10:32, thierry.nagellen at orange.com escribi?: Hi all Just for your information here is the last high level picture we have drawn to show the whole Fi-Ware architecture. We have decided not to put the links between the different GEs to avoid a very messy picture. This picture will also be part of the final architecture deliverable and we have aligned IoT part with what we discussed in F2F meeting in Paris. BR Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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. _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot ________________________________ 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: From thierry.nagellen at orange.com Thu Apr 11 08:40:17 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Thu, 11 Apr 2013 06:40:17 +0000 Subject: [Fiware-iot] Update the links on the wiki Message-ID: <18405_1365662418_51665AD2_18405_2791_1_976A65C5A08ADF49B9A8523F7F81925C0CEE2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Dear all, Please find here the status of links (provided by Miguel) we have on the wiki for docs for release R2.2. Some seems to be NOK. This is especially the case for Conf Man GE and Protocol Adapter. Could you please check them quickly (for EOB) because nothing will be published if the links are not OK. Thanks for your support. BR Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Link_Status - WP5.xlsx Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet Size: 11527 bytes Desc: Link_Status - WP5.xlsx URL: From thierry.nagellen at orange.com Thu Apr 11 08:44:46 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Thu, 11 Apr 2013 06:44:46 +0000 Subject: [Fiware-iot] Cross chapter architecture picture In-Reply-To: <5165913F.8080201@tid.es> References: <2573_1365582772_516523B4_2573_819_1_976A65C5A08ADF49B9A8523F7F81925C0CEAA5@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5165913F.8080201@tid.es> Message-ID: <18405_1365662687_51665BDF_18405_3108_1_976A65C5A08ADF49B9A8523F7F81925C0CEE43@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi Fermin, This is not a silly question, just something we have decided long time ago, before you have been involved... I cannot retrieve it on the forge and it is easier with google when you know the name of the tool. In fact we are using the Yed editor to manage graphml files. You can upload it in this place. http://www.yworks.com/en/products_yed_about.html BR Thierry De : fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de Ferm?n Gal?n M?rquez Envoy? : mercredi 10 avril 2013 18:20 ? : fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] Cross chapter architecture picture Dear Thierry, Maybe a silly question but... :) What tool do you use to view .graphml files? I have tried with my browsrs (Internet Explorer, Firefox and Chrome), but it renders to XML, not to a picture... Maybe a PNG/PDF picture may help. Thanks in adavance! Best regards, ------ Ferm?n El 10/04/2013 10:32, thierry.nagellen at orange.com escribi?: Hi all Just for your information here is the last high level picture we have drawn to show the whole Fi-Ware architecture. We have decided not to put the links between the different GEs to avoid a very messy picture. This picture will also be part of the final architecture deliverable and we have aligned IoT part with what we discussed in F2F meeting in Paris. BR Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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. _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot ________________________________ 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 _________________________________________________________________________________________________________________________ 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: From Tobias.Jacobs at neclab.eu Thu Apr 11 09:17:09 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Thu, 11 Apr 2013 07:17:09 +0000 Subject: [Fiware-iot] Cross chapter architecture picture In-Reply-To: <18405_1365662687_51665BDF_18405_3108_1_976A65C5A08ADF49B9A8523F7F81925C0CEE43@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <2573_1365582772_516523B4_2573_819_1_976A65C5A08ADF49B9A8523F7F81925C0CEAA5@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5165913F.8080201@tid.es> <18405_1365662687_51665BDF_18405_3108_1_976A65C5A08ADF49B9A8523F7F81925C0CEE43@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <8755F290097BD941865DC4245B335D2D38F621C8@DAPHNIS.office.hd> In addition you need to download the FMC stencils, you find the link+explanation in the FI-WARE wiki: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/How_to_install_FMC_stencils_in_yEd Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of thierry.nagellen at orange.com Sent: Donnerstag, 11. April 2013 08:45 To: Ferm?n Gal?n M?rquez; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Cross chapter architecture picture Hi Fermin, This is not a silly question, just something we have decided long time ago, before you have been involved... I cannot retrieve it on the forge and it is easier with google when you know the name of the tool. In fact we are using the Yed editor to manage graphml files. You can upload it in this place. http://www.yworks.com/en/products_yed_about.html BR Thierry De : fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de Ferm?n Gal?n M?rquez Envoy? : mercredi 10 avril 2013 18:20 ? : fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] Cross chapter architecture picture Dear Thierry, Maybe a silly question but... :) What tool do you use to view .graphml files? I have tried with my browsrs (Internet Explorer, Firefox and Chrome), but it renders to XML, not to a picture... Maybe a PNG/PDF picture may help. Thanks in adavance! Best regards, ------ Ferm?n El 10/04/2013 10:32, thierry.nagellen at orange.com escribi?: Hi all Just for your information here is the last high level picture we have drawn to show the whole Fi-Ware architecture. We have decided not to put the links between the different GEs to avoid a very messy picture. This picture will also be part of the final architecture deliverable and we have aligned IoT part with what we discussed in F2F meeting in Paris. BR Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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. _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot ________________________________ 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 _________________________________________________________________________________________________________________________ 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: From raihan.ul-islam at neclab.eu Thu Apr 11 10:54:58 2013 From: raihan.ul-islam at neclab.eu (Raihan Ul-Islam) Date: Thu, 11 Apr 2013 08:54:58 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <26633_1365606390_51657FF5_26633_531_1_DC254E6D1212F24EAE0D7766A11FE2890A0155@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <515EDA46.6060801@tid.es> <26633_1365606390_51657FF5_26633_531_1_DC254E6D1212F24EAE0D7766A11FE2890A0155@PEXCVZYM12.corporate.adroot.infra.ftgroup> Message-ID: Hi Fano, There is already a name for the association. In the example, under contextMetadata element the name element contains the name of the associations. There is also RegistrationId for each registration. The registerContext operation allows for updating the association. I hope that explains your suggestion. In the current context additional operations for searching/filter object based on associations seems not necessary. Thanks Raihan From: fano.ramparany at orange.com [mailto:fano.ramparany at orange.com] Sent: 10 April 2013 17:06 To: Raihan Ul-Islam; Ferm?n Gal?n M?rquez Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: RE: [Fiware-ngsi] how to represent associations Hi Raihan, Fermin and all, One suggestion is to name associations. This is a common practice in object oriented modeling languages and in addition, makes it possible to search/filter objects according to the name of the association they are linked to (as start or end). Best, Fano De : fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] De la part de Raihan Ul-Islam Envoy? : mercredi 10 avril 2013 09:59 ? : Ferm?n Gal?n M?rquez Cc : fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-ngsi] how to represent associations 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 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; 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] 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 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 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 _________________________________________________________________________________________________________________________ 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: From Tobias.Jacobs at neclab.eu Thu Apr 11 11:36:14 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Thu, 11 Apr 2013 09:36:14 +0000 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B2508903B86B@EX10-MB2-MAD.hi.inet> References: <8755F290097BD941865DC4245B335D2D38F53980@DAPHNIS.office.hd> <1971FF81B8E01C45991F6F92B9E3B2508903B86B@EX10-MB2-MAD.hi.inet> Message-ID: <8755F290097BD941865DC4245B335D2D38F6227F@DAPHNIS.office.hd> Dear Carlos, Probably this was not the right place to upload the revised IoT Broker Description doc, but anyway here is the link: https://forge.fi-ware.eu/docman/view.php/11/2089/D232_WP5_Backend_IoT_Broker_ImplementedReviewComments_NEC_20130411.docx I will notify you as soon as we have updated the wiki as well. Best Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Dienstag, 9. April 2013 17:46 To: Tobias Jacobs; t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Tob?as, I understand your concerns. The best procedure for that is the following: 1) Correct the image size in the .docx files as indicated in the peer-review. 2) In the wiki you can play with the size of the image in a very easy manner so the image will be always generated with the right size (and not only this time). Let mw show you an existing example in the Wiki: - URL: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/TID - If you check the source code, you will see how we scale the image to the right size without changing the image source file: [[File:Telefonica-i+d-Logo.jpg|200px]] If you go this way, you're gonna be free in the future from correcting the image size in every .docx generated file :-) Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 17:28 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, Thanks for your answer. My concern is that some efforts regarding the formatting of the doc file will be lost if the deliverable is generated again from the wiki. I received for example some comments regarding the size of figures. Best Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Dienstag, 9. April 2013 16:25 To: Tobias Jacobs; t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Tobias, Thanks to raise this point, because it is really quite important and will be part of the agenda in our conf call tomorrow. Actually the case of IoT chapter is a bit special because we are doing deep changes in the Architecture WIKi docs. In the docs we have just applied changes from the peer-reviews and in the Wiki we need to perform all changes => peer-reviews + what we agreed in the F2F meeting. The consequence is that we need to do the changes before Thu 11 EoB in both places (but in the docs only the peer-review comments while in the Wiki all them). Docs will be sent to peer-reviewers because they have a period of time to claim if feedback was actually done. However, I will use the Wiki to generate the docs that we will finally deliver so this is the material that we will deliver to the EC in the end (and thus all changes need to be applied there). Thanks for your understanding. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 09:45 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, all, As far as I understand, the changed doc is what will be submitted as deliverable, right? Best Tobias From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Montag, 8. April 2013 18:30 To: t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Both. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 8 de abril de 2013 18:17 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hello Carlos, Do we make the changes in the wiki or the docx? Best regards, Tarek From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 08 April 2013 14:11 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From Tobias.Jacobs at neclab.eu Thu Apr 11 13:36:00 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Thu, 11 Apr 2013 11:36:00 +0000 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) References: <8755F290097BD941865DC4245B335D2D38F53980@DAPHNIS.office.hd> <1971FF81B8E01C45991F6F92B9E3B2508903B86B@EX10-MB2-MAD.hi.inet> Message-ID: <8755F290097BD941865DC4245B335D2D38F62303@DAPHNIS.office.hd> Done in the public wiki: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.IoT.Backend.IoTBroker Best Tobias From: Tobias Jacobs Sent: Donnerstag, 11. April 2013 11:36 To: 'CARLOS RALLI UCENDO' Cc: fiware-iot at lists.fi-ware.eu Subject: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Carlos, Probably this was not the right place to upload the revised IoT Broker Description doc, but anyway here is the link: https://forge.fi-ware.eu/docman/view.php/11/2089/D232_WP5_Backend_IoT_Broker_ImplementedReviewComments_NEC_20130411.docx I will notify you as soon as we have updated the wiki as well. Best Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Dienstag, 9. April 2013 17:46 To: Tobias Jacobs; t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Tob?as, I understand your concerns. The best procedure for that is the following: 1) Correct the image size in the .docx files as indicated in the peer-review. 2) In the wiki you can play with the size of the image in a very easy manner so the image will be always generated with the right size (and not only this time). Let mw show you an existing example in the Wiki: - URL: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/TID - If you check the source code, you will see how we scale the image to the right size without changing the image source file: [[File:Telefonica-i+d-Logo.jpg|200px]] If you go this way, you're gonna be free in the future from correcting the image size in every .docx generated file :-) Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 17:28 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, Thanks for your answer. My concern is that some efforts regarding the formatting of the doc file will be lost if the deliverable is generated again from the wiki. I received for example some comments regarding the size of figures. Best Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Dienstag, 9. April 2013 16:25 To: Tobias Jacobs; t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Tobias, Thanks to raise this point, because it is really quite important and will be part of the agenda in our conf call tomorrow. Actually the case of IoT chapter is a bit special because we are doing deep changes in the Architecture WIKi docs. In the docs we have just applied changes from the peer-reviews and in the Wiki we need to perform all changes => peer-reviews + what we agreed in the F2F meeting. The consequence is that we need to do the changes before Thu 11 EoB in both places (but in the docs only the peer-review comments while in the Wiki all them). Docs will be sent to peer-reviewers because they have a period of time to claim if feedback was actually done. However, I will use the Wiki to generate the docs that we will finally deliver so this is the material that we will deliver to the EC in the end (and thus all changes need to be applied there). Thanks for your understanding. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 09:45 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, all, As far as I understand, the changed doc is what will be submitted as deliverable, right? Best Tobias From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Montag, 8. April 2013 18:30 To: t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Both. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 8 de abril de 2013 18:17 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hello Carlos, Do we make the changes in the wiki or the docx? Best regards, Tarek From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 08 April 2013 14:11 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From laurent.artusio at orange.com Thu Apr 11 16:30:09 2013 From: laurent.artusio at orange.com (laurent.artusio at orange.com) Date: Thu, 11 Apr 2013 14:30:09 +0000 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) In-Reply-To: <8755F290097BD941865DC4245B335D2D38F62303@DAPHNIS.office.hd> References: <8755F290097BD941865DC4245B335D2D38F53980@DAPHNIS.office.hd> <1971FF81B8E01C45991F6F92B9E3B2508903B86B@EX10-MB2-MAD.hi.inet> <8755F290097BD941865DC4245B335D2D38F62303@DAPHNIS.office.hd> Message-ID: <11873_1365690609_5166C8F1_11873_159_1_ADCB0720D5A0114384E4F982EFCDBAA905E964@PEXCVZYM12.corporate.adroot.infra.ftgroup> Hi Carlos, Here is the link for the revised word document : https://forge.fi-ware.eu/docman/view.php/27/2084/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Both private and public wiki are up to date with the word document, accordingly with the common restructuration work that we achieved with Maarten. BR, Laurent De : fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de Tobias Jacobs Envoy? : jeudi 11 avril 2013 13:36 ? : CARLOS RALLI UCENDO Cc : fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Done in the public wiki: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.IoT.Backend.IoTBroker Best Tobias From: Tobias Jacobs Sent: Donnerstag, 11. April 2013 11:36 To: 'CARLOS RALLI UCENDO' Cc: fiware-iot at lists.fi-ware.eu Subject: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Carlos, Probably this was not the right place to upload the revised IoT Broker Description doc, but anyway here is the link: https://forge.fi-ware.eu/docman/view.php/11/2089/D232_WP5_Backend_IoT_Broker_ImplementedReviewComments_NEC_20130411.docx I will notify you as soon as we have updated the wiki as well. Best Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Dienstag, 9. April 2013 17:46 To: Tobias Jacobs; t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Tob?as, I understand your concerns. The best procedure for that is the following: 1) Correct the image size in the .docx files as indicated in the peer-review. 2) In the wiki you can play with the size of the image in a very easy manner so the image will be always generated with the right size (and not only this time). Let mw show you an existing example in the Wiki: - URL: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/TID - If you check the source code, you will see how we scale the image to the right size without changing the image source file: [[File:Telefonica-i+d-Logo.jpg|200px]] If you go this way, you're gonna be free in the future from correcting the image size in every .docx generated file :-) Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 17:28 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, Thanks for your answer. My concern is that some efforts regarding the formatting of the doc file will be lost if the deliverable is generated again from the wiki. I received for example some comments regarding the size of figures. Best Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Dienstag, 9. April 2013 16:25 To: Tobias Jacobs; t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Tobias, Thanks to raise this point, because it is really quite important and will be part of the agenda in our conf call tomorrow. Actually the case of IoT chapter is a bit special because we are doing deep changes in the Architecture WIKi docs. In the docs we have just applied changes from the peer-reviews and in the Wiki we need to perform all changes => peer-reviews + what we agreed in the F2F meeting. The consequence is that we need to do the changes before Thu 11 EoB in both places (but in the docs only the peer-review comments while in the Wiki all them). Docs will be sent to peer-reviewers because they have a period of time to claim if feedback was actually done. However, I will use the Wiki to generate the docs that we will finally deliver so this is the material that we will deliver to the EC in the end (and thus all changes need to be applied there). Thanks for your understanding. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 09:45 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, all, As far as I understand, the changed doc is what will be submitted as deliverable, right? Best Tobias From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Montag, 8. April 2013 18:30 To: t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Both. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 8 de abril de 2013 18:17 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hello Carlos, Do we make the changes in the wiki or the docx? Best regards, Tarek From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 08 April 2013 14:11 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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 _________________________________________________________________________________________________________________________ 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: From sabrina.guerra at telecomitalia.it Thu Apr 11 17:48:02 2013 From: sabrina.guerra at telecomitalia.it (Guerra Sabrina) Date: Thu, 11 Apr 2013 17:48:02 +0200 Subject: [Fiware-iot] R: Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) In-Reply-To: <11873_1365690609_5166C8F1_11873_159_1_ADCB0720D5A0114384E4F982EFCDBAA905E964@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <8755F290097BD941865DC4245B335D2D38F53980@DAPHNIS.office.hd> <1971FF81B8E01C45991F6F92B9E3B2508903B86B@EX10-MB2-MAD.hi.inet> <8755F290097BD941865DC4245B335D2D38F62303@DAPHNIS.office.hd> <11873_1365690609_5166C8F1_11873_159_1_ADCB0720D5A0114384E4F982EFCDBAA905E964@PEXCVZYM12.corporate.adroot.infra.ftgroup> Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5AE3E4F09@GRFMBX702BA020.griffon.local> Hi Carlos, In the FI-WARE IoT doc manager in the Peer-Reviews folder I don't see the other partners documents so I send directly the peer-review document to you. We don't agree with some comments so in this doc there are both these comments and our asnwers. Please, let me know if it is OK. By the way the private wiki is up to date with this peer-review document. Best regards, Sabrina Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000003 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: D232_WP5_v1_revised_TI_GatewayProtocolAdapter.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 347653 bytes Desc: D232_WP5_v1_revised_TI_GatewayProtocolAdapter.docx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: From t.elsaleh at surrey.ac.uk Thu Apr 11 18:27:30 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Thu, 11 Apr 2013 17:27:30 +0100 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B25089038280@EX10-MB2-MAD.hi.inet> References: <1971FF81B8E01C45991F6F92B9E3B25089038280@EX10-MB2-MAD.hi.inet> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789B68994@EXMB05CMS.surrey.ac.uk> Hello Carlos, Attached is the revised architecture document for the IoT Discovery Engine GE. Best regards, Tarek From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 08 April 2013 14:11 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: D232_WP5_IoT_Generated_2013-04-01_ATOS--UNIS_Revised_11-04-13.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 1513927 bytes Desc: D232_WP5_IoT_Generated_2013-04-01_ATOS--UNIS_Revised_11-04-13.docx URL: From fermin at tid.es Fri Apr 12 16:29:35 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Fri, 12 Apr 2013 16:29:35 +0200 Subject: [Fiware-iot] Associations in Release 2.3 of ConfMan GE In-Reply-To: <8755F290097BD941865DC4245B335D2D38F52326@DAPHNIS.office.hd> References: <8755F290097BD941865DC4245B335D2D38F52326@DAPHNIS.office.hd> Message-ID: <51681A4F.2030003@tid.es> Dear Tobias, We have been discussing internally this issue and we (TID) agree in changing the existing Technical Roadmap (table) of Configuration Manager GE to include the support of associations for R2.3. As a consequence, some of the Features in the existing R2.3 will be deferred for the future. We will change Technical Roadmap (table) of Configuration Manager GE in the FIWARE public wiki in the next days accordingly. Is this sense, is there any feature page or trac item for thing-device associations? In positive case, could you provide the URLs, please? We think that NEC proposal to accomplish this is ok in general, although some details needs to be polished yet. We can continue the discussion of these technical details in the NGSI mailing list. Best regards, ------ Ferm?n El 08/04/2013 11:34, Tobias Jacobs escribi?: Dear Colleagues from TID, Could you provide us some information related to your current plans related to the releases of the Configuration Management GE? 1) We understand that the next release of the ConfMan GE will be 2.3. How does this match with the integration plans that were discussed in the F2F meeting? We planned the integration of the WP5 components, but without the ConfMan GE no integration will be able to work. 2) In the technical roadmap (https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Roadmap_of_Internet_of_Things_%28IoT%29_Services), there is a slight mismatch between the features list in the table and what is described in the bullet points when it comes to association support. We are concerned that there is no feature in the table on association support of the ConfMan GE. As the discussions with Juanjo last year have shown, the ability of translating between device-level and thing-level information is one of the essential abilities of the IoT Backend. The support of associations by ConfMan GE is an essential prerequisite for it. We can also discuss this point in the phone conference this week. Thanks and best regards Ernoe, Martin, Raihan, Salvatore, and 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: From Tobias.Jacobs at neclab.eu Fri Apr 12 17:17:34 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Fri, 12 Apr 2013 15:17:34 +0000 Subject: [Fiware-iot] Associations in Release 2.3 of ConfMan GE In-Reply-To: <51681A4F.2030003@tid.es> References: <8755F290097BD941865DC4245B335D2D38F52326@DAPHNIS.office.hd> <51681A4F.2030003@tid.es> Message-ID: <8755F290097BD941865DC4245B335D2D38F6351B@DAPHNIS.office.hd> Dear Fermin, all, Thanks a lot for you answer. We are very glad about your decision and we are looking forward to have a working IoT Backend with association support. We just have an association epic defined for the IoT Broker https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.Epic.IoT.Backend.IoTBroker.Associations. Best Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Freitag, 12. April 2013 16:30 To: Tobias Jacobs Cc: Juanjo Hierro; KEN GUNNAR ZANGELIN (kzangeli at tid.es); CARLOS RALLI UCENDO (ralli at tid.es); fiware-iot at lists.fi-ware.eu; Martin Bauer; Salvatore Longo; Raihan Ul-Islam; thierry.nagellen at orange.com Subject: Re: Associations in Release 2.3 of ConfMan GE Dear Tobias, We have been discussing internally this issue and we (TID) agree in changing the existing Technical Roadmap (table) of Configuration Manager GE to include the support of associations for R2.3. As a consequence, some of the Features in the existing R2.3 will be deferred for the future. We will change Technical Roadmap (table) of Configuration Manager GE in the FIWARE public wiki in the next days accordingly. Is this sense, is there any feature page or trac item for thing-device associations? In positive case, could you provide the URLs, please? We think that NEC proposal to accomplish this is ok in general, although some details needs to be polished yet. We can continue the discussion of these technical details in the NGSI mailing list. Best regards, ------ Ferm?n El 08/04/2013 11:34, Tobias Jacobs escribi?: Dear Colleagues from TID, Could you provide us some information related to your current plans related to the releases of the Configuration Management GE? 1) We understand that the next release of the ConfMan GE will be 2.3. How does this match with the integration plans that were discussed in the F2F meeting? We planned the integration of the WP5 components, but without the ConfMan GE no integration will be able to work. 2) In the technical roadmap (https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Roadmap_of_Internet_of_Things_%28IoT%29_Services), there is a slight mismatch between the features list in the table and what is described in the bullet points when it comes to association support. We are concerned that there is no feature in the table on association support of the ConfMan GE. As the discussions with Juanjo last year have shown, the ability of translating between device-level and thing-level information is one of the essential abilities of the IoT Backend. The support of associations by ConfMan GE is an essential prerequisite for it. We can also discuss this point in the phone conference this week. Thanks and best regards Ernoe, Martin, Raihan, Salvatore, and 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: From ralli at tid.es Sun Apr 14 23:23:53 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Sun, 14 Apr 2013 21:23:53 +0000 Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) In-Reply-To: <8755F290097BD941865DC4245B335D2D38F6227F@DAPHNIS.office.hd> Message-ID: <1971FF81B8E01C45991F6F92B9E3B250890426D3@EX10-MB2-MAD.hi.inet> Thanks, I put it to the right place: https://forge.fi-ware.eu/docman/view.php/27/2096/D232_WP5_Backend_IoT_Broker_ImplementedReviewComments_NEC_20130411.docx BR -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: jueves, 11 de abril de 2013 11:36 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Carlos, Probably this was not the right place to upload the revised IoT Broker Description doc, but anyway here is the link: https://forge.fi-ware.eu/docman/view.php/11/2089/D232_WP5_Backend_IoT_Broker_ImplementedReviewComments_NEC_20130411.docx I will notify you as soon as we have updated the wiki as well. Best Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Dienstag, 9. April 2013 17:46 To: Tobias Jacobs; t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Tob?as, I understand your concerns. The best procedure for that is the following: 1) Correct the image size in the .docx files as indicated in the peer-review. 2) In the wiki you can play with the size of the image in a very easy manner so the image will be always generated with the right size (and not only this time). Let mw show you an existing example in the Wiki: - URL: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/TID - If you check the source code, you will see how we scale the image to the right size without changing the image source file: [[File:Telefonica-i+d-Logo.jpg|200px]] If you go this way, you're gonna be free in the future from correcting the image size in every .docx generated file :-) Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 17:28 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, Thanks for your answer. My concern is that some efforts regarding the formatting of the doc file will be lost if the deliverable is generated again from the wiki. I received for example some comments regarding the size of figures. Best Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Dienstag, 9. April 2013 16:25 To: Tobias Jacobs; t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Tobias, Thanks to raise this point, because it is really quite important and will be part of the agenda in our conf call tomorrow. Actually the case of IoT chapter is a bit special because we are doing deep changes in the Architecture WIKi docs. In the docs we have just applied changes from the peer-reviews and in the Wiki we need to perform all changes => peer-reviews + what we agreed in the F2F meeting. The consequence is that we need to do the changes before Thu 11 EoB in both places (but in the docs only the peer-review comments while in the Wiki all them). Docs will be sent to peer-reviewers because they have a period of time to claim if feedback was actually done. However, I will use the Wiki to generate the docs that we will finally deliver so this is the material that we will deliver to the EC in the end (and thus all changes need to be applied there). Thanks for your understanding. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: martes, 9 de abril de 2013 09:45 Para: Carlos Ralli Ucendo >, "t.elsaleh at surrey.ac.uk" > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hi Carlos, all, As far as I understand, the changed doc is what will be submitted as deliverable, right? Best Tobias From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Montag, 8. April 2013 18:30 To: t.elsaleh at surrey.ac.uk Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Both. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 8 de abril de 2013 18:17 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Hello Carlos, Do we make the changes in the wiki or the docx? Best regards, Tarek From:fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 08 April 2013 14:11 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Time to implement changes regarding Peer-review #2 (Deadline Thu 11th EoB) Dear Colleagues, 2nd Peer-review has concluded and now it is our task to perform the changes you agree with plus previous pending changes (perhaps from peer-review#1 and from our F2F meeting). You can find 2nd peer-review comments in a separate per-GE .docx linked in the cockpit at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Please, remember deadline is next Thu 11th EoB. For your convenience, find here below the links for IoT files with those comments: IoT Chapter Chapter page: https://forge.fi-ware.eu/docman/view.php/27/2061/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Backend IoT Broker GE https://forge.fi-ware.eu/docman/view.php/27/2060/D232_WP5_Backend_IoT_Broker_2013-04-02-sergg.docx Backend Configuration Manager GE https://forge.fi-ware.eu/docman/view.php/27/2064/D232_WP5_IoT_Generated_2013-04-01_Boris.docx Backend IoT Discovery Engine GE https://forge.fi-ware.eu/docman/view.php/27/2063/D232_WP5_IoT_Generated_2013-04-01_ATOS.docx Backend Security GE Backend Advanced Connectivity GE Backend Template Handler GE Gateway Device Management GE https://forge.fi-ware.eu/docman/view.php/27/2062/D232_WP5_IoT_Generated_2013-04-01___frb_review.docx Gateway Protocol Adapter GE https://forge.fi-ware.eu/docman/view.php/27/2070/D232_WP5_IoT_Generated_2013-04-01-Protocol-Adapter-Review.docx Gateway Advanced Connectivity GE Gateway Data Handling GE https://forge.fi-ware.eu/docman/view.php/27/2069/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx Gateway Security GE Thanks for your cooperation, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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 ________________________________ 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: From Tobias.Jacobs at neclab.eu Mon Apr 15 09:10:01 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Mon, 15 Apr 2013 07:10:01 +0000 Subject: [Fiware-iot] Overall IoT Architecture Message-ID: <8755F290097BD941865DC4245B335D2D38F64647@DAPHNIS.office.hd> Hi Carlos, Are there any updates on the overall IoT architecture document? Thanks and have a nice week! Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralli at tid.es Mon Apr 15 09:13:38 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 15 Apr 2013 07:13:38 +0000 Subject: [Fiware-iot] Overall IoT Architecture In-Reply-To: <8755F290097BD941865DC4245B335D2D38F64647@DAPHNIS.office.hd> References: <8755F290097BD941865DC4245B335D2D38F64647@DAPHNIS.office.hd> Message-ID: <9C253765-9D1D-48B5-B626-A970B42DED52@tid.es> I'm working this morning to transfer changes to the public wiki and let you know in the afternoon so you can check it. I did it in another place, that's it. BR El 15/04/2013, a las 09:10, "Tobias Jacobs" > escribi?: Hi Carlos, Are there any updates on the overall IoT architecture document? Thanks and have a nice week! 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: From ralli at tid.es Mon Apr 15 10:35:23 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 15 Apr 2013 08:35:23 +0000 Subject: [Fiware-iot] IoT Architecture Deliverable Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089043FB9@EX10-MB2-MAD.hi.inet> Hi Thierry, This e-mail is jut to sync on the status of IoT-archietcture deliverable as I am sure we will be prompted by Miguel in the WPl conf.call in some half an hour. - All IoT GEs have provided the reviewed .docx link and now it is just pending from my side to generate a consolidated doc and put the link in the G column of the cockpit. https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Just FYI, I include here all the links I compiled for all the GEs: That document will be sent today to peer-reviewers (1+2) so they can check if changes were applied. In the meanwhile I'll generate the whole doc again from the Wiki tomorrow EoB as I understand all changes have been applied in the Wiki too. - BE Dev Man https://forge.fi-ware.eu/docman/view.php/27/2098/D232_WP5_IoT_BEDevMan_2013-04-13_reviewed.docx - BE IoT Broker https://forge.fi-ware.eu/docman/view.php/27/2096/D232_WP5_Backend_IoT_Broker_ImplementedReviewComments_NEC_20130411.docx - BE Conf.Man https://forge.fi-ware.eu/docman/view.php/27/2099/D232_WP5_IoT_BEConfMan_2013-04-13.docx - BE Discovery https://forge.fi-ware.eu/docman/view.php/27/2097/D232_WP5_IoT_Generated_2013-04-01_ATOS--UNIS_Revised_11-04-13.docx - GW DATA HANDLING https://forge.fi-ware.eu/docman/view.php/27/2084/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx - GW Dev Man https://forge.fi-ware.eu/docman/view.php/27/2090/D232_WP5_IoT_Generated_2013-04-01___frb_review_RevisedCommentsOrange.docx - GE Protocol Adapter https://forge.fi-ware.eu/docman/view.php/27/2095/D232_WP5_v1_revised_TI_GatewayProtocolAdapter.docx BR. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From thierry.nagellen at orange.com Mon Apr 15 10:42:35 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Mon, 15 Apr 2013 08:42:35 +0000 Subject: [Fiware-iot] IoT Architecture Deliverable In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B25089043FB9@EX10-MB2-MAD.hi.inet> References: <1971FF81B8E01C45991F6F92B9E3B25089043FB9@EX10-MB2-MAD.hi.inet> Message-ID: <17235_1366015357_516BBD7D_17235_3680_1_976A65C5A08ADF49B9A8523F7F81925C0D08C1@PEXCVZYM13.corporate.adroot.infra.ftgroup> Thanks a lot Carlos I would also inform you that Laurent has found a way to retrieve an access to google docs so I can again reach the cockpit. BR Thierry De : CARLOS RALLI UCENDO [mailto:ralli at tid.es] Envoy? : lundi 15 avril 2013 10:35 ? : NAGELLEN Thierry OLNC/OLPS Cc : fiware-iot at lists.fi-ware.eu Objet : IoT Architecture Deliverable Hi Thierry, This e-mail is jut to sync on the status of IoT-archietcture deliverable as I am sure we will be prompted by Miguel in the WPl conf.call in some half an hour. - All IoT GEs have provided the reviewed .docx link and now it is just pending from my side to generate a consolidated doc and put the link in the G column of the cockpit. https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Just FYI, I include here all the links I compiled for all the GEs: That document will be sent today to peer-reviewers (1+2) so they can check if changes were applied. In the meanwhile I'll generate the whole doc again from the Wiki tomorrow EoB as I understand all changes have been applied in the Wiki too. - BE Dev Man https://forge.fi-ware.eu/docman/view.php/27/2098/D232_WP5_IoT_BEDevMan_2013-04-13_reviewed.docx - BE IoT Broker https://forge.fi-ware.eu/docman/view.php/27/2096/D232_WP5_Backend_IoT_Broker_ImplementedReviewComments_NEC_20130411.docx - BE Conf.Man https://forge.fi-ware.eu/docman/view.php/27/2099/D232_WP5_IoT_BEConfMan_2013-04-13.docx - BE Discovery https://forge.fi-ware.eu/docman/view.php/27/2097/D232_WP5_IoT_Generated_2013-04-01_ATOS--UNIS_Revised_11-04-13.docx - GW DATA HANDLING https://forge.fi-ware.eu/docman/view.php/27/2084/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx - GW Dev Man https://forge.fi-ware.eu/docman/view.php/27/2090/D232_WP5_IoT_Generated_2013-04-01___frb_review_RevisedCommentsOrange.docx - GE Protocol Adapter https://forge.fi-ware.eu/docman/view.php/27/2095/D232_WP5_v1_revised_TI_GatewayProtocolAdapter.docx BR. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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 _________________________________________________________________________________________________________________________ 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: From ralli at tid.es Mon Apr 15 11:39:16 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 15 Apr 2013 09:39:16 +0000 Subject: [Fiware-iot] IoT Architecture Deliverable In-Reply-To: <17235_1366015357_516BBD7D_17235_3680_1_976A65C5A08ADF49B9A8523F7F81925C0D08C1@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <1971FF81B8E01C45991F6F92B9E3B250890441B1@EX10-MB2-MAD.hi.inet> Thierry, All, I have added to the cockpit the link to the consolidated document (including all 2nd peer-reviews). It in in the Column G of IoT row. https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 In this case, IoT has been the very first one and addressing the deadline. Thanks to all of you! Ps. Thierry, excellent you've got back access to Googledocs :-) BR, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: "thierry.nagellen at orange.com" > Fecha: lunes, 15 de abril de 2013 10:42 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: RE: IoT Architecture Deliverable Thanks a lot Carlos I would also inform you that Laurent has found a way to retrieve an access to google docs so I can again reach the cockpit. BR Thierry De : CARLOS RALLI UCENDO [mailto:ralli at tid.es] Envoy? : lundi 15 avril 2013 10:35 ? : NAGELLEN Thierry OLNC/OLPS Cc : fiware-iot at lists.fi-ware.eu Objet : IoT Architecture Deliverable Hi Thierry, This e-mail is jut to sync on the status of IoT-archietcture deliverable as I am sure we will be prompted by Miguel in the WPl conf.call in some half an hour. - All IoT GEs have provided the reviewed .docx link and now it is just pending from my side to generate a consolidated doc and put the link in the G column of the cockpit. https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Just FYI, I include here all the links I compiled for all the GEs: That document will be sent today to peer-reviewers (1+2) so they can check if changes were applied. In the meanwhile I'll generate the whole doc again from the Wiki tomorrow EoB as I understand all changes have been applied in the Wiki too. - BE Dev Man https://forge.fi-ware.eu/docman/view.php/27/2098/D232_WP5_IoT_BEDevMan_2013-04-13_reviewed.docx - BE IoT Broker https://forge.fi-ware.eu/docman/view.php/27/2096/D232_WP5_Backend_IoT_Broker_ImplementedReviewComments_NEC_20130411.docx - BE Conf.Man https://forge.fi-ware.eu/docman/view.php/27/2099/D232_WP5_IoT_BEConfMan_2013-04-13.docx - BE Discovery https://forge.fi-ware.eu/docman/view.php/27/2097/D232_WP5_IoT_Generated_2013-04-01_ATOS--UNIS_Revised_11-04-13.docx - GW DATA HANDLING https://forge.fi-ware.eu/docman/view.php/27/2084/D232_WP5_IoT_Generated_2013-04-01_DataHandling_Review.docx - GW Dev Man https://forge.fi-ware.eu/docman/view.php/27/2090/D232_WP5_IoT_Generated_2013-04-01___frb_review_RevisedCommentsOrange.docx - GE Protocol Adapter https://forge.fi-ware.eu/docman/view.php/27/2095/D232_WP5_v1_revised_TI_GatewayProtocolAdapter.docx BR. -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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 _________________________________________________________________________________________________________________________ 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. ________________________________ 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: From ralli at tid.es Mon Apr 15 11:57:09 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 15 Apr 2013 09:57:09 +0000 Subject: [Fiware-iot] Answer regarding NGSI associations support of ConfMan, now included in the past conf.call minutes Message-ID: <1971FF81B8E01C45991F6F92B9E3B250890442E3@EX10-MB2-MAD.hi.inet> Dear Colleagues, In the last conf.call NEC rised a question regarding NGSI associations support in the BE Configuration Manager GE that was properly answered by Fermin and has been consolidated into an EPIC. For your convenience, I've just included this information in the minutes section 4 right after the AP assigned to me on this regard. The link to the minutes was: https://docs.google.com/document/d/14R1Fc8OJlnxFhty3rZZIlTKfsqCsTfK2_wfQGNquZYM/edit In the short future I hope to have some time to upload all googledocs to the Admin folder we created in the IoT docman. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From ralli at tid.es Mon Apr 15 16:38:16 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 15 Apr 2013 14:38:16 +0000 Subject: [Fiware-iot] Fi-WARE overall IoT Architecture updated Wiki-page (needs your review) Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089044C16@EX10-MB2-MAD.hi.inet> Dear colleagues, As previously discussed, and after completing the peer-reviews process as all other chapters, I'm now updating the overall IoT architecture Wiki-page. All changes are what we agreed in our F2F meeting, checked also with the project Chief architect (Juanjo) and they are described below. My idea is to consolidate them by the end of the week so they can be included in the deliverable to be sent to the EC (I agreed with my colleagues managing the whole deliverable edition how to do it in this timeframe). I'm doing this at this URL in the public Wiki where we can agree the final version this week and then copy&paste to the actual one: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture_NEW Obviously, the original one accessible to vey else is at: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture ***** Summary of changes: 1. Include in the introduction the two domains of GEs we are considering at IoT. Explain if they are mandatory/optional and how many can be deployed in a specific scenario. Explain behavior, the fact that some features are duplicated between both domains and thus providing optimization (traffic, time-response) and enabling services-at-the-edge. 2. Explain how apps developers will access to IoT GEs (i.e. Directly through our APIs and/or configuring connectivity to Data/Context PubSubCB) 3. In the "Nota Bene." remove "Iot Gateway" item as long as Backend is not described there too. 4. Update the overall architecture figure. The idea is to simplify it providing a similar one compared to other chapters. Also include all updates discussed in our recent F2F meeting in Paris. Important note from Carlos: I need to do and update the FMC diagram (I used the figure in my .ppt presented in Madrid April's Architects Week). I would appreciate if someone may help on this ? 5. Update the Gateway description in the architecture section. State it is an optional element in Fi-WARE IoT model. Important: the previous sentence " The IoT gateway will support all the IoT backend features, taking into consideration " is *NOT* true anymore, as long as we are defining for instance a direct interface from GW Protocol Adapter to GW Data Handling for highly constraint gateway devices. Therefore, now the sentence looks like: "The IoT gateway will not always support all the IoT backend features, taking into consideration?" 6. Update the interaction with the Security chapter to take into account the new FI-WARE security access model. 7. Update the Architecture Description (i.e. The GEs we propose, specify and develop) for both the Backend and the Gateway Domain. This is a key point as it is the main entry point where UCs will see that we have significantly changed our GEs structure. Similarly to the presentation I made in the architects week (where our PO was present) I included some traceability notes that I consider useful during this Fi-PPP Phase II (so no previous UC from Phase I can complain that something disappeared or changed and they got lost). I will propose this mail as a point in the agenda of our next conf.call. Thanks for reading it in advance so we can have a useful discussion then. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From fermin at tid.es Mon Apr 15 18:13:21 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Mon, 15 Apr 2013 18:13:21 +0200 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: References: <515EDA46.6060801@tid.es> Message-ID: <516C2721.9060604@tid.es> 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 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? * I understand that the default scope (the one that a NGSI9 server instance will use if no is included in the ) 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? * 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) * I think a similar problem happens in update case. 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) 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 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; 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] 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 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fermin at tid.es Tue Apr 16 11:43:44 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Tue, 16 Apr 2013 11:43:44 +0200 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <516C2721.9060604@tid.es> References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> Message-ID: <516D1D50.8030301@tid.es> Hi, In addition, I have included a link to the extension description from https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/NGSI_change_proposals#FI-WARE_metadata_types Best regards, ------ Ferm?n El 15/04/2013 18:13, Ferm?n Gal?n M?rquez escribi?: 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 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? * I understand that the default scope (the one that a NGSI9 server instance will use if no is included in the ) 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? * 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) * I think a similar problem happens in update case. 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) 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 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; 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] 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 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 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 _______________________________________________ Fiware-ngsi mailing list Fiware-ngsi at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-ngsi ________________________________ 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: From Tobias.Jacobs at neclab.eu Tue Apr 16 12:16:59 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Tue, 16 Apr 2013 10:16:59 +0000 Subject: [Fiware-iot] Fi-WARE overall IoT Architecture updated Wiki-page (needs your review) In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B25089044C16@EX10-MB2-MAD.hi.inet> References: <1971FF81B8E01C45991F6F92B9E3B25089044C16@EX10-MB2-MAD.hi.inet> Message-ID: <8755F290097BD941865DC4245B335D2D38F64940@DAPHNIS.office.hd> Dear Carlos, Thanks a lot for your excellent work on the overall IoT architecture. I have a few comments - A number of minor typos and spelling inconsistencies I have corrected directly on the wiki page - The interface between IoT Broker and PubSub is NGSI10. - I am a bit confused about the name of the PubSub Broker. At some places it is called Context Broker GE, and I have been criticized in the peer review for calling it "PubSub". Still I am not sure what the official GE name is, but we should make sure we use the official name... - Architecture Overview: It is written "The deployment of the architecture of the IoT Service Enablement chapter is typically distributed across a large number of Devices, several Gateways and the Backend. The Generic Enablers described in this chapter, shown in the figure below, implement functionalities distributed across IoT resources hosted by devices, IoT Gateways and in the IoT Backend." How about changing this to something less repetitive: "The deployment of the IoT Service Enablement chapter is typically distributed across a large number of Devices, several Gateways and the Backend. The set of Generic Enablers described in this chapter, shown in the figure below, is partitioned into IoT Gateway Enablers and IoT Backend Enablers" - ETSI M2M: it should be mentioned that European ETSI M2M has now become part of the even broader, world-wide oneM2M standardization efforts. - I changed quite a bit in the NGSI section, as I found it not so clear. It is still a very brief section, but hopefully more clearly describes the relation between NGSI entities and FI-WARE devices and things. - upper/lower case spelling of "thing/Thing" should be consistent. My feeling is that the majority of us prefers the uppercase variant. Personally I do not have a strong preference. Best regards Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Montag, 15. April 2013 16:38 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Fi-WARE overall IoT Architecture updated Wiki-page (needs your review) Dear colleagues, As previously discussed, and after completing the peer-reviews process as all other chapters, I'm now updating the overall IoT architecture Wiki-page. All changes are what we agreed in our F2F meeting, checked also with the project Chief architect (Juanjo) and they are described below. My idea is to consolidate them by the end of the week so they can be included in the deliverable to be sent to the EC (I agreed with my colleagues managing the whole deliverable edition how to do it in this timeframe). I'm doing this at this URL in the public Wiki where we can agree the final version this week and then copy&paste to the actual one: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture_NEW Obviously, the original one accessible to vey else is at: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture ***** Summary of changes: 1. Include in the introduction the two domains of GEs we are considering at IoT. Explain if they are mandatory/optional and how many can be deployed in a specific scenario. Explain behavior, the fact that some features are duplicated between both domains and thus providing optimization (traffic, time-response) and enabling services-at-the-edge. 2. Explain how apps developers will access to IoT GEs (i.e. Directly through our APIs and/or configuring connectivity to Data/Context PubSubCB) 3. In the "Nota Bene." remove "Iot Gateway" item as long as Backend is not described there too. 4. Update the overall architecture figure. The idea is to simplify it providing a similar one compared to other chapters. Also include all updates discussed in our recent F2F meeting in Paris. Important note from Carlos: I need to do and update the FMC diagram (I used the figure in my .ppt presented in Madrid April's Architects Week). I would appreciate if someone may help on this ... 5. Update the Gateway description in the architecture section. State it is an optional element in Fi-WARE IoT model. Important: the previous sentence " The IoT gateway will support all the IoT backend features, taking into consideration " is *NOT* true anymore, as long as we are defining for instance a direct interface from GW Protocol Adapter to GW Data Handling for highly constraint gateway devices. Therefore, now the sentence looks like: "The IoT gateway will not always support all the IoT backend features, taking into consideration..." 6. Update the interaction with the Security chapter to take into account the new FI-WARE security access model. 7. Update the Architecture Description (i.e. The GEs we propose, specify and develop) for both the Backend and the Gateway Domain. This is a key point as it is the main entry point where UCs will see that we have significantly changed our GEs structure. Similarly to the presentation I made in the architects week (where our PO was present) I included some traceability notes that I consider useful during this Fi-PPP Phase II (so no previous UC from Phase I can complain that something disappeared or changed and they got lost). I will propose this mail as a point in the agenda of our next conf.call. Thanks for reading it in advance so we can have a useful discussion then. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From ralli at tid.es Tue Apr 16 15:55:43 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 16 Apr 2013 13:55:43 +0000 Subject: [Fiware-iot] Tomorrow's conf.call 10:00-11:30 Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089049F5D@EX10-MB2-MAD.hi.inet> Dear Colleagues, Just to remind you that we are having our regular conf.call tomorrow at 10h. I'll be sending the googledoc around today with the following proposed agenda: 1. Status of the IoT architecture updates in the Wiki (Overall + GEs) http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture_NEW 2. Fermin's mail on "April software release status in WP5" 3. Fraunhofer intro. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From ralli at tid.es Tue Apr 16 22:45:12 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 16 Apr 2013 20:45:12 +0000 Subject: [Fiware-iot] Tomorrow's conf.call 10:00-11:30 In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B25089049F5D@EX10-MB2-MAD.hi.inet> Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508904A50A@EX10-MB2-MAD.hi.inet> Dear colleagues, This is the googledoc we will be using for tomorrow's call. https://docs.google.com/document/d/1t2qBKw7cCuhFzeGOONFL2SYwfXdPsG6P_dPxMRzX0pQ/edit Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Carlos Ralli Ucendo > Fecha: martes, 16 de abril de 2013 15:55 Para: "fiware-iot at lists.fi-ware.eu" > Asunto: [Fiware-iot] Tomorrow's conf.call 10:00-11:30 Dear Colleagues, Just to remind you that we are having our regular conf.call tomorrow at 10h. I'll be sending the googledoc around today with the following proposed agenda: 1. Status of the IoT architecture updates in the Wiki (Overall + GEs) http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture_NEW 2. Fermin's mail on "April software release status in WP5" 3. Fraunhofer intro. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From ralli at tid.es Wed Apr 17 09:42:10 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 17 Apr 2013 07:42:10 +0000 Subject: [Fiware-iot] Tomorrow's conf.call 10:00-11:30 In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B2508904A50A@EX10-MB2-MAD.hi.inet> Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508904C2DB@EX10-MB2-MAD.hi.inet> Dear colleagues, Do not fgorget to access the googledoc and complete the attendees list with your names + (available) before our conf.call. (The available tag is to be removed once you are in the call so we avoid asking who is in continuously) https://docs.google.com/document/d/1t2qBKw7cCuhFzeGOONFL2SYwfXdPsG6P_dPxMRzX0pQ/edit Thanks, BR -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Carlos Ralli Ucendo > Fecha: martes, 16 de abril de 2013 22:45 Para: "fiware-iot at lists.fi-ware.eu" > Asunto: Re: [Fiware-iot] Tomorrow's conf.call 10:00-11:30 Dear colleagues, This is the googledoc we will be using for tomorrow's call. https://docs.google.com/document/d/1t2qBKw7cCuhFzeGOONFL2SYwfXdPsG6P_dPxMRzX0pQ/edit Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Carlos Ralli Ucendo > Fecha: martes, 16 de abril de 2013 15:55 Para: "fiware-iot at lists.fi-ware.eu" > Asunto: [Fiware-iot] Tomorrow's conf.call 10:00-11:30 Dear Colleagues, Just to remind you that we are having our regular conf.call tomorrow at 10h. I'll be sending the googledoc around today with the following proposed agenda: 1. Status of the IoT architecture updates in the Wiki (Overall + GEs) http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture_NEW 2. Fermin's mail on "April software release status in WP5" 3. Fraunhofer intro. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From raihan.ul-islam at neclab.eu Wed Apr 17 11:25:11 2013 From: raihan.ul-islam at neclab.eu (Raihan Ul-Islam) Date: Wed, 17 Apr 2013 09:25:11 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <516C2721.9060604@tid.es> References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> Message-ID: 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; 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 is included in the ) 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 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; 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] 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 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AssociationScenarioExample.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 583367 bytes Desc: AssociationScenarioExample.docx URL: From fermin at tid.es Wed Apr 17 13:21:59 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Wed, 17 Apr 2013 13:21:59 +0200 Subject: [Fiware-iot] Fwd: [Fiware] Clarification on version number for April 22nd software delivery In-Reply-To: <516E8563.30600@tid.es> References: <516E8563.30600@tid.es> Message-ID: <516E85D7.8060007@tid.es> Hi, I have clarified with Miguel what is expected for April 22nd and it is confirmed that it is March release (my confusion was due to I was originally thinking that April 22nd deadline would require to release the first sprint of release 2.3, but I was wrong). I have posted to the whole FI-WARE as I think the same doubt could happen in other chapters). Thus, regarding IoT Broker: [cid:part1.01050401.08030909 at tid.es] is everything ok. In fact, I think that it could be taken as an example of how to do it correctly for the other GEis in the chapter that has to deliver on April 22nd. Sorry for the confusion! Best regards, ------ Ferm?n -------- Mensaje original -------- Asunto: [Fiware] Clarification on version number for April 22nd software delivery Fecha: Wed, 17 Apr 2013 13:20:03 +0200 De: Ferm?n Gal?n M?rquez Para: fiware at lists.fi-ware.eu Hi, Some doubts have arisen regarding the version number to use in GEi release names related to software delivery for April 22nd deadline that we think could be of general interest, so I'm using this list to talk about it. Regarding the X.Y version numbers to use, the releasing procedure in [1] states: "X.Y = FI-WARE major release. It is mandatory to use the first two numbers of FIWARE numbering schema" For April 22nd deadline we are releasing R2.2 (which last sprint is March), so these are the numbers to use: X.Y = 2.2 Similarly, those delivered in June would normally use: X.Y = 2.3 I hope that this gets clearer now. Otherwise tell me so, please. thanks Best regards, ------ Ferm?n [1] https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Tutorial_releasing_fiware#Release_Management ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: egcibfib.png Type: image/png Size: 7095 bytes Desc: not available URL: From Salvatore.Longo at neclab.eu Wed Apr 17 13:32:16 2013 From: Salvatore.Longo at neclab.eu (Salvatore Longo) Date: Wed, 17 Apr 2013 11:32:16 +0000 Subject: [Fiware-iot] Fwd: [Fiware] Clarification on version number for April 22nd software delivery In-Reply-To: <516E85D7.8060007@tid.es> References: <516E8563.30600@tid.es> <516E85D7.8060007@tid.es> Message-ID: <5DCCEFAAAAD37745A888BC14F42BF4A538E62C1A@DAPHNIS.office.hd> Hi Fermin, Thanks for the clarification. - Salvatore ________________________________ Salvatore Longo Software Engineer NEC Europe Ltd. Kurf?rsten-Anlage 36 D-69115 Heidelberg Tel. +49/(0) 62 21/43 42 - 246 Fax. +49/(0) 62 21/43 42 - 115 E-Mail: Salvatore.longo at neclab.eu NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 ________________________________ From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Ferm?n Gal?n M?rquez Sent: Mittwoch, 17. April 2013 13:22 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Fwd: [Fiware] Clarification on version number for April 22nd software delivery Hi, I have clarified with Miguel what is expected for April 22nd and it is confirmed that it is March release (my confusion was due to I was originally thinking that April 22nd deadline would require to release the first sprint of release 2.3, but I was wrong). I have posted to the whole FI-WARE as I think the same doubt could happen in other chapters). Thus, regarding IoT Broker: [cid:image001.png at 01CE3B6F.DDB9C0F0] is everything ok. In fact, I think that it could be taken as an example of how to do it correctly for the other GEis in the chapter that has to deliver on April 22nd. Sorry for the confusion! Best regards, ------ Ferm?n -------- Mensaje original -------- Asunto: [Fiware] Clarification on version number for April 22nd software delivery Fecha: Wed, 17 Apr 2013 13:20:03 +0200 De: Ferm?n Gal?n M?rquez Para: fiware at lists.fi-ware.eu Hi, Some doubts have arisen regarding the version number to use in GEi release names related to software delivery for April 22nd deadline that we think could be of general interest, so I'm using this list to talk about it. Regarding the X.Y version numbers to use, the releasing procedure in [1] states: "X.Y = FI-WARE major release. It is mandatory to use the first two numbers of FIWARE numbering schema" For April 22nd deadline we are releasing R2.2 (which last sprint is March), so these are the numbers to use: X.Y = 2.2 Similarly, those delivered in June would normally use: X.Y = 2.3 I hope that this gets clearer now. Otherwise tell me so, please. thanks Best regards, ------ Ferm?n [1] https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Tutorial_releasing_fiware#Release_Management ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7095 bytes Desc: image001.png URL: From t.elsaleh at surrey.ac.uk Wed Apr 17 18:28:01 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Wed, 17 Apr 2013 17:28:01 +0100 Subject: [Fiware-iot] Full "architectural" support for (UoSurrey) ConfMan GE Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789B68E6C@EXMB05CMS.surrey.ac.uk> Hello Carlos, Fermin, Tobias, After discussing the matter internally, we (UoSurrey) will aim to provide our implementation for the GE by the end of Release 2.3, which I understand is end of June. This is due to the change in the IoT architecture last month in the F2F meeting, which has resulted in the removal of our original GE from the IoT architecture. We will aim to support the functions and interactions that are "architecturally" required for the ConfMan GE, meaning the ability to serve an NGSI-9 client that involves the following: ? NGSI-9 standard operations o Register, discover, subscribe/notify ? NGSI-9 convenience operations o Register, discover, subscribe/notify ? NGSI-9 associations ? NGSI-9 discovery restrictions (scopes) ? NGSI-9 subscription restrictions Fermin, Tobias, have I missed something? I understand there are other features in the ConfMan GE that are concerned with internal performance, such as multithreading. These type of features we will not plan to support. I hope this still makes our GE compliant, from an architecture point-of-view. Carlos, is the proposal OK? If so, can we confirm that UoSurrey will provide the GE implementation of ConfMan by end of June? This will mean that I will need to shift some of our features set in the Technical Roadmap to 2.3, as it doesn't make sense to provide these without the main functions of the ConfMan GE. Please can you also confirm whether the software documentation for our GE is still due on the 22nd of April or not? Because from what I understand that this will be delayed until June as well. Best regards, Tarek -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralli at tid.es Wed Apr 17 19:09:58 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 17 Apr 2013 17:09:58 +0000 Subject: [Fiware-iot] Full "architectural" support for (UoSurrey) ConfMan GE In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA789B68E6C@EXMB05CMS.surrey.ac.uk> References: <2AAC0B6FF99A064C853BFB1C9295F3CCA789B68E6C@EXMB05CMS.surrey.ac.uk> Message-ID: Hi Tarek Thanks for your mail. I need to check carefully and discuss internally but looks much better than before! Regarding docs, I'm almost sure it gets delayed too but I need to check agree this with the overall coordination. I'll come back to you on this matter ASAP. BR El 17/04/2013, a las 18:28, "t.elsaleh at surrey.ac.uk" > escribi?: Hello Carlos, Fermin, Tobias, After discussing the matter internally, we (UoSurrey) will aim to provide our implementation for the GE by the end of Release 2.3, which I understand is end of June. This is due to the change in the IoT architecture last month in the F2F meeting, which has resulted in the removal of our original GE from the IoT architecture. We will aim to support the functions and interactions that are ?architecturally? required for the ConfMan GE, meaning the ability to serve an NGSI-9 client that involves the following: ? NGSI-9 standard operations o Register, discover, subscribe/notify ? NGSI-9 convenience operations o Register, discover, subscribe/notify ? NGSI-9 associations ? NGSI-9 discovery restrictions (scopes) ? NGSI-9 subscription restrictions Fermin, Tobias, have I missed something? I understand there are other features in the ConfMan GE that are concerned with internal performance, such as multithreading. These type of features we will not plan to support. I hope this still makes our GE compliant, from an architecture point-of-view. Carlos, is the proposal OK? If so, can we confirm that UoSurrey will provide the GE implementation of ConfMan by end of June? This will mean that I will need to shift some of our features set in the Technical Roadmap to 2.3, as it doesn?t make sense to provide these without the main functions of the ConfMan GE. Please can you also confirm whether the software documentation for our GE is still due on the 22nd of April or not? Because from what I understand that this will be delayed until June as well. Best regards, Tarek ________________________________ 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: From fermin at tid.es Thu Apr 18 15:15:48 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Thu, 18 Apr 2013 15:15:48 +0200 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> Message-ID: <516FF204.1000805@tid.es> 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: house_3 indoorTemperature Include Associations SOURCES with the following associated response: Sensor5 measurement false http://myHomeGateway22.org association1 Association [...] http://www.fi-ware.eu/NGSI/association And the following discovery in the update case: Sensor5 indoorTemperature Include Associations TARGETS with the following associated response: association1 Association [...] http://www.fi-ware.eu/NGSI/association 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; 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 is included in the ) 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 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; 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] 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 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 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: From Tobias.Jacobs at neclab.eu Thu Apr 18 16:37:18 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Thu, 18 Apr 2013 14:37:18 +0000 Subject: [Fiware-iot] Full "architectural" support for (UoSurrey) ConfMan GE In-Reply-To: References: <2AAC0B6FF99A064C853BFB1C9295F3CCA789B68E6C@EXMB05CMS.surrey.ac.uk> Message-ID: <8755F290097BD941865DC4245B335D2D38F713F5@DAPHNIS.office.hd> Hi Tarek, Your proposal sound pretty much complete operation-wise, and I would agree (but it is not me who decides that) that it is ok not to implement the nonfunctional features. In summary, your GE implementation would be less tailored to performance, but instead have additional semantic discovery support. I am also curious how semantic support will look like and how it is accessed with NGSI. What I imagine is that registrations could be annotated with some metadata describing semantics, while discovery and subscribe-operations could use a specially defined scope type for making semantic queries. Best regards Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Mittwoch, 17. April 2013 19:10 To: t.elsaleh at surrey.ac.uk Cc: FERMIN GALAN MARQUEZ; Tobias Jacobs; fiware-iot at lists.fi-ware.eu; p.barnaghi at surrey.ac.uk Subject: Re: Full "architectural" support for (UoSurrey) ConfMan GE Hi Tarek Thanks for your mail. I need to check carefully and discuss internally but looks much better than before! Regarding docs, I'm almost sure it gets delayed too but I need to check agree this with the overall coordination. I'll come back to you on this matter ASAP. BR El 17/04/2013, a las 18:28, "t.elsaleh at surrey.ac.uk" > escribi?: Hello Carlos, Fermin, Tobias, After discussing the matter internally, we (UoSurrey) will aim to provide our implementation for the GE by the end of Release 2.3, which I understand is end of June. This is due to the change in the IoT architecture last month in the F2F meeting, which has resulted in the removal of our original GE from the IoT architecture. We will aim to support the functions and interactions that are "architecturally" required for the ConfMan GE, meaning the ability to serve an NGSI-9 client that involves the following: * NGSI-9 standard operations o Register, discover, subscribe/notify * NGSI-9 convenience operations o Register, discover, subscribe/notify * NGSI-9 associations * NGSI-9 discovery restrictions (scopes) * NGSI-9 subscription restrictions Fermin, Tobias, have I missed something? I understand there are other features in the ConfMan GE that are concerned with internal performance, such as multithreading. These type of features we will not plan to support. I hope this still makes our GE compliant, from an architecture point-of-view. Carlos, is the proposal OK? If so, can we confirm that UoSurrey will provide the GE implementation of ConfMan by end of June? This will mean that I will need to shift some of our features set in the Technical Roadmap to 2.3, as it doesn't make sense to provide these without the main functions of the ConfMan GE. Please can you also confirm whether the software documentation for our GE is still due on the 22nd of April or not? Because from what I understand that this will be delayed until June as well. Best regards, Tarek ________________________________ 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: From raihan.ul-islam at neclab.eu Thu Apr 18 18:15:42 2013 From: raihan.ul-islam at neclab.eu (Raihan Ul-Islam) Date: Thu, 18 Apr 2013 16:15:42 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <516FF204.1000805@tid.es> References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> <516FF204.1000805@tid.es> Message-ID: Hi Fermin, Thanks for your questions. Your interpretation of "basic implementation of associations" matches with us. Regarding your second question, If you look into the section "Retrieving Associations using NGSI-9" in the following link https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept you can get more clear view. In short, the TARGETS keyword is used to request any association between entity/attribute combinations from the target set. Therefore, only association is expected in the response of discoverContextAvailabilityRequest with target as scope. No information of context provider of any entity/attribute combination from the target set is required. I hope understand you question properly. Thanks Raihan From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: 18 April 2013 15:16 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-ngsi] how to represent associations 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: house_3 indoorTemperature Include Associations SOURCES with the following associated response: Sensor5 measurement false http://myHomeGateway22.org association1 Association [...] http://www.fi-ware.eu/NGSI/association And the following discovery in the update case: Sensor5 indoorTemperature Include Associations TARGETS with the following associated response: association1 Association [...] http://www.fi-ware.eu/NGSI/association 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; 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 is included in the ) 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 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; 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] 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 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 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: From ralli at tid.es Fri Apr 19 09:26:26 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Fri, 19 Apr 2013 07:26:26 +0000 Subject: [Fiware-iot] Fwd: Final checks on the IoT architecture pages References: Message-ID: FYI Inicio del mensaje reenviado: De: Garino Pierangelo > Fecha: 18 de abril de 2013 12:42:25 GMT+02:00 Para: NAGELLEN Thierry OLNC/OLPS >, "CARLOS RALLI UCENDO (ralli at tid.es)" > Cc: "Banniza, Thomas-Rolf (Thomas-Rolf)" >, "Heijnen Henk (henk.heijnen at technicolor.com)" >, Frank Schulze >, "Matthias.Baumgart at telekom.de" > Asunto: Final checks on the IoT architecture pages Dear Thierry and Carlos, here I report the latest checks on the IoT GE architectures, comparing the current document with the one produced during the first peer review we did. IoT Backend DeviceManagement ConfMan: - most of the comments were taken quite in account - Comment ?h1? was not considered - Comment h4, h8 not considered, they are links to a private wiki page. Will they resolve when moving the document to the public wiki? IoT Gateway DataHandling : While some of the comments seem to be taken into account, most of them cannot be verified in detail due to page rather heavily changed probably after the second peer review. If more details are required, then it would become a third review which is not what we planned to do now. IoT Gateway IoT Broker: - Comment pg1 not considered (it is in our view important) - Other comments properly managed IoT Gateway Protocol Adapter - Comments seem not taken into account, however they were mostly ?suggestions? for general improvements (no strong negative impact if not completely considered) IoT Gateway DeviceManagement: - Most of the (minor) comments taken in account - Comments bz7 bz8 seem not considered Could you please forward to the GE editors the results, and/or provide yourself the peer reviewers, in cc, your comments on the open issues? BR Pier ------------------------------------------------------------------ Telecom Italia Pierangelo Garino Innovation & Industry Relations ? Research & Prototyping Via G. Reiss Romoli 274, I-10148 TORINO Tel: +39 011 228 7142 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. [cid:00000000000000000000000000000003 at TI.Disclaimer] ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: From Tobias.Jacobs at neclab.eu Fri Apr 19 09:42:27 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Fri, 19 Apr 2013 07:42:27 +0000 Subject: [Fiware-iot] Final checks on the IoT architecture pages In-Reply-To: References: Message-ID: <8755F290097BD941865DC4245B335D2D38F7246B@DAPHNIS.office.hd> Hi Carlos, all, As for the IoT Broker Description, the page 1 review comment of the 1st review was ?A general IoT chapter overview is missing before the description of the single GEs. It would be helpful describing a number of technologies, interfaces, and more in general terms used by all the GE descriptions. If not done, here at least some reference to OMA and NGSI should be put.? As this requested overview will be present in the overall architecture deliverable I did not see a need to implement this comment. The 1st page review comment of the 2nd peer review asked for the ?basic design principles? section, which has been added to the end of the document. Best regards Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Freitag, 19. April 2013 09:26 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Fwd: Final checks on the IoT architecture pages FYI Inicio del mensaje reenviado: De: Garino Pierangelo > Fecha: 18 de abril de 2013 12:42:25 GMT+02:00 Para: NAGELLEN Thierry OLNC/OLPS >, "CARLOS RALLI UCENDO (ralli at tid.es)" > Cc: "Banniza, Thomas-Rolf (Thomas-Rolf)" >, "Heijnen Henk (henk.heijnen at technicolor.com)" >, Frank Schulze >, "Matthias.Baumgart at telekom.de" > Asunto: Final checks on the IoT architecture pages Dear Thierry and Carlos, here I report the latest checks on the IoT GE architectures, comparing the current document with the one produced during the first peer review we did. IoT Backend DeviceManagement ConfMan: - most of the comments were taken quite in account - Comment ?h1? was not considered - Comment h4, h8 not considered, they are links to a private wiki page. Will they resolve when moving the document to the public wiki? IoT Gateway DataHandling : While some of the comments seem to be taken into account, most of them cannot be verified in detail due to page rather heavily changed probably after the second peer review. If more details are required, then it would become a third review which is not what we planned to do now. IoT Gateway IoT Broker: - Comment pg1 not considered (it is in our view important) - Other comments properly managed IoT Gateway Protocol Adapter - Comments seem not taken into account, however they were mostly ?suggestions? for general improvements (no strong negative impact if not completely considered) IoT Gateway DeviceManagement: - Most of the (minor) comments taken in account - Comments bz7 bz8 seem not considered Could you please forward to the GE editors the results, and/or provide yourself the peer reviewers, in cc, your comments on the open issues? BR Pier ------------------------------------------------------------------ Telecom Italia Pierangelo Garino Innovation & Industry Relations ? Research & Prototyping Via G. Reiss Romoli 274, I-10148 TORINO Tel: +39 011 228 7142 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. [cid:image001.gif at 01CE3CE2.331B0F90] ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 677 bytes Desc: image001.gif URL: From Tobias.Jacobs at neclab.eu Fri Apr 19 09:47:32 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Fri, 19 Apr 2013 07:47:32 +0000 Subject: [Fiware-iot] Geo-scope support Message-ID: <8755F290097BD941865DC4245B335D2D38F724AB@DAPHNIS.office.hd> Dear Carlos, could you add the following description of the geo-scopes feature to the description of ConfMan GE? Thanks! Tobias As an optional feature, the Configuration Management GE supports the usage of geographic scopes in the operations discoverContextAvailability and subscribeContextAvailability. In particular, the geographic scopes defined under keyword SimpleGeoLocation in Appendix D of the OMA NGSI 9/10 specification[1] will be supported. For specifying the geographic location of entities and/or context providers, a new type of registration metadata will be defined and implemented. The exact syntax and semantics of this metadata type is under discussion. Reference [1]: http://technical.openmobilealliance.org/Technical/release_program/docs/NGSI/V1_0-20120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralli at tid.es Fri Apr 19 10:23:13 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Fri, 19 Apr 2013 08:23:13 +0000 Subject: [Fiware-iot] Geo-scope support In-Reply-To: <8755F290097BD941865DC4245B335D2D38F724AB@DAPHNIS.office.hd> References: <8755F290097BD941865DC4245B335D2D38F724AB@DAPHNIS.office.hd> Message-ID: <51B19032-0CE5-4118-BAB3-51E97E3A3110@tid.es> Sure! I'll let u know once done. BR El 19/04/2013, a las 09:48, "Tobias Jacobs" > escribi?: Dear Carlos, could you add the following description of the geo-scopes feature to the description of ConfMan GE? Thanks! Tobias As an optional feature, the Configuration Management GE supports the usage of geographic scopes in the operations discoverContextAvailability and subscribeContextAvailability. In particular, the geographic scopes defined under keyword SimpleGeoLocation in Appendix D of the OMA NGSI 9/10 specification[1] will be supported. For specifying the geographic location of entities and/or context providers, a new type of registration metadata will be defined and implemented. The exact syntax and semantics of this metadata type is under discussion. Reference [1]: http://technical.openmobilealliance.org/Technical/release_program/docs/NGSI/V1_0-20120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf ________________________________ 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: From ralli at tid.es Mon Apr 22 10:33:58 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 22 Apr 2013 08:33:58 +0000 Subject: [Fiware-iot] Final checks on the IoT architecture pages In-Reply-To: <8755F290097BD941865DC4245B335D2D38F7246B@DAPHNIS.office.hd> Message-ID: <1971FF81B8E01C45991F6F92B9E3B250890530C9@EX10-MB2-MAD.hi.inet> Thanks, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: viernes, 19 de abril de 2013 09:42 Para: Carlos Ralli Ucendo >, "fiware-iot at lists.fi-ware.eu" > Asunto: RE: Final checks on the IoT architecture pages Hi Carlos, all, As for the IoT Broker Description, the page 1 review comment of the 1st review was ?A general IoT chapter overview is missing before the description of the single GEs. It would be helpful describing a number of technologies, interfaces, and more in general terms used by all the GE descriptions. If not done, here at least some reference to OMA and NGSI should be put.? As this requested overview will be present in the overall architecture deliverable I did not see a need to implement this comment. The 1st page review comment of the 2nd peer review asked for the ?basic design principles? section, which has been added to the end of the document. Best regards Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Freitag, 19. April 2013 09:26 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Fwd: Final checks on the IoT architecture pages FYI Inicio del mensaje reenviado: De: Garino Pierangelo > Fecha: 18 de abril de 2013 12:42:25 GMT+02:00 Para: NAGELLEN Thierry OLNC/OLPS >, "CARLOS RALLI UCENDO (ralli at tid.es)" > Cc: "Banniza, Thomas-Rolf (Thomas-Rolf)" >, "Heijnen Henk (henk.heijnen at technicolor.com)" >, Frank Schulze >, "Matthias.Baumgart at telekom.de" > Asunto: Final checks on the IoT architecture pages Dear Thierry and Carlos, here I report the latest checks on the IoT GE architectures, comparing the current document with the one produced during the first peer review we did. IoT Backend DeviceManagement ConfMan: - most of the comments were taken quite in account - Comment ?h1? was not considered - Comment h4, h8 not considered, they are links to a private wiki page. Will they resolve when moving the document to the public wiki? IoT Gateway DataHandling : While some of the comments seem to be taken into account, most of them cannot be verified in detail due to page rather heavily changed probably after the second peer review. If more details are required, then it would become a third review which is not what we planned to do now. IoT Gateway IoT Broker: - Comment pg1 not considered (it is in our view important) - Other comments properly managed IoT Gateway Protocol Adapter - Comments seem not taken into account, however they were mostly ?suggestions? for general improvements (no strong negative impact if not completely considered) IoT Gateway DeviceManagement: - Most of the (minor) comments taken in account - Comments bz7 bz8 seem not considered Could you please forward to the GE editors the results, and/or provide yourself the peer reviewers, in cc, your comments on the open issues? BR Pier ------------------------------------------------------------------ Telecom Italia Pierangelo Garino Innovation & Industry Relations ? Research & Prototyping Via G. Reiss Romoli 274, I-10148 TORINO Tel: +39 011 228 7142 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. [cid:image001.gif at 01CE3CE2.331B0F90] ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 677 bytes Desc: image001.gif URL: From ralli at tid.es Mon Apr 22 11:04:24 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 22 Apr 2013 09:04:24 +0000 Subject: [Fiware-iot] Geo-scope support In-Reply-To: <8755F290097BD941865DC4245B335D2D38F724AB@DAPHNIS.office.hd> Message-ID: <1971FF81B8E01C45991F6F92B9E3B250890532C5@EX10-MB2-MAD.hi.inet> Done. It is at the end of: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.IoT.Backend.ConfMan#Geo-discovery BR -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: viernes, 19 de abril de 2013 09:47 Para: Carlos Ralli Ucendo > CC: "fiware-iot at lists.fi-ware.eu" > Asunto: Geo-scope support Dear Carlos, could you add the following description of the geo-scopes feature to the description of ConfMan GE? Thanks! Tobias As an optional feature, the Configuration Management GE supports the usage of geographic scopes in the operations discoverContextAvailability and subscribeContextAvailability. In particular, the geographic scopes defined under keyword SimpleGeoLocation in Appendix D of the OMA NGSI 9/10 specification[1] will be supported. For specifying the geographic location of entities and/or context providers, a new type of registration metadata will be defined and implemented. The exact syntax and semantics of this metadata type is under discussion. Reference [1]: http://technical.openmobilealliance.org/Technical/release_program/docs/NGSI/V1_0-20120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf ________________________________ 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: From ralli at tid.es Mon Apr 22 11:50:47 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 22 Apr 2013 09:50:47 +0000 Subject: [Fiware-iot] IoT Discovery GE included now as part of the Conf.Man GE description as planned Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508905342E@EX10-MB2-MAD.hi.inet> Hi Tarek, I have included your previous pages in the Conf.Man as agreed in the F2F meeting. You can see the result at: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.IoT.Backend.ConfMan I have deleted the copyright as it makes no sense anymore and I have replaced all references to "IoT DE GE" by "IoT DE component", explaining at the beginning that this would be a kind of additional component within the whole Conf.Man architecture. However, I need the following from you: 1. First make a quick review to check that the text makes sense within its new placeholder. Make any changes you need to provide a smooth integration. I need this by tomorrow EoB. 2. This integration is just a first step but I am sure it needs more work to really fit in the overall description of the mandatory features of the Conf.Man. For this, I think you better read the whole existing text for the Conf.Man and you update your part consequently after this week (so it does not collide with the deliverable generation) but before June 1st (to ensure the text is final before the project review). Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From fermin at tid.es Mon Apr 22 12:21:19 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Mon, 22 Apr 2013 12:21:19 +0200 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> <516FF204.1000805@tid.es> Message-ID: <51750F1F.7070300@tid.es> Dear Raihan, I haven been reading the detail the reference you send and I have realize of the slight asymmetry in TARGET and SOURCE scopes. I would propose a more symmetric processing way: * TARGETS is used when the requestor wishes to find out about the target set of a given set of entity/attribute combinations. The target set of an entity/attribute combination set is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the target set and (2) if there is an association . --> . and . is in the target set, then also . is in the target set. The TARGETS keyword is used to request any association between entity/attribute combinations from the target set, and, additionally, any context provider of any entity/attribute combination from the target set. * SOURCES is used when the requestor wishes to find out where and how information about a given set of entity/attribute combinations can be retrieved. The source set of a set of entity/attribute combinations is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the source set and (2) if there is an association . --> . and . is in the source set, then also . is in the source set. The SOURCES keyword is used to request any association between entity/attribute combinations from the source set and, additionally, any context provider of any entity/attribute combination from the source set. For your XML use case, it doesn't changes anything, as there are no providers registered for house3 in any step. However, I think is better that way, as it provides and analogous way of working for TARGET and HOUSE and more flexibility. Best regards, ------ Ferm?n El 18/04/2013 18:15, Raihan Ul-Islam escribi?: Hi Fermin, Thanks for your questions. Your interpretation of "basic implementation of associations" matches with us. Regarding your second question, If you look into the section "Retrieving Associations using NGSI-9" in the following link https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept you can get more clear view. In short, the TARGETS keyword is used to request any association between entity/attribute combinations from the target set. Therefore, only association is expected in the response of discoverContextAvailabilityRequest with target as scope. No information of context provider of any entity/attribute combination from the target set is required. I hope understand you question properly. Thanks Raihan From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: 18 April 2013 15:16 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-ngsi] how to represent associations 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: house_3 indoorTemperature Include Associations SOURCES with the following associated response: Sensor5 measurement false http://myHomeGateway22.org association1 Association [...] http://www.fi-ware.eu/NGSI/association And the following discovery in the update case: Sensor5 indoorTemperature Include Associations TARGETS with the following associated response: association1 Association [...] http://www.fi-ware.eu/NGSI/association 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; 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 is included in the ) 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 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; 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] 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 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 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 ________________________________ 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: From Tobias.Jacobs at neclab.eu Mon Apr 22 13:32:02 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Mon, 22 Apr 2013 11:32:02 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <51750F1F.7070300@tid.es> References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> <516FF204.1000805@tid.es> <51750F1F.7070300@tid.es> Message-ID: <8755F290097BD941865DC4245B335D2D38F73829@DAPHNIS.office.hd> Hi Fermin, Raihan is on holiday, so I answer instead. The reason why we propose not to include providers in the target set is that we see no use case where someone would ask for targets and needs context providers. The typical use case is when the IoT Broker receives an attribute value of an entity via the update operation and wants to find out which for which higher-level entity/attribute combinations the received update is relevant. The context providers are not needed for that. I understand that making it symmetric would make it somehow more beautiful and clear, but could you explain what you mean by more flexible? Best regards Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Ferm?n Gal?n M?rquez Sent: Montag, 22. April 2013 12:21 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Raihan, I haven been reading the detail the reference you send and I have realize of the slight asymmetry in TARGET and SOURCE scopes. I would propose a more symmetric processing way: * TARGETS is used when the requestor wishes to find out about the target set of a given set of entity/attribute combinations. The target set of an entity/attribute combination set is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the target set and (2) if there is an association . --> . and . is in the target set, then also . is in the target set. The TARGETS keyword is used to request any association between entity/attribute combinations from the target set, and, additionally, any context provider of any entity/attribute combination from the target set. * SOURCES is used when the requestor wishes to find out where and how information about a given set of entity/attribute combinations can be retrieved. The source set of a set of entity/attribute combinations is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the source set and (2) if there is an association . --> . and . is in the source set, then also . is in the source set. The SOURCES keyword is used to request any association between entity/attribute combinations from the source set and, additionally, any context provider of any entity/attribute combination from the source set. For your XML use case, it doesn't changes anything, as there are no providers registered for house3 in any step. However, I think is better that way, as it provides and analogous way of working for TARGET and HOUSE and more flexibility. Best regards, ------ Ferm?n El 18/04/2013 18:15, Raihan Ul-Islam escribi?: Hi Fermin, Thanks for your questions. Your interpretation of "basic implementation of associations" matches with us. Regarding your second question, If you look into the section "Retrieving Associations using NGSI-9" in the following link https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept you can get more clear view. In short, the TARGETS keyword is used to request any association between entity/attribute combinations from the target set. Therefore, only association is expected in the response of discoverContextAvailabilityRequest with target as scope. No information of context provider of any entity/attribute combination from the target set is required. I hope understand you question properly. Thanks Raihan From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: 18 April 2013 15:16 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-ngsi] how to represent associations 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: house_3 indoorTemperature Include Associations SOURCES with the following associated response: Sensor5 measurement false http://myHomeGateway22.org association1 Association [...] http://www.fi-ware.eu/NGSI/association And the following discovery in the update case: Sensor5 indoorTemperature Include Associations TARGETS with the following associated response: association1 Association [...] http://www.fi-ware.eu/NGSI/association 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; 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 is included in the ) 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 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; 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] 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 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 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 ________________________________ 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: From thierry.nagellen at orange.com Mon Apr 22 15:59:03 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Mon, 22 Apr 2013 13:59:03 +0000 Subject: [Fiware-iot] Status of delievrables: software and guides Message-ID: <7044_1366639144_51754228_7044_2651_1_976A65C5A08ADF49B9A8523F7F81925C0DDF93@PEXCVZYM13.corporate.adroot.infra.ftgroup> Dear all, Could you send me by email if everything is OK for each of you: software uploaded in the new place and Unit Test Plan, Administration and Installation Guide, User & Programmers Manual. As WPL I will manage directly to push all docs on the public wiki when Telefonica will give the GO. (SAP has set a specific tool to push everything and we have some cover pages to edit also) Thanks for your feedback Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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: From t.elsaleh at surrey.ac.uk Mon Apr 22 16:14:13 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Mon, 22 Apr 2013 15:14:13 +0100 Subject: [Fiware-iot] Status of delievrables: software and guides In-Reply-To: <7044_1366639144_51754228_7044_2651_1_976A65C5A08ADF49B9A8523F7F81925C0DDF93@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <7044_1366639144_51754228_7044_2651_1_976A65C5A08ADF49B9A8523F7F81925C0DDF93@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789B691EB@EXMB05CMS.surrey.ac.uk> Hello Thierry, As discussed in the last conf call and acknowledged by the WPA, we (UoSurrey) will be releasing the software and guides for 2.3 i.e. end of June, for our implementation of the ConfMan GE. Best regards, Tarek From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of thierry.nagellen at orange.com Sent: 22 April 2013 14:59 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Status of delievrables: software and guides Importance: High Dear all, Could you send me by email if everything is OK for each of you: software uploaded in the new place and Unit Test Plan, Administration and Installation Guide, User & Programmers Manual. As WPL I will manage directly to push all docs on the public wiki when Telefonica will give the GO. (SAP has set a specific tool to push everything and we have some cover pages to edit also) Thanks for your feedback Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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: From Salvatore.Longo at neclab.eu Mon Apr 22 16:36:00 2013 From: Salvatore.Longo at neclab.eu (Salvatore Longo) Date: Mon, 22 Apr 2013 14:36:00 +0000 Subject: [Fiware-iot] Status of delievrables: software and guides In-Reply-To: <7044_1366639144_51754228_7044_2651_1_976A65C5A08ADF49B9A8523F7F81925C0DDF93@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <7044_1366639144_51754228_7044_2651_1_976A65C5A08ADF49B9A8523F7F81925C0DDF93@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <5DCCEFAAAAD37745A888BC14F42BF4A538E6DF74@DAPHNIS.office.hd> Hi Thierry, >From NEC side all it ok about the software deliverables. The updated version is the one in the private wiki according to the Miguel guidelines. This is the link: : https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FiwareDeliverablesR2 BR, - Salvatore Longo ________________________________ Salvatore Longo Software Engineer NEC Europe Ltd. Kurf?rsten-Anlage 36 D-69115 Heidelberg Tel. +49/(0) 62 21/43 42 - 246 Fax. +49/(0) 62 21/43 42 - 115 E-Mail: Salvatore.longo at neclab.eu NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 ________________________________ From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of thierry.nagellen at orange.com Sent: Montag, 22. April 2013 15:59 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Status of delievrables: software and guides Importance: High Dear all, Could you send me by email if everything is OK for each of you: software uploaded in the new place and Unit Test Plan, Administration and Installation Guide, User & Programmers Manual. As WPL I will manage directly to push all docs on the public wiki when Telefonica will give the GO. (SAP has set a specific tool to push everything and we have some cover pages to edit also) Thanks for your feedback Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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: From ralli at tid.es Mon Apr 22 17:39:21 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 22 Apr 2013 15:39:21 +0000 Subject: [Fiware-iot] IoT Architecture Deliverable contrib. ready Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089053F46@EX10-MB2-MAD.hi.inet> Dear Colleagues, Just to let you know that I have generated again the .docx from the Public Wiki pages. The final document, ready to be delivered is located at: https://forge.fi-ware.eu/docman/view.php/27/2128/D232_WP5_v3_reviewed_final_.docx It has been linked also within the Architecture cockpit placeholder: column G of IoT row at: https://docs.google.com/spreadsheet/ccc?key=0AhTmk3UgJVcbdFFLVmJtcC03NWU3LVdtN0VSNl96a2c#gid=0 Thanks to your efforts of updating both the .docx files and the Wiki, now we will all save the efforts to update the Wiki (contrary to other Wps). Additionally, we have re-generated the overall architecture diagram with the new IoT architecture (basically, deleting the GEs we eliminated in our chapter). http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Architecture (first diagram) Thanks for your efforts. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From fermin at tid.es Tue Apr 23 09:35:12 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Tue, 23 Apr 2013 09:35:12 +0200 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <8755F290097BD941865DC4245B335D2D38F73829@DAPHNIS.office.hd> References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> <516FF204.1000805@tid.es> <51750F1F.7070300@tid.es> <8755F290097BD941865DC4245B335D2D38F73829@DAPHNIS.office.hd> Message-ID: <517639B0.3020801@tid.es> Dear Tobias, Even if beauty or clearness weren't enough (for many people, they are :), we see associations as a generic concept that goes much beyond device-thing relationships. For example, you can use associations to define symmetric relationships such as redundancy: let's think in a couple of entities (station1 and station2) at the same abstraction level (i.e. none of them is the "device" of the "thing" represented by the other) each one representing the same set of meteorological station providing a set of metrics (temperature, humidity, etc.) so if station1 fails, station2 could be used or viceversa. In this case, having the ability to get the provider of one end traversing the association from the other, no matter if the the starting end is target of source, can be very useful. I haven't dig into detailed used cases, but there are probably many others. Our point is that we want to be as flexible as possible with associations in Orion Context Broker (the piece of software the implements ConfMan GE), beyond the use case with the IoT Broker. As long as the proposed interpretation doesn't "hurt" the IoT Broker case (i.e. there is no change in the XML you propose to use for the query or update cases) we understand that there is no problem on adopting it. Best regards, ------ Ferm?n El 22/04/2013 13:32, Tobias Jacobs escribi?: Hi Fermin, Raihan is on holiday, so I answer instead. The reason why we propose not to include providers in the target set is that we see no use case where someone would ask for targets and needs context providers. The typical use case is when the IoT Broker receives an attribute value of an entity via the update operation and wants to find out which for which higher-level entity/attribute combinations the received update is relevant. The context providers are not needed for that. I understand that making it symmetric would make it somehow more beautiful and clear, but could you explain what you mean by more flexible? Best regards Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Ferm?n Gal?n M?rquez Sent: Montag, 22. April 2013 12:21 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Raihan, I haven been reading the detail the reference you send and I have realize of the slight asymmetry in TARGET and SOURCE scopes. I would propose a more symmetric processing way: * TARGETS is used when the requestor wishes to find out about the target set of a given set of entity/attribute combinations. The target set of an entity/attribute combination set is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the target set and (2) if there is an association . --> . and . is in the target set, then also . is in the target set. The TARGETS keyword is used to request any association between entity/attribute combinations from the target set, and, additionally, any context provider of any entity/attribute combination from the target set. * SOURCES is used when the requestor wishes to find out where and how information about a given set of entity/attribute combinations can be retrieved. The source set of a set of entity/attribute combinations is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the source set and (2) if there is an association . --> . and . is in the source set, then also . is in the source set. The SOURCES keyword is used to request any association between entity/attribute combinations from the source set and, additionally, any context provider of any entity/attribute combination from the source set. For your XML use case, it doesn't changes anything, as there are no providers registered for house3 in any step. However, I think is better that way, as it provides and analogous way of working for TARGET and HOUSE and more flexibility. Best regards, ------ Ferm?n El 18/04/2013 18:15, Raihan Ul-Islam escribi?: Hi Fermin, Thanks for your questions. Your interpretation of "basic implementation of associations" matches with us. Regarding your second question, If you look into the section "Retrieving Associations using NGSI-9" in the following link https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept you can get more clear view. In short, the TARGETS keyword is used to request any association between entity/attribute combinations from the target set. Therefore, only association is expected in the response of discoverContextAvailabilityRequest with target as scope. No information of context provider of any entity/attribute combination from the target set is required. I hope understand you question properly. Thanks Raihan From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: 18 April 2013 15:16 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-ngsi] how to represent associations 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: house_3 indoorTemperature Include Associations SOURCES with the following associated response: Sensor5 measurement false http://myHomeGateway22.org association1 Association [...] http://www.fi-ware.eu/NGSI/association And the following discovery in the update case: Sensor5 indoorTemperature Include Associations TARGETS with the following associated response: association1 Association [...] http://www.fi-ware.eu/NGSI/association 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; 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 is included in the ) 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 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; 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] 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 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 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 ________________________________ 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: From ralli at tid.es Tue Apr 23 09:41:10 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 23 Apr 2013 07:41:10 +0000 Subject: [Fiware-iot] Starting to update the IoT Roadmap page Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089054761@EX10-MB2-MAD.hi.inet> Dear Colleagues, After cleaning the IoT Architecture Wiki pages, I have started to focus on the IoT roadmap. Basically I have created a new page with the old contents that *we will not modify*, so we keep that as a static reference. It is located at: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Roadmap_of_Internet_of_Things_(IoT)_Services_PREVIOUS Then, in the public roadmap at the Wiki I have started to make the evident modifications after our discussions (F2F and later on). That is at: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Roadmap_of_Internet_of_Things_(IoT)_Services I have not modified anything related to BE IoT Broker, GW Protocol Adapter and GW Data Handling. For the remaining ones I have only make changes in the tables, but not in the previous text (that I'm sure we'll need to modify too). These changes are: 1. BE Dev. Man: I have included a note stating the changes coming up as per Ericsson/NSN withdrawal from this chapter. I need to work out also the EPICs, Features, etc but I'll do this in the coming weeks. 2. BE Conf. Man: I have included the Discovery Features/Epics at the end with a short notice before for traceability. All discovery items have been assigned R2.3 (june 2013) as discussed with UoS. Tarek, now it is your time to consider how to create/delete/modify existing features/EPICs but maybe I would wait to complete the discussion with Ferm?n and Tob?as/Salvatore on how your implementation is going to be. In any case, we need a final update of this before June 1st (so it is ready for our review). 3. BE Template Handler GE. Thierry, this is the 1st time I hear of this. I was tempted to delete it but maybe it can be moved to the GW Dev Man, I do not know. Therefore I wait till we discuss with Fraunhofer although I'm almost sure we won't provide this. 4. GW Dev. Man. I included a short notice to give time to Fraunhofer to present us their asset/plans, have a discussion and then update it. Everything should be ready before June 1st. Sabrina, Gianpiero, maybe you should include some EPIC/features related to the NGSI interface of the Protocol Adapter. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From Tobias.Jacobs at neclab.eu Tue Apr 23 10:07:59 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Tue, 23 Apr 2013 08:07:59 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <517639B0.3020801@tid.es> References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> <516FF204.1000805@tid.es> <51750F1F.7070300@tid.es> <8755F290097BD941865DC4245B335D2D38F73829@DAPHNIS.office.hd> <517639B0.3020801@tid.es> Message-ID: <8755F290097BD941865DC4245B335D2D38F739B7@DAPHNIS.office.hd> Hi Fermin, I understand your use case of symmetric associations, but this is a different kind of association with different semantics from as we have defined it up to now. The way we have defined associations up to now is that there is a specified source and a specified target. The semantics is that attribute values of the source can be interpreted as attribute values of the target, but not every attribute value of the target is can be interpreted as one of the source. So there is an inherent asymmetry. This distinction between the source and the target is where the difference in the SOURCES and TARGETS keyword comes from. In order to model symmetric associations like in your use case I see two possibilities: 1) Use the defined asymmetric associations and insert both station1 --> station2 and station2 --> station1. Then you have expressed what you want: each attribute value of station1 is one from station2 and vice versa. 2) Define a new metadata type for symmetric associations, and correspondingly a new scope type for querying those kind of associations. Note that here it is not necessary to distinguish between SOURCES and TARGETS, but you either include all associations or not. Best Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Dienstag, 23. April 2013 09:35 To: Tobias Jacobs Cc: Raihan Ul-Islam; fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Tobias, Even if beauty or clearness weren't enough (for many people, they are :), we see associations as a generic concept that goes much beyond device-thing relationships. For example, you can use associations to define symmetric relationships such as redundancy: let's think in a couple of entities (station1 and station2) at the same abstraction level (i.e. none of them is the "device" of the "thing" represented by the other) each one representing the same set of meteorological station providing a set of metrics (temperature, humidity, etc.) so if station1 fails, station2 could be used or viceversa. In this case, having the ability to get the provider of one end traversing the association from the other, no matter if the the starting end is target of source, can be very useful. I haven't dig into detailed used cases, but there are probably many others. Our point is that we want to be as flexible as possible with associations in Orion Context Broker (the piece of software the implements ConfMan GE), beyond the use case with the IoT Broker. As long as the proposed interpretation doesn't "hurt" the IoT Broker case (i.e. there is no change in the XML you propose to use for the query or update cases) we understand that there is no problem on adopting it. Best regards, ------ Ferm?n El 22/04/2013 13:32, Tobias Jacobs escribi?: Hi Fermin, Raihan is on holiday, so I answer instead. The reason why we propose not to include providers in the target set is that we see no use case where someone would ask for targets and needs context providers. The typical use case is when the IoT Broker receives an attribute value of an entity via the update operation and wants to find out which for which higher-level entity/attribute combinations the received update is relevant. The context providers are not needed for that. I understand that making it symmetric would make it somehow more beautiful and clear, but could you explain what you mean by more flexible? Best regards Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Ferm?n Gal?n M?rquez Sent: Montag, 22. April 2013 12:21 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Raihan, I haven been reading the detail the reference you send and I have realize of the slight asymmetry in TARGET and SOURCE scopes. I would propose a more symmetric processing way: * TARGETS is used when the requestor wishes to find out about the target set of a given set of entity/attribute combinations. The target set of an entity/attribute combination set is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the target set and (2) if there is an association . --> . and . is in the target set, then also . is in the target set. The TARGETS keyword is used to request any association between entity/attribute combinations from the target set, and, additionally, any context provider of any entity/attribute combination from the target set. * SOURCES is used when the requestor wishes to find out where and how information about a given set of entity/attribute combinations can be retrieved. The source set of a set of entity/attribute combinations is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the source set and (2) if there is an association . --> . and . is in the source set, then also . is in the source set. The SOURCES keyword is used to request any association between entity/attribute combinations from the source set and, additionally, any context provider of any entity/attribute combination from the source set. For your XML use case, it doesn't changes anything, as there are no providers registered for house3 in any step. However, I think is better that way, as it provides and analogous way of working for TARGET and HOUSE and more flexibility. Best regards, ------ Ferm?n El 18/04/2013 18:15, Raihan Ul-Islam escribi?: Hi Fermin, Thanks for your questions. Your interpretation of "basic implementation of associations" matches with us. Regarding your second question, If you look into the section "Retrieving Associations using NGSI-9" in the following link https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept you can get more clear view. In short, the TARGETS keyword is used to request any association between entity/attribute combinations from the target set. Therefore, only association is expected in the response of discoverContextAvailabilityRequest with target as scope. No information of context provider of any entity/attribute combination from the target set is required. I hope understand you question properly. Thanks Raihan From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: 18 April 2013 15:16 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-ngsi] how to represent associations 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: house_3 indoorTemperature Include Associations SOURCES with the following associated response: Sensor5 measurement false http://myHomeGateway22.org association1 Association [...] http://www.fi-ware.eu/NGSI/association And the following discovery in the update case: Sensor5 indoorTemperature Include Associations TARGETS with the following associated response: association1 Association [...] http://www.fi-ware.eu/NGSI/association 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; 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 is included in the ) 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 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; 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] 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 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 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 ________________________________ 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: From t.elsaleh at surrey.ac.uk Tue Apr 23 10:51:17 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Tue, 23 Apr 2013 09:51:17 +0100 Subject: [Fiware-iot] IoT Discovery GE included now as part of the Conf.Man GE description as planned In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B2508905342E@EX10-MB2-MAD.hi.inet> References: <1971FF81B8E01C45991F6F92B9E3B2508905342E@EX10-MB2-MAD.hi.inet> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789B69277@EXMB05CMS.surrey.ac.uk> Hello Carlos, Am I still able to make changes to the ConfMan architecture wiki with respect to the IoT Discovery, since you mentioned below by EOB today? Best regards, Tarek From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: 22 April 2013 10:51 To: Elsaleh T Mr (Electronic Eng) Cc: fiware-iot at lists.fi-ware.eu Subject: IoT Discovery GE included now as part of the Conf.Man GE description as planned Hi Tarek, I have included your previous pages in the Conf.Man as agreed in the F2F meeting. You can see the result at: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.IoT.Backend.ConfMan I have deleted the copyright as it makes no sense anymore and I have replaced all references to "IoT DE GE" by "IoT DE component", explaining at the beginning that this would be a kind of additional component within the whole Conf.Man architecture. However, I need the following from you: 1. First make a quick review to check that the text makes sense within its new placeholder. Make any changes you need to provide a smooth integration. I need this by tomorrow EoB. 2. This integration is just a first step but I am sure it needs more work to really fit in the overall description of the mandatory features of the Conf.Man. For this, I think you better read the whole existing text for the Conf.Man and you update your part consequently after this week (so it does not collide with the deliverable generation) but before June 1st (to ensure the text is final before the project review). Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From ralli at tid.es Tue Apr 23 20:14:32 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 23 Apr 2013 18:14:32 +0000 Subject: [Fiware-iot] Tomorror conf.call at 10h Message-ID: <61B51B73-1AE2-4A6C-8D62-656CF3A73B60@tid.es> Dear colleagues, I'll be sending around the googledoc. The agenda will be: - status of architecture, roadmap, open specs. - R2.2 sw delivery - AoB Best regards. ________________________________ 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 From thierry.nagellen at orange.com Wed Apr 24 08:18:11 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 24 Apr 2013 06:18:11 +0000 Subject: [Fiware-iot] Tomorror conf.call at 10h In-Reply-To: <61B51B73-1AE2-4A6C-8D62-656CF3A73B60@tid.es> References: <61B51B73-1AE2-4A6C-8D62-656CF3A73B60@tid.es> Message-ID: <16652_1366784292_51777924_16652_3421_1_976A65C5A08ADF49B9A8523F7F81925C0DEBDF@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi all, We had a meeting yesterday evening here in Sophia-Antipolis with Sebastian on ETSI-M2M topic (ETSI M2M meeting in parallel). We have to organize urgently a F2F meeting to define the features we will implement and the impact also on the Gateway Device Management GE (Ericsson asset currently). Because May is overbooked we have find just 2 days which are available Wednesday 15th or Thursday 16th. We think that we need only one day focusing all efforts only on this topic. Of course everybody can attend the meeting but I'm not sure that everybody has the same interest regarding the GEs to attend the meeting.At least Telefonica, Telecom Italia and Orange are directly impacted. Could you check your calendar before the telco this morning so we will be able to fix the date. I propose to organize the meeting in Paris because for one day meeting it should be the best place to limit your travel expenses. BR Thierry -----Message d'origine----- De?: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI UCENDO Envoy??: mardi 23 avril 2013 20:15 ??: fiware-iot at lists.fi-ware.eu Objet?: [Fiware-iot] Tomorror conf.call at 10h Dear colleagues, I'll be sending around the googledoc. The agenda will be: - status of architecture, roadmap, open specs. - R2.2 sw delivery - AoB Best regards. ________________________________ 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 _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot _________________________________________________________________________________________________________________________ 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. From ralli at tid.es Wed Apr 24 09:23:35 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 24 Apr 2013 07:23:35 +0000 Subject: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) In-Reply-To: <16652_1366784292_51777924_16652_3421_1_976A65C5A08ADF49B9A8523F7F81925C0DEBDF@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508905861D@EX10-MB2-MAD.hi.inet> Dear Colleagues, Here you are: https://docs.google.com/document/d/1SMe6tMxNvBLH4hsZQkQoyLhJUTuGu6NVzGGPsWV nJDU/edit Best regards, -- --------------------------------------------------------------------------- --------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain --------------------------------------------------------------------------- --------------------------------------------- Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 --------------------------------------------------------------------------- --------------------------------------------- El 24/04/13 08:18, "thierry.nagellen at orange.com" escribi?: >Hi all, > >We had a meeting yesterday evening here in Sophia-Antipolis with >Sebastian on ETSI-M2M topic (ETSI M2M meeting in parallel). We have to >organize urgently a F2F meeting to define the features we will implement >and the impact also on the Gateway Device Management GE (Ericsson asset >currently). > >Because May is overbooked we have find just 2 days which are available >Wednesday 15th or Thursday 16th. We think that we need only one day >focusing all efforts only on this topic. > >Of course everybody can attend the meeting but I'm not sure that >everybody has the same interest regarding the GEs to attend the >meeting.At least Telefonica, Telecom Italia and Orange are directly >impacted. > >Could you check your calendar before the telco this morning so we will be >able to fix the date. I propose to organize the meeting in Paris because >for one day meeting it should be the best place to limit your travel >expenses. > >BR >Thierry > >-----Message d'origine----- >De : fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI >UCENDO >Envoy? : mardi 23 avril 2013 20:15 >? : fiware-iot at lists.fi-ware.eu >Objet : [Fiware-iot] Tomorror conf.call at 10h > >Dear colleagues, > >I'll be sending around the googledoc. The agenda will be: >- status of architecture, roadmap, open specs. >- R2.2 sw delivery >- AoB > > >Best regards. > > > >________________________________ > >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 >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >__________________________________________________________________________ >_______________________________________________ > >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. > ________________________________ 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 From thierry.nagellen at orange.com Wed Apr 24 09:32:00 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 24 Apr 2013 07:32:00 +0000 Subject: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B2508905861D@EX10-MB2-MAD.hi.inet> References: <16652_1366784292_51777924_16652_3421_1_976A65C5A08ADF49B9A8523F7F81925C0DEBDF@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1971FF81B8E01C45991F6F92B9E3B2508905861D@EX10-MB2-MAD.hi.inet> Message-ID: <8053_1366788721_51778A71_8053_609_1_976A65C5A08ADF49B9A8523F7F81925C0DEC69@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi Carlos We cannot access the document. Your link is broken is the email but with the full link we have no access rights to access it. BR Thierry -----Message d'origine----- De?: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI UCENDO Envoy??: mercredi 24 avril 2013 09:24 ??: fiware-iot at lists.fi-ware.eu Objet?: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) Dear Colleagues, Here you are: https://docs.google.com/document/d/1SMe6tMxNvBLH4hsZQkQoyLhJUTuGu6NVzGGPsWV nJDU/edit Best regards, -- --------------------------------------------------------------------------- --------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain --------------------------------------------------------------------------- --------------------------------------------- Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 --------------------------------------------------------------------------- --------------------------------------------- El 24/04/13 08:18, "thierry.nagellen at orange.com" escribi?: >Hi all, > >We had a meeting yesterday evening here in Sophia-Antipolis with >Sebastian on ETSI-M2M topic (ETSI M2M meeting in parallel). We have to >organize urgently a F2F meeting to define the features we will >implement and the impact also on the Gateway Device Management GE >(Ericsson asset currently). > >Because May is overbooked we have find just 2 days which are available >Wednesday 15th or Thursday 16th. We think that we need only one day >focusing all efforts only on this topic. > >Of course everybody can attend the meeting but I'm not sure that >everybody has the same interest regarding the GEs to attend the >meeting.At least Telefonica, Telecom Italia and Orange are directly >impacted. > >Could you check your calendar before the telco this morning so we will >be able to fix the date. I propose to organize the meeting in Paris >because for one day meeting it should be the best place to limit your >travel expenses. > >BR >Thierry > >-----Message d'origine----- >De : fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI >UCENDO Envoy? : mardi 23 avril 2013 20:15 ? : >fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] Tomorror conf.call at >10h > >Dear colleagues, > >I'll be sending around the googledoc. The agenda will be: >- status of architecture, roadmap, open specs. >- R2.2 sw delivery >- AoB > > >Best regards. > > > >________________________________ > >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 >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >_______________________________________________________________________ >___ _______________________________________________ > >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. > ________________________________ 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 _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot _________________________________________________________________________________________________________________________ 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. From raihan.ul-islam at neclab.eu Wed Apr 24 09:33:49 2013 From: raihan.ul-islam at neclab.eu (Raihan Ul-Islam) Date: Wed, 24 Apr 2013 07:33:49 +0000 Subject: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) In-Reply-To: <8053_1366788721_51778A71_8053_609_1_976A65C5A08ADF49B9A8523F7F81925C0DEC69@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <16652_1366784292_51777924_16652_3421_1_976A65C5A08ADF49B9A8523F7F81925C0DEBDF@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1971FF81B8E01C45991F6F92B9E3B2508905861D@EX10-MB2-MAD.hi.inet> <8053_1366788721_51778A71_8053_609_1_976A65C5A08ADF49B9A8523F7F81925C0DEC69@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: Hi Carlos, I am also facing same problem. Thanks Raihan -----Original Message----- From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of thierry.nagellen at orange.com Sent: 24 April 2013 09:32 To: CARLOS RALLI UCENDO; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) Hi Carlos We cannot access the document. Your link is broken is the email but with the full link we have no access rights to access it. BR Thierry -----Message d'origine----- De?: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI UCENDO Envoy??: mercredi 24 avril 2013 09:24 ??: fiware-iot at lists.fi-ware.eu Objet?: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) Dear Colleagues, Here you are: https://docs.google.com/document/d/1SMe6tMxNvBLH4hsZQkQoyLhJUTuGu6NVzGGPsWV nJDU/edit Best regards, -- --------------------------------------------------------------------------- --------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain --------------------------------------------------------------------------- --------------------------------------------- Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 --------------------------------------------------------------------------- --------------------------------------------- El 24/04/13 08:18, "thierry.nagellen at orange.com" escribi?: >Hi all, > >We had a meeting yesterday evening here in Sophia-Antipolis with >Sebastian on ETSI-M2M topic (ETSI M2M meeting in parallel). We have to >organize urgently a F2F meeting to define the features we will >implement and the impact also on the Gateway Device Management GE >(Ericsson asset currently). > >Because May is overbooked we have find just 2 days which are available >Wednesday 15th or Thursday 16th. We think that we need only one day >focusing all efforts only on this topic. > >Of course everybody can attend the meeting but I'm not sure that >everybody has the same interest regarding the GEs to attend the >meeting.At least Telefonica, Telecom Italia and Orange are directly >impacted. > >Could you check your calendar before the telco this morning so we will >be able to fix the date. I propose to organize the meeting in Paris >because for one day meeting it should be the best place to limit your >travel expenses. > >BR >Thierry > >-----Message d'origine----- >De : fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI >UCENDO Envoy? : mardi 23 avril 2013 20:15 ? : >fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] Tomorror conf.call at >10h > >Dear colleagues, > >I'll be sending around the googledoc. The agenda will be: >- status of architecture, roadmap, open specs. >- R2.2 sw delivery >- AoB > > >Best regards. > > > >________________________________ > >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 >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >_______________________________________________________________________ >___ _______________________________________________ > >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. > ________________________________ 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 _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot _________________________________________________________________________________________________________________________ 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. _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot From ralli at tid.es Wed Apr 24 09:34:39 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 24 Apr 2013 07:34:39 +0000 Subject: [Fiware-iot] =?windows-1252?q?FW=3A_=5BFiware-wpl=5D_State_of_the?= =?windows-1252?q?_Art_Analysis_=AD_Emerging_Technologies?= In-Reply-To: <517713C0.2040104@tid.es> Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508905870B@EX10-MB2-MAD.hi.inet> FYI De: Miguel Carrillo > Fecha: mi?rcoles, 24 de abril de 2013 01:05 Para: "fiware-wpa at lists.fi-ware.eu" >, "fiware-wpl at lists.fi-ware.eu" > Asunto: [Fiware-wpl] State of the Art Analysis ? Emerging Technologies Dear all, As you are aware, we agreed in the last WPL/WPA call to create a skeleton based on the State of the Art in the DoW. I am sending you this skeleton that you can start filling in now. This needs to be heavily edited by each WP. The one who drives the process is the WPL and the WPA. The main actor here should be the academia, as expressed in the DoW. I encourage the WPL/WPA to primarily rely on them for this work. Note that we do not want a section per GE, try to group in sections like the ones we have now, not GE per GE. This will be edited directly on the Word document as the result will not go to the wiki. Each WP will deliver their section by the 7th of May. I remind you the schedule (the one on the minutes of meeting) * April, 23 - Skeleton ready * May, 7 - Contributions from chapters to be sent by email (consolidated in a single doc per WP) * May, 10 - Peer Review ready (academia partners) * May, 17 - Feedback incorporated * May, 20 - Delivery I will consolidate all the inputs and will put a brief text in the introductory sections. Best regards, Miguel -- ---------------------------------------------------------------------- _/ _/_/ Miguel Carrillo Pacheco _/ _/ _/ _/ Telef?nica Distrito Telef?nica _/ _/_/_/ _/ _/ Investigaci?n y Edifico Oeste 1, Planta 4 _/ _/ _/ _/ Desarrollo Ronda de la Comunicaci?n S/N _/ _/_/ 28050 Madrid (Spain) Tel: (+34) 91 483 26 77 e-mail: mcp at tid.es Follow FI-WARE on the net Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: http://twitter.com/Fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ---------------------------------------------------------------------- ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: D.2.6.2 State of the Art Analysis ? Emerging Technologies.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 426976 bytes Desc: D.2.6.2 State of the Art Analysis ? Emerging Technologies.docx URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From carsten.magerkurth at sap.com Wed Apr 24 09:39:53 2013 From: carsten.magerkurth at sap.com (Magerkurth, Carsten) Date: Wed, 24 Apr 2013 07:39:53 +0000 Subject: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B2508905861D@EX10-MB2-MAD.hi.inet> References: <16652_1366784292_51777924_16652_3421_1_976A65C5A08ADF49B9A8523F7F81925C0DEBDF@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1971FF81B8E01C45991F6F92B9E3B2508905861D@EX10-MB2-MAD.hi.inet> Message-ID: <85A7992034599A4A83D05984B3A9EA710D034FBC@DEWDFEMB12A.global.corp.sap> Hi Carlos, I also get an "access denied", although I paste the two parts together manually, Best, Carsten -----Original Message----- From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Mittwoch, 24. April 2013 09:24 To: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) Dear Colleagues, Here you are: https://docs.google.com/document/d/1SMe6tMxNvBLH4hsZQkQoyLhJUTuGu6NVzGGPsWV nJDU/edit Best regards, -- --------------------------------------------------------------------------- --------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain --------------------------------------------------------------------------- --------------------------------------------- Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 --------------------------------------------------------------------------- --------------------------------------------- El 24/04/13 08:18, "thierry.nagellen at orange.com" escribi?: >Hi all, > >We had a meeting yesterday evening here in Sophia-Antipolis with >Sebastian on ETSI-M2M topic (ETSI M2M meeting in parallel). We have to >organize urgently a F2F meeting to define the features we will implement >and the impact also on the Gateway Device Management GE (Ericsson asset >currently). > >Because May is overbooked we have find just 2 days which are available >Wednesday 15th or Thursday 16th. We think that we need only one day >focusing all efforts only on this topic. > >Of course everybody can attend the meeting but I'm not sure that >everybody has the same interest regarding the GEs to attend the >meeting.At least Telefonica, Telecom Italia and Orange are directly >impacted. > >Could you check your calendar before the telco this morning so we will be >able to fix the date. I propose to organize the meeting in Paris because >for one day meeting it should be the best place to limit your travel >expenses. > >BR >Thierry > >-----Message d'origine----- >De : fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI >UCENDO >Envoy? : mardi 23 avril 2013 20:15 >? : fiware-iot at lists.fi-ware.eu >Objet : [Fiware-iot] Tomorror conf.call at 10h > >Dear colleagues, > >I'll be sending around the googledoc. The agenda will be: >- status of architecture, roadmap, open specs. >- R2.2 sw delivery >- AoB > > >Best regards. > > > >________________________________ > >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 >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >__________________________________________________________________________ >_______________________________________________ > >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. > ________________________________ 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 _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot From sabrina.guerra at telecomitalia.it Wed Apr 24 09:41:49 2013 From: sabrina.guerra at telecomitalia.it (Guerra Sabrina) Date: Wed, 24 Apr 2013 09:41:49 +0200 Subject: [Fiware-iot] R: Tomorror conf.call at 10h (Googledoc) In-Reply-To: References: <16652_1366784292_51777924_16652_3421_1_976A65C5A08ADF49B9A8523F7F81925C0DEBDF@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1971FF81B8E01C45991F6F92B9E3B2508905861D@EX10-MB2-MAD.hi.inet> <8053_1366788721_51778A71_8053_609_1_976A65C5A08ADF49B9A8523F7F81925C0DEC69@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5AE77AEF3@GRFMBX702BA020.griffon.local> Hi Carlos, we have the same problem, too. BR, Sabrina -----Messaggio originale----- Da: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Raihan Ul-Islam Inviato: mercoled? 24 aprile 2013 09:34 A: CARLOS RALLI UCENDO Cc: fiware-iot at lists.fi-ware.eu Oggetto: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) Hi Carlos, I am also facing same problem. Thanks Raihan -----Original Message----- From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of thierry.nagellen at orange.com Sent: 24 April 2013 09:32 To: CARLOS RALLI UCENDO; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) Hi Carlos We cannot access the document. Your link is broken is the email but with the full link we have no access rights to access it. BR Thierry -----Message d'origine----- De : fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI UCENDO Envoy? : mercredi 24 avril 2013 09:24 ? : fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) Dear Colleagues, Here you are: https://docs.google.com/document/d/1SMe6tMxNvBLH4hsZQkQoyLhJUTuGu6NVzGGPsWV nJDU/edit Best regards, -- --------------------------------------------------------------------------- --------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain --------------------------------------------------------------------------- --------------------------------------------- Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 --------------------------------------------------------------------------- --------------------------------------------- El 24/04/13 08:18, "thierry.nagellen at orange.com" escribi?: >Hi all, > >We had a meeting yesterday evening here in Sophia-Antipolis with >Sebastian on ETSI-M2M topic (ETSI M2M meeting in parallel). We have to >organize urgently a F2F meeting to define the features we will >implement and the impact also on the Gateway Device Management GE >(Ericsson asset currently). > >Because May is overbooked we have find just 2 days which are available >Wednesday 15th or Thursday 16th. We think that we need only one day >focusing all efforts only on this topic. > >Of course everybody can attend the meeting but I'm not sure that >everybody has the same interest regarding the GEs to attend the >meeting.At least Telefonica, Telecom Italia and Orange are directly >impacted. > >Could you check your calendar before the telco this morning so we will >be able to fix the date. I propose to organize the meeting in Paris >because for one day meeting it should be the best place to limit your >travel expenses. > >BR >Thierry > >-----Message d'origine----- >De : fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI >UCENDO Envoy? : mardi 23 avril 2013 20:15 ? : >fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] Tomorror conf.call at >10h > >Dear colleagues, > >I'll be sending around the googledoc. The agenda will be: >- status of architecture, roadmap, open specs. >- R2.2 sw delivery >- AoB > > >Best regards. > > > >________________________________ > >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 >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >_______________________________________________________________________ >___ _______________________________________________ > >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. > ________________________________ 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 _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot _________________________________________________________________________________________________________________________ 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. _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. From ralli at tid.es Wed Apr 24 09:43:07 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 24 Apr 2013 07:43:07 +0000 Subject: [Fiware-iot] R: Tomorror conf.call at 10h (Googledoc) In-Reply-To: <36A93B31228D3B49B691AD31652BCAE9A5AE77AEF3@GRFMBX702BA020.griffon.local> Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089058784@EX10-MB2-MAD.hi.inet> Updated! Thanks! BR -- --------------------------------------------------------------------------- --------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain --------------------------------------------------------------------------- --------------------------------------------- Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 --------------------------------------------------------------------------- --------------------------------------------- El 24/04/13 09:41, "Guerra Sabrina" escribi?: >Hi Carlos, >we have the same problem, too. >BR, >Sabrina > >-----Messaggio originale----- >Da: fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Raihan Ul-Islam >Inviato: mercoled? 24 aprile 2013 09:34 >A: CARLOS RALLI UCENDO >Cc: fiware-iot at lists.fi-ware.eu >Oggetto: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) > >Hi Carlos, > >I am also facing same problem. >Thanks >Raihan > >-----Original Message----- >From: fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of >thierry.nagellen at orange.com >Sent: 24 April 2013 09:32 >To: CARLOS RALLI UCENDO; fiware-iot at lists.fi-ware.eu >Subject: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) > >Hi Carlos > >We cannot access the document. Your link is broken is the email but with >the full link we have no access rights to access it. > >BR >Thierry > >-----Message d'origine----- >De : fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI >UCENDO Envoy? : mercredi 24 avril 2013 09:24 ? : >fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] Tomorror conf.call >at 10h (Googledoc) > >Dear Colleagues, > > >Here you are: > >https://docs.google.com/document/d/1SMe6tMxNvBLH4hsZQkQoyLhJUTuGu6NVzGGPsW >V >nJDU/edit > >Best regards, >-- >-------------------------------------------------------------------------- >- >--------------------------------------------- >Carlos Ralli Ucendo (ralli at tid.es) >Cell: +34696923588 >Twitter: @carlosralli >IPv6 Blog: http://the-internet6.blogspot.com.es >Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU >Madrid, Spain >-------------------------------------------------------------------------- >- >--------------------------------------------- >Follow FI-WARE project (Future Internet Services Core Platform): > Website: http://www.fi-ware.eu > Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 > Twitter: @fiware > LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 >-------------------------------------------------------------------------- >- >--------------------------------------------- > > > > > >El 24/04/13 08:18, "thierry.nagellen at orange.com" > escribi?: > >>Hi all, >> >>We had a meeting yesterday evening here in Sophia-Antipolis with >>Sebastian on ETSI-M2M topic (ETSI M2M meeting in parallel). We have to >>organize urgently a F2F meeting to define the features we will >>implement and the impact also on the Gateway Device Management GE >>(Ericsson asset currently). >> >>Because May is overbooked we have find just 2 days which are available >>Wednesday 15th or Thursday 16th. We think that we need only one day >>focusing all efforts only on this topic. >> >>Of course everybody can attend the meeting but I'm not sure that >>everybody has the same interest regarding the GEs to attend the >>meeting.At least Telefonica, Telecom Italia and Orange are directly >>impacted. >> >>Could you check your calendar before the telco this morning so we will >>be able to fix the date. I propose to organize the meeting in Paris >>because for one day meeting it should be the best place to limit your >>travel expenses. >> >>BR >>Thierry >> >>-----Message d'origine----- >>De : fiware-iot-bounces at lists.fi-ware.eu >>[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI >>UCENDO Envoy? : mardi 23 avril 2013 20:15 ? : >>fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] Tomorror conf.call at >>10h >> >>Dear colleagues, >> >>I'll be sending around the googledoc. The agenda will be: >>- status of architecture, roadmap, open specs. >>- R2.2 sw delivery >>- AoB >> >> >>Best regards. >> >> >> >>________________________________ >> >>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 >>_______________________________________________ >>Fiware-iot mailing list >>Fiware-iot at lists.fi-ware.eu >>https://lists.fi-ware.eu/listinfo/fiware-iot >> >>_______________________________________________________________________ >>___ _______________________________________________ >> >>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. >> > > >________________________________ > >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 >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >__________________________________________________________________________ >_______________________________________________ > >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. > >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >persone indicate. La diffusione, copia o qualsiasi altra azione derivante >dalla conoscenza di queste informazioni sono rigorosamente vietate. >Qualora abbiate ricevuto questo documento per errore siete cortesemente >pregati di darne immediata comunicazione al mittente e di provvedere alla >sua distruzione, Grazie. > >This e-mail and any attachments is confidential and may contain >privileged information intended for the addressee(s) only. Dissemination, >copying, printing or use by anybody else is unauthorised. If you are not >the intended recipient, please delete this message and any attachments >and advise the sender by return e-mail, Thanks. > ________________________________ 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 From t.elsaleh at surrey.ac.uk Wed Apr 24 10:09:56 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Wed, 24 Apr 2013 09:09:56 +0100 Subject: [Fiware-iot] R: Tomorror conf.call at 10h (Googledoc) In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B25089058784@EX10-MB2-MAD.hi.inet> References: <36A93B31228D3B49B691AD31652BCAE9A5AE77AEF3@GRFMBX702BA020.griffon.local> <1971FF81B8E01C45991F6F92B9E3B25089058784@EX10-MB2-MAD.hi.inet> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5AB9D@EXMB05CMS.surrey.ac.uk> Hello Carlos, I have the same problem, I can't access the google doc. Best regards, Tarek -----Original Message----- From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 24 April 2013 08:43 To: Guerra Sabrina; Raihan Ul-Islam Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] R: Tomorror conf.call at 10h (Googledoc) Updated! Thanks! BR -- --------------------------------------------------------------------------- --------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain --------------------------------------------------------------------------- --------------------------------------------- Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 --------------------------------------------------------------------------- --------------------------------------------- El 24/04/13 09:41, "Guerra Sabrina" escribi?: >Hi Carlos, >we have the same problem, too. >BR, >Sabrina > >-----Messaggio originale----- >Da: fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Raihan >Ul-Islam >Inviato: mercoled? 24 aprile 2013 09:34 >A: CARLOS RALLI UCENDO >Cc: fiware-iot at lists.fi-ware.eu >Oggetto: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) > >Hi Carlos, > >I am also facing same problem. >Thanks >Raihan > >-----Original Message----- >From: fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of >thierry.nagellen at orange.com >Sent: 24 April 2013 09:32 >To: CARLOS RALLI UCENDO; fiware-iot at lists.fi-ware.eu >Subject: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) > >Hi Carlos > >We cannot access the document. Your link is broken is the email but >with the full link we have no access rights to access it. > >BR >Thierry > >-----Message d'origine----- >De : fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI >UCENDO Envoy? : mercredi 24 avril 2013 09:24 ? : >fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] Tomorror conf.call >at 10h (Googledoc) > >Dear Colleagues, > > >Here you are: > >https://docs.google.com/document/d/1SMe6tMxNvBLH4hsZQkQoyLhJUTuGu6NVzGG >PsW >V >nJDU/edit > >Best regards, >-- >----------------------------------------------------------------------- >--- >- >--------------------------------------------- >Carlos Ralli Ucendo (ralli at tid.es) >Cell: +34696923588 >Twitter: @carlosralli >IPv6 Blog: http://the-internet6.blogspot.com.es >Product Development & Innovation (Telef?nica Digital) Telef?nica I+D >SAU Madrid, Spain >----------------------------------------------------------------------- >--- >- >--------------------------------------------- >Follow FI-WARE project (Future Internet Services Core Platform): > Website: http://www.fi-ware.eu > Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 > Twitter: @fiware > LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 >----------------------------------------------------------------------- >--- >- >--------------------------------------------- > > > > > >El 24/04/13 08:18, "thierry.nagellen at orange.com" > escribi?: > >>Hi all, >> >>We had a meeting yesterday evening here in Sophia-Antipolis with >>Sebastian on ETSI-M2M topic (ETSI M2M meeting in parallel). We have to >>organize urgently a F2F meeting to define the features we will >>implement and the impact also on the Gateway Device Management GE >>(Ericsson asset currently). >> >>Because May is overbooked we have find just 2 days which are available >>Wednesday 15th or Thursday 16th. We think that we need only one day >>focusing all efforts only on this topic. >> >>Of course everybody can attend the meeting but I'm not sure that >>everybody has the same interest regarding the GEs to attend the >>meeting.At least Telefonica, Telecom Italia and Orange are directly >>impacted. >> >>Could you check your calendar before the telco this morning so we will >>be able to fix the date. I propose to organize the meeting in Paris >>because for one day meeting it should be the best place to limit your >>travel expenses. >> >>BR >>Thierry >> >>-----Message d'origine----- >>De : fiware-iot-bounces at lists.fi-ware.eu >>[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS >>RALLI UCENDO Envoy? : mardi 23 avril 2013 20:15 ? : >>fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] Tomorror conf.call at >>10h >> >>Dear colleagues, >> >>I'll be sending around the googledoc. The agenda will be: >>- status of architecture, roadmap, open specs. >>- R2.2 sw delivery >>- AoB >> >> >>Best regards. >> >> >> >>________________________________ >> >>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 >>_______________________________________________ >>Fiware-iot mailing list >>Fiware-iot at lists.fi-ware.eu >>https://lists.fi-ware.eu/listinfo/fiware-iot >> >>______________________________________________________________________ >>_ ___ _______________________________________________ >> >>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. >> > > >________________________________ > >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 >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >_______________________________________________________________________ >___ _______________________________________________ > >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. > >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >persone indicate. La diffusione, copia o qualsiasi altra azione >derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. >Qualora abbiate ricevuto questo documento per errore siete cortesemente >pregati di darne immediata comunicazione al mittente e di provvedere >alla sua distruzione, Grazie. > >This e-mail and any attachments is confidential and may contain >privileged information intended for the addressee(s) only. >Dissemination, copying, printing or use by anybody else is >unauthorised. If you are not the intended recipient, please delete this >message and any attachments and advise the sender by return e-mail, Thanks. > ________________________________ 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 _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot From thierry.nagellen at orange.com Wed Apr 24 10:11:20 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 24 Apr 2013 08:11:20 +0000 Subject: [Fiware-iot] R: Tomorror conf.call at 10h (Googledoc) In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5AB9D@EXMB05CMS.surrey.ac.uk> References: <36A93B31228D3B49B691AD31652BCAE9A5AE77AEF3@GRFMBX702BA020.griffon.local> <1971FF81B8E01C45991F6F92B9E3B25089058784@EX10-MB2-MAD.hi.inet> <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5AB9D@EXMB05CMS.surrey.ac.uk> Message-ID: <15893_1366791080_517793A8_15893_7331_1_976A65C5A08ADF49B9A8523F7F81925C0DECF3@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi Tarek Could you access it now because it seems that the problem is solved now BR Thierry -----Message d'origine----- De?: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de t.elsaleh at surrey.ac.uk Envoy??: mercredi 24 avril 2013 10:10 ??: ralli at tid.es Cc?: fiware-iot at lists.fi-ware.eu Objet?: Re: [Fiware-iot] R: Tomorror conf.call at 10h (Googledoc) Hello Carlos, I have the same problem, I can't access the google doc. Best regards, Tarek -----Original Message----- From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 24 April 2013 08:43 To: Guerra Sabrina; Raihan Ul-Islam Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] R: Tomorror conf.call at 10h (Googledoc) Updated! Thanks! BR -- --------------------------------------------------------------------------- --------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain --------------------------------------------------------------------------- --------------------------------------------- Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 --------------------------------------------------------------------------- --------------------------------------------- El 24/04/13 09:41, "Guerra Sabrina" escribi?: >Hi Carlos, >we have the same problem, too. >BR, >Sabrina > >-----Messaggio originale----- >Da: fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Raihan >Ul-Islam >Inviato: mercoled? 24 aprile 2013 09:34 >A: CARLOS RALLI UCENDO >Cc: fiware-iot at lists.fi-ware.eu >Oggetto: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) > >Hi Carlos, > >I am also facing same problem. >Thanks >Raihan > >-----Original Message----- >From: fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of >thierry.nagellen at orange.com >Sent: 24 April 2013 09:32 >To: CARLOS RALLI UCENDO; fiware-iot at lists.fi-ware.eu >Subject: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) > >Hi Carlos > >We cannot access the document. Your link is broken is the email but >with the full link we have no access rights to access it. > >BR >Thierry > >-----Message d'origine----- >De : fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI >UCENDO Envoy? : mercredi 24 avril 2013 09:24 ? : >fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] Tomorror conf.call >at 10h (Googledoc) > >Dear Colleagues, > > >Here you are: > >https://docs.google.com/document/d/1SMe6tMxNvBLH4hsZQkQoyLhJUTuGu6NVzGG >PsW >V >nJDU/edit > >Best regards, >-- >----------------------------------------------------------------------- >--- >- >--------------------------------------------- >Carlos Ralli Ucendo (ralli at tid.es) >Cell: +34696923588 >Twitter: @carlosralli >IPv6 Blog: http://the-internet6.blogspot.com.es >Product Development & Innovation (Telef?nica Digital) Telef?nica I+D >SAU Madrid, Spain >----------------------------------------------------------------------- >--- >- >--------------------------------------------- >Follow FI-WARE project (Future Internet Services Core Platform): > Website: http://www.fi-ware.eu > Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 > Twitter: @fiware > LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 >----------------------------------------------------------------------- >--- >- >--------------------------------------------- > > > > > >El 24/04/13 08:18, "thierry.nagellen at orange.com" > escribi?: > >>Hi all, >> >>We had a meeting yesterday evening here in Sophia-Antipolis with >>Sebastian on ETSI-M2M topic (ETSI M2M meeting in parallel). We have to >>organize urgently a F2F meeting to define the features we will >>implement and the impact also on the Gateway Device Management GE >>(Ericsson asset currently). >> >>Because May is overbooked we have find just 2 days which are available >>Wednesday 15th or Thursday 16th. We think that we need only one day >>focusing all efforts only on this topic. >> >>Of course everybody can attend the meeting but I'm not sure that >>everybody has the same interest regarding the GEs to attend the >>meeting.At least Telefonica, Telecom Italia and Orange are directly >>impacted. >> >>Could you check your calendar before the telco this morning so we will >>be able to fix the date. I propose to organize the meeting in Paris >>because for one day meeting it should be the best place to limit your >>travel expenses. >> >>BR >>Thierry >> >>-----Message d'origine----- >>De : fiware-iot-bounces at lists.fi-ware.eu >>[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS >>RALLI UCENDO Envoy? : mardi 23 avril 2013 20:15 ? : >>fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] Tomorror conf.call at >>10h >> >>Dear colleagues, >> >>I'll be sending around the googledoc. The agenda will be: >>- status of architecture, roadmap, open specs. >>- R2.2 sw delivery >>- AoB >> >> >>Best regards. >> >> >> >>________________________________ >> >>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 >>_______________________________________________ >>Fiware-iot mailing list >>Fiware-iot at lists.fi-ware.eu >>https://lists.fi-ware.eu/listinfo/fiware-iot >> >>______________________________________________________________________ >>_ ___ _______________________________________________ >> >>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. >> > > >________________________________ > >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 >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >_______________________________________________________________________ >___ _______________________________________________ > >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. > >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >persone indicate. La diffusione, copia o qualsiasi altra azione >derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. >Qualora abbiate ricevuto questo documento per errore siete cortesemente >pregati di darne immediata comunicazione al mittente e di provvedere >alla sua distruzione, Grazie. > >This e-mail and any attachments is confidential and may contain >privileged information intended for the addressee(s) only. >Dissemination, copying, printing or use by anybody else is >unauthorised. If you are not the intended recipient, please delete this >message and any attachments and advise the sender by return e-mail, Thanks. > ________________________________ 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 _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot _________________________________________________________________________________________________________________________ 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. From t.elsaleh at surrey.ac.uk Wed Apr 24 11:23:43 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Wed, 24 Apr 2013 10:23:43 +0100 Subject: [Fiware-iot] R: Tomorror conf.call at 10h (Googledoc) In-Reply-To: <15893_1366791080_517793A8_15893_7331_1_976A65C5A08ADF49B9A8523F7F81925C0DECF3@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <36A93B31228D3B49B691AD31652BCAE9A5AE77AEF3@GRFMBX702BA020.griffon.local> <1971FF81B8E01C45991F6F92B9E3B25089058784@EX10-MB2-MAD.hi.inet> <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5AB9D@EXMB05CMS.surrey.ac.uk> <15893_1366791080_517793A8_15893_7331_1_976A65C5A08ADF49B9A8523F7F81925C0DECF3@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5ABD8@EXMB05CMS.surrey.ac.uk> Hello Carlos, Thierry, Could you please forward me the link to the google doc again, as I can't access using the link provided this morning. Did you create a another link by any chance this morning? >https://docs.google.com/document/d/1SMe6tMxNvBLH4hsZQkQoyLhJUTuGu6NVzGG (doesn't work for me) Best regards, Tarek -----Original Message----- From: thierry.nagellen at orange.com [mailto:thierry.nagellen at orange.com] Sent: 24 April 2013 09:11 To: Elsaleh T Mr (Electronic Eng); ralli at tid.es Cc: fiware-iot at lists.fi-ware.eu Subject: RE: [Fiware-iot] R: Tomorror conf.call at 10h (Googledoc) Hi Tarek Could you access it now because it seems that the problem is solved now BR Thierry -----Message d'origine----- De?: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de t.elsaleh at surrey.ac.uk Envoy??: mercredi 24 avril 2013 10:10 ??: ralli at tid.es Cc?: fiware-iot at lists.fi-ware.eu Objet?: Re: [Fiware-iot] R: Tomorror conf.call at 10h (Googledoc) Hello Carlos, I have the same problem, I can't access the google doc. Best regards, Tarek -----Original Message----- From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: 24 April 2013 08:43 To: Guerra Sabrina; Raihan Ul-Islam Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] R: Tomorror conf.call at 10h (Googledoc) Updated! Thanks! BR -- --------------------------------------------------------------------------- --------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain --------------------------------------------------------------------------- --------------------------------------------- Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 --------------------------------------------------------------------------- --------------------------------------------- El 24/04/13 09:41, "Guerra Sabrina" escribi?: >Hi Carlos, >we have the same problem, too. >BR, >Sabrina > >-----Messaggio originale----- >Da: fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Raihan >Ul-Islam >Inviato: mercoled? 24 aprile 2013 09:34 >A: CARLOS RALLI UCENDO >Cc: fiware-iot at lists.fi-ware.eu >Oggetto: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) > >Hi Carlos, > >I am also facing same problem. >Thanks >Raihan > >-----Original Message----- >From: fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of >thierry.nagellen at orange.com >Sent: 24 April 2013 09:32 >To: CARLOS RALLI UCENDO; fiware-iot at lists.fi-ware.eu >Subject: Re: [Fiware-iot] Tomorror conf.call at 10h (Googledoc) > >Hi Carlos > >We cannot access the document. Your link is broken is the email but >with the full link we have no access rights to access it. > >BR >Thierry > >-----Message d'origine----- >De : fiware-iot-bounces at lists.fi-ware.eu >[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS RALLI >UCENDO Envoy? : mercredi 24 avril 2013 09:24 ? : >fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] Tomorror conf.call >at 10h (Googledoc) > >Dear Colleagues, > > >Here you are: > >https://docs.google.com/document/d/1SMe6tMxNvBLH4hsZQkQoyLhJUTuGu6NVzGG >PsW >V >nJDU/edit > >Best regards, >-- >----------------------------------------------------------------------- >--- >- >--------------------------------------------- >Carlos Ralli Ucendo (ralli at tid.es) >Cell: +34696923588 >Twitter: @carlosralli >IPv6 Blog: http://the-internet6.blogspot.com.es >Product Development & Innovation (Telef?nica Digital) Telef?nica I+D >SAU Madrid, Spain >----------------------------------------------------------------------- >--- >- >--------------------------------------------- >Follow FI-WARE project (Future Internet Services Core Platform): > Website: http://www.fi-ware.eu > Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 > Twitter: @fiware > LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 >----------------------------------------------------------------------- >--- >- >--------------------------------------------- > > > > > >El 24/04/13 08:18, "thierry.nagellen at orange.com" > escribi?: > >>Hi all, >> >>We had a meeting yesterday evening here in Sophia-Antipolis with >>Sebastian on ETSI-M2M topic (ETSI M2M meeting in parallel). We have to >>organize urgently a F2F meeting to define the features we will >>implement and the impact also on the Gateway Device Management GE >>(Ericsson asset currently). >> >>Because May is overbooked we have find just 2 days which are available >>Wednesday 15th or Thursday 16th. We think that we need only one day >>focusing all efforts only on this topic. >> >>Of course everybody can attend the meeting but I'm not sure that >>everybody has the same interest regarding the GEs to attend the >>meeting.At least Telefonica, Telecom Italia and Orange are directly >>impacted. >> >>Could you check your calendar before the telco this morning so we will >>be able to fix the date. I propose to organize the meeting in Paris >>because for one day meeting it should be the best place to limit your >>travel expenses. >> >>BR >>Thierry >> >>-----Message d'origine----- >>De : fiware-iot-bounces at lists.fi-ware.eu >>[mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de CARLOS >>RALLI UCENDO Envoy? : mardi 23 avril 2013 20:15 ? : >>fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] Tomorror conf.call at >>10h >> >>Dear colleagues, >> >>I'll be sending around the googledoc. The agenda will be: >>- status of architecture, roadmap, open specs. >>- R2.2 sw delivery >>- AoB >> >> >>Best regards. >> >> >> >>________________________________ >> >>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 >>_______________________________________________ >>Fiware-iot mailing list >>Fiware-iot at lists.fi-ware.eu >>https://lists.fi-ware.eu/listinfo/fiware-iot >> >>______________________________________________________________________ >>_ ___ _______________________________________________ >> >>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. >> > > >________________________________ > >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 >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >_______________________________________________________________________ >___ _______________________________________________ > >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. > >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot >_______________________________________________ >Fiware-iot mailing list >Fiware-iot at lists.fi-ware.eu >https://lists.fi-ware.eu/listinfo/fiware-iot > >Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >persone indicate. La diffusione, copia o qualsiasi altra azione >derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. >Qualora abbiate ricevuto questo documento per errore siete cortesemente >pregati di darne immediata comunicazione al mittente e di provvedere >alla sua distruzione, Grazie. > >This e-mail and any attachments is confidential and may contain >privileged information intended for the addressee(s) only. >Dissemination, copying, printing or use by anybody else is >unauthorised. If you are not the intended recipient, please delete this >message and any attachments and advise the sender by return e-mail, Thanks. > ________________________________ 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 _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot _______________________________________________ Fiware-iot mailing list Fiware-iot at lists.fi-ware.eu https://lists.fi-ware.eu/listinfo/fiware-iot _________________________________________________________________________________________________________________________ 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. From ralli at tid.es Wed Apr 24 11:42:47 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 24 Apr 2013 09:42:47 +0000 Subject: [Fiware-iot] Overall description of IoT GEs Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089058B04@EX10-MB2-MAD.hi.inet> Dear colleagues, I was requested by the project coordination to make a summary of all modifications, on-going work and planned/re-planned deliveries of IoT GEs. I made the following list included below. Please, if you have any major comment, let me know. Thierry, I think we can use this as basic material for one of the introduction slides of IoT chapter in the forthcoming June review. ***** - BE Things Management GE Released in R1 but eliminated later on, as it has been split in two: IoT Broker & Conf.Man, - IoT Broker GE (NEC) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management - Configuration Manager GE (TID) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management A new version will be provided in R2.3 together will all documents. There will be, in principle, 3 implementations of this GE: TID, NEC (with Geo-discovery) and UoSurrey (with semantic Discovery) - BE Discovery GE: (UoSurrey). Originally planned for R2.2 but it has been eliminated as a GE (Roadmap updated accordingly on April 23th) Functionality will be delivered as part of the Configuration Manager in R2.3 (maybe it will be re-planned to R3.x). Related features/epics have been moved into the Conf.Man section with a short notice for readers. UoS is performing a review right now and features/EPICs may change in the short term. - BE Dev Man (TID, previously NSN) Planned for major R2 -> R2.3 It will be the combination of two assets (IDAS + IoT-Agent). Features/Epics to change significantly before R2.3 delivery (on-going task). - BE Advanced Connectivity: Eliminated. Functionalities will be developed as part of the BE Dev.Man. Features/Epics dropped from Roadmap by now. - BE Security: Eliminated. Functionalities are being developed/deployed as part of the overall Fi-WARE Security approach (Sec. chapter GEs). Features/Epics dropped from Roadmap by now. - GW Dev Man (Fraunhofer, previously Ericsson) This GE will be significantly updated very soon and maybe even re-planned because of Ericsson withdrawal. Fraunhofer joined us jus 1 week ago? - GW Data Handling (Orange, ATOS) There is only one GE with 2 implementations (Orange and ATOS). Architecture Wiki has been modified accordingly. Roadmap now under revision. - GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector. - GW Advanced Connectivity: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. - GW Security: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. ***** Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From t.elsaleh at surrey.ac.uk Wed Apr 24 12:24:12 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Wed, 24 Apr 2013 11:24:12 +0100 Subject: [Fiware-iot] Mandatory/Optional support for ConfMan GE Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5ABFC@EXMB05CMS.surrey.ac.uk> Hello Tobias, Fermin, Thanks for the reply Tobias. It would good if Fermin can give his opinion on this as well. Let's start with asserting what features/epics are mandatory and what are optional. As I mentioned, and what you (Tobias) confirmed is that non-functional features should be optional. This takes us to the Epics/Features defined for the ConfMan by TID which are: ? FIWARE.EPIC.ContextBroker.ParallelProcessingSupport, o I believe this is non-functional related epic therefore it should be optional. ? FIWARE.EPIC.ContextBroker.MassiveDataSupport, o I believe this is non-functional related epic therefore it should be optional. ? FIWARE.EPIC.ContextBroker.DataChapterGEsIntegration ? I am not sure how D/C chapter here are a special case, since I guess they will also take the role of a NGSI-9 client. From the description, it hints to performance-related issues. But Fermin please correct me if I am wrong. ? FIWARE.Feature.ContextBroker.AvailabilityContextSubscription&Notification, o This is a functional requirement and is therefore mandatory ? FIWARE.Feature.ContextBroker.JSONSupport o Is this mandatory, since the main support is in XML? ? FIWARE.Feature.ContextBroker.ConvenienceOperations, o This is a functional requirement and is therefore mandatory This is my analysis of the epic/features. What is your take on this? Best regards, Tarek From: Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] Sent: 18 April 2013 15:37 To: CARLOS RALLI UCENDO; Elsaleh T Mr (Electronic Eng) Cc: FERMIN GALAN MARQUEZ; fiware-iot at lists.fi-ware.eu; Barnaghi P Dr (Electronic Eng) Subject: RE: Full "architectural" support for (UoSurrey) ConfMan GE Hi Tarek, Your proposal sound pretty much complete operation-wise, and I would agree (but it is not me who decides that) that it is ok not to implement the nonfunctional features. In summary, your GE implementation would be less tailored to performance, but instead have additional semantic discovery support. I am also curious how semantic support will look like and how it is accessed with NGSI. What I imagine is that registrations could be annotated with some metadata describing semantics, while discovery and subscribe-operations could use a specially defined scope type for making semantic queries. Best regards Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Mittwoch, 17. April 2013 19:10 To: t.elsaleh at surrey.ac.uk Cc: FERMIN GALAN MARQUEZ; Tobias Jacobs; fiware-iot at lists.fi-ware.eu; p.barnaghi at surrey.ac.uk Subject: Re: Full "architectural" support for (UoSurrey) ConfMan GE Hi Tarek Thanks for your mail. I need to check carefully and discuss internally but looks much better than before! Regarding docs, I'm almost sure it gets delayed too but I need to check agree this with the overall coordination. I'll come back to you on this matter ASAP. BR El 17/04/2013, a las 18:28, "t.elsaleh at surrey.ac.uk" > escribi?: Hello Carlos, Fermin, Tobias, After discussing the matter internally, we (UoSurrey) will aim to provide our implementation for the GE by the end of Release 2.3, which I understand is end of June. This is due to the change in the IoT architecture last month in the F2F meeting, which has resulted in the removal of our original GE from the IoT architecture. We will aim to support the functions and interactions that are "architecturally" required for the ConfMan GE, meaning the ability to serve an NGSI-9 client that involves the following: * NGSI-9 standard operations o Register, discover, subscribe/notify * NGSI-9 convenience operations o Register, discover, subscribe/notify * NGSI-9 associations * NGSI-9 discovery restrictions (scopes) * NGSI-9 subscription restrictions Fermin, Tobias, have I missed something? I understand there are other features in the ConfMan GE that are concerned with internal performance, such as multithreading. These type of features we will not plan to support. I hope this still makes our GE compliant, from an architecture point-of-view. Carlos, is the proposal OK? If so, can we confirm that UoSurrey will provide the GE implementation of ConfMan by end of June? This will mean that I will need to shift some of our features set in the Technical Roadmap to 2.3, as it doesn't make sense to provide these without the main functions of the ConfMan GE. Please can you also confirm whether the software documentation for our GE is still due on the 22nd of April or not? Because from what I understand that this will be delayed until June as well. Best regards, Tarek ________________________________ 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: From fermin at tid.es Wed Apr 24 16:34:09 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Wed, 24 Apr 2013 16:34:09 +0200 Subject: [Fiware-iot] Mandatory/Optional support for ConfMan GE In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5ABFC@EXMB05CMS.surrey.ac.uk> References: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5ABFC@EXMB05CMS.surrey.ac.uk> Message-ID: <5177ED61.3060906@tid.es> Dear Tarek, Sorry for the delay in the answer. Please, find my comments inline. What is functional and non fucntional is very clear for me. However, I'm not sure if I'm the right one to decide wether "mandatory" or "optional". What can I do (in the hope it would be useful) is tell you what we have include in TID's ConfMan roadmap for 2.3. El 24/04/2013 12:24, t.elsaleh at surrey.ac.uk escribi?: Hello Tobias, Fermin, Thanks for the reply Tobias. It would good if Fermin can give his opinion on this as well. Let's start with asserting what features/epics are mandatory and what are optional. As I mentioned, and what you (Tobias) confirmed is that non-functional features should be optional. This takes us to the Epics/Features defined for the ConfMan by TID which are: ? FIWARE.EPIC.ContextBroker.ParallelProcessingSupport, o I believe this is non-functional related epic therefore it should be optional. [FGM1] Right. It is not functional. Included in 2.3 roadmap. ? FIWARE.EPIC.ContextBroker.MassiveDataSupport, o I believe this is non-functional related epic therefore it should be optional. [FGM2] Right. It is not functional. Included in 2.3 roadmap. ? FIWARE.EPIC.ContextBroker.DataChapterGEsIntegration ? I am not sure how D/C chapter here are a special case, since I guess they will also take the role of a NGSI-9 client. From the description, it hints to performance-related issues. But Fermin please correct me if I am wrong. [FGM3] This is an EPIC yet to be refined. It has to do with how ContexBroker (in its Pub/Sub Broker GE role) will integrate with other GEs in the Data Chapter (CEP, BigData, etc.). It hasn't to do with IoT chapter (in fact, in http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Materializing_Internet_of_Things_%28IoT%29_Services_Enablement_in_FI-WARE#Backend_Configuration_Management_GE it is not included). ? FIWARE.Feature.ContextBroker.AvailabilityContextSubscription&Notification, o This is a functional requirement and is therefore mandatory [FGM4] Right. It is functional. Included in 2.3 roadmap. ? FIWARE.Feature.ContextBroker.JSONSupport o Is this mandatory, since the main support is in XML? [FGM5] This is functional, but secondary. In fact, we have drop this feature from 2.3 roadmap to accommodate the more priority feature on associations implementation. ? FIWARE.Feature.ContextBroker.ConvenienceOperations, o This is a functional requirement and is therefore mandatory [FGM6] There are 41 different convenience operations (including both NGSI9 and NGSI10). We have defined a subset of around 20 operations to be implemented for 2.3, the rest will be referred to release 3. You can check the detail at https://docs.google.com/spreadsheet/ccc?key=0Aj_S9VF3rt5DdEhqZHlBaGVURmhZRDY3aDRBdlpHS3c#gid=0 (pay attention only to NGSI9). This is my analysis of the epic/features. What is your take on this? Best regards, Tarek From: Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] Sent: 18 April 2013 15:37 To: CARLOS RALLI UCENDO; Elsaleh T Mr (Electronic Eng) Cc: FERMIN GALAN MARQUEZ; fiware-iot at lists.fi-ware.eu; Barnaghi P Dr (Electronic Eng) Subject: RE: Full "architectural" support for (UoSurrey) ConfMan GE Hi Tarek, Your proposal sound pretty much complete operation-wise, and I would agree (but it is not me who decides that) that it is ok not to implement the nonfunctional features. In summary, your GE implementation would be less tailored to performance, but instead have additional semantic discovery support. I am also curious how semantic support will look like and how it is accessed with NGSI. What I imagine is that registrations could be annotated with some metadata describing semantics, while discovery and subscribe-operations could use a specially defined scope type for making semantic queries. Best regards Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Mittwoch, 17. April 2013 19:10 To: t.elsaleh at surrey.ac.uk Cc: FERMIN GALAN MARQUEZ; Tobias Jacobs; fiware-iot at lists.fi-ware.eu; p.barnaghi at surrey.ac.uk Subject: Re: Full "architectural" support for (UoSurrey) ConfMan GE Hi Tarek Thanks for your mail. I need to check carefully and discuss internally but looks much better than before! Regarding docs, I'm almost sure it gets delayed too but I need to check agree this with the overall coordination. I'll come back to you on this matter ASAP. BR El 17/04/2013, a las 18:28, "t.elsaleh at surrey.ac.uk" > escribi?: Hello Carlos, Fermin, Tobias, After discussing the matter internally, we (UoSurrey) will aim to provide our implementation for the GE by the end of Release 2.3, which I understand is end of June. This is due to the change in the IoT architecture last month in the F2F meeting, which has resulted in the removal of our original GE from the IoT architecture. We will aim to support the functions and interactions that are "architecturally" required for the ConfMan GE, meaning the ability to serve an NGSI-9 client that involves the following: * NGSI-9 standard operations o Register, discover, subscribe/notify * NGSI-9 convenience operations o Register, discover, subscribe/notify * NGSI-9 associations * NGSI-9 discovery restrictions (scopes) * NGSI-9 subscription restrictions Fermin, Tobias, have I missed something? I understand there are other features in the ConfMan GE that are concerned with internal performance, such as multithreading. These type of features we will not plan to support. I hope this still makes our GE compliant, from an architecture point-of-view. Carlos, is the proposal OK? If so, can we confirm that UoSurrey will provide the GE implementation of ConfMan by end of June? This will mean that I will need to shift some of our features set in the Technical Roadmap to 2.3, as it doesn't make sense to provide these without the main functions of the ConfMan GE. Please can you also confirm whether the software documentation for our GE is still due on the 22nd of April or not? Because from what I understand that this will be delayed until June as well. Best regards, Tarek Best regards, ------ Ferm?n ________________________________ 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: From fermin at tid.es Wed Apr 24 17:29:14 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Wed, 24 Apr 2013 17:29:14 +0200 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <8755F290097BD941865DC4245B335D2D38F739B7@DAPHNIS.office.hd> References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> <516FF204.1000805@tid.es> <51750F1F.7070300@tid.es> <8755F290097BD941865DC4245B335D2D38F73829@DAPHNIS.office.hd> <517639B0.3020801@tid.es> <8755F290097BD941865DC4245B335D2D38F739B7@DAPHNIS.office.hd> Message-ID: <5177FA4A.9060702@tid.es> Dear Tobias, I'm not meaning symmetric in the sense of "symetric relationships" but in the sense of symmetric processing of TARGETS and SOURCES scopes. Consider the following case: station2 is the backup of station1, but station1 is not the backup of station2. In this case, the relationship "backup" is clearly asymmetric station1->station2 but, even so, a client may want to query ConfMan for "all the providers of entities associated with entity1", that is a discoverContextAttribute on station1 with scope=TARGETS that not only has to include the station1->station2 association, but also the provider for station2. Of course, you can model the association in the opossite way ("backed_by" station2->station1) but why to impose a restriction in the way the user of the ConfMan has to model its associations? Why to introduce artificial asymmetries in the processing of both ends when we don't need it (I stress the point that your IoT Broker case will work exactly the same)? On the contrary, they reduce the flexibility. Best regards, ------ Ferm?n El 23/04/2013 10:07, Tobias Jacobs escribi?: Hi Fermin, I understand your use case of symmetric associations, but this is a different kind of association with different semantics from as we have defined it up to now. The way we have defined associations up to now is that there is a specified source and a specified target. The semantics is that attribute values of the source can be interpreted as attribute values of the target, but not every attribute value of the target is can be interpreted as one of the source. So there is an inherent asymmetry. This distinction between the source and the target is where the difference in the SOURCES and TARGETS keyword comes from. In order to model symmetric associations like in your use case I see two possibilities: 1) Use the defined asymmetric associations and insert both station1 --> station2 and station2 --> station1. Then you have expressed what you want: each attribute value of station1 is one from station2 and vice versa. 2) Define a new metadata type for symmetric associations, and correspondingly a new scope type for querying those kind of associations. Note that here it is not necessary to distinguish between SOURCES and TARGETS, but you either include all associations or not. Best Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Dienstag, 23. April 2013 09:35 To: Tobias Jacobs Cc: Raihan Ul-Islam; fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Tobias, Even if beauty or clearness weren't enough (for many people, they are :), we see associations as a generic concept that goes much beyond device-thing relationships. For example, you can use associations to define symmetric relationships such as redundancy: let's think in a couple of entities (station1 and station2) at the same abstraction level (i.e. none of them is the "device" of the "thing" represented by the other) each one representing the same set of meteorological station providing a set of metrics (temperature, humidity, etc.) so if station1 fails, station2 could be used or viceversa. In this case, having the ability to get the provider of one end traversing the association from the other, no matter if the the starting end is target of source, can be very useful. I haven't dig into detailed used cases, but there are probably many others. Our point is that we want to be as flexible as possible with associations in Orion Context Broker (the piece of software the implements ConfMan GE), beyond the use case with the IoT Broker. As long as the proposed interpretation doesn't "hurt" the IoT Broker case (i.e. there is no change in the XML you propose to use for the query or update cases) we understand that there is no problem on adopting it. Best regards, ------ Ferm?n El 22/04/2013 13:32, Tobias Jacobs escribi?: Hi Fermin, Raihan is on holiday, so I answer instead. The reason why we propose not to include providers in the target set is that we see no use case where someone would ask for targets and needs context providers. The typical use case is when the IoT Broker receives an attribute value of an entity via the update operation and wants to find out which for which higher-level entity/attribute combinations the received update is relevant. The context providers are not needed for that. I understand that making it symmetric would make it somehow more beautiful and clear, but could you explain what you mean by more flexible? Best regards Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Ferm?n Gal?n M?rquez Sent: Montag, 22. April 2013 12:21 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Raihan, I haven been reading the detail the reference you send and I have realize of the slight asymmetry in TARGET and SOURCE scopes. I would propose a more symmetric processing way: * TARGETS is used when the requestor wishes to find out about the target set of a given set of entity/attribute combinations. The target set of an entity/attribute combination set is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the target set and (2) if there is an association . --> . and . is in the target set, then also . is in the target set. The TARGETS keyword is used to request any association between entity/attribute combinations from the target set, and, additionally, any context provider of any entity/attribute combination from the target set. * SOURCES is used when the requestor wishes to find out where and how information about a given set of entity/attribute combinations can be retrieved. The source set of a set of entity/attribute combinations is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the source set and (2) if there is an association . --> . and . is in the source set, then also . is in the source set. The SOURCES keyword is used to request any association between entity/attribute combinations from the source set and, additionally, any context provider of any entity/attribute combination from the source set. For your XML use case, it doesn't changes anything, as there are no providers registered for house3 in any step. However, I think is better that way, as it provides and analogous way of working for TARGET and HOUSE and more flexibility. Best regards, ------ Ferm?n El 18/04/2013 18:15, Raihan Ul-Islam escribi?: Hi Fermin, Thanks for your questions. Your interpretation of "basic implementation of associations" matches with us. Regarding your second question, If you look into the section "Retrieving Associations using NGSI-9" in the following link https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept you can get more clear view. In short, the TARGETS keyword is used to request any association between entity/attribute combinations from the target set. Therefore, only association is expected in the response of discoverContextAvailabilityRequest with target as scope. No information of context provider of any entity/attribute combination from the target set is required. I hope understand you question properly. Thanks Raihan From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: 18 April 2013 15:16 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-ngsi] how to represent associations 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: house_3 indoorTemperature Include Associations SOURCES with the following associated response: Sensor5 measurement false http://myHomeGateway22.org association1 Association [...] http://www.fi-ware.eu/NGSI/association And the following discovery in the update case: Sensor5 indoorTemperature Include Associations TARGETS with the following associated response: association1 Association [...] http://www.fi-ware.eu/NGSI/association 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; 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 is included in the ) 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 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; 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] 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 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 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: From nuria.delama at atosresearch.eu Wed Apr 24 19:42:59 2013 From: nuria.delama at atosresearch.eu (Nuria De-Lama Sanchez) Date: Wed, 24 Apr 2013 19:42:59 +0200 Subject: [Fiware-iot] Invitation to participate in FI-WARE workshop @FIA Dublin Message-ID: <66E3B1FDDB04BE4D92DC3A2BA8D98D9A01F6CEE5@INTMAIL03.es.int.atosorigin.com> Dear colleagues of the IoT cluster, I am contacting you on behalf of the FI-WARE project. As you know, FI-WARE is the Technology Foundation of the Future Internet PPP and one of its major technical areas of work is precisely IoT. Philippe and I (re)started discussions on the possible collaboration between the two initiatives and I know there has been some progress about this and a plan for FIA Dublin. FI-WARE is organizing a Pre-FIA workshop on May 7 (from 14:30 to 17:30) and one of the slots has been devoted to establish synergies with other relevant groups. IERC is for sure one of those. Would any of you be available to provide your views on the work carried out by the cluster and the potential collaboration opportunities with FI-WARE? This could be the seed and starting point for the discussions and subsequent meetings. By the way, I have seen that there is another Pre-FIA workshop organized by you the very same day, but I thought that sending one person for a while could help. Carlos Ralli, from Telef?nica, will also be following this, but I wanted to anticipate the agenda of the workshop to get your feedback and willingness to participate. In that case, get in contact with us to organize it. Best regards and thanks in advance, WHEN: Tuesday May 7, from 14:30 to 17:30 WHERE: FIA Dublin Introduction and brief presentation of the workshop (10'): Nuria de Lama (Atos) The Open Innovation Lab (20'): Stefano de Panfilis (Engineering); FI-WARE Technical value (30') (Fi-WARE chapters)-Telef?nica Engage in building FI-WARE: contributions from the Research community (15') Break & networking (30') Real Experiences on how to use FI-WARE Practical case 1: OUTSMART Project (20') Practical case 2: FI-CONTENT II Project (20') Make business out of FI-WARE Entrepreneurship initiatives in Europe: Representative from the EC (20') Building the FI-WARE community: activities for developers and entrepreneurs in FI-WARE (15') Conclusions and next steps (5') Nuria de Lama Research & Innovation Representative to the European Commission T +34 91214 9321 F +34 91754 3252 nuria.delama at atosresearch.eu Albarrac?n 25 28037 Madrid Spain www.atosresearch.eu es.atos.net ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 78 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 816 bytes Desc: image002.gif URL: From sebastian.wahle at fokus.fraunhofer.de Thu Apr 25 09:45:22 2013 From: sebastian.wahle at fokus.fraunhofer.de (Wahle, Sebastian) Date: Thu, 25 Apr 2013 07:45:22 +0000 Subject: [Fiware-iot] Overall description of IoT GEs In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B25089058B04@EX10-MB2-MAD.hi.inet> References: <1971FF81B8E01C45991F6F92B9E3B25089058B04@EX10-MB2-MAD.hi.inet> Message-ID: Hi Carlos, "- GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector." I think that the Protocol Adapter shall support the ETSI interface since ETSI explicitly defines a so called GIP (Gateway Interworking Proxy) to interface with ZigBee, KNX, Wireless M-Bus, Bluetooth etc. It is an inherent design feature of an IoT Gateway to support multiple local area network technologies and connect such devices to a wide area network. Therefore, I see the "GW Protocol Adapter" plugging into the gateway directly by means of the ETSI standard. Best, Sebastian Von: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Im Auftrag von CARLOS RALLI UCENDO Gesendet: Mittwoch, 24. April 2013 11:43 An: fiware-iot at lists.fi-ware.eu Betreff: [Fiware-iot] Overall description of IoT GEs Dear colleagues, I was requested by the project coordination to make a summary of all modifications, on-going work and planned/re-planned deliveries of IoT GEs. I made the following list included below. Please, if you have any major comment, let me know. Thierry, I think we can use this as basic material for one of the introduction slides of IoT chapter in the forthcoming June review. ***** - BE Things Management GE Released in R1 but eliminated later on, as it has been split in two: IoT Broker & Conf.Man, - IoT Broker GE (NEC) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management - Configuration Manager GE (TID) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management A new version will be provided in R2.3 together will all documents. There will be, in principle, 3 implementations of this GE: TID, NEC (with Geo-discovery) and UoSurrey (with semantic Discovery) - BE Discovery GE: (UoSurrey). Originally planned for R2.2 but it has been eliminated as a GE (Roadmap updated accordingly on April 23th) Functionality will be delivered as part of the Configuration Manager in R2.3 (maybe it will be re-planned to R3.x). Related features/epics have been moved into the Conf.Man section with a short notice for readers. UoS is performing a review right now and features/EPICs may change in the short term. - BE Dev Man (TID, previously NSN) Planned for major R2 -> R2.3 It will be the combination of two assets (IDAS + IoT-Agent). Features/Epics to change significantly before R2.3 delivery (on-going task). - BE Advanced Connectivity: Eliminated. Functionalities will be developed as part of the BE Dev.Man. Features/Epics dropped from Roadmap by now. - BE Security: Eliminated. Functionalities are being developed/deployed as part of the overall Fi-WARE Security approach (Sec. chapter GEs). Features/Epics dropped from Roadmap by now. - GW Dev Man (Fraunhofer, previously Ericsson) This GE will be significantly updated very soon and maybe even re-planned because of Ericsson withdrawal. Fraunhofer joined us jus 1 week ago... - GW Data Handling (Orange, ATOS) There is only one GE with 2 implementations (Orange and ATOS). Architecture Wiki has been modified accordingly. Roadmap now under revision. - GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector. - GW Advanced Connectivity: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. - GW Security: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. ***** Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From gianpiero.fici at telecomitalia.it Fri Apr 26 12:02:04 2013 From: gianpiero.fici at telecomitalia.it (Fici Gian Piero) Date: Fri, 26 Apr 2013 12:02:04 +0200 Subject: [Fiware-iot] R: Overall description of IoT GEs In-Reply-To: References: <1971FF81B8E01C45991F6F92B9E3B25089058B04@EX10-MB2-MAD.hi.inet> Message-ID: Hi Sebastian and Carlos, the description of the GIP capability contained in Sebastian's e-mail does not correspond entirely to the ETSI specifications (see the M2M functional architecture rel. 00002ed121v1111 or 00002ed211v2012). In the specifications it is stated the GIP provides the functionality of the interworking between non ETSI compliant devices and the GSCL and it is the GIP which communicates via reference point dIa with GSCL (see chapter 5.3.9 in the specification of the first release, or annex X in the one of the second release, and the description of chapter 6.1 in both specifications). [cid:image004.png at 01CE4275.DDA2BD80][cid:image006.png at 01CE4275.DDA2BD80] Following the definition of GIP written in the standard, the protocol used for the connection of Legacy devices 'd' (such as the Gateway Protocol Adapter GE) is not dIa (if only for the fact that in that case the Legacy device would be a compliant ETSI Application and there would be no need of a GIP functionality), therefore it is the task of the GIP to provide the interworking between the 'd' protocol and the GSCL and not of the Gateway Protocol Adapter GE to plug into the gateway directly by means of the ETSI standard. In the specification of the second release there is also the possibility for the GIP to be an ETSI application external to the GSCL, but we cannot provide it because the implementation of the ETSI M2M standard is not in the roadmap for Telecom Italia. Currently the ZPA, our implementation of the Gateway Protocol Adapter GE, is providing 2 different northbound interfaces: Generic Device Access API and NGSI. The Generic Device Access API was the interface we developed for the integration with the Gateway Device Management GE by Ericsson. The NGSI interface was discussed and agreed during the recent Paris F2F meeting in order to have an interface with the Data Handling GE and it is currently under development. In our opinion we should start from these interfaces to discuss a possible integration with the ETSI M2M Gateway through the GIP. Feel free to ask for further clarifications or details. Best regards, Gian Piero and Sabrina Da: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Wahle, Sebastian Inviato: gioved? 25 aprile 2013 09:45 A: CARLOS RALLI UCENDO Cc: fiware-iot at lists.fi-ware.eu Oggetto: Re: [Fiware-iot] Overall description of IoT GEs Hi Carlos, "- GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector." I think that the Protocol Adapter shall support the ETSI interface since ETSI explicitly defines a so called GIP (Gateway Interworking Proxy) to interface with ZigBee, KNX, Wireless M-Bus, Bluetooth etc. It is an inherent design feature of an IoT Gateway to support multiple local area network technologies and connect such devices to a wide area network. Therefore, I see the "GW Protocol Adapter" plugging into the gateway directly by means of the ETSI standard. Best, Sebastian Von: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Im Auftrag von CARLOS RALLI UCENDO Gesendet: Mittwoch, 24. April 2013 11:43 An: fiware-iot at lists.fi-ware.eu Betreff: [Fiware-iot] Overall description of IoT GEs Dear colleagues, I was requested by the project coordination to make a summary of all modifications, on-going work and planned/re-planned deliveries of IoT GEs. I made the following list included below. Please, if you have any major comment, let me know. Thierry, I think we can use this as basic material for one of the introduction slides of IoT chapter in the forthcoming June review. ***** - BE Things Management GE Released in R1 but eliminated later on, as it has been split in two: IoT Broker & Conf.Man, - IoT Broker GE (NEC) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management - Configuration Manager GE (TID) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management A new version will be provided in R2.3 together will all documents. There will be, in principle, 3 implementations of this GE: TID, NEC (with Geo-discovery) and UoSurrey (with semantic Discovery) - BE Discovery GE: (UoSurrey). Originally planned for R2.2 but it has been eliminated as a GE (Roadmap updated accordingly on April 23th) Functionality will be delivered as part of the Configuration Manager in R2.3 (maybe it will be re-planned to R3.x). Related features/epics have been moved into the Conf.Man section with a short notice for readers. UoS is performing a review right now and features/EPICs may change in the short term. - BE Dev Man (TID, previously NSN) Planned for major R2 -> R2.3 It will be the combination of two assets (IDAS + IoT-Agent). Features/Epics to change significantly before R2.3 delivery (on-going task). - BE Advanced Connectivity: Eliminated. Functionalities will be developed as part of the BE Dev.Man. Features/Epics dropped from Roadmap by now. - BE Security: Eliminated. Functionalities are being developed/deployed as part of the overall Fi-WARE Security approach (Sec. chapter GEs). Features/Epics dropped from Roadmap by now. - GW Dev Man (Fraunhofer, previously Ericsson) This GE will be significantly updated very soon and maybe even re-planned because of Ericsson withdrawal. Fraunhofer joined us jus 1 week ago... - GW Data Handling (Orange, ATOS) There is only one GE with 2 implementations (Orange and ATOS). Architecture Wiki has been modified accordingly. Roadmap now under revision. - GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector. - GW Advanced Connectivity: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. - GW Security: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. ***** Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000003 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.emz Type: application/octet-stream Size: 3603 bytes Desc: image001.emz URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 3644 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 41862 bytes Desc: image006.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: From sebastian.wahle at fokus.fraunhofer.de Fri Apr 26 13:31:21 2013 From: sebastian.wahle at fokus.fraunhofer.de (Wahle, Sebastian) Date: Fri, 26 Apr 2013 11:31:21 +0000 Subject: [Fiware-iot] Invitation - Fraunhofer introduction on M2M work / ETSI interfaces Message-ID: Dear IoT Chapter Members, As agreed two weeks ago, I will introduce our M2M work and some background on the ETSI standard on Monday. We will use the usual PowWowNow bridge and a GoToMeeting session for slide sharing. 1. Please join the meeting: https://www3.gotomeeting.com/join/188260998 2. Join the conference call: "PowWowNow" Conference Call. PIN 028919 Phone numbers list: http://pdf.powwownow.com/pdf/USA_en_pwn-dial-in-numbers.pdf Not at your computer? Click the link to join this meeting from your iPhone?, iPad? or Android? device via the GoToMeeting app. Best regards from Berlin, Sebastian --------------------------------------------------------------------------------- Dr. Sebastian Wahle Head of M2M Solutions Fraunhofer Institute for Open Communication Systems - FOKUS Kaiserin-Augusta-Allee 31, 10589 Berlin, Germany Phone: +493034637365 Mobile: +491757222698 eMail: sebastian.wahle at fokus.fraunhofer.de Twitter: @3flight Web: www.fokus.fraunhofer.de --------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2755 bytes Desc: not available URL: From sebastian.wahle at fokus.fraunhofer.de Fri Apr 26 13:47:48 2013 From: sebastian.wahle at fokus.fraunhofer.de (Wahle, Sebastian) Date: Fri, 26 Apr 2013 11:47:48 +0000 Subject: [Fiware-iot] Overall description of IoT GEs In-Reply-To: References: <1971FF81B8E01C45991F6F92B9E3B25089058B04@EX10-MB2-MAD.hi.inet> Message-ID: Dear Gian Piero and Sabrina, Thanks for the detailed response. From a gateway design perspective, I think the legacy device 'd' should be the ZigBee device rather than the Protocol Adapter GE. In such case, the Protocol Adapter GE could function as a GIP and we would have eliminated the need for another abstraction layer. Best regards and happy WE, Sebastian Von: Fici Gian Piero [mailto:gianpiero.fici at telecomitalia.it] Gesendet: Freitag, 26. April 2013 12:02 An: Wahle, Sebastian; CARLOS RALLI UCENDO Cc: fiware-iot at lists.fi-ware.eu Betreff: R: [Fiware-iot] Overall description of IoT GEs Hi Sebastian and Carlos, the description of the GIP capability contained in Sebastian's e-mail does not correspond entirely to the ETSI specifications (see the M2M functional architecture rel. 00002ed121v1111 or 00002ed211v2012). In the specifications it is stated the GIP provides the functionality of the interworking between non ETSI compliant devices and the GSCL and it is the GIP which communicates via reference point dIa with GSCL (see chapter 5.3.9 in the specification of the first release, or annex X in the one of the second release, and the description of chapter 6.1 in both specifications). [Figure extracted from the ETSI M2M Functional Architecture describing the mapping of reference points to different deployment scenarios. Please note there is no dIa between 'd' and GIP.][cid:image005.png at 01CE4283.CFE874B0] Following the definition of GIP written in the standard, the protocol used for the connection of Legacy devices 'd' (such as the Gateway Protocol Adapter GE) is not dIa (if only for the fact that in that case the Legacy device would be a compliant ETSI Application and there would be no need of a GIP functionality), therefore it is the task of the GIP to provide the interworking between the 'd' protocol and the GSCL and not of the Gateway Protocol Adapter GE to plug into the gateway directly by means of the ETSI standard. In the specification of the second release there is also the possibility for the GIP to be an ETSI application external to the GSCL, but we cannot provide it because the implementation of the ETSI M2M standard is not in the roadmap for Telecom Italia. Currently the ZPA, our implementation of the Gateway Protocol Adapter GE, is providing 2 different northbound interfaces: Generic Device Access API and NGSI. The Generic Device Access API was the interface we developed for the integration with the Gateway Device Management GE by Ericsson. The NGSI interface was discussed and agreed during the recent Paris F2F meeting in order to have an interface with the Data Handling GE and it is currently under development. In our opinion we should start from these interfaces to discuss a possible integration with the ETSI M2M Gateway through the GIP. Feel free to ask for further clarifications or details. Best regards, Gian Piero and Sabrina Da: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Wahle, Sebastian Inviato: gioved? 25 aprile 2013 09:45 A: CARLOS RALLI UCENDO Cc: fiware-iot at lists.fi-ware.eu Oggetto: Re: [Fiware-iot] Overall description of IoT GEs Hi Carlos, "- GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector." I think that the Protocol Adapter shall support the ETSI interface since ETSI explicitly defines a so called GIP (Gateway Interworking Proxy) to interface with ZigBee, KNX, Wireless M-Bus, Bluetooth etc. It is an inherent design feature of an IoT Gateway to support multiple local area network technologies and connect such devices to a wide area network. Therefore, I see the "GW Protocol Adapter" plugging into the gateway directly by means of the ETSI standard. Best, Sebastian Von: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Im Auftrag von CARLOS RALLI UCENDO Gesendet: Mittwoch, 24. April 2013 11:43 An: fiware-iot at lists.fi-ware.eu Betreff: [Fiware-iot] Overall description of IoT GEs Dear colleagues, I was requested by the project coordination to make a summary of all modifications, on-going work and planned/re-planned deliveries of IoT GEs. I made the following list included below. Please, if you have any major comment, let me know. Thierry, I think we can use this as basic material for one of the introduction slides of IoT chapter in the forthcoming June review. ***** - BE Things Management GE Released in R1 but eliminated later on, as it has been split in two: IoT Broker & Conf.Man, - IoT Broker GE (NEC) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management - Configuration Manager GE (TID) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management A new version will be provided in R2.3 together will all documents. There will be, in principle, 3 implementations of this GE: TID, NEC (with Geo-discovery) and UoSurrey (with semantic Discovery) - BE Discovery GE: (UoSurrey). Originally planned for R2.2 but it has been eliminated as a GE (Roadmap updated accordingly on April 23th) Functionality will be delivered as part of the Configuration Manager in R2.3 (maybe it will be re-planned to R3.x). Related features/epics have been moved into the Conf.Man section with a short notice for readers. UoS is performing a review right now and features/EPICs may change in the short term. - BE Dev Man (TID, previously NSN) Planned for major R2 -> R2.3 It will be the combination of two assets (IDAS + IoT-Agent). Features/Epics to change significantly before R2.3 delivery (on-going task). - BE Advanced Connectivity: Eliminated. Functionalities will be developed as part of the BE Dev.Man. Features/Epics dropped from Roadmap by now. - BE Security: Eliminated. Functionalities are being developed/deployed as part of the overall Fi-WARE Security approach (Sec. chapter GEs). Features/Epics dropped from Roadmap by now. - GW Dev Man (Fraunhofer, previously Ericsson) This GE will be significantly updated very soon and maybe even re-planned because of Ericsson withdrawal. Fraunhofer joined us jus 1 week ago... - GW Data Handling (Orange, ATOS) There is only one GE with 2 implementations (Orange and ATOS). Architecture Wiki has been modified accordingly. Roadmap now under revision. - GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector. - GW Advanced Connectivity: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. - GW Security: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. ***** Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.emz Type: application/octet-stream Size: 3603 bytes Desc: image002.emz URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 3653 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 41862 bytes Desc: image005.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.gif Type: image/gif Size: 677 bytes Desc: image006.gif URL: From gianpiero.fici at telecomitalia.it Fri Apr 26 14:35:37 2013 From: gianpiero.fici at telecomitalia.it (Fici Gian Piero) Date: Fri, 26 Apr 2013 14:35:37 +0200 Subject: [Fiware-iot] R: Overall description of IoT GEs In-Reply-To: References: <1971FF81B8E01C45991F6F92B9E3B25089058B04@EX10-MB2-MAD.hi.inet> Message-ID: Hi Sebastian, yes, your interpretation is a valid one, and I think others may agree with you, but if you look at the entity-relation representation of the M2M area network (see document Interworking with m2m area networks 00014ed111v020) you may see that there is the concept of M2M Area Network in between the IPU (Interworking Proxy Unit, i.e. another way to indicate a GIP not as a capability but as an ETSI M2M Application) and the devices of type 'd'. This was introduced in order to provide a single entry point for the ETSI M2M architecture to all the devices included in a Wireless Sensor Network. [cid:image003.png at 01CE428B.51257620] In our view the Gateway Protocol Adapter GE is this single "M2M Area Network" component, interfacing the ETSI M2M architecture. In any case the ETSI M2M architecture (by design) is flexible enough to accommodate different implementations, but the point is that we are not going to implement the ETSI M2M dIa because it is not in the roadmap of our company (moreover if we had the intention to implement it we would not need an ETSI M2M compliant gateway). We can talk about this in the Monday conf call. Best regards, Gian Piero and Sabrina Da: Wahle, Sebastian [mailto:sebastian.wahle at fokus.fraunhofer.de] Inviato: venerd? 26 aprile 2013 13:48 A: Fici Gian Piero; CARLOS RALLI UCENDO Cc: fiware-iot at lists.fi-ware.eu Oggetto: AW: [Fiware-iot] Overall description of IoT GEs Dear Gian Piero and Sabrina, Thanks for the detailed response. From a gateway design perspective, I think the legacy device 'd' should be the ZigBee device rather than the Protocol Adapter GE. In such case, the Protocol Adapter GE could function as a GIP and we would have eliminated the need for another abstraction layer. Best regards and happy WE, Sebastian Von: Fici Gian Piero [mailto:gianpiero.fici at telecomitalia.it] Gesendet: Freitag, 26. April 2013 12:02 An: Wahle, Sebastian; CARLOS RALLI UCENDO Cc: fiware-iot at lists.fi-ware.eu Betreff: R: [Fiware-iot] Overall description of IoT GEs Hi Sebastian and Carlos, the description of the GIP capability contained in Sebastian's e-mail does not correspond entirely to the ETSI specifications (see the M2M functional architecture rel. 00002ed121v1111 or 00002ed211v2012). In the specifications it is stated the GIP provides the functionality of the interworking between non ETSI compliant devices and the GSCL and it is the GIP which communicates via reference point dIa with GSCL (see chapter 5.3.9 in the specification of the first release, or annex X in the one of the second release, and the description of chapter 6.1 in both specifications). [cid:image007.png at 01CE428B.51257620][cid:image005.png at 01CE4288.03E72AF0] Following the definition of GIP written in the standard, the protocol used for the connection of Legacy devices 'd' (such as the Gateway Protocol Adapter GE) is not dIa (if only for the fact that in that case the Legacy device would be a compliant ETSI Application and there would be no need of a GIP functionality), therefore it is the task of the GIP to provide the interworking between the 'd' protocol and the GSCL and not of the Gateway Protocol Adapter GE to plug into the gateway directly by means of the ETSI standard. In the specification of the second release there is also the possibility for the GIP to be an ETSI application external to the GSCL, but we cannot provide it because the implementation of the ETSI M2M standard is not in the roadmap for Telecom Italia. Currently the ZPA, our implementation of the Gateway Protocol Adapter GE, is providing 2 different northbound interfaces: Generic Device Access API and NGSI. The Generic Device Access API was the interface we developed for the integration with the Gateway Device Management GE by Ericsson. The NGSI interface was discussed and agreed during the recent Paris F2F meeting in order to have an interface with the Data Handling GE and it is currently under development. In our opinion we should start from these interfaces to discuss a possible integration with the ETSI M2M Gateway through the GIP. Feel free to ask for further clarifications or details. Best regards, Gian Piero and Sabrina Da: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Wahle, Sebastian Inviato: gioved? 25 aprile 2013 09:45 A: CARLOS RALLI UCENDO Cc: fiware-iot at lists.fi-ware.eu Oggetto: Re: [Fiware-iot] Overall description of IoT GEs Hi Carlos, "- GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector." I think that the Protocol Adapter shall support the ETSI interface since ETSI explicitly defines a so called GIP (Gateway Interworking Proxy) to interface with ZigBee, KNX, Wireless M-Bus, Bluetooth etc. It is an inherent design feature of an IoT Gateway to support multiple local area network technologies and connect such devices to a wide area network. Therefore, I see the "GW Protocol Adapter" plugging into the gateway directly by means of the ETSI standard. Best, Sebastian Von: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Im Auftrag von CARLOS RALLI UCENDO Gesendet: Mittwoch, 24. April 2013 11:43 An: fiware-iot at lists.fi-ware.eu Betreff: [Fiware-iot] Overall description of IoT GEs Dear colleagues, I was requested by the project coordination to make a summary of all modifications, on-going work and planned/re-planned deliveries of IoT GEs. I made the following list included below. Please, if you have any major comment, let me know. Thierry, I think we can use this as basic material for one of the introduction slides of IoT chapter in the forthcoming June review. ***** - BE Things Management GE Released in R1 but eliminated later on, as it has been split in two: IoT Broker & Conf.Man, - IoT Broker GE (NEC) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management - Configuration Manager GE (TID) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management A new version will be provided in R2.3 together will all documents. There will be, in principle, 3 implementations of this GE: TID, NEC (with Geo-discovery) and UoSurrey (with semantic Discovery) - BE Discovery GE: (UoSurrey). Originally planned for R2.2 but it has been eliminated as a GE (Roadmap updated accordingly on April 23th) Functionality will be delivered as part of the Configuration Manager in R2.3 (maybe it will be re-planned to R3.x). Related features/epics have been moved into the Conf.Man section with a short notice for readers. UoS is performing a review right now and features/EPICs may change in the short term. - BE Dev Man (TID, previously NSN) Planned for major R2 -> R2.3 It will be the combination of two assets (IDAS + IoT-Agent). Features/Epics to change significantly before R2.3 delivery (on-going task). - BE Advanced Connectivity: Eliminated. Functionalities will be developed as part of the BE Dev.Man. Features/Epics dropped from Roadmap by now. - BE Security: Eliminated. Functionalities are being developed/deployed as part of the overall Fi-WARE Security approach (Sec. chapter GEs). Features/Epics dropped from Roadmap by now. - GW Dev Man (Fraunhofer, previously Ericsson) This GE will be significantly updated very soon and maybe even re-planned because of Ericsson withdrawal. Fraunhofer joined us jus 1 week ago... - GW Data Handling (Orange, ATOS) There is only one GE with 2 implementations (Orange and ATOS). Architecture Wiki has been modified accordingly. Roadmap now under revision. - GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector. - GW Advanced Connectivity: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. - GW Security: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. ***** Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:image006.gif at 01CE4288.03E72AF0]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.emz Type: application/octet-stream Size: 3603 bytes Desc: image001.emz URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 41862 bytes Desc: image005.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.gif Type: image/gif Size: 677 bytes Desc: image006.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 14772 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 3644 bytes Desc: image007.png URL: From ralli at tid.es Mon Apr 29 12:23:58 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 29 Apr 2013 10:23:58 +0000 Subject: [Fiware-iot] Notes and conclusions from our Technical Conf.Call today Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508905EBA3@EX10-MB2-MAD.hi.inet> Dear Colleagues, Just to keep it somewhere find here the link to the googledoc we've been using for today's meeting notes. https://docs.google.com/document/d/183HYkKXms3kokNFyBCU3uJ_2Y_7DutSTpp66i5h-Zvk/edit As long as we took relevant decisions on the architecture it is very important that you review it during this week analyzing the implications and risks. No comments during this week means we all agree with that including feasibility from resources point of view. Should you have comments or things you did not realize during the call, please send an e-mail to the list. Sebastian, thanks for kicking off the discussion and providing a way to integrate Fokus asset in the whole puzzle. Please, send us to the list the pointers to the most updated documents for the ETSI M2M interfaces to be implemented as discussed. >From the NGSi point of view, I'll forward you the specs that we have and you can of course request more docs or our support on this. BR -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From Tobias.Jacobs at neclab.eu Mon Apr 29 13:09:31 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Mon, 29 Apr 2013 11:09:31 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <5177FA4A.9060702@tid.es> References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> <516FF204.1000805@tid.es> <51750F1F.7070300@tid.es> <8755F290097BD941865DC4245B335D2D38F73829@DAPHNIS.office.hd> <517639B0.3020801@tid.es> <8755F290097BD941865DC4245B335D2D38F739B7@DAPHNIS.office.hd> <5177FA4A.9060702@tid.es> Message-ID: <8755F290097BD941865DC4245B335D2D38F760CF@DAPHNIS.office.hd> Hi Fermin, Sorry for the late reply; I have been absent Thursday and Friday. I think our different opinions are coming from two different underlying assumptions. What you have in mind (correct me if I am wrong) is to define associations purely syntactically and leave it to the application how to use it. They can use it to model backup, colocation, as sensor-thing relationships, as A-contains-B relationship etc. I guess this is what you mean by "flexibility". Under this assumption I would support your approach. I would even suggest then to distinguish between scope keywords for including and excluding providers. And I would maybe not use the words "source" and "target", although I have no alternative in my mind right now. However, what we have in mind is to predefine the semantics of associations, namely "A --> B means that attribute values for A can be interpreted as attribute values for B". Under this assumption it always makes sense to include providers of SOURCES and it never makes sense to include providers of TARGETS. In other words, the asymmetry here comes naturally from this predefined semantics and is nothing artificial. Under our assumption the correct way to model your example is station2 --> station1. This is because every attribute value of station2 can be interpreted as one of station1, but not vice versa. Then asking for SOURCES of station1 should do exactly what is required. Under your assumption of flexible semantics it is not important if station1 --> station2 or station2 --> station1 is used, as long as it is consistent. Do you share my view that the underlying disagreement is on "fixed vs. flexible semantics of associations"? If yes, we can continue the discussion on this basis, please find my argumentation below. - The reason why I am supporting the predefined semantics is that within the IoT Chapter the way to interpret associations will have to be predefined anyway - the IoT Broker needs to know what to do with associations. For example, your modeling with station1 --> station2 could not be processed correctly by the IoT Broker, because when receiving a request for station1 it would ask ConfMan for SOURCES of station1 and would not receive anything. - I would not design associations as a generic way of connecting pairs of entities to each other. There are more suitable standards than NGSI (e.g. OWL+SPARQL) for these things. Best regards Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Mittwoch, 24. April 2013 17:29 To: Tobias Jacobs Cc: Raihan Ul-Islam; fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Tobias, I'm not meaning symmetric in the sense of "symetric relationships" but in the sense of symmetric processing of TARGETS and SOURCES scopes. Consider the following case: station2 is the backup of station1, but station1 is not the backup of station2. In this case, the relationship "backup" is clearly asymmetric station1->station2 but, even so, a client may want to query ConfMan for "all the providers of entities associated with entity1", that is a discoverContextAttribute on station1 with scope=TARGETS that not only has to include the station1->station2 association, but also the provider for station2. Of course, you can model the association in the opossite way ("backed_by" station2->station1) but why to impose a restriction in the way the user of the ConfMan has to model its associations? Why to introduce artificial asymmetries in the processing of both ends when we don't need it (I stress the point that your IoT Broker case will work exactly the same)? On the contrary, they reduce the flexibility. Best regards, ------ Ferm?n El 23/04/2013 10:07, Tobias Jacobs escribi?: Hi Fermin, I understand your use case of symmetric associations, but this is a different kind of association with different semantics from as we have defined it up to now. The way we have defined associations up to now is that there is a specified source and a specified target. The semantics is that attribute values of the source can be interpreted as attribute values of the target, but not every attribute value of the target is can be interpreted as one of the source. So there is an inherent asymmetry. This distinction between the source and the target is where the difference in the SOURCES and TARGETS keyword comes from. In order to model symmetric associations like in your use case I see two possibilities: 1) Use the defined asymmetric associations and insert both station1 --> station2 and station2 --> station1. Then you have expressed what you want: each attribute value of station1 is one from station2 and vice versa. 2) Define a new metadata type for symmetric associations, and correspondingly a new scope type for querying those kind of associations. Note that here it is not necessary to distinguish between SOURCES and TARGETS, but you either include all associations or not. Best Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Dienstag, 23. April 2013 09:35 To: Tobias Jacobs Cc: Raihan Ul-Islam; fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Tobias, Even if beauty or clearness weren't enough (for many people, they are :), we see associations as a generic concept that goes much beyond device-thing relationships. For example, you can use associations to define symmetric relationships such as redundancy: let's think in a couple of entities (station1 and station2) at the same abstraction level (i.e. none of them is the "device" of the "thing" represented by the other) each one representing the same set of meteorological station providing a set of metrics (temperature, humidity, etc.) so if station1 fails, station2 could be used or viceversa. In this case, having the ability to get the provider of one end traversing the association from the other, no matter if the the starting end is target of source, can be very useful. I haven't dig into detailed used cases, but there are probably many others. Our point is that we want to be as flexible as possible with associations in Orion Context Broker (the piece of software the implements ConfMan GE), beyond the use case with the IoT Broker. As long as the proposed interpretation doesn't "hurt" the IoT Broker case (i.e. there is no change in the XML you propose to use for the query or update cases) we understand that there is no problem on adopting it. Best regards, ------ Ferm?n El 22/04/2013 13:32, Tobias Jacobs escribi?: Hi Fermin, Raihan is on holiday, so I answer instead. The reason why we propose not to include providers in the target set is that we see no use case where someone would ask for targets and needs context providers. The typical use case is when the IoT Broker receives an attribute value of an entity via the update operation and wants to find out which for which higher-level entity/attribute combinations the received update is relevant. The context providers are not needed for that. I understand that making it symmetric would make it somehow more beautiful and clear, but could you explain what you mean by more flexible? Best regards Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Ferm?n Gal?n M?rquez Sent: Montag, 22. April 2013 12:21 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Raihan, I haven been reading the detail the reference you send and I have realize of the slight asymmetry in TARGET and SOURCE scopes. I would propose a more symmetric processing way: * TARGETS is used when the requestor wishes to find out about the target set of a given set of entity/attribute combinations. The target set of an entity/attribute combination set is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the target set and (2) if there is an association . --> . and . is in the target set, then also . is in the target set. The TARGETS keyword is used to request any association between entity/attribute combinations from the target set, and, additionally, any context provider of any entity/attribute combination from the target set. * SOURCES is used when the requestor wishes to find out where and how information about a given set of entity/attribute combinations can be retrieved. The source set of a set of entity/attribute combinations is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the source set and (2) if there is an association . --> . and . is in the source set, then also . is in the source set. The SOURCES keyword is used to request any association between entity/attribute combinations from the source set and, additionally, any context provider of any entity/attribute combination from the source set. For your XML use case, it doesn't changes anything, as there are no providers registered for house3 in any step. However, I think is better that way, as it provides and analogous way of working for TARGET and HOUSE and more flexibility. Best regards, ------ Ferm?n El 18/04/2013 18:15, Raihan Ul-Islam escribi?: Hi Fermin, Thanks for your questions. Your interpretation of "basic implementation of associations" matches with us. Regarding your second question, If you look into the section "Retrieving Associations using NGSI-9" in the following link https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept you can get more clear view. In short, the TARGETS keyword is used to request any association between entity/attribute combinations from the target set. Therefore, only association is expected in the response of discoverContextAvailabilityRequest with target as scope. No information of context provider of any entity/attribute combination from the target set is required. I hope understand you question properly. Thanks Raihan From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: 18 April 2013 15:16 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-ngsi] how to represent associations 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: house_3 indoorTemperature Include Associations SOURCES with the following associated response: Sensor5 measurement false http://myHomeGateway22.org association1 Association [...] http://www.fi-ware.eu/NGSI/association And the following discovery in the update case: Sensor5 indoorTemperature Include Associations TARGETS with the following associated response: association1 Association [...] http://www.fi-ware.eu/NGSI/association 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; 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 is included in the ) 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 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; 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] 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 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 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: From Tobias.Jacobs at neclab.eu Mon Apr 29 15:20:17 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Mon, 29 Apr 2013 13:20:17 +0000 Subject: [Fiware-iot] Overall description of IoT GEs In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B25089058B04@EX10-MB2-MAD.hi.inet> References: <1971FF81B8E01C45991F6F92B9E3B25089058B04@EX10-MB2-MAD.hi.inet> Message-ID: <8755F290097BD941865DC4245B335D2D38F76189@DAPHNIS.office.hd> Hi Carlos, This might come too late, but actually there was progress on the IoT Broker Software in Release 2.2 as compared to release 1. The same holds for the documentation. Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Mittwoch, 24. April 2013 11:43 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Overall description of IoT GEs Dear colleagues, I was requested by the project coordination to make a summary of all modifications, on-going work and planned/re-planned deliveries of IoT GEs. I made the following list included below. Please, if you have any major comment, let me know. Thierry, I think we can use this as basic material for one of the introduction slides of IoT chapter in the forthcoming June review. ***** - BE Things Management GE Released in R1 but eliminated later on, as it has been split in two: IoT Broker & Conf.Man, - IoT Broker GE (NEC) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management - Configuration Manager GE (TID) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management A new version will be provided in R2.3 together will all documents. There will be, in principle, 3 implementations of this GE: TID, NEC (with Geo-discovery) and UoSurrey (with semantic Discovery) - BE Discovery GE: (UoSurrey). Originally planned for R2.2 but it has been eliminated as a GE (Roadmap updated accordingly on April 23th) Functionality will be delivered as part of the Configuration Manager in R2.3 (maybe it will be re-planned to R3.x). Related features/epics have been moved into the Conf.Man section with a short notice for readers. UoS is performing a review right now and features/EPICs may change in the short term. - BE Dev Man (TID, previously NSN) Planned for major R2 -> R2.3 It will be the combination of two assets (IDAS + IoT-Agent). Features/Epics to change significantly before R2.3 delivery (on-going task). - BE Advanced Connectivity: Eliminated. Functionalities will be developed as part of the BE Dev.Man. Features/Epics dropped from Roadmap by now. - BE Security: Eliminated. Functionalities are being developed/deployed as part of the overall Fi-WARE Security approach (Sec. chapter GEs). Features/Epics dropped from Roadmap by now. - GW Dev Man (Fraunhofer, previously Ericsson) This GE will be significantly updated very soon and maybe even re-planned because of Ericsson withdrawal. Fraunhofer joined us jus 1 week ago... - GW Data Handling (Orange, ATOS) There is only one GE with 2 implementations (Orange and ATOS). Architecture Wiki has been modified accordingly. Roadmap now under revision. - GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector. - GW Advanced Connectivity: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. - GW Security: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. ***** Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From ralli at tid.es Mon Apr 29 15:45:58 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 29 Apr 2013 13:45:58 +0000 Subject: [Fiware-iot] FW: [Fiware-wpa] Backlog - Sprint transition: from S2.3.1-M24 to S2.3.2-M25 In-Reply-To: <65CDBE2E7E5A964BB8BC5F4328FDE90B8904821C@EX10-MB2-MAD.hi.inet> Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508905F17A@EX10-MB2-MAD.hi.inet> Dear partners, It?s time to update the backlog, close this sprint items if finished, or shift them to the next sprint, and create new ones. Please follow the instructions bellowbefore tomorrow at 16.00h, as it was decided today during the WPL/WPA call. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: MANUEL ESCRICHE VICENTE > Fecha: lunes, 29 de abril de 2013 09:31 Para: "fiware-wpl at lists.fi-ware.eu" >, "fiware-wpa at lists.fi-ware.eu" > Asunto: [Fiware-wpa] Backlog - Sprint transition: from S2.3.1-M24 to S2.3.2-M25 Dear Partners, Let me remind you that we are finishing sprint S2.3.1-M24 and about to start S2.3.2-M25, which places us in the last two months before closing the Second Major Release. http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Releases_and_Sprints_numbering,_with_mapping_to_calendar_dates Please, update your backlog items accordingly: 1. Close the backlog items finished during M24 (if not already done) 2. Update items under execution not finished to belong to S2.3.2 3. Proceed to identify the backlog items to be delivered during S2.3.2. This task should be finished the first week of S2.3.2-M25 Let me inform you that I?m about to get a snapshot of the backlog to produce the corresponding deliverable today. I assume you didn?t miss my previous messages about sprint transitions, so there shouldn?t be major concern about the tracker containing the actual state of the backlog!! To WPLeaders, please, distribute the message to your teams!! Thanks for cooperation! Kind regards, Manuel ---------------------------- Manuel Escriche Vicente Agile Project Manager/Leader FI-WARE Initiative Telef?nica Digital Parque Tecnol?gico C/ Abraham Zacuto, 10 47151 - Boecillo Valladolid - Spain Tfno: +34.91.312.99.72 Fax: +34.983.36.75.64 http://www.tid.es ________________________________ 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From ralli at tid.es Mon Apr 29 16:17:32 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 29 Apr 2013 14:17:32 +0000 Subject: [Fiware-iot] Overall description of IoT GEs In-Reply-To: <8755F290097BD941865DC4245B335D2D38F76189@DAPHNIS.office.hd> Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089060479@EX10-MB2-MAD.hi.inet> Hi Tob?as, Good to know event at this point. I wouldn't touch too much but ensure the roadmap and backlog are consistent mainly for R2.3. We may consider that was something that was actually delivered before planned. Is this approach ok for you? BR -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: lunes, 29 de abril de 2013 15:20 Para: Carlos Ralli Ucendo >, "fiware-iot at lists.fi-ware.eu" > Asunto: RE: Overall description of IoT GEs Hi Carlos, This might come too late, but actually there was progress on the IoT Broker Software in Release 2.2 as compared to release 1. The same holds for the documentation. Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Mittwoch, 24. April 2013 11:43 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Overall description of IoT GEs Dear colleagues, I was requested by the project coordination to make a summary of all modifications, on-going work and planned/re-planned deliveries of IoT GEs. I made the following list included below. Please, if you have any major comment, let me know. Thierry, I think we can use this as basic material for one of the introduction slides of IoT chapter in the forthcoming June review. ***** - BE Things Management GE Released in R1 but eliminated later on, as it has been split in two: IoT Broker & Conf.Man, - IoT Broker GE (NEC) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management - Configuration Manager GE (TID) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management A new version will be provided in R2.3 together will all documents. There will be, in principle, 3 implementations of this GE: TID, NEC (with Geo-discovery) and UoSurrey (with semantic Discovery) - BE Discovery GE: (UoSurrey). Originally planned for R2.2 but it has been eliminated as a GE (Roadmap updated accordingly on April 23th) Functionality will be delivered as part of the Configuration Manager in R2.3 (maybe it will be re-planned to R3.x). Related features/epics have been moved into the Conf.Man section with a short notice for readers. UoS is performing a review right now and features/EPICs may change in the short term. - BE Dev Man (TID, previously NSN) Planned for major R2 -> R2.3 It will be the combination of two assets (IDAS + IoT-Agent). Features/Epics to change significantly before R2.3 delivery (on-going task). - BE Advanced Connectivity: Eliminated. Functionalities will be developed as part of the BE Dev.Man. Features/Epics dropped from Roadmap by now. - BE Security: Eliminated. Functionalities are being developed/deployed as part of the overall Fi-WARE Security approach (Sec. chapter GEs). Features/Epics dropped from Roadmap by now. - GW Dev Man (Fraunhofer, previously Ericsson) This GE will be significantly updated very soon and maybe even re-planned because of Ericsson withdrawal. Fraunhofer joined us jus 1 week ago? - GW Data Handling (Orange, ATOS) There is only one GE with 2 implementations (Orange and ATOS). Architecture Wiki has been modified accordingly. Roadmap now under revision. - GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector. - GW Advanced Connectivity: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. - GW Security: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. ***** Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From Tobias.Jacobs at neclab.eu Mon Apr 29 16:25:31 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Mon, 29 Apr 2013 14:25:31 +0000 Subject: [Fiware-iot] Overall description of IoT GEs In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B25089060479@EX10-MB2-MAD.hi.inet> References: <8755F290097BD941865DC4245B335D2D38F76189@DAPHNIS.office.hd> <1971FF81B8E01C45991F6F92B9E3B25089060479@EX10-MB2-MAD.hi.inet> Message-ID: <8755F290097BD941865DC4245B335D2D38F761FF@DAPHNIS.office.hd> Hi Carlos, The features planned and delivered for release 2.2 were FIWARE.Feature.IoT.Backend.IoTBroker.Query.Patterns FIWARE.Feature.IoT.Backend.IoTBroker.Query.Restriction FIWARE.Feature.IoT.Backend.IoTBroker.Update.IdBased They have been in the technical roadmap table for some time, so I think it would be good to be mentioned that they were also delivered, if possible. Thanks! Tobias From: CARLOS RALLI UCENDO [mailto:ralli at tid.es] Sent: Montag, 29. April 2013 16:18 To: Tobias Jacobs; fiware-iot at lists.fi-ware.eu Subject: Re: Overall description of IoT GEs Hi Tob?as, Good to know event at this point. I wouldn't touch too much but ensure the roadmap and backlog are consistent mainly for R2.3. We may consider that was something that was actually delivered before planned. Is this approach ok for you? BR -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ De: Tobias Jacobs > Fecha: lunes, 29 de abril de 2013 15:20 Para: Carlos Ralli Ucendo >, "fiware-iot at lists.fi-ware.eu" > Asunto: RE: Overall description of IoT GEs Hi Carlos, This might come too late, but actually there was progress on the IoT Broker Software in Release 2.2 as compared to release 1. The same holds for the documentation. Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Mittwoch, 24. April 2013 11:43 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Overall description of IoT GEs Dear colleagues, I was requested by the project coordination to make a summary of all modifications, on-going work and planned/re-planned deliveries of IoT GEs. I made the following list included below. Please, if you have any major comment, let me know. Thierry, I think we can use this as basic material for one of the introduction slides of IoT chapter in the forthcoming June review. ***** - BE Things Management GE Released in R1 but eliminated later on, as it has been split in two: IoT Broker & Conf.Man, - IoT Broker GE (NEC) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management - Configuration Manager GE (TID) "New" one for R2.2 but SW and documents are actually the ones of that subcomponent in R1 BE Things Management A new version will be provided in R2.3 together will all documents. There will be, in principle, 3 implementations of this GE: TID, NEC (with Geo-discovery) and UoSurrey (with semantic Discovery) - BE Discovery GE: (UoSurrey). Originally planned for R2.2 but it has been eliminated as a GE (Roadmap updated accordingly on April 23th) Functionality will be delivered as part of the Configuration Manager in R2.3 (maybe it will be re-planned to R3.x). Related features/epics have been moved into the Conf.Man section with a short notice for readers. UoS is performing a review right now and features/EPICs may change in the short term. - BE Dev Man (TID, previously NSN) Planned for major R2 -> R2.3 It will be the combination of two assets (IDAS + IoT-Agent). Features/Epics to change significantly before R2.3 delivery (on-going task). - BE Advanced Connectivity: Eliminated. Functionalities will be developed as part of the BE Dev.Man. Features/Epics dropped from Roadmap by now. - BE Security: Eliminated. Functionalities are being developed/deployed as part of the overall Fi-WARE Security approach (Sec. chapter GEs). Features/Epics dropped from Roadmap by now. - GW Dev Man (Fraunhofer, previously Ericsson) This GE will be significantly updated very soon and maybe even re-planned because of Ericsson withdrawal. Fraunhofer joined us jus 1 week ago... - GW Data Handling (Orange, ATOS) There is only one GE with 2 implementations (Orange and ATOS). Architecture Wiki has been modified accordingly. Roadmap now under revision. - GW Protocol Adapter (T.Italia) As planned before. Only one modification to be done in the roadmap (new EPIC/feature to come): develop an NGSI northbound interface/connector. - GW Advanced Connectivity: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. - GW Security: Eliminated. Functionalities will be developed as part of the GW Dev.Man. Features/Epics dropped from Roadmap by now. ***** Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli IPv6 Blog: http://the-internet6.blogspot.com.es Product Development & Innovation (Telef?nica Digital) Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ 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: From thierry.nagellen at orange.com Tue Apr 30 10:29:54 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Tue, 30 Apr 2013 08:29:54 +0000 Subject: [Fiware-iot] State of the Art deliverable Message-ID: <407_1367310595_517F8103_407_11382_1_976A65C5A08ADF49B9A8523F7F81925C0DFDD3@PEXCVZYM13.corporate.adroot.infra.ftgroup> Dear all, As discuss during our last weekly meeting, here are the guidelines for the deliverable D2.6.2 to update the State-of-the-Art we provided in the original DoW (in yellow in the attached document). The main idea is not to provide an hundred pages book for the IoT chapter but to include new things which occur since we wrote the DoW. Maybe the initial sub-chapters seem not relevant today but to avoid a hard work revising everything, I propose to keep it as it is and to develop new inputs into 3 categories: 1. General inputs regarding IoT area (and we could describe here especially some standards improvements or new emerging standards) 2. Inputs from other projects of FI PPP (for some of us who were involved in phase 1 projects or are now involved in phase 2 projects => for this second issue, see below) 3. Inputs from other research projects (FP7, Eureka projects or national projects) And we can add this new content in the 4 sub-chapters we have: IoT Communication, IoT Resources Management, IoT Data Handling and IoT Process Automation. Based on what we are currently doing, I propose to distribute the work between partners in this way: * IoT Communciation: Telecom Italia, Fokus * IoT Resources Management: NEC, Telefonica * IoT Data Handling: Orange, Atos * IoT Process Automation: University of Surrey, SAP Of course we can provide inputs for all sections if we have some to support our partners. If you feel more comfortable with another section please feel free to comment it but at the end we will have to fulfill every section. Regarding Phase 2 projects, it was decided during the negotiation phase and then discussed during the Architect week in Madrid that they will share their DoW with us. Telefonica has collected the DoW (except for FITMAN project which wants to sign first the PPP Collaboration Agreement). So we can use their State of the Art to provide a new content. This is also very useful for us to understand what could be their expectations regarding IoT GEs. You can find these DoWs in the Fi-Ware private project: https://forge.fi-ware.eu/docman/?group_id=27# [cid:part1.06030601.08090108 at tid.es] Of course there are not Public Documents but we can use them internally because we have signed the Collaboration Agreement! What about the deadlines? I would receive your contributions for the 6th of May because I have to consolidate everything for the 7th. Hereunder are the milestones for Telefonica to submit this deliverable to EC and reviewers. * May, 7 - Contributions from chapters to be sent by email (consolidated in a single doc per WP) * May, 10 - Peer Review ready (academia partners) * May, 17 - Feedback incorporated * May, 20 - Delivery Thanks for your support. Thierry Nagellen Program Manager Future Internet Orange Labs Networks & Carriers 905 rue Albert Einstein 06921 Sophia Antipolis Cedex +33 492 94 52 84 +33 679 85 08 44 _________________________________________________________________________________________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 13197 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: D 2 6 2 State of the Art Analysis Emerging Technologies.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 423007 bytes Desc: D 2 6 2 State of the Art Analysis Emerging Technologies.docx URL: From fano.ramparany at orange.com Tue Apr 30 18:23:10 2013 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Tue, 30 Apr 2013 16:23:10 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <8755F290097BD941865DC4245B335D2D38F760CF@DAPHNIS.office.hd> References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> <516FF204.1000805@tid.es> <51750F1F.7070300@tid.es> <8755F290097BD941865DC4245B335D2D38F73829@DAPHNIS.office.hd> <517639B0.3020801@tid.es> <8755F290097BD941865DC4245B335D2D38F739B7@DAPHNIS.office.hd> <5177FA4A.9060702@tid.es> <8755F290097BD941865DC4245B335D2D38F760CF@DAPHNIS.office.hd> Message-ID: <2160_1367338991_517FEFEF_2160_13994_1_DC254E6D1212F24EAE0D7766A11FE2890B17AE@PEXCVZYM12.corporate.adroot.infra.ftgroup> Hi Tobias and Fermin, If associations are named (see one of my earlier mail), a specific semantic (to be agreed by parties sharing these descriptions) can be attached to them which at the same time gives the flexibility Fermin is looking an enables a predefined semantics as you require. For instance in this association: A -[isAttributeProxyFor]->B , A and B are linked with the association named "isAttributeProxyFor", and the semantics of this association is that "attribute values for A can be interpreted as attribute values for B". Best regards, Fano De : fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] De la part de Tobias Jacobs Envoy? : lundi 29 avril 2013 13:10 ? : Ferm?n Gal?n M?rquez Cc : fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-ngsi] [Fiware-iot] how to represent associations Hi Fermin, Sorry for the late reply; I have been absent Thursday and Friday. I think our different opinions are coming from two different underlying assumptions. What you have in mind (correct me if I am wrong) is to define associations purely syntactically and leave it to the application how to use it. They can use it to model backup, colocation, as sensor-thing relationships, as A-contains-B relationship etc. I guess this is what you mean by "flexibility". Under this assumption I would support your approach. I would even suggest then to distinguish between scope keywords for including and excluding providers. And I would maybe not use the words "source" and "target", although I have no alternative in my mind right now. However, what we have in mind is to predefine the semantics of associations, namely "A --> B means that attribute values for A can be interpreted as attribute values for B". Under this assumption it always makes sense to include providers of SOURCES and it never makes sense to include providers of TARGETS. In other words, the asymmetry here comes naturally from this predefined semantics and is nothing artificial. Under our assumption the correct way to model your example is station2 --> station1. This is because every attribute value of station2 can be interpreted as one of station1, but not vice versa. Then asking for SOURCES of station1 should do exactly what is required. Under your assumption of flexible semantics it is not important if station1 --> station2 or station2 --> station1 is used, as long as it is consistent. Do you share my view that the underlying disagreement is on "fixed vs. flexible semantics of associations"? If yes, we can continue the discussion on this basis, please find my argumentation below. - The reason why I am supporting the predefined semantics is that within the IoT Chapter the way to interpret associations will have to be predefined anyway - the IoT Broker needs to know what to do with associations. For example, your modeling with station1 --> station2 could not be processed correctly by the IoT Broker, because when receiving a request for station1 it would ask ConfMan for SOURCES of station1 and would not receive anything. - I would not design associations as a generic way of connecting pairs of entities to each other. There are more suitable standards than NGSI (e.g. OWL+SPARQL) for these things. Best regards Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Mittwoch, 24. April 2013 17:29 To: Tobias Jacobs Cc: Raihan Ul-Islam; fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Tobias, I'm not meaning symmetric in the sense of "symetric relationships" but in the sense of symmetric processing of TARGETS and SOURCES scopes. Consider the following case: station2 is the backup of station1, but station1 is not the backup of station2. In this case, the relationship "backup" is clearly asymmetric station1->station2 but, even so, a client may want to query ConfMan for "all the providers of entities associated with entity1", that is a discoverContextAttribute on station1 with scope=TARGETS that not only has to include the station1->station2 association, but also the provider for station2. Of course, you can model the association in the opossite way ("backed_by" station2->station1) but why to impose a restriction in the way the user of the ConfMan has to model its associations? Why to introduce artificial asymmetries in the processing of both ends when we don't need it (I stress the point that your IoT Broker case will work exactly the same)? On the contrary, they reduce the flexibility. Best regards, ------ Ferm?n El 23/04/2013 10:07, Tobias Jacobs escribi?: Hi Fermin, I understand your use case of symmetric associations, but this is a different kind of association with different semantics from as we have defined it up to now. The way we have defined associations up to now is that there is a specified source and a specified target. The semantics is that attribute values of the source can be interpreted as attribute values of the target, but not every attribute value of the target is can be interpreted as one of the source. So there is an inherent asymmetry. This distinction between the source and the target is where the difference in the SOURCES and TARGETS keyword comes from. In order to model symmetric associations like in your use case I see two possibilities: 1) Use the defined asymmetric associations and insert both station1 --> station2 and station2 --> station1. Then you have expressed what you want: each attribute value of station1 is one from station2 and vice versa. 2) Define a new metadata type for symmetric associations, and correspondingly a new scope type for querying those kind of associations. Note that here it is not necessary to distinguish between SOURCES and TARGETS, but you either include all associations or not. Best Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Dienstag, 23. April 2013 09:35 To: Tobias Jacobs Cc: Raihan Ul-Islam; fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Tobias, Even if beauty or clearness weren't enough (for many people, they are :), we see associations as a generic concept that goes much beyond device-thing relationships. For example, you can use associations to define symmetric relationships such as redundancy: let's think in a couple of entities (station1 and station2) at the same abstraction level (i.e. none of them is the "device" of the "thing" represented by the other) each one representing the same set of meteorological station providing a set of metrics (temperature, humidity, etc.) so if station1 fails, station2 could be used or viceversa. In this case, having the ability to get the provider of one end traversing the association from the other, no matter if the the starting end is target of source, can be very useful. I haven't dig into detailed used cases, but there are probably many others. Our point is that we want to be as flexible as possible with associations in Orion Context Broker (the piece of software the implements ConfMan GE), beyond the use case with the IoT Broker. As long as the proposed interpretation doesn't "hurt" the IoT Broker case (i.e. there is no change in the XML you propose to use for the query or update cases) we understand that there is no problem on adopting it. Best regards, ------ Ferm?n El 22/04/2013 13:32, Tobias Jacobs escribi?: Hi Fermin, Raihan is on holiday, so I answer instead. The reason why we propose not to include providers in the target set is that we see no use case where someone would ask for targets and needs context providers. The typical use case is when the IoT Broker receives an attribute value of an entity via the update operation and wants to find out which for which higher-level entity/attribute combinations the received update is relevant. The context providers are not needed for that. I understand that making it symmetric would make it somehow more beautiful and clear, but could you explain what you mean by more flexible? Best regards Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Ferm?n Gal?n M?rquez Sent: Montag, 22. April 2013 12:21 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Dear Raihan, I haven been reading the detail the reference you send and I have realize of the slight asymmetry in TARGET and SOURCE scopes. I would propose a more symmetric processing way: * TARGETS is used when the requestor wishes to find out about the target set of a given set of entity/attribute combinations. The target set of an entity/attribute combination set is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the target set and (2) if there is an association . --> . and . is in the target set, then also . is in the target set. The TARGETS keyword is used to request any association between entity/attribute combinations from the target set, and, additionally, any context provider of any entity/attribute combination from the target set. * SOURCES is used when the requestor wishes to find out where and how information about a given set of entity/attribute combinations can be retrieved. The source set of a set of entity/attribute combinations is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the source set and (2) if there is an association . --> . and . is in the source set, then also . is in the source set. The SOURCES keyword is used to request any association between entity/attribute combinations from the source set and, additionally, any context provider of any entity/attribute combination from the source set. For your XML use case, it doesn't changes anything, as there are no providers registered for house3 in any step. However, I think is better that way, as it provides and analogous way of working for TARGET and HOUSE and more flexibility. Best regards, ------ Ferm?n El 18/04/2013 18:15, Raihan Ul-Islam escribi?: Hi Fermin, Thanks for your questions. Your interpretation of "basic implementation of associations" matches with us. Regarding your second question, If you look into the section "Retrieving Associations using NGSI-9" in the following link https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept you can get more clear view. In short, the TARGETS keyword is used to request any association between entity/attribute combinations from the target set. Therefore, only association is expected in the response of discoverContextAvailabilityRequest with target as scope. No information of context provider of any entity/attribute combination from the target set is required. I hope understand you question properly. Thanks Raihan From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: 18 April 2013 15:16 To: Raihan Ul-Islam Cc: fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-ngsi] how to represent associations 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: house_3 indoorTemperature Include Associations SOURCES with the following associated response: Sensor5 measurement false http://myHomeGateway22.org association1 Association [...] http://www.fi-ware.eu/NGSI/association And the following discovery in the update case: Sensor5 indoorTemperature Include Associations TARGETS with the following associated response: association1 Association [...] http://www.fi-ware.eu/NGSI/association 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; 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 is included in the ) 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 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; 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] 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 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 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 _________________________________________________________________________________________________________________________ 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: