From t.elsaleh at surrey.ac.uk Wed May 1 10:17:46 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Wed, 1 May 2013 09:17:46 +0100 Subject: [Fiware-iot] PhC today? Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B105@EXMB05CMS.surrey.ac.uk> Hello All, Is there a PhC today? or have the PhC details been changed ? Best regards, Tarek -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralli at tid.es Wed May 1 10:41:51 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 01 May 2013 08:41:51 +0000 Subject: [Fiware-iot] PhC today? In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B105@EXMB05CMS.surrey.ac.uk> Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089062E45@EX10-MB2-MAD.hi.inet> There is no PhC as long as it is a day off in most places, Tarek. 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: "t.elsaleh at surrey.ac.uk" > Fecha: mi?rcoles, 1 de mayo de 2013 10:17 Para: "fiware-iot at lists.fi-ware.eu" > Asunto: [Fiware-iot] PhC today? Hello All, Is there a PhC today? or have the PhC details been changed ? 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 Tobias.Jacobs at neclab.eu Thu May 2 09:59:53 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Thu, 2 May 2013 07:59:53 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <2160_1367338991_517FEFEF_2160_13994_1_DC254E6D1212F24EAE0D7766A11FE2890B17AE@PEXCVZYM12.corporate.adroot.infra.ftgroup> 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> <2160_1367338991_517FEFEF_2160_13994_1_DC254E6D1212F24EAE0D7766A11FE2890B17AE@PEXCVZYM12.corporate.adroot.infra.ftgroup> Message-ID: <8755F290097BD941865DC4245B335D2D38F7642D@DAPHNIS.office.hd> Hi Fano, What you propose, as far as I interpret it, is to introduce the possibility of registering arbitrary triples (subject, predicate, object), where subject and object are entities. I am a bit skeptical about this, because - NGSI does not have an appropriate query language for this. NGSI has been designed on purpose as an interface with a simple data model and simple query language. - The difference between NGSI 9 and 10 would become blurry, because these triples represent rather information than just availability information. The purpose of NGSI 9 has always been to exchange information about how information can be accessed, but not the information itself. If other relations between entities are needed, I would rather use predefined attributes to encode this. Then this information can be exchanged using NGSI 10. Best Tobias From: fano.ramparany at orange.com [mailto:fano.ramparany at orange.com] Sent: Dienstag, 30. April 2013 18:23 To: Tobias Jacobs; 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] [Fiware-iot] how to represent associations 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: From fano.ramparany at orange.com Thu May 2 10:11:50 2013 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Thu, 2 May 2013 08:11:50 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <8755F290097BD941865DC4245B335D2D38F7642D@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> <2160_1367338991_517FEFEF_2160_13994_1_DC254E6D1212F24EAE0D7766A11FE2890B17AE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8755F290097BD941865DC4245B335D2D38F7642D@DAPHNIS.office.hd> Message-ID: <2022_1367482312_51821FC8_2022_194_1_DC254E6D1212F24EAE0D7766A11FE2890B1D1D@PEXCVZYM12.corporate.adroot.infra.ftgroup> Hi Tobias and all, My proposal aims at representing the information and making sure that the clients interpret this information correctly. It doesn't requires that this representation be query-able. Best regards, Fano De : Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] Envoy? : jeudi 2 mai 2013 10:00 ? : RAMPARANY Fano OLNC/OLPS; 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 Fano, What you propose, as far as I interpret it, is to introduce the possibility of registering arbitrary triples (subject, predicate, object), where subject and object are entities. I am a bit skeptical about this, because - NGSI does not have an appropriate query language for this. NGSI has been designed on purpose as an interface with a simple data model and simple query language. - The difference between NGSI 9 and 10 would become blurry, because these triples represent rather information than just availability information. The purpose of NGSI 9 has always been to exchange information about how information can be accessed, but not the information itself. If other relations between entities are needed, I would rather use predefined attributes to encode this. Then this information can be exchanged using NGSI 10. Best Tobias From: fano.ramparany at orange.com [mailto:fano.ramparany at orange.com] Sent: Dienstag, 30. April 2013 18:23 To: Tobias Jacobs; 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] [Fiware-iot] how to represent associations 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. _________________________________________________________________________________________________________________________ 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 wafa.soubra at orange.com Thu May 2 15:25:36 2013 From: wafa.soubra at orange.com (wafa.soubra at orange.com) Date: Thu, 2 May 2013 13:25:36 +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: <6896_1367501137_51826951_6896_113_1_ED0C49DD0B403E41975CD998B541E17C06F0C09C@PEXCVZYM11.corporate.adroot.infra.ftgroup> Dear Sebastian, The GE ? GW Advanced Connectivity" was eliminated and it will be developed as part of the GW Dev. Man. (cf. mail below). Knowing that the 2 capabilities specified in ETSI M2M, GSC (Gateway Communication Selection) & GREM (Gateway Remote Entity Management), are not part of the deliverable of OpennMTC on the testbed, I was wondering how the connectivity through OpenMTC (GSCL side) will be managed in Fi-Ware ? As far as I understand, the GRAR capability gives you the reachability status of an M2M Device, so what does happen if the device is sleeping (not connected)? How data to/from the device will be managed? Maybe I misunderstood something, could you please clarify this to me? Thanks. Best Regards, Wafa. 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 11:43 ? : fiware-iot at lists.fi-ware.eu Objet : [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 _________________________________________________________________________________________________________________________ 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 sebastian.wahle at fokus.fraunhofer.de Thu May 2 16:02:56 2013 From: sebastian.wahle at fokus.fraunhofer.de (Wahle, Sebastian) Date: Thu, 2 May 2013 14:02:56 +0000 Subject: [Fiware-iot] Overall description of IoT GEs In-Reply-To: <6896_1367501137_51826951_6896_113_1_ED0C49DD0B403E41975CD998B541E17C06F0C09C@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <1971FF81B8E01C45991F6F92B9E3B25089058B04@EX10-MB2-MAD.hi.inet> <6896_1367501137_51826951_6896_113_1_ED0C49DD0B403E41975CD998B541E17C06F0C09C@PEXCVZYM11.corporate.adroot.infra.ftgroup> Message-ID: Dear Wafa, The gateway acts as an aggregation point. Applications can retrieve data from sensors via the resources stored in the gateway. For this, applications can request information via dedicated requests to the gateway or subscribe to specific resources. In the subscribe/notify case, the gateway will notify subscribed applications in case new data is available. This means that the gateway can always respond with the most recent data that it has received from the device. Triggering sleeping devices to wake up and send data upon request requires an advanced management infrastructure that we cannot deliver as part of the gateway. Also, it of course requires devices that support such triggering in the first place. Do you have specific devices in mind that need to be supported? Best, Sebastian Von: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Im Auftrag von wafa.soubra at orange.com Gesendet: Donnerstag, 2. Mai 2013 15:26 An: fiware-iot at lists.fi-ware.eu Betreff: Re: [Fiware-iot] Overall description of IoT GEs Dear Sebastian, The GE ? GW Advanced Connectivity" was eliminated and it will be developed as part of the GW Dev. Man. (cf. mail below). Knowing that the 2 capabilities specified in ETSI M2M, GSC (Gateway Communication Selection) & GREM (Gateway Remote Entity Management), are not part of the deliverable of OpennMTC on the testbed, I was wondering how the connectivity through OpenMTC (GSCL side) will be managed in Fi-Ware ? As far as I understand, the GRAR capability gives you the reachability status of an M2M Device, so what does happen if the device is sleeping (not connected)? How data to/from the device will be managed? Maybe I misunderstood something, could you please clarify this to me? Thanks. Best Regards, Wafa. 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 11:43 ? : fiware-iot at lists.fi-ware.eu Objet : [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 _________________________________________________________________________________________________________________________ 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 fano.ramparany at orange.com Thu May 2 17:13:19 2013 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Thu, 2 May 2013 15:13:19 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <8755F290097BD941865DC4245B335D2D38F764D0@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> <2160_1367338991_517FEFEF_2160_13994_1_DC254E6D1212F24EAE0D7766A11FE2890B17AE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8755F290097BD941865DC4245B335D2D38F7642D@DAPHNIS.office.hd> <2022_1367482312_51821FC8_2022_194_1_DC254E6D1212F24EAE0D7766A11FE2890B1D1D@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8755F290097BD941865DC4245B335D2D38F764D0@DAPHNIS.office.hd> Message-ID: <1513_1367507600_51828290_1513_5513_1_DC254E6D1212F24EAE0D7766A11FE2890B217D@PEXCVZYM12.corporate.adroot.infra.ftgroup> Hi Tobias, I feel quite comfortable with your proposal of a fixed semantics for associations without a need for naming them. You could then consider my association naming proposal as a possible option we might explore, if in the future we need to handle different semantics. To answer your question, I'm thinking of the "contains" association between a "car" and its "motor engine". In this case there are only some attributes which are shared between the two entities, such as the "location" attributes. Regards, Fano De : Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] Envoy? : jeudi 2 mai 2013 11:39 ? : RAMPARANY Fano OLNC/OLPS Objet : RE: [Fiware-ngsi] [Fiware-iot] how to represent associations Hi Fano, In the FI-WARE IoT architecture, applications would interact with the system by NGSI10. So they need to know how to correctly interpret the entities and attributes there. When there is only a single way to interpret associations (which is what I am proposing) then there is no need for additional naming conventions. But maybe there is something I have not understood yet. Can you make an example of two different possible association interpretations that would be important to distinguish by using some name field beyond the already existing metadata name field? Best Tobias From: fano.ramparany at orange.com [mailto:fano.ramparany at orange.com] Sent: Donnerstag, 2. Mai 2013 10:12 To: Tobias Jacobs; 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] [Fiware-iot] how to represent associations Hi Tobias and all, My proposal aims at representing the information and making sure that the clients interpret this information correctly. It doesn't requires that this representation be query-able. Best regards, Fano De : Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] Envoy? : jeudi 2 mai 2013 10:00 ? : RAMPARANY Fano OLNC/OLPS; 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 Fano, What you propose, as far as I interpret it, is to introduce the possibility of registering arbitrary triples (subject, predicate, object), where subject and object are entities. I am a bit skeptical about this, because - NGSI does not have an appropriate query language for this. NGSI has been designed on purpose as an interface with a simple data model and simple query language. - The difference between NGSI 9 and 10 would become blurry, because these triples represent rather information than just availability information. The purpose of NGSI 9 has always been to exchange information about how information can be accessed, but not the information itself. If other relations between entities are needed, I would rather use predefined attributes to encode this. Then this information can be exchanged using NGSI 10. Best Tobias From: fano.ramparany at orange.com [mailto:fano.ramparany at orange.com] Sent: Dienstag, 30. April 2013 18:23 To: Tobias Jacobs; 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] [Fiware-iot] how to represent associations 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. _________________________________________________________________________________________________________________________ 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 wafa.soubra at orange.com Thu May 2 17:16:17 2013 From: wafa.soubra at orange.com (wafa.soubra at orange.com) Date: Thu, 2 May 2013 15:16:17 +0000 Subject: [Fiware-iot] Overall description of IoT GEs In-Reply-To: References: <1971FF81B8E01C45991F6F92B9E3B25089058B04@EX10-MB2-MAD.hi.inet> <6896_1367501137_51826951_6896_113_1_ED0C49DD0B403E41975CD998B541E17C06F0C09C@PEXCVZYM11.corporate.adroot.infra.ftgroup> Message-ID: <12900_1367507778_51828342_12900_6523_1_ED0C49DD0B403E41975CD998B541E17C06F0C10B@PEXCVZYM11.corporate.adroot.infra.ftgroup> Thanks for the information provided. Currently, I don't think about a specific device. But you answered my question that the features of the gateway (GSCL) will deal only with connected devices. Regards, Wafa. De : Wahle, Sebastian [mailto:sebastian.wahle at fokus.fraunhofer.de] Envoy? : jeudi 2 mai 2013 16:03 ? : SOUBRA Wafa OLNC/OLPS; fiware-iot at lists.fi-ware.eu Objet : AW: [Fiware-iot] Overall description of IoT GEs Dear Wafa, The gateway acts as an aggregation point. Applications can retrieve data from sensors via the resources stored in the gateway. For this, applications can request information via dedicated requests to the gateway or subscribe to specific resources. In the subscribe/notify case, the gateway will notify subscribed applications in case new data is available. This means that the gateway can always respond with the most recent data that it has received from the device. Triggering sleeping devices to wake up and send data upon request requires an advanced management infrastructure that we cannot deliver as part of the gateway. Also, it of course requires devices that support such triggering in the first place. Do you have specific devices in mind that need to be supported? Best, Sebastian Von: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Im Auftrag von wafa.soubra at orange.com Gesendet: Donnerstag, 2. Mai 2013 15:26 An: fiware-iot at lists.fi-ware.eu Betreff: Re: [Fiware-iot] Overall description of IoT GEs Dear Sebastian, The GE ? GW Advanced Connectivity" was eliminated and it will be developed as part of the GW Dev. Man. (cf. mail below). Knowing that the 2 capabilities specified in ETSI M2M, GSC (Gateway Communication Selection) & GREM (Gateway Remote Entity Management), are not part of the deliverable of OpennMTC on the testbed, I was wondering how the connectivity through OpenMTC (GSCL side) will be managed in Fi-Ware ? As far as I understand, the GRAR capability gives you the reachability status of an M2M Device, so what does happen if the device is sleeping (not connected)? How data to/from the device will be managed? Maybe I misunderstood something, could you please clarify this to me? Thanks. Best Regards, Wafa. 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 11:43 ? : fiware-iot at lists.fi-ware.eu Objet : [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 _________________________________________________________________________________________________________________________ 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 Fri May 3 09:58:04 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Fri, 03 May 2013 07:58:04 +0000 Subject: [Fiware-iot] State of the Art deliverable In-Reply-To: <407_1367310595_517F8103_407_11382_1_976A65C5A08ADF49B9A8523F7F81925C0DFDD3@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089065408@EX10-MB2-MAD.hi.inet> HI Thierry, All, One relevant clarification I discussed internally about the contents of this deliverable. While all details and deadlines mentioned by you, Thierry, are true the key idea of this deliverable is to get info mainly from RTD projects *out* of the FP-7/EC sphere. Of course, we can mention FP7/EC relevant initiatives but the idea is to get the state of the art from the overall innovation scene. We might get some ideas from the Phase II Ucs DoWs but again we want to identify actions/projects/decisions out of the EU funded projects field. 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: "thierry.nagellen at orange.com" > Fecha: martes, 30 de abril de 2013 10:29 Para: "fiware-iot at lists.fi-ware.eu" > Asunto: [Fiware-iot] State of the Art deliverable 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. ________________________________ 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: 13197 bytes Desc: image001.png URL: From fermin at tid.es Mon May 6 17:15:29 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Mon, 06 May 2013 17:15:29 +0200 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: <5187C911.5000600@tid.es> Dear Tobias, I think that you are mostly right in your "motivations" analysis. To complete it, take into account that the piece of software that implements ConfMan in IoT chapter (named Orion Context Broker) is used in other places. So, what I'm trying to avoid is to develop a functionality (with the cost in design, coding and testing that it involves) that is only useful in a single use case, i.e. the one from IoT chapter. Note that from Orion Context Broker point of view, IoT Broker is just an application and I would like to avoid "hardwire" a semantic only needed by a particular application (because in that case, every application will potentially needs modifications in the Orion Context Broker code). Thus, we have to find a way that at the same time doesn't hardwire predefined semantics in the Orion Context Broker only useful in IoT chapter (due to, as I mention before, the development of Orion Context Broker is not driven exclusively by IoT chapter requirements) and at the same time fulfills the IoTBroker-ConfMan case. I honestly think the way I propose matches both objectives. In particular, I think it that it fulfills the IoTBroker-ConfMan in the definition you did in the .doc with the query and update cases, but given that I have mention that before in several emails but this discussion continues maybe I'm wrong (in that case, please tell me the case/step/etc. in which I'm wrong). You are right in that the "stations backups" case is not supported by IoT Broker but it has been never supposed to support it. However, other applications build on top the Orion Context Broker will take advantage of flexible association semantics to support it, without breaking the IoT Broker use case. Regarding the OWL+SPARQL alternative, I don't know the technology well enough in order to have an opinion on that and how it compares with the one that we are currently on the table. Best regards, ------- Ferm?n El 29/04/2013 13:09, Tobias Jacobs escribi?: 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 ________________________________ 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 May 7 09:27:19 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Tue, 7 May 2013 07:27:19 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <5187C911.5000600@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> <8755F290097BD941865DC4245B335D2D38F760CF@DAPHNIS.office.hd> <5187C911.5000600@tid.es> Message-ID: <8755F290097BD941865DC4245B335D2D38F76A15@DAPHNIS.office.hd> Hi Fermin, I hope you had some nice vacations. I understand your need to have a flexible model for entity-entity relationships, but I am not yet convinced that associations in particular and NGSI-9 in general are the appropriate vehicle for it. Could you give an example of a relationship that would actually need the "symmetry" between source and target? (As said, the backup example can be easily modeled by the "asymmetric" solution using station2 --> station1 and then even the IoT Broker could understand it correctly.) Best Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Montag, 6. Mai 2013 17:15 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 think that you are mostly right in your "motivations" analysis. To complete it, take into account that the piece of software that implements ConfMan in IoT chapter (named Orion Context Broker) is used in other places. So, what I'm trying to avoid is to develop a functionality (with the cost in design, coding and testing that it involves) that is only useful in a single use case, i.e. the one from IoT chapter. Note that from Orion Context Broker point of view, IoT Broker is just an application and I would like to avoid "hardwire" a semantic only needed by a particular application (because in that case, every application will potentially needs modifications in the Orion Context Broker code). Thus, we have to find a way that at the same time doesn't hardwire predefined semantics in the Orion Context Broker only useful in IoT chapter (due to, as I mention before, the development of Orion Context Broker is not driven exclusively by IoT chapter requirements) and at the same time fulfills the IoTBroker-ConfMan case. I honestly think the way I propose matches both objectives. In particular, I think it that it fulfills the IoTBroker-ConfMan in the definition you did in the .doc with the query and update cases, but given that I have mention that before in several emails but this discussion continues maybe I'm wrong (in that case, please tell me the case/step/etc. in which I'm wrong). You are right in that the "stations backups" case is not supported by IoT Broker but it has been never supposed to support it. However, other applications build on top the Orion Context Broker will take advantage of flexible association semantics to support it, without breaking the IoT Broker use case. Regarding the OWL+SPARQL alternative, I don't know the technology well enough in order to have an opinion on that and how it compares with the one that we are currently on the table. Best regards, ------- Ferm?n El 29/04/2013 13:09, Tobias Jacobs escribi?: 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 ________________________________ 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 May 7 09:37:07 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Tue, 7 May 2013 07:37:07 +0000 Subject: [Fiware-iot] Urgent actions from last Architecture Board Message-ID: <16173_1367912229_5188AF24_16173_5242_1_976A65C5A08ADF49B9A8523F7F81925C0E098E@PEXCVZYM13.corporate.adroot.infra.ftgroup> Dear all, You can find in attachment the minutes from the last Architecture Board (last Friday). We have to urgent actions to manage to be up to date for the new UC projects and to push them to use our GEs. 1. To check the list of GE which will be available in release 2 (including 2.3) and update the Googledoc spreadsheet 2. Provide dates for webinars on the use of the GE instances before Thursday 9! (this Thursday) because UC Projects will give us the list of attendees one week later. Thanks for your support BR Thierry De : fiware-pcc-bounces at lists.fi-ware.eu [mailto:fiware-pcc-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro Envoy? : mardi 7 mai 2013 09:00 ? : fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu; fiware at lists.fi-ware.eu; fiware-pcc at lists.fi-ware.eu Objet : [Fiware-pcc] Draft minutes of the last FI-PPP AB meeting and related URGENT Action Points on Chapter teams and FI-WARE GEi owners Dear all, Last Friday, May 3rd, we celebrated the first FI-PPP AB virtual meeting involving the new projects in phase 2 of the FI-PPP. You can take a look at the minutes available at: https://docs.google.com/document/d/1_DXfn7qSY4UEidfBv3E9MhplU1wcVOzkEpWhQ_0QK-M/edit?usp=sharing There are two URGENT Action Points that we have to finalize along this week so I ask for the cooperation of the several FI-WARE chapter teams and GEi owners: * Updating spreadsheet about "FI-WARE Testbed/GEis planned usage" available at https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdEd6bGhLQWtNai1jeGN5UnJMeEdxZ0E&usp=sharing * All chapter teams have to review the sheets linked "FI-WARE GEi (2nd Release) planned usage in Phase 1/2" if they haven't done so yet and send me their comments so that I can implement the proposed changes: * @I2ND was going to provide the name of FI-WARE GE and GEis (two first columns) for rows that have to be inserted for the new FI-WARE GEis in 2nd Release * @Apps was going to provide final feedback on whether it would make sense to split the package linked to Business Framework or not * Remember that this is to collect info about planned usage by UC projects, that's why it makes sense to have some rows in the sheets linked to packages of GEis / functionalities (e.g., Cloud) than as individual GEis * Please, don't edit yourself, forward feedback to me through your chapter leader * VERY IMPORTANT for FI-WARE GEi owners: Proposal on first series of webinars regarding FI-WARE GEis already available for UC projects in the Testbed (or to be available by end of May): * Deadline: Thursday May 9 EOB. * You should edit the following spreadsheet in Google docs yourself: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdF9aeWphSkFkWjJRQ3pPVW1PVURLX3c&usp=sharing * You just have to provide two alternative dates during the period from May 20th until June 14th. Try to make them in two alternative weeks. * Note that these webinars are not mandatory for all FI-WARE GEis but strongly recommended for GEis/functionality that can be already demonstrated in the Testbed while in the webinars or at least presented as mockup (e.g., this might be useful for some new Cloud functions) * You can select your favorite bridge tools. How do you declare the tools you plan to use so that people will connect ? Defining a hashtag * This will be used as an Id for the bridge/webex details to be provided in sheet "Logistics details" * It will be referred from the cell associated to the row linked to your GEi and the column "Logistic details" of sheet "FI-WARE GEi (2nd Release) - series of webinars" * We advise you also to use this hashtag in posts to the @FIware twitter account during the webinar. It may be helpful to collect questions on-line so people do not necessarily interrupt you (you can watch the twitter account and then decide when to answer those questions) * UC projects will declare their interest to attend the different webinars along the week of May 17th Please pay attention to this two urgent actions. We believe that their implementation can be rather useful for a successful project review mid June. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect You can follow FI-WARE at: 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 _________________________________________________________________________________________________________________________ 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: MinutesFI-PPPABMay2013.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 35369 bytes Desc: MinutesFI-PPPABMay2013.docx URL: From t.elsaleh at surrey.ac.uk Tue May 7 12:06:27 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Tue, 7 May 2013 11:06:27 +0100 Subject: [Fiware-iot] State of the Art deliverable In-Reply-To: <407_1367310595_517F8103_407_11382_1_976A65C5A08ADF49B9A8523F7F81925C0DFDD3@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <407_1367310595_517F8103_407_11382_1_976A65C5A08ADF49B9A8523F7F81925C0DFDD3@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B4FC@EXMB05CMS.surrey.ac.uk> Hello Thierry, Attached is the SOTA contribution from UNIS. 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: 30 April 2013 09:30 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] State of the Art deliverable Importance: High 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:image001.png at 01CE4B12.EB6E1E00] 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____WP5_UNIS--RM_and_PA.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 429943 bytes Desc: D 2 6 2 State of the Art Analysis Emerging Technologies____WP5_UNIS--RM_and_PA.docx URL: From Tobias.Jacobs at neclab.eu Tue May 7 13:27:22 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Tue, 7 May 2013 11:27:22 +0000 Subject: [Fiware-iot] State of the Art deliverable In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B4FC@EXMB05CMS.surrey.ac.uk> References: <407_1367310595_517F8103_407_11382_1_976A65C5A08ADF49B9A8523F7F81925C0DFDD3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B4FC@EXMB05CMS.surrey.ac.uk> Message-ID: <8755F290097BD941865DC4245B335D2D38F76B02@DAPHNIS.office.hd> Hi Thierry, and here is the update from NEC regarding Task 5.2 (Resource Management). We basically described the achievements of the IoT-A project. Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of t.elsaleh at surrey.ac.uk Sent: Dienstag, 7. Mai 2013 12:06 To: thierry.nagellen at orange.com Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] State of the Art deliverable Hello Thierry, Attached is the SOTA contribution from UNIS. Best regards, Tarek 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: 30 April 2013 09:30 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] State of the Art deliverable Importance: High 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 rel evant to ork 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 belo w)< MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo2'>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 f eel free 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.06 /span>

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.

* 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: SOTA_update2013_NEC.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 429009 bytes Desc: SOTA_update2013_NEC.docx URL: From thierry.nagellen at orange.com Tue May 7 15:24:51 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Tue, 7 May 2013 13:24:51 +0000 Subject: [Fiware-iot] State of the Art deliverable In-Reply-To: <8755F290097BD941865DC4245B335D2D38F76B02@DAPHNIS.office.hd> References: <407_1367310595_517F8103_407_11382_1_976A65C5A08ADF49B9A8523F7F81925C0DFDD3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B4FC@EXMB05CMS.surrey.ac.uk> <8755F290097BD941865DC4245B335D2D38F76B02@DAPHNIS.office.hd> Message-ID: <24936_1367933092_518900A4_24936_1591_1_976A65C5A08ADF49B9A8523F7F81925C0E0B39@PEXCVZYM13.corporate.adroot.infra.ftgroup> Thanks a lot Tobias. BR Thierry De : Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] Envoy? : mardi 7 mai 2013 13:27 ? : NAGELLEN Thierry OLNC/OLPS Cc : fiware-iot at lists.fi-ware.eu Objet : RE: [Fiware-iot] State of the Art deliverable Hi Thierry, and here is the update from NEC regarding Task 5.2 (Resource Management). We basically described the achievements of the IoT-A project. Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of t.elsaleh at surrey.ac.uk Sent: Dienstag, 7. Mai 2013 12:06 To: thierry.nagellen at orange.com Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] State of the Art deliverable Hello Thierry, Attached is the SOTA contribution from UNIS. Best regards, Tarek 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: 30 April 2013 09:30 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] State of the Art deliverable Importance: High 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 rel evant to ork 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 belo w)< MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo2'>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 f eel free 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.06 /span>

?

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.

? 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 13197 bytes Desc: image001.png URL: From carsten.magerkurth at sap.com Tue May 7 16:40:43 2013 From: carsten.magerkurth at sap.com (Magerkurth, Carsten) Date: Tue, 7 May 2013 14:40:43 +0000 Subject: [Fiware-iot] State of the Art deliverable In-Reply-To: <8755F290097BD941865DC4245B335D2D38F76B02@DAPHNIS.office.hd> References: <407_1367310595_517F8103_407_11382_1_976A65C5A08ADF49B9A8523F7F81925C0DFDD3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B4FC@EXMB05CMS.surrey.ac.uk> <8755F290097BD941865DC4245B335D2D38F76B02@DAPHNIS.office.hd> Message-ID: <85A7992034599A4A83D05984B3A9EA710D048E7C@DEWDFEMB12A.global.corp.sap> Hi Thierry, here comes also an Update from SAP re. the Process Automation, best regards, Carsten From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Tobias Jacobs Sent: Dienstag, 7. Mai 2013 13:27 To: thierry.nagellen at orange.com Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] State of the Art deliverable Hi Thierry, and here is the update from NEC regarding Task 5.2 (Resource Management). We basically described the achievements of the IoT-A project. Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of t.elsaleh at surrey.ac.uk Sent: Dienstag, 7. Mai 2013 12:06 To: thierry.nagellen at orange.com Cc: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] State of the Art deliverable Hello Thierry, Attached is the SOTA contribution from UNIS. Best regards, Tarek 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: 30 April 2013 09:30 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] State of the Art deliverable Importance: High 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 rel evant to ork 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 belo w)< MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo2'>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 f eel free 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.06 /span>

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.

* 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____WP5_UNIS--RM....docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 431514 bytes Desc: D 2 6 2 State of the Art Analysis Emerging Technologies____WP5_UNIS--RM....docx URL: From Tobias.Jacobs at neclab.eu Wed May 8 10:02:41 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Wed, 8 May 2013 08:02:41 +0000 Subject: [Fiware-iot] Phone call today? Message-ID: <8755F290097BD941865DC4245B335D2D38F76C5F@DAPHNIS.office.hd> Hi, do we have a phone conf today? -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.elsaleh at surrey.ac.uk Wed May 8 10:24:49 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Wed, 8 May 2013 09:24:49 +0100 Subject: [Fiware-iot] Phone call today? In-Reply-To: <8755F290097BD941865DC4245B335D2D38F76C5F@DAPHNIS.office.hd> References: <8755F290097BD941865DC4245B335D2D38F76C5F@DAPHNIS.office.hd> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B634@EXMB05CMS.surrey.ac.uk> I joined earlier but no one there except Sabrina. Best regards, Tarek From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Tobias Jacobs Sent: 08 May 2013 09:03 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Phone call today? Hi, do we have a phone conf today? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Jacobs at neclab.eu Wed May 8 10:26:02 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Wed, 8 May 2013 08:26:02 +0000 Subject: [Fiware-iot] Phone call today? In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B634@EXMB05CMS.surrey.ac.uk> References: <8755F290097BD941865DC4245B335D2D38F76C5F@DAPHNIS.office.hd> <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B634@EXMB05CMS.surrey.ac.uk> Message-ID: <8755F290097BD941865DC4245B335D2D38F76CA1@DAPHNIS.office.hd> Hi, After 10 minutes we decided to cancel the conference, as no WPL or WPA was there and no one had a specific point to discuss. I guess this is because of the Future Internet Assembly in Dublin taking place at the moment. Best Tobias From: t.elsaleh at surrey.ac.uk [mailto:t.elsaleh at surrey.ac.uk] Sent: Mittwoch, 8. Mai 2013 10:25 To: Tobias Jacobs Cc: fiware-iot at lists.fi-ware.eu Subject: RE: Phone call today? I joined earlier but no one there except Sabrina. Best regards, Tarek From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Tobias Jacobs Sent: 08 May 2013 09:03 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Phone call today? Hi, do we have a phone conf today? -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.elsaleh at surrey.ac.uk Wed May 8 11:44:30 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Wed, 8 May 2013 10:44:30 +0100 Subject: [Fiware-iot] Urgent actions from last Architecture Board In-Reply-To: <16173_1367912229_5188AF24_16173_5242_1_976A65C5A08ADF49B9A8523F7F81925C0E098E@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <16173_1367912229_5188AF24_16173_5242_1_976A65C5A08ADF49B9A8523F7F81925C0E098E@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B670@EXMB05CMS.surrey.ac.uk> Hello Thierry, Would you know the period in which the webinars need to take place? 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: 07 May 2013 08:37 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Urgent actions from last Architecture Board Importance: High Dear all, You can find in attachment the minutes from the last Architecture Board (last Friday). We have to urgent actions to manage to be up to date for the new UC projects and to push them to use our GEs. 1. To check the list of GE which will be available in release 2 (including 2.3) and update the Googledoc spreadsheet 2. Provide dates for webinars on the use of the GE instances before Thursday 9! (this Thursday) because UC Projects will give us the list of attendees one week later. Thanks for your support BR Thierry De : fiware-pcc-bounces at lists.fi-ware.eu [mailto:fiware-pcc-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro Envoy? : mardi 7 mai 2013 09:00 ? : fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu; fiware at lists.fi-ware.eu; fiware-pcc at lists.fi-ware.eu Objet : [Fiware-pcc] Draft minutes of the last FI-PPP AB meeting and related URGENT Action Points on Chapter teams and FI-WARE GEi owners Dear all, Last Friday, May 3rd, we celebrated the first FI-PPP AB virtual meeting involving the new projects in phase 2 of the FI-PPP. You can take a look at the minutes available at: https://docs.google.com/document/d/1_DXfn7qSY4UEidfBv3E9MhplU1wcVOzkEpWhQ_0QK-M/edit?usp=sharing There are two URGENT Action Points that we have to finalize along this week so I ask for the cooperation of the several FI-WARE chapter teams and GEi owners: * Updating spreadsheet about "FI-WARE Testbed/GEis planned usage" available at https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdEd6bGhLQWtNai1jeGN5UnJMeEdxZ0E&usp=sharing * All chapter teams have to review the sheets linked "FI-WARE GEi (2nd Release) planned usage in Phase 1/2" if they haven't done so yet and send me their comments so that I can implement the proposed changes: * @I2ND was going to provide the name of FI-WARE GE and GEis (two first columns) for rows that have to be inserted for the new FI-WARE GEis in 2nd Release * @Apps was going to provide final feedback on whether it would make sense to split the package linked to Business Framework or not * Remember that this is to collect info about planned usage by UC projects, that's why it makes sense to have some rows in the sheets linked to packages of GEis / functionalities (e.g., Cloud) than as individual GEis * Please, don't edit yourself, forward feedback to me through your chapter leader * VERY IMPORTANT for FI-WARE GEi owners: Proposal on first series of webinars regarding FI-WARE GEis already available for UC projects in the Testbed (or to be available by end of May): * Deadline: Thursday May 9 EOB. * You should edit the following spreadsheet in Google docs yourself: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdF9aeWphSkFkWjJRQ3pPVW1PVURLX3c&usp=sharing * You just have to provide two alternative dates during the period from May 20th until June 14th. Try to make them in two alternative weeks. * Note that these webinars are not mandatory for all FI-WARE GEis but strongly recommended for GEis/functionality that can be already demonstrated in the Testbed while in the webinars or at least presented as mockup (e.g., this might be useful for some new Cloud functions) * You can select your favorite bridge tools. How do you declare the tools you plan to use so that people will connect ? Defining a hashtag * This will be used as an Id for the bridge/webex details to be provided in sheet "Logistics details" * It will be referred from the cell associated to the row linked to your GEi and the column "Logistic details" of sheet "FI-WARE GEi (2nd Release) - series of webinars" * We advise you also to use this hashtag in posts to the @FIware twitter account during the webinar. It may be helpful to collect questions on-line so people do not necessarily interrupt you (you can watch the twitter account and then decide when to answer those questions) * UC projects will declare their interest to attend the different webinars along the week of May 17th Please pay attention to this two urgent actions. We believe that their implementation can be rather useful for a successful project review mid June. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect You can follow FI-WARE at: 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 _________________________________________________________________________________________________________________________ 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 Wed May 8 12:39:15 2013 From: sabrina.guerra at telecomitalia.it (Guerra Sabrina) Date: Wed, 8 May 2013 12:39:15 +0200 Subject: [Fiware-iot] R: Urgent actions from last Architecture Board In-Reply-To: <16173_1367912229_5188AF24_16173_5242_1_976A65C5A08ADF49B9A8523F7F81925C0E098E@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <16173_1367912229_5188AF24_16173_5242_1_976A65C5A08ADF49B9A8523F7F81925C0E098E@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5AE9F594B@GRFMBX702BA020.griffon.local> Hi, as you suggested I checked the list of GEs which will be available in release 2: in particular I reviewed the sheets linked "FI-WARE GEi (2nd Release) planned usage in Phase 1/2" and our asset (the ZigBee Protocol Adapter) is correctly present in the list. About your second point, re-reading the Juanjo's e-mail below, it isn't clear for me if the webinars are only related to the GEs will be available by end of May? In this case our GE is not yet available so we cannot provide any date for the moment. By the way will there be the F2F meeting next week? Because in the last call (organized by Fraunhofer on 29th April) we had a useful session about the integration of the OpenMTC into the gateway (basically they agreed to use NGSI for the integration with the other GEs included the Protocol Adapter) so we don't know what could be the topic of this meeting. Please, let us know so we can plan the activities for the next Wednesday. 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: marted? 7 maggio 2013 09:37 A: fiware-iot at lists.fi-ware.eu Oggetto: [Fiware-iot] Urgent actions from last Architecture Board Priorit?: Alta Dear all, You can find in attachment the minutes from the last Architecture Board (last Friday). We have to urgent actions to manage to be up to date for the new UC projects and to push them to use our GEs. 1. To check the list of GE which will be available in release 2 (including 2.3) and update the Googledoc spreadsheet 2. Provide dates for webinars on the use of the GE instances before Thursday 9! (this Thursday) because UC Projects will give us the list of attendees one week later. Thanks for your support BR Thierry De : fiware-pcc-bounces at lists.fi-ware.eu [mailto:fiware-pcc-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro Envoy? : mardi 7 mai 2013 09:00 ? : fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu; fiware at lists.fi-ware.eu; fiware-pcc at lists.fi-ware.eu Objet : [Fiware-pcc] Draft minutes of the last FI-PPP AB meeting and related URGENT Action Points on Chapter teams and FI-WARE GEi owners Dear all, Last Friday, May 3rd, we celebrated the first FI-PPP AB virtual meeting involving the new projects in phase 2 of the FI-PPP. You can take a look at the minutes available at: https://docs.google.com/document/d/1_DXfn7qSY4UEidfBv3E9MhplU1wcVOzkEpWhQ_0QK-M/edit?usp=sharing There are two URGENT Action Points that we have to finalize along this week so I ask for the cooperation of the several FI-WARE chapter teams and GEi owners: * Updating spreadsheet about "FI-WARE Testbed/GEis planned usage" available at https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdEd6bGhLQWtNai1jeGN5UnJMeEdxZ0E&usp=sharing * All chapter teams have to review the sheets linked "FI-WARE GEi (2nd Release) planned usage in Phase 1/2" if they haven't done so yet and send me their comments so that I can implement the proposed changes: * @I2ND was going to provide the name of FI-WARE GE and GEis (two first columns) for rows that have to be inserted for the new FI-WARE GEis in 2nd Release * @Apps was going to provide final feedback on whether it would make sense to split the package linked to Business Framework or not * Remember that this is to collect info about planned usage by UC projects, that's why it makes sense to have some rows in the sheets linked to packages of GEis / functionalities (e.g., Cloud) than as individual GEis * Please, don't edit yourself, forward feedback to me through your chapter leader * VERY IMPORTANT for FI-WARE GEi owners: Proposal on first series of webinars regarding FI-WARE GEis already available for UC projects in the Testbed (or to be available by end of May): * Deadline: Thursday May 9 EOB. * You should edit the following spreadsheet in Google docs yourself: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdF9aeWphSkFkWjJRQ3pPVW1PVURLX3c&usp=sharing * You just have to provide two alternative dates during the period from May 20th until June 14th. Try to make them in two alternative weeks. * Note that these webinars are not mandatory for all FI-WARE GEis but strongly recommended for GEis/functionality that can be already demonstrated in the Testbed while in the webinars or at least presented as mockup (e.g., this might be useful for some new Cloud functions) * You can select your favorite bridge tools. How do you declare the tools you plan to use so that people will connect ? Defining a hashtag * This will be used as an Id for the bridge/webex details to be provided in sheet "Logistics details" * It will be referred from the cell associated to the row linked to your GEi and the column "Logistic details" of sheet "FI-WARE GEi (2nd Release) - series of webinars" * We advise you also to use this hashtag in posts to the @FIware twitter account during the webinar. It may be helpful to collect questions on-line so people do not necessarily interrupt you (you can watch the twitter account and then decide when to answer those questions) * UC projects will declare their interest to attend the different webinars along the week of May 17th Please pay attention to this two urgent actions. We believe that their implementation can be rather useful for a successful project review mid June. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect You can follow FI-WARE at: 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 _________________________________________________________________________________________________________________________ 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: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: From thierry.nagellen at orange.com Wed May 8 14:52:09 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 8 May 2013 12:52:09 +0000 Subject: [Fiware-iot] Phone call today? In-Reply-To: <8755F290097BD941865DC4245B335D2D38F76CA1@DAPHNIS.office.hd> References: <8755F290097BD941865DC4245B335D2D38F76C5F@DAPHNIS.office.hd> <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B634@EXMB05CMS.surrey.ac.uk> <8755F290097BD941865DC4245B335D2D38F76CA1@DAPHNIS.office.hd> Message-ID: <4186_1368017530_518A4A7A_4186_4553_1_976A65C5A08ADF49B9A8523F7F81925C0E0E7F@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hello all, I apologize for the inconvenience not to cancel the IoT meeting. In fact we are with Carlos at the Future Internet Assembly in Dublin. We will have the meeting next Wednesday and I will be able to comment also the interest at least of 2 projects on IoT GEs and which required closed collaboration (FIT-Man and FISpace). In the same time we will have an informal meeting tomorrow with IERC cluster (Thanks to Martin to organize it) but there are lots of requests about collaboration so we will also organize a workshop during the next IoT week in Helsinki http://www.iot-week.eu/ (17th to 20th June) to define how to launch effective collaboration between IERC projects and Fi-Ware IoT chapters. BR Thierry 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? : mercredi 8 mai 2013 10:26 ? : t.elsaleh at surrey.ac.uk Cc : fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] Phone call today? Hi, After 10 minutes we decided to cancel the conference, as no WPL or WPA was there and no one had a specific point to discuss. I guess this is because of the Future Internet Assembly in Dublin taking place at the moment. Best Tobias From: t.elsaleh at surrey.ac.uk [mailto:t.elsaleh at surrey.ac.uk] Sent: Mittwoch, 8. Mai 2013 10:25 To: Tobias Jacobs Cc: fiware-iot at lists.fi-ware.eu Subject: RE: Phone call today? I joined earlier but no one there except Sabrina. Best regards, Tarek From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Tobias Jacobs Sent: 08 May 2013 09:03 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Phone call today? Hi, do we have a phone conf today? _________________________________________________________________________________________________________________________ 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 Martin.Bauer at neclab.eu Wed May 8 20:25:15 2013 From: Martin.Bauer at neclab.eu (Martin Bauer) Date: Wed, 8 May 2013 18:25:15 +0000 Subject: [Fiware-iot] FIA-Meeting IERC AC1 - FI-WARE IoT Message-ID: Dear IERC AC1 and FI-WARE IoT people, For those of you who are at FIA, this is a reminder that we have our meeting tomorrow during lunch break. We will meet at the reception (which is actually right between the FI-WARE and IoT-A booth) and have lunch together. Thanks to Carlos, we have organized a room for after lunch, which is somewhere in the back, so we have to go to the reception and then we will be guided there so that we can have further discussions there. The idea for tomorrow is to get to know each other and start the discussion - in this case focussing on the architecture topic. The plan is to have an IERC / FI-WARE IoT meeting during IoT Week in Helsinki. Best regards, Martin ------------------------------------------ Dr. Martin Bauer Senior Researcher NEC Europe Ltd. NEC Laboratories Europe Software & Services Research Division Kurf?rsten-Anlage 36 D-69115 Heidelberg Tel: +49/ (0)6221/4342-168 Fax: +49/ (0)6221/4342-155 E-Mail: Martin.Bauer at neclab.eu http://www.nw.neclab.eu ************************************************************* NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, Great Britain Registered in England 2832014 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry.nagellen at orange.com Mon May 13 09:35:16 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Mon, 13 May 2013 07:35:16 +0000 Subject: [Fiware-iot] Urgent actions from last Architecture Board In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B670@EXMB05CMS.surrey.ac.uk> References: <16173_1367912229_5188AF24_16173_5242_1_976A65C5A08ADF49B9A8523F7F81925C0E098E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B670@EXMB05CMS.surrey.ac.uk> Message-ID: <12111_1368430517_519097B5_12111_1062_4_976A65C5A08ADF49B9A8523F7F81925C0E19B6@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi Tarek I apologize for the delay in answering... The best slot would be late in May or June, before Summer vacations and so the UC projects will be able to integrate some GEs in their plans for September. BR Thierry De : t.elsaleh at surrey.ac.uk [mailto:t.elsaleh at surrey.ac.uk] Envoy? : mercredi 8 mai 2013 11:45 ? : NAGELLEN Thierry OLNC/OLPS Cc : fiware-iot at lists.fi-ware.eu Objet : RE: Urgent actions from last Architecture Board Hello Thierry, Would you know the period in which the webinars need to take place? 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: 07 May 2013 08:37 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Urgent actions from last Architecture Board Importance: High Dear all, You can find in attachment the minutes from the last Architecture Board (last Friday). We have to urgent actions to manage to be up to date for the new UC projects and to push them to use our GEs. 1. To check the list of GE which will be available in release 2 (including 2.3) and update the Googledoc spreadsheet 2. Provide dates for webinars on the use of the GE instances before Thursday 9! (this Thursday) because UC Projects will give us the list of attendees one week later. Thanks for your support BR Thierry De : fiware-pcc-bounces at lists.fi-ware.eu [mailto:fiware-pcc-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro Envoy? : mardi 7 mai 2013 09:00 ? : fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu; fiware at lists.fi-ware.eu; fiware-pcc at lists.fi-ware.eu Objet : [Fiware-pcc] Draft minutes of the last FI-PPP AB meeting and related URGENT Action Points on Chapter teams and FI-WARE GEi owners Dear all, Last Friday, May 3rd, we celebrated the first FI-PPP AB virtual meeting involving the new projects in phase 2 of the FI-PPP. You can take a look at the minutes available at: https://docs.google.com/document/d/1_DXfn7qSY4UEidfBv3E9MhplU1wcVOzkEpWhQ_0QK-M/edit?usp=sharing There are two URGENT Action Points that we have to finalize along this week so I ask for the cooperation of the several FI-WARE chapter teams and GEi owners: * Updating spreadsheet about "FI-WARE Testbed/GEis planned usage" available at https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdEd6bGhLQWtNai1jeGN5UnJMeEdxZ0E&usp=sharing * All chapter teams have to review the sheets linked "FI-WARE GEi (2nd Release) planned usage in Phase 1/2" if they haven't done so yet and send me their comments so that I can implement the proposed changes: * @I2ND was going to provide the name of FI-WARE GE and GEis (two first columns) for rows that have to be inserted for the new FI-WARE GEis in 2nd Release * @Apps was going to provide final feedback on whether it would make sense to split the package linked to Business Framework or not * Remember that this is to collect info about planned usage by UC projects, that's why it makes sense to have some rows in the sheets linked to packages of GEis / functionalities (e.g., Cloud) than as individual GEis * Please, don't edit yourself, forward feedback to me through your chapter leader * VERY IMPORTANT for FI-WARE GEi owners: Proposal on first series of webinars regarding FI-WARE GEis already available for UC projects in the Testbed (or to be available by end of May): * Deadline: Thursday May 9 EOB. * You should edit the following spreadsheet in Google docs yourself: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdF9aeWphSkFkWjJRQ3pPVW1PVURLX3c&usp=sharing * You just have to provide two alternative dates during the period from May 20th until June 14th. Try to make them in two alternative weeks. * Note that these webinars are not mandatory for all FI-WARE GEis but strongly recommended for GEis/functionality that can be already demonstrated in the Testbed while in the webinars or at least presented as mockup (e.g., this might be useful for some new Cloud functions) * You can select your favorite bridge tools. How do you declare the tools you plan to use so that people will connect ? Defining a hashtag * This will be used as an Id for the bridge/webex details to be provided in sheet "Logistics details" * It will be referred from the cell associated to the row linked to your GEi and the column "Logistic details" of sheet "FI-WARE GEi (2nd Release) - series of webinars" * We advise you also to use this hashtag in posts to the @FIware twitter account during the webinar. It may be helpful to collect questions on-line so people do not necessarily interrupt you (you can watch the twitter account and then decide when to answer those questions) * UC projects will declare their interest to attend the different webinars along the week of May 17th Please pay attention to this two urgent actions. We believe that their implementation can be rather useful for a successful project review mid June. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect You can follow FI-WARE at: 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 _________________________________________________________________________________________________________________________ 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 thierry.nagellen at orange.com Mon May 13 09:38:12 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Mon, 13 May 2013 07:38:12 +0000 Subject: [Fiware-iot] Urgent actions from last Architecture Board In-Reply-To: <36A93B31228D3B49B691AD31652BCAE9A5AE9F594B@GRFMBX702BA020.griffon.local> References: <16173_1367912229_5188AF24_16173_5242_1_976A65C5A08ADF49B9A8523F7F81925C0E098E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <36A93B31228D3B49B691AD31652BCAE9A5AE9F594B@GRFMBX702BA020.griffon.local> Message-ID: <12113_1368430693_51909864_12113_2400_1_976A65C5A08ADF49B9A8523F7F81925C0E19D1@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi Sabrina, As the Protocol Adapter ZPA has been deliver a first time in release 1, we have to manage a webinar for UC projects Phase 2. Of course you cannot explain in all details features you will provide in release 2.3. Regarding F2F meeting, nothing is planned for this week, I will come back for a potential telco but really not sure it is now useful based on the previous telco you had with Fraunhofer. BR Thierry De : Guerra Sabrina [mailto:sabrina.guerra at telecomitalia.it] Envoy? : mercredi 8 mai 2013 12:39 ? : NAGELLEN Thierry OLNC/OLPS; CARLOS RALLI UCENDO (ralli at tid.es) (ralli at tid.es) Cc : fiware-iot at lists.fi-ware.eu Objet : R: Urgent actions from last Architecture Board Hi, as you suggested I checked the list of GEs which will be available in release 2: in particular I reviewed the sheets linked "FI-WARE GEi (2nd Release) planned usage in Phase 1/2" and our asset (the ZigBee Protocol Adapter) is correctly present in the list. About your second point, re-reading the Juanjo's e-mail below, it isn't clear for me if the webinars are only related to the GEs will be available by end of May? In this case our GE is not yet available so we cannot provide any date for the moment. By the way will there be the F2F meeting next week? Because in the last call (organized by Fraunhofer on 29th April) we had a useful session about the integration of the OpenMTC into the gateway (basically they agreed to use NGSI for the integration with the other GEs included the Protocol Adapter) so we don't know what could be the topic of this meeting. Please, let us know so we can plan the activities for the next Wednesday. 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: marted? 7 maggio 2013 09:37 A: fiware-iot at lists.fi-ware.eu Oggetto: [Fiware-iot] Urgent actions from last Architecture Board Priorit?: Alta Dear all, You can find in attachment the minutes from the last Architecture Board (last Friday). We have to urgent actions to manage to be up to date for the new UC projects and to push them to use our GEs. 1. To check the list of GE which will be available in release 2 (including 2.3) and update the Googledoc spreadsheet 2. Provide dates for webinars on the use of the GE instances before Thursday 9! (this Thursday) because UC Projects will give us the list of attendees one week later. Thanks for your support BR Thierry De : fiware-pcc-bounces at lists.fi-ware.eu [mailto:fiware-pcc-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro Envoy? : mardi 7 mai 2013 09:00 ? : fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu; fiware at lists.fi-ware.eu; fiware-pcc at lists.fi-ware.eu Objet : [Fiware-pcc] Draft minutes of the last FI-PPP AB meeting and related URGENT Action Points on Chapter teams and FI-WARE GEi owners Dear all, Last Friday, May 3rd, we celebrated the first FI-PPP AB virtual meeting involving the new projects in phase 2 of the FI-PPP. You can take a look at the minutes available at: https://docs.google.com/document/d/1_DXfn7qSY4UEidfBv3E9MhplU1wcVOzkEpWhQ_0QK-M/edit?usp=sharing There are two URGENT Action Points that we have to finalize along this week so I ask for the cooperation of the several FI-WARE chapter teams and GEi owners: * Updating spreadsheet about "FI-WARE Testbed/GEis planned usage" available at https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdEd6bGhLQWtNai1jeGN5UnJMeEdxZ0E&usp=sharing * All chapter teams have to review the sheets linked "FI-WARE GEi (2nd Release) planned usage in Phase 1/2" if they haven't done so yet and send me their comments so that I can implement the proposed changes: * @I2ND was going to provide the name of FI-WARE GE and GEis (two first columns) for rows that have to be inserted for the new FI-WARE GEis in 2nd Release * @Apps was going to provide final feedback on whether it would make sense to split the package linked to Business Framework or not * Remember that this is to collect info about planned usage by UC projects, that's why it makes sense to have some rows in the sheets linked to packages of GEis / functionalities (e.g., Cloud) than as individual GEis * Please, don't edit yourself, forward feedback to me through your chapter leader * VERY IMPORTANT for FI-WARE GEi owners: Proposal on first series of webinars regarding FI-WARE GEis already available for UC projects in the Testbed (or to be available by end of May): * Deadline: Thursday May 9 EOB. * You should edit the following spreadsheet in Google docs yourself: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdF9aeWphSkFkWjJRQ3pPVW1PVURLX3c&usp=sharing * You just have to provide two alternative dates during the period from May 20th until June 14th. Try to make them in two alternative weeks. * Note that these webinars are not mandatory for all FI-WARE GEis but strongly recommended for GEis/functionality that can be already demonstrated in the Testbed while in the webinars or at least presented as mockup (e.g., this might be useful for some new Cloud functions) * You can select your favorite bridge tools. How do you declare the tools you plan to use so that people will connect ? Defining a hashtag * This will be used as an Id for the bridge/webex details to be provided in sheet "Logistics details" * It will be referred from the cell associated to the row linked to your GEi and the column "Logistic details" of sheet "FI-WARE GEi (2nd Release) - series of webinars" * We advise you also to use this hashtag in posts to the @FIware twitter account during the webinar. It may be helpful to collect questions on-line so people do not necessarily interrupt you (you can watch the twitter account and then decide when to answer those questions) * UC projects will declare their interest to attend the different webinars along the week of May 17th Please pay attention to this two urgent actions. We believe that their implementation can be rather useful for a successful project review mid June. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect You can follow FI-WARE at: 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 _________________________________________________________________________________________________________________________ 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. -------------- 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 Mon May 13 15:44:44 2013 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Mon, 13 May 2013 13:44:44 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <8755F290097BD941865DC4245B335D2D38F76A15@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> <5187C911.5000600@tid.es> <8755F290097BD941865DC4245B335D2D38F76A15@DAPHNIS.office.hd> Message-ID: <11800_1368452685_5190EE4D_11800_3603_1_DC254E6D1212F24EAE0D7766A11FE2890B6170@PEXCVZYM12.corporate.adroot.infra.ftgroup> Hi ! Sorry for my late feedback on the discussion but I was offline the entire previous week. If I understand the current situation: 1) Fermin points out the need for a flexible model for entity-entity relationship 2) Tobias says that NGSI data structure is not well adapted for modeling generic entity-entity relationships. I agree with both views and don't think they are conflicting. However, I still don't understand Tobias objection to assigning names to associations even if the IoT Broker will ignore them (because of the fixed semantics assumption), and will handle them using its predefined interpretation. After all, there are other GEs or SW components which might be able to handle these associations based on their names. About "symmetrical" relationship examples: "is the same object than", "has the same location than", "has the same price than" Best regards, Fano 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? : mardi 7 mai 2013 09:27 ? : Ferm?n Gal?n M?rquez Cc : fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Hi Fermin, I hope you had some nice vacations. I understand your need to have a flexible model for entity-entity relationships, but I am not yet convinced that associations in particular and NGSI-9 in general are the appropriate vehicle for it. Could you give an example of a relationship that would actually need the "symmetry" between source and target? (As said, the backup example can be easily modeled by the "asymmetric" solution using station2 --> station1 and then even the IoT Broker could understand it correctly.) Best Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Montag, 6. Mai 2013 17:15 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 think that you are mostly right in your "motivations" analysis. To complete it, take into account that the piece of software that implements ConfMan in IoT chapter (named Orion Context Broker) is used in other places. So, what I'm trying to avoid is to develop a functionality (with the cost in design, coding and testing that it involves) that is only useful in a single use case, i.e. the one from IoT chapter. Note that from Orion Context Broker point of view, IoT Broker is just an application and I would like to avoid "hardwire" a semantic only needed by a particular application (because in that case, every application will potentially needs modifications in the Orion Context Broker code). Thus, we have to find a way that at the same time doesn't hardwire predefined semantics in the Orion Context Broker only useful in IoT chapter (due to, as I mention before, the development of Orion Context Broker is not driven exclusively by IoT chapter requirements) and at the same time fulfills the IoTBroker-ConfMan case. I honestly think the way I propose matches both objectives. In particular, I think it that it fulfills the IoTBroker-ConfMan in the definition you did in the .doc with the query and update cases, but given that I have mention that before in several emails but this discussion continues maybe I'm wrong (in that case, please tell me the case/step/etc. in which I'm wrong). You are right in that the "stations backups" case is not supported by IoT Broker but it has been never supposed to support it. However, other applications build on top the Orion Context Broker will take advantage of flexible association semantics to support it, without breaking the IoT Broker use case. Regarding the OWL+SPARQL alternative, I don't know the technology well enough in order to have an opinion on that and how it compares with the one that we are currently on the table. Best regards, ------- Ferm?n El 29/04/2013 13:09, Tobias Jacobs escribi?: 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 ________________________________ 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 Mon May 13 16:28:03 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Mon, 13 May 2013 14:28:03 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <11800_1368452685_5190EE4D_11800_3603_1_DC254E6D1212F24EAE0D7766A11FE2890B6170@PEXCVZYM12.corporate.adroot.infra.ftgroup> 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> <5187C911.5000600@tid.es> <8755F290097BD941865DC4245B335D2D38F76A15@DAPHNIS.office.hd> <11800_1368452685_5190EE4D_11800_3603_1_DC254E6D1212F24EAE0D7766A11FE2890B6170@PEXCVZYM12.corporate.adroot.infra.ftgroup> Message-ID: <8755F290097BD941865DC4245B335D2D38F79278@DAPHNIS.office.hd> Hi Fano, As NGSI is a standard, I think it would be good to have the semantics of any syntax as much fixed as possible. If Applications have the need for other kinds of entity-entity relationships via NGSI-9 there is still the possibility to use own, non-standard metadata types. Before continuing the discussion, could you give an example of two different association kinds that would need to be distinguished from each other? In general, I see a lot of need in the WP to model generic entity-entity relationships, and I have also heard these kind of requests from use case projects. So let us collect the use cases where this is needed and think about if we can achieve that with NGSI and how. Best Tobias From: fano.ramparany at orange.com [mailto:fano.ramparany at orange.com] Sent: Montag, 13. Mai 2013 15:45 To: Tobias Jacobs; Ferm?n Gal?n M?rquez 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 Hi ! Sorry for my late feedback on the discussion but I was offline the entire previous week. If I understand the current situation: 1) Fermin points out the need for a flexible model for entity-entity relationship 2) Tobias says that NGSI data structure is not well adapted for modeling generic entity-entity relationships. I agree with both views and don't think they are conflicting. However, I still don't understand Tobias objection to assigning names to associations even if the IoT Broker will ignore them (because of the fixed semantics assumption), and will handle them using its predefined interpretation. After all, there are other GEs or SW components which might be able to handle these associations based on their names. About "symmetrical" relationship examples: "is the same object than", "has the same location than", "has the same price than" Best regards, Fano 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? : mardi 7 mai 2013 09:27 ? : Ferm?n Gal?n M?rquez Cc : fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Hi Fermin, I hope you had some nice vacations. I understand your need to have a flexible model for entity-entity relationships, but I am not yet convinced that associations in particular and NGSI-9 in general are the appropriate vehicle for it. Could you give an example of a relationship that would actually need the "symmetry" between source and target? (As said, the backup example can be easily modeled by the "asymmetric" solution using station2 --> station1 and then even the IoT Broker could understand it correctly.) Best Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Montag, 6. Mai 2013 17:15 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 think that you are mostly right in your "motivations" analysis. To complete it, take into account that the piece of software that implements ConfMan in IoT chapter (named Orion Context Broker) is used in other places. So, what I'm trying to avoid is to develop a functionality (with the cost in design, coding and testing that it involves) that is only useful in a single use case, i.e. the one from IoT chapter. Note that from Orion Context Broker point of view, IoT Broker is just an application and I would like to avoid "hardwire" a semantic only needed by a particular application (because in that case, every application will potentially needs modifications in the Orion Context Broker code). Thus, we have to find a way that at the same time doesn't hardwire predefined semantics in the Orion Context Broker only useful in IoT chapter (due to, as I mention before, the development of Orion Context Broker is not driven exclusively by IoT chapter requirements) and at the same time fulfills the IoTBroker-ConfMan case. I honestly think the way I propose matches both objectives. In particular, I think it that it fulfills the IoTBroker-ConfMan in the definition you did in the .doc with the query and update cases, but given that I have mention that before in several emails but this discussion continues maybe I'm wrong (in that case, please tell me the case/step/etc. in which I'm wrong). You are right in that the "stations backups" case is not supported by IoT Broker but it has been never supposed to support it. However, other applications build on top the Orion Context Broker will take advantage of flexible association semantics to support it, without breaking the IoT Broker use case. Regarding the OWL+SPARQL alternative, I don't know the technology well enough in order to have an opinion on that and how it compares with the one that we are currently on the table. Best regards, ------- Ferm?n El 29/04/2013 13:09, Tobias Jacobs escribi?: 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 ________________________________ 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 fano.ramparany at orange.com Mon May 13 17:49:46 2013 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Mon, 13 May 2013 15:49:46 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <8755F290097BD941865DC4245B335D2D38F79278@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> <5187C911.5000600@tid.es> <8755F290097BD941865DC4245B335D2D38F76A15@DAPHNIS.office.hd> <11800_1368452685_5190EE4D_11800_3603_1_DC254E6D1212F24EAE0D7766A11FE2890B6170@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8755F290097BD941865DC4245B335D2D38F79278@DAPHNIS.office.hd> Message-ID: <9487_1368460187_51910B9B_9487_856_1_DC254E6D1212F24EAE0D7766A11FE2890B6837@PEXCVZYM12.corporate.adroot.infra.ftgroup> Hi Tobias and all, About examples, I've provided already a few of them in my previous reply: "is the same object than", "has the same location than", "has the same price than" and also in older ones: "is located in", "is composed of". Best regards, Fano De : Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] Envoy? : lundi 13 mai 2013 16:28 ? : RAMPARANY Fano OLNC/OLPS; Ferm?n Gal?n M?rquez Cc : fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Objet : RE: [Fiware-iot] [Fiware-ngsi] how to represent associations Hi Fano, As NGSI is a standard, I think it would be good to have the semantics of any syntax as much fixed as possible. If Applications have the need for other kinds of entity-entity relationships via NGSI-9 there is still the possibility to use own, non-standard metadata types. Before continuing the discussion, could you give an example of two different association kinds that would need to be distinguished from each other? In general, I see a lot of need in the WP to model generic entity-entity relationships, and I have also heard these kind of requests from use case projects. So let us collect the use cases where this is needed and think about if we can achieve that with NGSI and how. Best Tobias From: fano.ramparany at orange.com [mailto:fano.ramparany at orange.com] Sent: Montag, 13. Mai 2013 15:45 To: Tobias Jacobs; Ferm?n Gal?n M?rquez 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 Hi ! Sorry for my late feedback on the discussion but I was offline the entire previous week. If I understand the current situation: 1) Fermin points out the need for a flexible model for entity-entity relationship 2) Tobias says that NGSI data structure is not well adapted for modeling generic entity-entity relationships. I agree with both views and don't think they are conflicting. However, I still don't understand Tobias objection to assigning names to associations even if the IoT Broker will ignore them (because of the fixed semantics assumption), and will handle them using its predefined interpretation. After all, there are other GEs or SW components which might be able to handle these associations based on their names. About "symmetrical" relationship examples: "is the same object than", "has the same location than", "has the same price than" Best regards, Fano 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? : mardi 7 mai 2013 09:27 ? : Ferm?n Gal?n M?rquez Cc : fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Hi Fermin, I hope you had some nice vacations. I understand your need to have a flexible model for entity-entity relationships, but I am not yet convinced that associations in particular and NGSI-9 in general are the appropriate vehicle for it. Could you give an example of a relationship that would actually need the "symmetry" between source and target? (As said, the backup example can be easily modeled by the "asymmetric" solution using station2 --> station1 and then even the IoT Broker could understand it correctly.) Best Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Montag, 6. Mai 2013 17:15 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 think that you are mostly right in your "motivations" analysis. To complete it, take into account that the piece of software that implements ConfMan in IoT chapter (named Orion Context Broker) is used in other places. So, what I'm trying to avoid is to develop a functionality (with the cost in design, coding and testing that it involves) that is only useful in a single use case, i.e. the one from IoT chapter. Note that from Orion Context Broker point of view, IoT Broker is just an application and I would like to avoid "hardwire" a semantic only needed by a particular application (because in that case, every application will potentially needs modifications in the Orion Context Broker code). Thus, we have to find a way that at the same time doesn't hardwire predefined semantics in the Orion Context Broker only useful in IoT chapter (due to, as I mention before, the development of Orion Context Broker is not driven exclusively by IoT chapter requirements) and at the same time fulfills the IoTBroker-ConfMan case. I honestly think the way I propose matches both objectives. In particular, I think it that it fulfills the IoTBroker-ConfMan in the definition you did in the .doc with the query and update cases, but given that I have mention that before in several emails but this discussion continues maybe I'm wrong (in that case, please tell me the case/step/etc. in which I'm wrong). You are right in that the "stations backups" case is not supported by IoT Broker but it has been never supposed to support it. However, other applications build on top the Orion Context Broker will take advantage of flexible association semantics to support it, without breaking the IoT Broker use case. Regarding the OWL+SPARQL alternative, I don't know the technology well enough in order to have an opinion on that and how it compares with the one that we are currently on the table. Best regards, ------- Ferm?n El 29/04/2013 13:09, Tobias Jacobs escribi?: 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 ________________________________ 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. _________________________________________________________________________________________________________________________ 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 Tue May 14 10:30:18 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Tue, 14 May 2013 08:30:18 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <9487_1368460187_51910B9B_9487_856_1_DC254E6D1212F24EAE0D7766A11FE2890B6837@PEXCVZYM12.corporate.adroot.infra.ftgroup> 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> <5187C911.5000600@tid.es> <8755F290097BD941865DC4245B335D2D38F76A15@DAPHNIS.office.hd> <11800_1368452685_5190EE4D_11800_3603_1_DC254E6D1212F24EAE0D7766A11FE2890B6170@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8755F290097BD941865DC4245B335D2D38F79278@DAPHNIS.office.hd> <9487_1368460187_51910B9B_9487_856_1_DC254E6D1212F24EAE0D7766A11FE2890B6837@PEXCVZYM12.corporate.adroot.infra.ftgroup> Message-ID: <8755F290097BD941865DC4245B335D2D38F793F3@DAPHNIS.office.hd> Hi Fano, Thanks for re-sending the examples. To me they are context information than context availability information, so I would encode them so that this information can be exchanged via NGSI10. Recall that NGSI-9 is for exchanging context availability information, not context information itself. E.g. you can encode relationships with other entities as attribute values. An entity could have an attribute "identical_to", whose value is a list of entity ids. If you encode it like this, you can use restrictions for querying e.g. for all entities that are identical to a certain entity. Another possibility to encode relationships among entities is to introduce special entities representing these relationships. Best Tobias From: fano.ramparany at orange.com [mailto:fano.ramparany at orange.com] Sent: Montag, 13. Mai 2013 17:50 To: Tobias Jacobs; Ferm?n Gal?n M?rquez 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 Hi Tobias and all, About examples, I've provided already a few of them in my previous reply: "is the same object than", "has the same location than", "has the same price than" and also in older ones: "is located in", "is composed of". Best regards, Fano De : Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] Envoy? : lundi 13 mai 2013 16:28 ? : RAMPARANY Fano OLNC/OLPS; Ferm?n Gal?n M?rquez Cc : fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Objet : RE: [Fiware-iot] [Fiware-ngsi] how to represent associations Hi Fano, As NGSI is a standard, I think it would be good to have the semantics of any syntax as much fixed as possible. If Applications have the need for other kinds of entity-entity relationships via NGSI-9 there is still the possibility to use own, non-standard metadata types. Before continuing the discussion, could you give an example of two different association kinds that would need to be distinguished from each other? In general, I see a lot of need in the WP to model generic entity-entity relationships, and I have also heard these kind of requests from use case projects. So let us collect the use cases where this is needed and think about if we can achieve that with NGSI and how. Best Tobias From: fano.ramparany at orange.com [mailto:fano.ramparany at orange.com] Sent: Montag, 13. Mai 2013 15:45 To: Tobias Jacobs; Ferm?n Gal?n M?rquez 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 Hi ! Sorry for my late feedback on the discussion but I was offline the entire previous week. If I understand the current situation: 1) Fermin points out the need for a flexible model for entity-entity relationship 2) Tobias says that NGSI data structure is not well adapted for modeling generic entity-entity relationships. I agree with both views and don't think they are conflicting. However, I still don't understand Tobias objection to assigning names to associations even if the IoT Broker will ignore them (because of the fixed semantics assumption), and will handle them using its predefined interpretation. After all, there are other GEs or SW components which might be able to handle these associations based on their names. About "symmetrical" relationship examples: "is the same object than", "has the same location than", "has the same price than" Best regards, Fano 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? : mardi 7 mai 2013 09:27 ? : Ferm?n Gal?n M?rquez Cc : fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] [Fiware-ngsi] how to represent associations Hi Fermin, I hope you had some nice vacations. I understand your need to have a flexible model for entity-entity relationships, but I am not yet convinced that associations in particular and NGSI-9 in general are the appropriate vehicle for it. Could you give an example of a relationship that would actually need the "symmetry" between source and target? (As said, the backup example can be easily modeled by the "asymmetric" solution using station2 --> station1 and then even the IoT Broker could understand it correctly.) Best Tobias From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: Montag, 6. Mai 2013 17:15 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 think that you are mostly right in your "motivations" analysis. To complete it, take into account that the piece of software that implements ConfMan in IoT chapter (named Orion Context Broker) is used in other places. So, what I'm trying to avoid is to develop a functionality (with the cost in design, coding and testing that it involves) that is only useful in a single use case, i.e. the one from IoT chapter. Note that from Orion Context Broker point of view, IoT Broker is just an application and I would like to avoid "hardwire" a semantic only needed by a particular application (because in that case, every application will potentially needs modifications in the Orion Context Broker code). Thus, we have to find a way that at the same time doesn't hardwire predefined semantics in the Orion Context Broker only useful in IoT chapter (due to, as I mention before, the development of Orion Context Broker is not driven exclusively by IoT chapter requirements) and at the same time fulfills the IoTBroker-ConfMan case. I honestly think the way I propose matches both objectives. In particular, I think it that it fulfills the IoTBroker-ConfMan in the definition you did in the .doc with the query and update cases, but given that I have mention that before in several emails but this discussion continues maybe I'm wrong (in that case, please tell me the case/step/etc. in which I'm wrong). You are right in that the "stations backups" case is not supported by IoT Broker but it has been never supposed to support it. However, other applications build on top the Orion Context Broker will take advantage of flexible association semantics to support it, without breaking the IoT Broker use case. Regarding the OWL+SPARQL alternative, I don't know the technology well enough in order to have an opinion on that and how it compares with the one that we are currently on the table. Best regards, ------- Ferm?n El 29/04/2013 13:09, Tobias Jacobs escribi?: 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 ________________________________ 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. _________________________________________________________________________________________________________________________ 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 May 15 09:24:34 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 15 May 2013 07:24:34 +0000 Subject: [Fiware-iot] Today IoT meeting: googledocs link Message-ID: <16904_1368602674_51933832_16904_313_1_976A65C5A08ADF49B9A8523F7F81925C0E21ED@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi all, Here is the link for the minutes today. In the agenda we have the status on architecture, guides and SOTA, the open specs and the peer review we have to do very quickly, the organization of a session at the IoT Week in Helsinki about architecture and semantic interoperability. https://docs.google.com/document/d/1Dd8qDT3LbCEXzwesnK1BGhq_bwxFMLfluEuJSEDKSjE/edit 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 t.elsaleh at surrey.ac.uk Wed May 15 11:06:01 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Wed, 15 May 2013 10:06:01 +0100 Subject: [Fiware-iot] Urgent actions from last Architecture Board In-Reply-To: <12111_1368430517_519097B5_12111_1062_4_976A65C5A08ADF49B9A8523F7F81925C0E19B6@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <16173_1367912229_5188AF24_16173_5242_1_976A65C5A08ADF49B9A8523F7F81925C0E098E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B670@EXMB05CMS.surrey.ac.uk> <12111_1368430517_519097B5_12111_1062_4_976A65C5A08ADF49B9A8523F7F81925C0E19B6@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789E66598@EXMB05CMS.surrey.ac.uk> Hello Thierry, With regards to the webinars for the GEs, we are aiming to release our GEI for 2.3.3, i.e. by end of June. Therefore would it still be feasible to arrange a webinar during the last week of June? Best regards, Tarek From: thierry.nagellen at orange.com [mailto:thierry.nagellen at orange.com] Sent: 13 May 2013 08:35 To: Elsaleh T Mr (Electronic Eng) Cc: fiware-iot at lists.fi-ware.eu Subject: RE: Urgent actions from last Architecture Board Hi Tarek I apologize for the delay in answering... The best slot would be late in May or June, before Summer vacations and so the UC projects will be able to integrate some GEs in their plans for September. BR Thierry De : t.elsaleh at surrey.ac.uk [mailto:t.elsaleh at surrey.ac.uk] Envoy? : mercredi 8 mai 2013 11:45 ? : NAGELLEN Thierry OLNC/OLPS Cc : fiware-iot at lists.fi-ware.eu Objet : RE: Urgent actions from last Architecture Board Hello Thierry, Would you know the period in which the webinars need to take place? 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: 07 May 2013 08:37 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Urgent actions from last Architecture Board Importance: High Dear all, You can find in attachment the minutes from the last Architecture Board (last Friday). We have to urgent actions to manage to be up to date for the new UC projects and to push them to use our GEs. 1. To check the list of GE which will be available in release 2 (including 2.3) and update the Googledoc spreadsheet 2. Provide dates for webinars on the use of the GE instances before Thursday 9! (this Thursday) because UC Projects will give us the list of attendees one week later. Thanks for your support BR Thierry De : fiware-pcc-bounces at lists.fi-ware.eu [mailto:fiware-pcc-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro Envoy? : mardi 7 mai 2013 09:00 ? : fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu; fiware at lists.fi-ware.eu; fiware-pcc at lists.fi-ware.eu Objet : [Fiware-pcc] Draft minutes of the last FI-PPP AB meeting and related URGENT Action Points on Chapter teams and FI-WARE GEi owners Dear all, Last Friday, May 3rd, we celebrated the first FI-PPP AB virtual meeting involving the new projects in phase 2 of the FI-PPP. You can take a look at the minutes available at: https://docs.google.com/document/d/1_DXfn7qSY4UEidfBv3E9MhplU1wcVOzkEpWhQ_0QK-M/edit?usp=sharing There are two URGENT Action Points that we have to finalize along this week so I ask for the cooperation of the several FI-WARE chapter teams and GEi owners: * Updating spreadsheet about "FI-WARE Testbed/GEis planned usage" available at https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdEd6bGhLQWtNai1jeGN5UnJMeEdxZ0E&usp=sharing * All chapter teams have to review the sheets linked "FI-WARE GEi (2nd Release) planned usage in Phase 1/2" if they haven't done so yet and send me their comments so that I can implement the proposed changes: * @I2ND was going to provide the name of FI-WARE GE and GEis (two first columns) for rows that have to be inserted for the new FI-WARE GEis in 2nd Release * @Apps was going to provide final feedback on whether it would make sense to split the package linked to Business Framework or not * Remember that this is to collect info about planned usage by UC projects, that's why it makes sense to have some rows in the sheets linked to packages of GEis / functionalities (e.g., Cloud) than as individual GEis * Please, don't edit yourself, forward feedback to me through your chapter leader * VERY IMPORTANT for FI-WARE GEi owners: Proposal on first series of webinars regarding FI-WARE GEis already available for UC projects in the Testbed (or to be available by end of May): * Deadline: Thursday May 9 EOB. * You should edit the following spreadsheet in Google docs yourself: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdF9aeWphSkFkWjJRQ3pPVW1PVURLX3c&usp=sharing * You just have to provide two alternative dates during the period from May 20th until June 14th. Try to make them in two alternative weeks. * Note that these webinars are not mandatory for all FI-WARE GEis but strongly recommended for GEis/functionality that can be already demonstrated in the Testbed while in the webinars or at least presented as mockup (e.g., this might be useful for some new Cloud functions) * You can select your favorite bridge tools. How do you declare the tools you plan to use so that people will connect ? Defining a hashtag * This will be used as an Id for the bridge/webex details to be provided in sheet "Logistics details" * It will be referred from the cell associated to the row linked to your GEi and the column "Logistic details" of sheet "FI-WARE GEi (2nd Release) - series of webinars" * We advise you also to use this hashtag in posts to the @FIware twitter account during the webinar. It may be helpful to collect questions on-line so people do not necessarily interrupt you (you can watch the twitter account and then decide when to answer those questions) * UC projects will declare their interest to attend the different webinars along the week of May 17th Please pay attention to this two urgent actions. We believe that their implementation can be rather useful for a successful project review mid June. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect You can follow FI-WARE at: 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 _________________________________________________________________________________________________________________________ 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 thierry.nagellen at orange.com Wed May 15 11:26:24 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 15 May 2013 09:26:24 +0000 Subject: [Fiware-iot] Urgent actions from last Architecture Board In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA789E66598@EXMB05CMS.surrey.ac.uk> References: <16173_1367912229_5188AF24_16173_5242_1_976A65C5A08ADF49B9A8523F7F81925C0E098E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AAC0B6FF99A064C853BFB1C9295F3CCA789D5B670@EXMB05CMS.surrey.ac.uk> <12111_1368430517_519097B5_12111_1062_4_976A65C5A08ADF49B9A8523F7F81925C0E19B6@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AAC0B6FF99A064C853BFB1C9295F3CCA789E66598@EXMB05CMS.surrey.ac.uk> Message-ID: <6156_1368609985_519354C1_6156_382_1_976A65C5A08ADF49B9A8523F7F81925C0E22F4@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi Tarek Yes it's fine for me. You can announce it and explained that it will be available in July. BR Thierry De : t.elsaleh at surrey.ac.uk [mailto:t.elsaleh at surrey.ac.uk] Envoy? : mercredi 15 mai 2013 11:06 ? : NAGELLEN Thierry OLNC/OLPS Cc : fiware-iot at lists.fi-ware.eu Objet : RE: Urgent actions from last Architecture Board Hello Thierry, With regards to the webinars for the GEs, we are aiming to release our GEI for 2.3.3, i.e. by end of June. Therefore would it still be feasible to arrange a webinar during the last week of June? Best regards, Tarek From: thierry.nagellen at orange.com [mailto:thierry.nagellen at orange.com] Sent: 13 May 2013 08:35 To: Elsaleh T Mr (Electronic Eng) Cc: fiware-iot at lists.fi-ware.eu Subject: RE: Urgent actions from last Architecture Board Hi Tarek I apologize for the delay in answering... The best slot would be late in May or June, before Summer vacations and so the UC projects will be able to integrate some GEs in their plans for September. BR Thierry De : t.elsaleh at surrey.ac.uk [mailto:t.elsaleh at surrey.ac.uk] Envoy? : mercredi 8 mai 2013 11:45 ? : NAGELLEN Thierry OLNC/OLPS Cc : fiware-iot at lists.fi-ware.eu Objet : RE: Urgent actions from last Architecture Board Hello Thierry, Would you know the period in which the webinars need to take place? 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: 07 May 2013 08:37 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Urgent actions from last Architecture Board Importance: High Dear all, You can find in attachment the minutes from the last Architecture Board (last Friday). We have to urgent actions to manage to be up to date for the new UC projects and to push them to use our GEs. 1. To check the list of GE which will be available in release 2 (including 2.3) and update the Googledoc spreadsheet 2. Provide dates for webinars on the use of the GE instances before Thursday 9! (this Thursday) because UC Projects will give us the list of attendees one week later. Thanks for your support BR Thierry De : fiware-pcc-bounces at lists.fi-ware.eu [mailto:fiware-pcc-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro Envoy? : mardi 7 mai 2013 09:00 ? : fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu; fiware at lists.fi-ware.eu; fiware-pcc at lists.fi-ware.eu Objet : [Fiware-pcc] Draft minutes of the last FI-PPP AB meeting and related URGENT Action Points on Chapter teams and FI-WARE GEi owners Dear all, Last Friday, May 3rd, we celebrated the first FI-PPP AB virtual meeting involving the new projects in phase 2 of the FI-PPP. You can take a look at the minutes available at: https://docs.google.com/document/d/1_DXfn7qSY4UEidfBv3E9MhplU1wcVOzkEpWhQ_0QK-M/edit?usp=sharing There are two URGENT Action Points that we have to finalize along this week so I ask for the cooperation of the several FI-WARE chapter teams and GEi owners: * Updating spreadsheet about "FI-WARE Testbed/GEis planned usage" available at https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdEd6bGhLQWtNai1jeGN5UnJMeEdxZ0E&usp=sharing * All chapter teams have to review the sheets linked "FI-WARE GEi (2nd Release) planned usage in Phase 1/2" if they haven't done so yet and send me their comments so that I can implement the proposed changes: * @I2ND was going to provide the name of FI-WARE GE and GEis (two first columns) for rows that have to be inserted for the new FI-WARE GEis in 2nd Release * @Apps was going to provide final feedback on whether it would make sense to split the package linked to Business Framework or not * Remember that this is to collect info about planned usage by UC projects, that's why it makes sense to have some rows in the sheets linked to packages of GEis / functionalities (e.g., Cloud) than as individual GEis * Please, don't edit yourself, forward feedback to me through your chapter leader * VERY IMPORTANT for FI-WARE GEi owners: Proposal on first series of webinars regarding FI-WARE GEis already available for UC projects in the Testbed (or to be available by end of May): * Deadline: Thursday May 9 EOB. * You should edit the following spreadsheet in Google docs yourself: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdF9aeWphSkFkWjJRQ3pPVW1PVURLX3c&usp=sharing * You just have to provide two alternative dates during the period from May 20th until June 14th. Try to make them in two alternative weeks. * Note that these webinars are not mandatory for all FI-WARE GEis but strongly recommended for GEis/functionality that can be already demonstrated in the Testbed while in the webinars or at least presented as mockup (e.g., this might be useful for some new Cloud functions) * You can select your favorite bridge tools. How do you declare the tools you plan to use so that people will connect ? Defining a hashtag * This will be used as an Id for the bridge/webex details to be provided in sheet "Logistics details" * It will be referred from the cell associated to the row linked to your GEi and the column "Logistic details" of sheet "FI-WARE GEi (2nd Release) - series of webinars" * We advise you also to use this hashtag in posts to the @FIware twitter account during the webinar. It may be helpful to collect questions on-line so people do not necessarily interrupt you (you can watch the twitter account and then decide when to answer those questions) * UC projects will declare their interest to attend the different webinars along the week of May 17th Please pay attention to this two urgent actions. We believe that their implementation can be rather useful for a successful project review mid June. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect You can follow FI-WARE at: 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sabrina.guerra at telecomitalia.it Wed May 15 11:59:08 2013 From: sabrina.guerra at telecomitalia.it (Guerra Sabrina) Date: Wed, 15 May 2013 11:59:08 +0200 Subject: [Fiware-iot] Meeting invitation: FIWARE GE (2nd Release) - IoT Webinar - Gateway Protocol Adapter (ZPA) Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5AEB04355@GRFMBX702BA020.griffon.local> Hi all, Tuesday 16th May, at 15.00 Telecom Italia will have a webinar on Protocol Adapter GE (2nd Release). For attending to this webinar please join to the webex and powwownow sessions that are included in this e-mail. Please, if you plan to participate to this webinar send me an e-mail. Best regards, Sabrina Topic: FIWARE GE (2nd Release) - IoT Webinar - Gateway Protocol Adapter (ZPA) Date: Thursday, May 16, 2013 Time: 3:00 pm, Europe Summer Time (Rome, GMT+02:00) Meeting Number: 702 385 598 Meeting Password: fiwareiot ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://telecomitalia-sales.webex.com/telecomitalia-sales-en/j.php?ED=255250642&UID=1545816402&PW=NMTVhOWE5YzMy&RT=MiMxNDI%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: fiwareiot 4. Click "Join". To view in other time zones or languages, please click the link: https://telecomitalia-sales.webex.com/telecomitalia-sales-en/j.php?ED=255250642&UID=1545816402&PW=NMTVhOWE5YzMy&ORT=MiMxNDI%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- The audio conference will use powwownow: http://pdf.powwownow.com/pdf/USA_en_pwn-dial-in-numbers.pdf powwownow PIN dedicated to the FI-WARE IoT chapter: 028919 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://telecomitalia-sales.webex.com/telecomitalia-sales-en/mc 2. On the left navigation bar, click "Support". You can contact me at: gianpiero.fici at telecomitalia.it 39-0112287019 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://telecomitalia-sales.webex.com/telecomitalia-sales-en/j.php?ED=255250642&UID=1545816402&ICS=MI&LD=1&RD=2&ST=1&SHA2=bdNhbx51stYTWEHMKjxicjuyKgI4YV1YsrtSXWTTf9o=&RT=MiMxNDI%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://telecomitalia-sales.webex.com/telecomitalia-sales-en/systemdiagnosis.php. http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. 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: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: From thierry.nagellen at orange.com Thu May 16 08:45:44 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Thu, 16 May 2013 06:45:44 +0000 Subject: [Fiware-iot] Actions for peer-review of Open Specs Message-ID: <22212_1368686745_51948099_22212_1959_1_976A65C5A08ADF49B9A8523F7F81925C0E2833@PEXCVZYM13.corporate.adroot.infra.ftgroup> Dear all, This is a reminder for some of you who were not at the IoT meeting. We have an urgent action regarding peer review of Open Specs for WP6 You can check the minutes or directly the cockpit where I put partners' names. Minutes : https://docs.google.com/document/d/1Dd8qDT3LbCEXzwesnK1BGhq_bwxFMLfluEuJSEDKSjE/edit cockpit : https://docs.google.com/spreadsheet/ccc?key=0AmxBgS-lWT4vdHYxYTVOZ3FrNEprZXRBZk80TGRLMGc#gid=0 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 carsten.magerkurth at sap.com Fri May 17 10:08:08 2013 From: carsten.magerkurth at sap.com (Magerkurth, Carsten) Date: Fri, 17 May 2013 08:08:08 +0000 Subject: [Fiware-iot] Actions for peer-review of Open Specs In-Reply-To: <22212_1368686745_51948099_22212_1959_1_976A65C5A08ADF49B9A8523F7F81925C0E2833@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <22212_1368686745_51948099_22212_1959_1_976A65C5A08ADF49B9A8523F7F81925C0E2833@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <85A7992034599A4A83D05984B3A9EA710D04D87C@DEWDFEMB12A.global.corp.sap> Dear Thierry, please find the review of the SAP colleagues attached, best regards, Carsten 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, 16. Mai 2013 08:46 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Actions for peer-review of Open Specs Dear all, This is a reminder for some of you who were not at the IoT meeting. We have an urgent action regarding peer review of Open Specs for WP6 You can check the minutes or directly the cockpit where I put partners' names. Minutes : https://docs.google.com/document/d/1Dd8qDT3LbCEXzwesnK1BGhq_bwxFMLfluEuJSEDKSjE/edit cockpit : https://docs.google.com/spreadsheet/ccc?key=0AmxBgS-lWT4vdHYxYTVOZ3FrNEprZXRBZk80TGRLMGc#gid=0 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: D612_WP6_v11_generated_ReviewSAP.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 4708460 bytes Desc: D612_WP6_v11_generated_ReviewSAP.docx URL: From t.elsaleh at surrey.ac.uk Fri May 17 11:43:01 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Fri, 17 May 2013 10:43:01 +0100 Subject: [Fiware-iot] Actions for peer-review of Open Specs In-Reply-To: <85A7992034599A4A83D05984B3A9EA710D04D87C@DEWDFEMB12A.global.corp.sap> References: <22212_1368686745_51948099_22212_1959_1_976A65C5A08ADF49B9A8523F7F81925C0E2833@PEXCVZYM13.corporate.adroot.infra.ftgroup> <85A7992034599A4A83D05984B3A9EA710D04D87C@DEWDFEMB12A.global.corp.sap> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789E667E5@EXMB05CMS.surrey.ac.uk> Hello Thierry, Attached is the UNIS review for the Semantic Annotation 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 Magerkurth, Carsten Sent: 17 May 2013 09:08 To: thierry.nagellen at orange.com; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Actions for peer-review of Open Specs Dear Thierry, please find the review of the SAP colleagues attached, best regards, Carsten 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, 16. Mai 2013 08:46 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Actions for peer-review of Open Specs Dear all, This is a reminder for some of you who were not at the IoT meeting. We have an urgent action regarding peer review of Open Specs for WP6 You can check the minutes or directly the cockpit where I put partners' names. Minutes : https://docs.google.com/document/d/1Dd8qDT3LbCEXzwesnK1BGhq_bwxFMLfluEuJSEDKSjE/edit cockpit : https://docs.google.com/spreadsheet/ccc?key=0AmxBgS-lWT4vdHYxYTVOZ3FrNEprZXRBZk80TGRLMGc#gid=0 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: D612_WP6_v11_generated-SA_peer_review-WP5_UNIS.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 4690338 bytes Desc: D612_WP6_v11_generated-SA_peer_review-WP5_UNIS.docx URL: From thierry.nagellen at orange.com Fri May 17 13:57:18 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Fri, 17 May 2013 11:57:18 +0000 Subject: [Fiware-iot] Actions for peer-review of Open Specs In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA789E667E5@EXMB05CMS.surrey.ac.uk> References: <22212_1368686745_51948099_22212_1959_1_976A65C5A08ADF49B9A8523F7F81925C0E2833@PEXCVZYM13.corporate.adroot.infra.ftgroup> <85A7992034599A4A83D05984B3A9EA710D04D87C@DEWDFEMB12A.global.corp.sap> <2AAC0B6FF99A064C853BFB1C9295F3CCA789E667E5@EXMB05CMS.surrey.ac.uk> Message-ID: <31939_1368791839_51961B1F_31939_2232_1_976A65C5A08ADF49B9A8523F7F81925C0E2F59@PEXCVZYM13.corporate.adroot.infra.ftgroup> Thanks Tarek De : t.elsaleh at surrey.ac.uk [mailto:t.elsaleh at surrey.ac.uk] Envoy? : vendredi 17 mai 2013 11:43 ? : NAGELLEN Thierry OLNC/OLPS Cc : fiware-iot at lists.fi-ware.eu Objet : RE: [Fiware-iot] Actions for peer-review of Open Specs Hello Thierry, Attached is the UNIS review for the Semantic Annotation 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 Magerkurth, Carsten Sent: 17 May 2013 09:08 To: thierry.nagellen at orange.com; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Actions for peer-review of Open Specs Dear Thierry, please find the review of the SAP colleagues attached, best regards, Carsten 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, 16. Mai 2013 08:46 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Actions for peer-review of Open Specs Dear all, This is a reminder for some of you who were not at the IoT meeting. We have an urgent action regarding peer review of Open Specs for WP6 You can check the minutes or directly the cockpit where I put partners' names. Minutes : https://docs.google.com/document/d/1Dd8qDT3LbCEXzwesnK1BGhq_bwxFMLfluEuJSEDKSjE/edit cockpit : https://docs.google.com/spreadsheet/ccc?key=0AmxBgS-lWT4vdHYxYTVOZ3FrNEprZXRBZk80TGRLMGc#gid=0 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 thierry.nagellen at orange.com Fri May 17 13:57:44 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Fri, 17 May 2013 11:57:44 +0000 Subject: [Fiware-iot] Actions for peer-review of Open Specs In-Reply-To: <85A7992034599A4A83D05984B3A9EA710D04D87C@DEWDFEMB12A.global.corp.sap> References: <22212_1368686745_51948099_22212_1959_1_976A65C5A08ADF49B9A8523F7F81925C0E2833@PEXCVZYM13.corporate.adroot.infra.ftgroup> <85A7992034599A4A83D05984B3A9EA710D04D87C@DEWDFEMB12A.global.corp.sap> Message-ID: <30806_1368791865_51961B39_30806_5902_1_976A65C5A08ADF49B9A8523F7F81925C0E2F6B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Thanks Carsten De : Magerkurth, Carsten [mailto:carsten.magerkurth at sap.com] Envoy? : vendredi 17 mai 2013 10:08 ? : NAGELLEN Thierry OLNC/OLPS; fiware-iot at lists.fi-ware.eu Objet : RE: Actions for peer-review of Open Specs Dear Thierry, please find the review of the SAP colleagues attached, best regards, Carsten 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, 16. Mai 2013 08:46 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Actions for peer-review of Open Specs Dear all, This is a reminder for some of you who were not at the IoT meeting. We have an urgent action regarding peer review of Open Specs for WP6 You can check the minutes or directly the cockpit where I put partners' names. Minutes : https://docs.google.com/document/d/1Dd8qDT3LbCEXzwesnK1BGhq_bwxFMLfluEuJSEDKSjE/edit cockpit : https://docs.google.com/spreadsheet/ccc?key=0AmxBgS-lWT4vdHYxYTVOZ3FrNEprZXRBZk80TGRLMGc#gid=0 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 sabrina.guerra at telecomitalia.it Fri May 17 14:53:51 2013 From: sabrina.guerra at telecomitalia.it (Guerra Sabrina) Date: Fri, 17 May 2013 14:53:51 +0200 Subject: [Fiware-iot] Actions for peer-review of Open Specs Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5AEB04B75@GRFMBX702BA020.griffon.local> Hi Thierry, I attach TI contribution related to the peer-review of the BigData (WP6). Since in this section there is the note reported below, probably the comments and revisions are based on a description that will be changed in the subsequent versions (as it is written in the note). IMPORTANT NOTE: Due to a change in Telefonica's strategy related to Big Data products and tools, the previous implementation of this GE has been discontinued. The new implementation of the Big Data Generic Enabler to be deliver as part of the FI-WARE project is still under analysis and the specifications and related documents will be provided in subsequent versions of the deliverables. Best regards, Sabrina ------------------------------------------------------------------ Telecom Italia Sabrina Guerra Innovation & Industry Relations Research & Prototyping Future Internet Technologies & Research 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: D612_WP6_v11_BigData-peer_review_TI.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 265283 bytes Desc: D612_WP6_v11_BigData-peer_review_TI.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 thierry.nagellen at orange.com Fri May 17 14:54:42 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Fri, 17 May 2013 12:54:42 +0000 Subject: [Fiware-iot] Actions for peer-review of Open Specs In-Reply-To: <36A93B31228D3B49B691AD31652BCAE9A5AEB04B75@GRFMBX702BA020.griffon.local> References: <36A93B31228D3B49B691AD31652BCAE9A5AEB04B75@GRFMBX702BA020.griffon.local> Message-ID: <7621_1368795284_51962894_7621_821_4_976A65C5A08ADF49B9A8523F7F81925C0E3027@PEXCVZYM13.corporate.adroot.infra.ftgroup> Ok thanks a lot Sabrina Thierry De : Guerra Sabrina [mailto:sabrina.guerra at telecomitalia.it] Envoy? : vendredi 17 mai 2013 14:54 ? : NAGELLEN Thierry OLNC/OLPS Cc : CARLOS RALLI UCENDO (ralli at tid.es) (ralli at tid.es); fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] Actions for peer-review of Open Specs Hi Thierry, I attach TI contribution related to the peer-review of the BigData (WP6). Since in this section there is the note reported below, probably the comments and revisions are based on a description that will be changed in the subsequent versions (as it is written in the note). IMPORTANT NOTE: Due to a change in Telefonica's strategy related to Big Data products and tools, the previous implementation of this GE has been discontinued. The new implementation of the Big Data Generic Enabler to be deliver as part of the FI-WARE project is still under analysis and the specifications and related documents will be provided in subsequent versions of the deliverables. Best regards, Sabrina ------------------------------------------------------------------ Telecom Italia Sabrina Guerra Innovation & Industry Relations Research & Prototyping Future Internet Technologies & Research 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. -------------- 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 maarten.los at atosresearch.eu Fri May 17 15:35:38 2013 From: maarten.los at atosresearch.eu (Maarten Los) Date: Fri, 17 May 2013 15:35:38 +0200 Subject: [Fiware-iot] Actions for peer-review of Open Specs Message-ID: <461EDDC0FEB25648B2FE8B0145848AA5025853AB@INTMAIL02.es.int.atosorigin.com> Hi Thierry, Please find attached our review. Regards, Maarten 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: jueves, 16 de mayo de 2013 8:46 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Actions for peer-review of Open Specs Dear all, This is a reminder for some of you who were not at the IoT meeting. We have an urgent action regarding peer review of Open Specs for WP6 You can check the minutes or directly the cockpit where I put partners' names. Minutes : https://docs.google.com/document/d/1Dd8qDT3LbCEXzwesnK1BGhq_bwxFMLfluEuJ SEDKSjE/edit cockpit : https://docs.google.com/spreadsheet/ccc?key=0AmxBgS-lWT4vdHYxYTVOZ3FrNEp rZXRBZk80TGRLMGc#gid=0 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. ------------------------------------------------------------------ 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: D612_WP6_v11_Atos_Reviewed.docx Type: application/octet-stream Size: 4693542 bytes Desc: D612_WP6_v11_Atos_Reviewed.docx URL: From thierry.nagellen at orange.com Fri May 17 16:02:58 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Fri, 17 May 2013 14:02:58 +0000 Subject: [Fiware-iot] Actions for peer-review of Open Specs In-Reply-To: <461EDDC0FEB25648B2FE8B0145848AA5025853AB@INTMAIL02.es.int.atosorigin.com> References: <461EDDC0FEB25648B2FE8B0145848AA5025853AB@INTMAIL02.es.int.atosorigin.com> Message-ID: <13607_1368799378_51963892_13607_280_1_976A65C5A08ADF49B9A8523F7F81925C0E3097@PEXCVZYM13.corporate.adroot.infra.ftgroup> Thanks Marteen. BR Thierry De : Maarten Los [mailto:maarten.los at atosresearch.eu] Envoy? : vendredi 17 mai 2013 15:36 ? : NAGELLEN Thierry OLNC/OLPS; fiware-iot at lists.fi-ware.eu Objet : RE: [Fiware-iot] Actions for peer-review of Open Specs Hi Thierry, Please find attached our review. Regards, Maarten 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: jueves, 16 de mayo de 2013 8:46 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Actions for peer-review of Open Specs Dear all, This is a reminder for some of you who were not at the IoT meeting. We have an urgent action regarding peer review of Open Specs for WP6 You can check the minutes or directly the cockpit where I put partners' names. Minutes : https://docs.google.com/document/d/1Dd8qDT3LbCEXzwesnK1BGhq_bwxFMLfluEuJSEDKSjE/edit cockpit : https://docs.google.com/spreadsheet/ccc?key=0AmxBgS-lWT4vdHYxYTVOZ3FrNEprZXRBZk80TGRLMGc#gid=0 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. ------------------------------------------------------------------ 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. ------------------------------------------------------------------ _________________________________________________________________________________________________________________________ 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 Fri May 17 18:48:55 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Fri, 17 May 2013 18:48:55 +0200 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> Message-ID: <51965F77.3030300@tid.es> Dear Raihan, I think I have found a typo in the .doc. On the one hand, in the update case you have for the discoverContextAvailability: [cid:part1.03070007.08030600 at tid.es] On the other hand, the XML you use for this is shows a different attribute: [cid:part2.08040406.01020903 at tid.es] I understand that the right one is "measurement". Please, confirm. 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: adicdigj.png Type: image/png Size: 15856 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bbdbhhhb.png Type: image/png Size: 17414 bytes Desc: not available URL: From t.elsaleh at surrey.ac.uk Mon May 20 11:36:10 2013 From: t.elsaleh at surrey.ac.uk (t.elsaleh at surrey.ac.uk) Date: Mon, 20 May 2013 10:36:10 +0100 Subject: [Fiware-iot] FW: [Fiware-testbed] cockpit v2 ready References: <2AAC0B6FF99A064C853BFB1C9295F3CCA789E668F0@EXMB05CMS.surrey.ac.uk> Message-ID: <2AAC0B6FF99A064C853BFB1C9295F3CCA789E66935@EXMB05CMS.surrey.ac.uk> Hello All, Please look at the email below from Stefano (WP10 - Testbed). There seems to be some inconsistent information between the Cockpit and Manuals wikis. To resolve this, Stefano has requested information about the GEs as in the format below: * GE Name: * GE Implementation Name: * GE Implementation Owner: * Date of Deployment: You could either send this directly to him, or reply to me to compile a list and then send to him. Carlos, I think some countries today are on holiday, like Germany and France. As WPA and from an authoritative perspective, would you be able to compile the information on behalf of NEC and Orange? Best regards, Tarek From: Elsaleh T Mr (Electronic Eng) Sent: 20 May 2013 10:21 To: 'stefano de panfilis' Cc: thierry.nagellen at orange.com; Salvatore Longo Subject: RE: [Fiware-testbed] cockpit v2 ready Hello Stefano, I believe that today could be a public holiday for some countries, like Germany and France. I will forward this to the WP and will try to get this info by EOB. But just in case, and as an example, for University of Surrey: * GE Name: Configuration Management GE * GE Implementation Name: IoT Discovery * GE Implementation Owner: UNIS * Date of Deployment: 30/06/13 Please let me know if the information provided for this specific GEI is insufficient. Best regards, Tarek From: stefano de panfilis [mailto:stefano.depanfilis at eng.it] Sent: 20 May 2013 09:36 To: Elsaleh T Mr (Electronic Eng); thierry.nagellen at orange.com; Salvatore Longo Subject: Re: [Fiware-testbed] cockpit v2 ready dear tarek, and thierry and salvatore as well, the page of the cockpit for release 2 is at: https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/Testbed_V2_Implementation_Cockpit the planned geis are at: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FiwareDeliverablesR2 between the two lists there is a clear huge mismatch which alone i'm not able to resolve. just to remind you that in the cockpit we must have not only the geis released in v2, but also the released up and running in v1, i.e. in cockpit ve must have the Whole set of deployed (and plenned to be deplyed) geis. what i need is only the the list of geis with the ge owener (organisation short name) and the date of deplyment. the rest i'll create. please do this by today so Tomorrow at the phc we have the full list ready. ciao, stefano 2013/5/20 > Hello Stefano, With regards to IoT, University of Surrey is planning to release a GEI of the Configuration Management for 30/06/13 (2.x.x). Apparently there is some missing information. Could you please point to me where you gather the information so that I can add it? Is this via the template (https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/Template:GETestbedRequirements )? Best regards, Tarek From: fiware-testbed-bounces at lists.fi-ware.eu [mailto:fiware-testbed-bounces at lists.fi-ware.eu] On Behalf Of stefano de panfilis Sent: 18 May 2013 00:50 To: fiware-testbed at lists.fi-ware.eu Subject: [Fiware-testbed] cockpit v2 ready dear all, the implementation cockpit v2 page at (https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/Testbed_V2_Implementation_Cockpit#Cockpit), is now ready for final check before use since our next phc as agreed. the only section i have problem to update with respect to the installation and administration guide page (both april and june subsections) is iot which indeed is marked in red. infact the missmatch between the two pages are too big and unclear to me. please salvatore (and thierry) can you clarify? there is also a single missmatch with the june section which i do not know how to solve (publsh subscribe ges family ...). please Miguel to verify it with Carlos. ciao, stefano -- Stefano De Panfilis Chief Innovation Officer Engineering Ingegneria Informatica S.p.A. via Riccardo Morandi 32 00148 Roma Italy tel (direct): +39-068307-4295 tel (secr.): +39-068307-4513 fax: +39-068307-4200 cell: +39-335-7542-567 -- Stefano De Panfilis Chief Innovation Officer Engineering Ingegneria Informatica S.p.A. via Riccardo Morandi 32 00148 Roma Italy tel (direct): +39-068307-4295 tel (secr.): +39-068307-4513 fax: +39-068307-4200 cell: +39-335-7542-567 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralli at tid.es Mon May 20 12:59:45 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 20 May 2013 10:59:45 +0000 Subject: [Fiware-iot] [Fiware-testbed] cockpit v2 ready In-Reply-To: <2AAC0B6FF99A064C853BFB1C9295F3CCA789E66935@EXMB05CMS.surrey.ac.uk> Message-ID: <1971FF81B8E01C45991F6F92B9E3B25089079297@EX10-MB2-MAD.hi.inet> Hi Tarek, I think it is better to wait till tomorrow to get the most accurate info. 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: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 20 de mayo de 2013 11:36 Para: "fiware-iot at lists.fi-ware.eu" > CC: "stefano.depanfilis at eng.it" >, Carlos Ralli Ucendo > Asunto: FW: [Fiware-testbed] cockpit v2 ready Hello All, Please look at the email below from Stefano (WP10 ? Testbed). There seems to be some inconsistent information between the Cockpit and Manuals wikis. To resolve this, Stefano has requested information about the GEs as in the format below: ? GE Name: ? GE Implementation Name: ? GE Implementation Owner: ? Date of Deployment: You could either send this directly to him, or reply to me to compile a list and then send to him. Carlos, I think some countries today are on holiday, like Germany and France. As WPA and from an authoritative perspective, would you be able to compile the information on behalf of NEC and Orange? Best regards, Tarek From: Elsaleh T Mr (Electronic Eng) Sent: 20 May 2013 10:21 To: 'stefano de panfilis' Cc: thierry.nagellen at orange.com; Salvatore Longo Subject: RE: [Fiware-testbed] cockpit v2 ready Hello Stefano, I believe that today could be a public holiday for some countries, like Germany and France. I will forward this to the WP and will try to get this info by EOB. But just in case, and as an example, for University of Surrey: ? GE Name: Configuration Management GE ? GE Implementation Name: IoT Discovery ? GE Implementation Owner: UNIS ? Date of Deployment: 30/06/13 Please let me know if the information provided for this specific GEI is insufficient. Best regards, Tarek From: stefano de panfilis [mailto:stefano.depanfilis at eng.it] Sent: 20 May 2013 09:36 To: Elsaleh T Mr (Electronic Eng); thierry.nagellen at orange.com; Salvatore Longo Subject: Re: [Fiware-testbed] cockpit v2 ready dear tarek, and thierry and salvatore as well, the page of the cockpit for release 2 is at: https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/Testbed_V2_Implementation_Cockpit the planned geis are at: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FiwareDeliverablesR2 between the two lists there is a clear huge mismatch which alone i'm not able to resolve. just to remind you that in the cockpit we must have not only the geis released in v2, but also the released up and running in v1, i.e. in cockpit ve must have the Whole set of deployed (and plenned to be deplyed) geis. what i need is only the the list of geis with the ge owener (organisation short name) and the date of deplyment. the rest i'll create. please do this by today so Tomorrow at the phc we have the full list ready. ciao, stefano 2013/5/20 > Hello Stefano, With regards to IoT, University of Surrey is planning to release a GEI of the Configuration Management for 30/06/13 (2.x.x). Apparently there is some missing information. Could you please point to me where you gather the information so that I can add it? Is this via the template (https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/Template:GETestbedRequirements )? Best regards, Tarek From:fiware-testbed-bounces at lists.fi-ware.eu [mailto:fiware-testbed-bounces at lists.fi-ware.eu] On Behalf Of stefano de panfilis Sent: 18 May 2013 00:50 To: fiware-testbed at lists.fi-ware.eu Subject: [Fiware-testbed] cockpit v2 ready dear all, the implementation cockpit v2 page at (https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/Testbed_V2_Implementation_Cockpit#Cockpit), is now ready for final check before use since our next phc as agreed. the only section i have problem to update with respect to the installation and administration guide page (both april and june subsections) is iot which indeed is marked in red. infact the missmatch between the two pages are too big and unclear to me. please salvatore (and thierry) can you clarify? there is also a single missmatch with the june section which i do not know how to solve (publsh subscribe ges family ...). please Miguel to verify it with Carlos. ciao, stefano -- Stefano De Panfilis Chief Innovation Officer Engineering Ingegneria Informatica S.p.A. via Riccardo Morandi 32 00148 Roma Italy tel (direct): +39-068307-4295 tel (secr.): +39-068307-4513 fax: +39-068307-4200 cell: +39-335-7542-567 -- Stefano De Panfilis Chief Innovation Officer Engineering Ingegneria Informatica S.p.A. via Riccardo Morandi 32 00148 Roma Italy tel (direct): +39-068307-4295 tel (secr.): +39-068307-4513 fax: +39-068307-4200 cell: +39-335-7542-567 ________________________________ 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 Tue May 21 10:06:43 2013 From: raihan.ul-islam at neclab.eu (Raihan Ul-Islam) Date: Tue, 21 May 2013 08:06:43 +0000 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: <51965F77.3030300@tid.es> References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> <51965F77.3030300@tid.es> Message-ID: Hi Fermin, I am sorry for my late answer . We had a bank holiday on Monday. Thanks for your notification. It is a typo mistake. The discoverContextAvailabilityRequest will be following 3. discoverContextAvailabilityRequest Sensor5 measurement Include Associations TARGETS Best Regards Raihan From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: 17 May 2013 18:49 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, I think I have found a typo in the .doc. On the one hand, in the update case you have for the discoverContextAvailability: [cid:image001.png at 01CE560A.E47DBB70] On the other hand, the XML you use for this is shows a different attribute: [cid:image002.png at 01CE560A.E47DBB70] I understand that the right one is "measurement". Please, confirm. 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 15856 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 17414 bytes Desc: image002.png URL: From ralli at tid.es Wed May 22 09:30:25 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 22 May 2013 07:30:25 +0000 Subject: [Fiware-iot] Today's conf call will be at 10:30 (till 11:30) Message-ID: <1971FF81B8E01C45991F6F92B9E3B2508907D72F@EX10-MB2-MAD.hi.inet> Dear colleagues, We will make a short call in order to check the status and finalize all pending deliverables from our side. As I was truly busy last week to generate WP12 deliverables and Thierry if off today for other project final review, I'll need your help to compile the info and deliver everything asap. This is the googledoc including connection details: https://docs.google.com/document/d/1CWYZrQPj-RkoqKB3TYSm1oIGRR-ER9a7CHGh2Gx5EgQ/edit Thanks for your cooperation. 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 stefano.depanfilis at eng.it Mon May 20 15:08:53 2013 From: stefano.depanfilis at eng.it (stefano de panfilis) Date: Mon, 20 May 2013 15:08:53 +0200 Subject: [Fiware-iot] [Fiware-testbed] cockpit v2 ready In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B25089079297@EX10-MB2-MAD.hi.inet> References: <2AAC0B6FF99A064C853BFB1C9295F3CCA789E66935@EXMB05CMS.surrey.ac.uk> <1971FF81B8E01C45991F6F92B9E3B25089079297@EX10-MB2-MAD.hi.inet> Message-ID: dear Carlos, all these info should be ready since weeks ..... why to wait more? for you to know, iot is the only chapter with incomplete info. ciao, stefano 2013/5/20 CARLOS RALLI UCENDO > Hi Tarek, > > I think it is better to wait till tomorrow to get the most accurate info. > > 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: "t.elsaleh at surrey.ac.uk" > Fecha: lunes, 20 de mayo de 2013 11:36 > Para: "fiware-iot at lists.fi-ware.eu" > CC: "stefano.depanfilis at eng.it" , Carlos Ralli > Ucendo > Asunto: FW: [Fiware-testbed] cockpit v2 ready > > Hello All, > > > > Please look at the email below from Stefano (WP10 ? Testbed). There seems > to be some inconsistent information between the Cockpit and Manuals wikis. > > > > To resolve this, Stefano has requested information about the GEs as in the > format below: > > > > ? GE Name: > > ? GE Implementation Name: > > ? GE Implementation Owner: > > ? Date of Deployment: > > > > You could either send this directly to him, or reply to me to compile a > list and then send to him. > > > > Carlos, I think some countries today are on holiday, like Germany and > France. As WPA and from an authoritative perspective, would you be able to > compile the information on behalf of NEC and Orange? > > > > Best regards, > > Tarek > > > > > > > > *From:* Elsaleh T Mr (Electronic Eng) > *Sent:* 20 May 2013 10:21 > *To:* 'stefano de panfilis' > *Cc:* thierry.nagellen at orange.com; Salvatore Longo > *Subject:* RE: [Fiware-testbed] cockpit v2 ready > > > > Hello Stefano, > > > > I believe that today could be a public holiday for some countries, like > Germany and France. I will forward this to the WP and will try to get this > info by EOB. > > > > But just in case, and as an example, for University of Surrey: > > > > ? GE Name: Configuration Management GE > > ? GE Implementation Name: IoT Discovery > > ? GE Implementation Owner: UNIS > > ? Date of Deployment: 30/06/13 > > > > Please let me know if the information provided for this specific GEI is > insufficient. > > > > Best regards, > > Tarek > > > > > > > > *From:* stefano de panfilis [mailto:stefano.depanfilis at eng.it] > > *Sent:* 20 May 2013 09:36 > *To:* Elsaleh T Mr (Electronic Eng); thierry.nagellen at orange.com; > Salvatore Longo > *Subject:* Re: [Fiware-testbed] cockpit v2 ready > > > > dear tarek, and thierry and salvatore as well, > > > > the page of the cockpit for release 2 is at: > > > https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/Testbed_V2_Implementation_Cockpit > > > > the planned geis are at: > > > https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FiwareDeliverablesR2 > > between the two lists there is a clear huge mismatch which alone i'm not > able to resolve. > > > > just to remind you that in the cockpit we must have not only the geis > released in v2, but also the released up and running in v1, i.e. in cockpit > ve must have the Whole set of deployed (and plenned to be deplyed) geis. > > > > what i need is only the the list of geis with the ge owener (organisation > short name) and the date of deplyment. the rest i'll create. > > > > please do this by today so Tomorrow at the phc we have the full list ready. > > > > ciao, > > stefano > > > > 2013/5/20 > > Hello Stefano, > > > > With regards to IoT, University of Surrey is planning to release a GEI of > the Configuration Management for 30/06/13 (2.x.x). > > > > Apparently there is some missing information. Could you please point to me > where you gather the information so that I can add it? Is this via the > template ( > https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/Template:GETestbedRequirements)? > > > > Best regards, > > Tarek > > > > > > > > *From:*fiware-testbed-bounces at lists.fi-ware.eu [mailto: > fiware-testbed-bounces at lists.fi-ware.eu] *On Behalf Of *stefano de > panfilis > *Sent:* 18 May 2013 00:50 > *To:* fiware-testbed at lists.fi-ware.eu > *Subject:* [Fiware-testbed] cockpit v2 ready > > > > dear all, > > > > the implementation cockpit v2 page at ( > https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/Testbed_V2_Implementation_Cockpit#Cockpit > ), > > is now ready for final check before use since our next phc as agreed. > > > > the only section i have problem to update with respect to the installation > and administration guide page (both april and june subsections) is iot > which indeed is marked in red. infact the missmatch between the two pages > are too big and unclear to me. please salvatore (and thierry) can you > clarify? > > > > there is also a single missmatch with the june section which i do not know > how to solve (publsh subscribe ges family ...). please Miguel to verify it > with Carlos. > > > > ciao, > > stefano > > -- > Stefano De Panfilis > Chief Innovation Officer > Engineering Ingegneria Informatica S.p.A. > via Riccardo Morandi 32 > 00148 Roma > Italy > > tel (direct): +39-068307-4295 > tel (secr.): +39-068307-4513 > fax: +39-068307-4200 > cell: +39-335-7542-567 > > > > > -- > Stefano De Panfilis > Chief Innovation Officer > Engineering Ingegneria Informatica S.p.A. > via Riccardo Morandi 32 > 00148 Roma > Italy > > tel (direct): +39-068307-4295 > tel (secr.): +39-068307-4513 > fax: +39-068307-4200 > cell: +39-335-7542-567 > > ------------------------------ > > 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 > -- Stefano De Panfilis Chief Innovation Officer Engineering Ingegneria Informatica S.p.A. via Riccardo Morandi 32 00148 Roma Italy tel (direct): +39-068307-4295 tel (secr.): +39-068307-4513 fax: +39-068307-4200 cell: +39-335-7542-567 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sabrina.guerra at telecomitalia.it Wed May 22 11:52:14 2013 From: sabrina.guerra at telecomitalia.it (Guerra Sabrina) Date: Wed, 22 May 2013 11:52:14 +0200 Subject: [Fiware-iot] R: Meeting invitation: FIWARE GE (2nd Release) - IoT Webinar - Gateway Protocol Adapter (ZPA) Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5AEC142E1@GRFMBX702BA020.griffon.local> Hi all, Friday 24th May, at 10.00 a.m. Telecom Italia will have the second webinar on Protocol Adapter GE (2nd Release). For attending to this webinar please join to the webex and powwownow sessions that are included in this e-mail. Please, if you plan to participate to this webinar send me an e-mail and put your name in the following spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdF9aeWphSkFkWjJRQ3pPVW1PVURLX3c#gid=8 Best regards, Sabrina Topic: FIWARE GE (2nd Release) - IoT Webinar - Gateway Protocol Adapter (ZPA) Date: Friday, May 24, 2013 Time: 10:00 am, Europe Summer Time (Rome, GMT+02:00) Meeting Number: 703 006 426 Meeting Password: fiwareiot ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://telecomitalia-sales.webex.com/telecomitalia-sales-en/j.php?ED=256314512&UID=1550416512&PW=NMjhlM2JmZjQx&RT=MiMxNDI%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: fiwareiot 4. Click "Join". To view in other time zones or languages, please click the link: https://telecomitalia-sales.webex.com/telecomitalia-sales-en/j.php?ED=256314512&UID=1550416512&PW=NMjhlM2JmZjQx&ORT=MiMxNDI%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- The audio conference will use powwownow: http://pdf.powwownow.com/pdf/USA_en_pwn-dial-in-numbers.pdf ; powwownow PIN dedicated to the FI-WARE IoT chapter: 028919 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://telecomitalia-sales.webex.com/telecomitalia-sales-en/mc 2. On the left navigation bar, click "Support". You can contact me at: sabrina.guerra at telecomitalia.it To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://telecomitalia-sales.webex.com/telecomitalia-sales-en/j.php?ED=256314512&UID=1550416512&ICS=MI&LD=1&RD=2&ST=1&SHA2=aXXmow2DYnR7RgxWP0vNNLqSdvwgIghLkyWcRDGrlsg=&RT=MiMxNDI%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://telecomitalia-sales.webex.com/telecomitalia-sales-en/systemdiagnosis.php. http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. 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: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: From Tobias.Jacobs at neclab.eu Wed May 22 12:13:26 2013 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Wed, 22 May 2013 10:13:26 +0000 Subject: [Fiware-iot] IoT Broker webinar invitation Message-ID: <8755F290097BD941865DC4245B335D2D38F8FBEF@Hydra.office.hd> Dear all, please find below the information required to join the IoT Broker webinar. We use a PowWowNow for the audio and a separate system for screen sharing. PowWowNow dial-in numbers http://pdf.powwownow.com/pdf/USA_en_pwn-dial-in-numbers.pdf PIN will be 613931 This is the link for accessing the presentation: https://join.me/819-307-828 As the number of participants is limited with this system, please let us know if you have connection problems. Best regards Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From fermin at tid.es Wed May 22 13:33:58 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Wed, 22 May 2013 13:33:58 +0200 Subject: [Fiware-iot] [Fiware-ngsi] how to represent associations In-Reply-To: References: <515EDA46.6060801@tid.es> <516C2721.9060604@tid.es> <51965F77.3030300@tid.es> Message-ID: <519CAD26.6010802@tid.es> Dear Rihan, Thanks for your confirmation. I think there is another typo: you use in your XMLs. We agreed in the past (around Apirl 4-5th) that "metadata" is a single word, so it should be . Best regards, ------ Ferm?n El 21/05/2013 10:06, Raihan Ul-Islam escribi?: Hi Fermin, I am sorry for my late answer . We had a bank holiday on Monday. Thanks for your notification. It is a typo mistake. The discoverContextAvailabilityRequest will be following 3. discoverContextAvailabilityRequest Sensor5 measurement Include Associations TARGETS Best Regards Raihan From: Ferm?n Gal?n M?rquez [mailto:fermin at tid.es] Sent: 17 May 2013 18:49 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, I think I have found a typo in the .doc. On the one hand, in the update case you have for the discoverContextAvailability: [cid:part1.07010500.05040909 at tid.es] On the other hand, the XML you use for this is shows a different attribute: [cid:part2.08050108.06050301 at tid.es] I understand that the right one is "measurement". Please, confirm. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15856 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 17414 bytes Desc: not available URL: From fermin at tid.es Wed May 22 13:50:56 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Wed, 22 May 2013 13:50:56 +0200 Subject: [Fiware-iot] Today's conf call will be at 10:30 (till 11:30) In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B2508907D72F@EX10-MB2-MAD.hi.inet> References: <1971FF81B8E01C45991F6F92B9E3B2508907D72F@EX10-MB2-MAD.hi.inet> Message-ID: <519CB120.5000803@tid.es> Hi, Regarding the following item in the minutes: -> TI: the PA was actually used in the last live demo (Nov 2012, Brussels review). The API was not the real one but the component itself yes. Carlos: ask Fermin if the actuation is still needed for this demo. TI: it is available but need to know some days in advance. We still need the lamp turning on/off for Live Demo. It will be exactly the same stuff the one already in release 1. There are no changes from the point of view of development/integration so I understand that it will work. Review is June 12-13th but we will need to do some integration tests before. Please, confirm who is the TI contact for this. Thanks! Best regards, ------ Ferm?n PD. I have pasted the above answer in the minutes. El 22/05/2013 9:30, CARLOS RALLI UCENDO escribi?: Dear colleagues, We will make a short call in order to check the status and finalize all pending deliverables from our side. As I was truly busy last week to generate WP12 deliverables and Thierry if off today for other project final review, I'll need your help to compile the info and deliver everything asap. This is the googledoc including connection details: https://docs.google.com/document/d/1CWYZrQPj-RkoqKB3TYSm1oIGRR-ER9a7CHGh2Gx5EgQ/edit Thanks for your cooperation. 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 _______________________________________________ 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 maarten.los at atosresearch.eu Thu May 23 13:15:19 2013 From: maarten.los at atosresearch.eu (Maarten Los) Date: Thu, 23 May 2013 13:15:19 +0200 Subject: [Fiware-iot] change of interface Message-ID: <461EDDC0FEB25648B2FE8B0145848AA502652649@INTMAIL02.es.int.atosorigin.com> Dear FI-WARE IoT-ers, I will be exchanging south-bound to north-bound, using the NGSI (Now Going Somewhere Inthenetherlands) interface. In non-m2m terms (human2human), this means I will be heading to my home country, also leaving Atos. I enjoyed meeting and working with you all, and will be leaving our contributions in the capable hands of my colleagues at the ARI Smart Objects Lab. Thanks, and best wishes, Maarten maarten.los at gmail.com ------------------------------------------------------------------ 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: From sabrina.guerra at telecomitalia.it Fri May 24 10:59:19 2013 From: sabrina.guerra at telecomitalia.it (Guerra Sabrina) Date: Fri, 24 May 2013 10:59:19 +0200 Subject: [Fiware-iot] R: Meeting invitation: FIWARE GE (2nd Release) - IoT Webinar - Gateway Protocol Adapter (ZPA) Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5AEC14A0E@GRFMBX702BA020.griffon.local> Hi all, thanks for having attended to the second webinar session on Protocol Adapter GE (2nd Release). Here you may find the presentation slides used in the webinar: https://forge.fi-ware.eu/docman/view.php/7/2321/Webinar+%282nd+Release%29+on+Gateway+Protocol+Adapter+GE.pdf If you have any question please feel free to contact me. Best regards, Sabrina Da: Guerra Sabrina Inviato: mercoled? 22 maggio 2013 11:52 A: 'fiware-training at lists.fi-ware.eu' Cc: 'fiware-iot at lists.fi-ware.eu' Oggetto: R: [Fiware-iot] Meeting invitation: FIWARE GE (2nd Release) - IoT Webinar - Gateway Protocol Adapter (ZPA) Hi all, Friday 24th May, at 10.00 a.m. Telecom Italia will have the second webinar on Protocol Adapter GE (2nd Release). For attending to this webinar please join to the webex and powwownow sessions that are included in this e-mail. Please, if you plan to participate to this webinar send me an e-mail and put your name in the following spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdF9aeWphSkFkWjJRQ3pPVW1PVURLX3c#gid=8 Best regards, Sabrina Topic: FIWARE GE (2nd Release) - IoT Webinar - Gateway Protocol Adapter (ZPA) Date: Friday, May 24, 2013 Time: 10:00 am, Europe Summer Time (Rome, GMT+02:00) Meeting Number: 703 006 426 Meeting Password: fiwareiot ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://telecomitalia-sales.webex.com/telecomitalia-sales-en/j.php?ED=256314512&UID=1550416512&PW=NMjhlM2JmZjQx&RT=MiMxNDI%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: fiwareiot 4. Click "Join". To view in other time zones or languages, please click the link: https://telecomitalia-sales.webex.com/telecomitalia-sales-en/j.php?ED=256314512&UID=1550416512&PW=NMjhlM2JmZjQx&ORT=MiMxNDI%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- The audio conference will use powwownow: http://pdf.powwownow.com/pdf/USA_en_pwn-dial-in-numbers.pdf ; powwownow PIN dedicated to the FI-WARE IoT chapter: 028919 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://telecomitalia-sales.webex.com/telecomitalia-sales-en/mc 2. On the left navigation bar, click "Support". You can contact me at: sabrina.guerra at telecomitalia.it To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://telecomitalia-sales.webex.com/telecomitalia-sales-en/j.php?ED=256314512&UID=1550416512&ICS=MI&LD=1&RD=2&ST=1&SHA2=aXXmow2DYnR7RgxWP0vNNLqSdvwgIghLkyWcRDGrlsg=&RT=MiMxNDI%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://telecomitalia-sales.webex.com/telecomitalia-sales-en/systemdiagnosis.php. http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. 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: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: From ralli at tid.es Tue May 28 15:14:50 2013 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 28 May 2013 13:14:50 +0000 Subject: [Fiware-iot] Conference call tomorrow at 10h Message-ID: <1971FF81B8E01C45991F6F92B9E3B250890888D8@EX10-MB2-MAD.hi.inet> Dear Colleagues, Just to confirm our meeting tomorrow. The googledoc we're using is hereby linked: https://docs.google.com/document/d/15rp8NKsCvu9Q4ISXwXl2iHc8cXz3DaNyBhVLq3qhgj8/edit Agenda is currently almost empty, but Thierry and myself will be completing it ASAP. Should you have suggestions, please do use the AoB section and we will re-arrange it before the call. 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 Tue May 28 15:19:21 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Tue, 28 May 2013 13:19:21 +0000 Subject: [Fiware-iot] Conference call tomorrow at 10h In-Reply-To: <1971FF81B8E01C45991F6F92B9E3B250890888D8@EX10-MB2-MAD.hi.inet> References: <1971FF81B8E01C45991F6F92B9E3B250890888D8@EX10-MB2-MAD.hi.inet> Message-ID: <12047_1369747162_51A4AEDA_12047_544_1_976A65C5A08ADF49B9A8523F7F81925C0E4998@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi all We have to come back on integration task for NGSI and to discuss now the delivery for release 2.3. We will check if what we have described in the Technical Roadmap will be developed for End of July because we will have also the new doc to do for OIL for end of July. So it is critical to develop now! We can also discuss a hot topic for September and the campus party: what about scalability and how we can address a bit this issue (not to define huge test to assume that everything will be ok but some first check points and tests to achieve before end of July) BR Thierry 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 28 mai 2013 15:15 ? : fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] Conference call tomorrow at 10h Dear Colleagues, Just to confirm our meeting tomorrow. The googledoc we're using is hereby linked: https://docs.google.com/document/d/15rp8NKsCvu9Q4ISXwXl2iHc8cXz3DaNyBhVLq3qhgj8/edit Agenda is currently almost empty, but Thierry and myself will be completing it ASAP. Should you have suggestions, please do use the AoB section and we will re-arrange it before the call. 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 fermin at tid.es Tue May 28 17:24:51 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Tue, 28 May 2013 17:24:51 +0200 Subject: [Fiware-iot] Conference call tomorrow at 10h In-Reply-To: <12047_1369747162_51A4AEDA_12047_544_1_976A65C5A08ADF49B9A8523F7F81925C0E4998@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <1971FF81B8E01C45991F6F92B9E3B250890888D8@EX10-MB2-MAD.hi.inet> <12047_1369747162_51A4AEDA_12047_544_1_976A65C5A08ADF49B9A8523F7F81925C0E4998@PEXCVZYM13.corporate.adroot.infra.ftgroup> Message-ID: <51A4CC43.5010707@tid.es> Dear Thierry, Some feedback on integration tasks, both from my roles of ConfMan developer and Live Demo App architect: * From a point of view of ConfMan developer: * We (NEC and TID) were performing integration tests between IoT Broker and ConfMan and everything goes well. Next step was to involve other GEs in the integration scenario (I think that Salvatore take this AP, but I haven't had any new since our tests...). * Very recently (yesterday :) we have finalized the association extension implementation in ConfMan ("TID's way": if you follow emails in fiware-ngsi mailling list you know what I mean :) so we are ready to test also this part based on the scenarios that were defined by NEC (in this sense, "TID's way" is compatible with these scenarios). * From a point of view of Live Demo App architect: * A Backend Device Management GE instance connected to SmartSantander sensors is already integrated and working (through IoT Agent component) with Data chapter's Pub/Sub Context Broker. * We have considered to include IoT Broker and ConfMan in the Live Demo App (NEC people is aware of that) as they can add value to "plain" context information reported by Backend Device Management GE. However, this is being delayed due to two reasons: 1) we need IoTAgent to support queryContext operations and currently it doesn't although we are working on this (Carlos can provide a more precise update on this than me); 2) we have to define how application have to be modified (e.g. define "things", how they are represented in the mashup, etc.) and currently the UPM team working on that mashup has no more bandwith to deal with this. Probably we have to do that as evolution to Live Demo App after June 12-13th review. * Protocol Adapter was used in Live Demo R1 and we will plan to keep it for Live Demo App version June 12-13th. I hope this information could help... Best regards, ------ Ferm?n El 28/05/2013 15:19, thierry.nagellen at orange.com escribi?: Hi all We have to come back on integration task for NGSI and to discuss now the delivery for release 2.3. We will check if what we have described in the Technical Roadmap will be developed for End of July because we will have also the new doc to do for OIL for end of July. So it is critical to develop now! We can also discuss a hot topic for September and the campus party: what about scalability and how we can address a bit this issue (not to define huge test to assume that everything will be ok but some first check points and tests to achieve before end of July) BR Thierry 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 28 mai 2013 15:15 ? : fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] Conference call tomorrow at 10h Dear Colleagues, Just to confirm our meeting tomorrow. The googledoc we're using is hereby linked: https://docs.google.com/document/d/15rp8NKsCvu9Q4ISXwXl2iHc8cXz3DaNyBhVLq3qhgj8/edit Agenda is currently almost empty, but Thierry and myself will be completing it ASAP. Should you have suggestions, please do use the AoB section and we will re-arrange it before the call. 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. _______________________________________________ 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 Wed May 29 08:45:46 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 29 May 2013 06:45:46 +0000 Subject: [Fiware-iot] Conference call tomorrow at 10h In-Reply-To: <51A4CC43.5010707@tid.es> References: <1971FF81B8E01C45991F6F92B9E3B250890888D8@EX10-MB2-MAD.hi.inet> <12047_1369747162_51A4AEDA_12047_544_1_976A65C5A08ADF49B9A8523F7F81925C0E4998@PEXCVZYM13.corporate.adroot.infra.ftgroup> <51A4CC43.5010707@tid.es> Message-ID: <31561_1369809947_51A5A41B_31561_7515_1_976A65C5A08ADF49B9A8523F7F81925C0E91C8@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi Fermin Thanks for this quick feedback. Association of entities is clearly a topic we will discuss this morning. I try to follow all your exchanges through NGSI mailing list but I'm not sure I have captured all details. Regarding the Technical Roadmap and what we have to achieve for July: ? What is the status on geolocation discovery? ? What about the dynamic registration of entities (at least two typical cases: a mobile sensor which arrive in a dedicated area and could be registered: a car which could provide pollution details for a city; and your smartphone which will be include as a sensor for a building when you are inside it) ? The last bullet is unclear to me: functions to model attributes describing abstract things... This part should be integrated In OMA NGSI 10 with association of entities but maybe you can clarify it. 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? : mardi 28 mai 2013 17:25 ? : fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] Conference call tomorrow at 10h Dear Thierry, Some feedback on integration tasks, both from my roles of ConfMan developer and Live Demo App architect: * From a point of view of ConfMan developer: * We (NEC and TID) were performing integration tests between IoT Broker and ConfMan and everything goes well. Next step was to involve other GEs in the integration scenario (I think that Salvatore take this AP, but I haven't had any new since our tests...). * Very recently (yesterday :) we have finalized the association extension implementation in ConfMan ("TID's way": if you follow emails in fiware-ngsi mailling list you know what I mean :) so we are ready to test also this part based on the scenarios that were defined by NEC (in this sense, "TID's way" is compatible with these scenarios). * From a point of view of Live Demo App architect: * A Backend Device Management GE instance connected to SmartSantander sensors is already integrated and working (through IoT Agent component) with Data chapter's Pub/Sub Context Broker. * We have considered to include IoT Broker and ConfMan in the Live Demo App (NEC people is aware of that) as they can add value to "plain" context information reported by Backend Device Management GE. However, this is being delayed due to two reasons: 1) we need IoTAgent to support queryContext operations and currently it doesn't although we are working on this (Carlos can provide a more precise update on this than me); 2) we have to define how application have to be modified (e.g. define "things", how they are represented in the mashup, etc.) and currently the UPM team working on that mashup has no more bandwith to deal with this. Probably we have to do that as evolution to Live Demo App after June 12-13th review. * Protocol Adapter was used in Live Demo R1 and we will plan to keep it for Live Demo App version June 12-13th. I hope this information could help... Best regards, ------ Ferm?n El 28/05/2013 15:19, thierry.nagellen at orange.com escribi?: Hi all We have to come back on integration task for NGSI and to discuss now the delivery for release 2.3. We will check if what we have described in the Technical Roadmap will be developed for End of July because we will have also the new doc to do for OIL for end of July. So it is critical to develop now! We can also discuss a hot topic for September and the campus party: what about scalability and how we can address a bit this issue (not to define huge test to assume that everything will be ok but some first check points and tests to achieve before end of July) BR Thierry 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 28 mai 2013 15:15 ? : fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] Conference call tomorrow at 10h Dear Colleagues, Just to confirm our meeting tomorrow. The googledoc we're using is hereby linked: https://docs.google.com/document/d/15rp8NKsCvu9Q4ISXwXl2iHc8cXz3DaNyBhVLq3qhgj8/edit Agenda is currently almost empty, but Thierry and myself will be completing it ASAP. Should you have suggestions, please do use the AoB section and we will re-arrange it before the call. 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. _______________________________________________ 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 thierry.nagellen at orange.com Wed May 29 09:25:34 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 29 May 2013 07:25:34 +0000 Subject: [Fiware-iot] TR: [Fiware-wpl] Fwd: Submission of extra issue of FI-WARE Technical roadmap (D.2.4.2b) Message-ID: <28542_1369812347_51A5AD73_28542_563_2_976A65C5A08ADF49B9A8523F7F81925C0EB210@PEXCVZYM13.corporate.adroot.infra.ftgroup> Dear all, Please find the official delivery of the Technical Roadmap. BR Thierry De : fiware-wpl-bounces at lists.fi-ware.eu [mailto:fiware-wpl-bounces at lists.fi-ware.eu] De la part de Miguel Carrillo Envoy? : mardi 28 mai 2013 19:20 ? : fiware-wpa at lists.fi-ware.eu; fiware-wpl at lists.fi-ware.eu Objet : [Fiware-wpl] Fwd: Submission of extra issue of FI-WARE Technical roadmap (D.2.4.2b) Dear all, As announced. I generated the source file shortly after 4pm. Best regards, Miguel -------- Mensaje original -------- Asunto: Submission of extra issue of FI-WARE Technical roadmap (D.2.4.2b) Fecha: Tue, 28 May 2013 19:17:37 +0200 De: Miguel Carrillo Para: Arian.ZWEGERS at ec.europa.eu , Dominic Greenwood , msli at icfocus.co.uk, renaud.difrancesco at eu.sony.com, irena.pavlova at isoft-technology.com, INFSO-ICT-285248 at ec.europa.eu CC: JUAN JOSE HIERRO SUREDA , "Vanessa.VANHUMBEECK at ec.europa.eu" , MANUEL ESCRICHE VICENTE Dear all, Following our agile methodology, our roadmap is in constant evolution. Although the changes on this occasion are not particularly extensive, we think that it is a good idea to provide you with an extra issue reflecting the current status of the roadmap. This is therefore not on the list of commited deliverables but we thought that you would appreciate it. This is publicly available here: * https://forge.fi-ware.eu/docman/view.php/7/2501/D2.4.2b+FI-WARE+Technical+Roadmap+%28extra+issue%29.pdf You can find the source pages constantly updated under http://wiki.fi-ware.eu/FI-WARE_Technical_Roadmap I also attach it with this message in pdf format. Best regards, Miguel -- ---------------------------------------------------------------------- _/ _/_/ Miguel Carrillo Pacheco _/ _/ _/ _/ Telef?nica Distrito Telef?nica _/ _/_/_/ _/ _/ Investigaci?n y Edifico Oeste 1, Planta 9 _/ _/ _/ _/ 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 _________________________________________________________________________________________________________________________ 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: D2.4.2b FI-WARE Technical Roadmap (extra issue).pdf Type: application/pdf Size: 1652223 bytes Desc: D2.4.2b FI-WARE Technical Roadmap (extra issue).pdf URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From thierry.nagellen at orange.com Wed May 29 09:51:05 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 29 May 2013 07:51:05 +0000 Subject: [Fiware-iot] TR: Submission of FI-WARE IoT deliverables D5.2.2, D5.3.2, D5.4.2 & D5.5.2 Message-ID: <31561_1369813873_51A5B36D_31561_9264_1_976A65C5A08ADF49B9A8523F7F81925C0EC268@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi all Here is the official submission of docs for WP5. BR Thierry De : Miguel Carrillo [mailto:mcp at tid.es] Envoy? : mardi 28 mai 2013 20:15 ? : Arian.ZWEGERS at ec.europa.eu; Ragnar.Bergstrom at ec.europa.eu; Dominic Greenwood; msli at icfocus.co.uk; DiFrancesco, Renaud; irena.pavlova at isoft-technology.com; INFSO-ICT-285248 at ec.europa.eu Cc : JUAN JOSE HIERRO SUREDA; MANUEL ESCRICHE VICENTE; Vanessa.VANHUMBEECK at ec.europa.eu; CARLOS RALLI UCENDO; NAGELLEN Thierry OLNC/OLPS Objet : Submission of FI-WARE IoT deliverables D5.2.2, D5.3.2, D5.4.2 & D5.5.2 Dear all, This is the official submission of the following deliverables from WP5 in the project FI-WARE for M24: * D.5.2.2 FI-WARE SW Release * D.5.3.2 FI-WARE Installation and Administration Guide * D.5.4.2 FI-WARE User and Programmers Guide * D.5.5.2 FI-WARE Unit Testing Plan and Report The documents are publicly or privately available (depending on the dissemination level ) on: * https://forge.fi-ware.eu/docman/view.php/7/2492/D522_SW_Release.pdf * https://forge.fi-ware.eu/docman/view.php/7/2493/D532_Installation_and_Administration_Guide.pdf * https://forge.fi-ware.eu/docman/view.php/7/2494/D542_Users_and_Programmers_Guide.pdf * https://forge.fi-ware.eu/docman/view.php/7/2496/D552_Unit_Testing_Plan_and_Report.pdf You have access to them all as well as all the PPP members (using your forge user for the private ones). The public source pages are always up to date on our wiki under Materializing Internet of Things (IoT) Services Enablement in FI-WARE I also attach them with this message in a zip file for your convenience. Best regards, Miguel -- ---------------------------------------------------------------------- _/ _/_/ Miguel Carrillo Pacheco _/ _/ _/ _/ Telef?nica Distrito Telef?nica _/ _/_/_/ _/ _/ Investigaci?n y Edifico Oeste 1, Planta 9 _/ _/ _/ _/ 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 _________________________________________________________________________________________________________________________ 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: WP5.zip Type: application/x-zip-compressed Size: 4580306 bytes Desc: WP5.zip URL: From thierry.nagellen at orange.com Wed May 29 09:52:10 2013 From: thierry.nagellen at orange.com (thierry.nagellen at orange.com) Date: Wed, 29 May 2013 07:52:10 +0000 Subject: [Fiware-iot] TR: Submission of FI-WARE Deliverable D.5.1.2 Open Specifications (WP5 - IoT Chapter) Message-ID: <28542_1369813932_51A5B3AC_28542_1306_2_976A65C5A08ADF49B9A8523F7F81925C0EC278@PEXCVZYM13.corporate.adroot.infra.ftgroup> Hi all, Here is the official submisison for IoT Open Specs BR Thierry De : Juanjo Hierro [mailto:jhierro at tid.es] Envoy? : mardi 28 mai 2013 19:32 ? : Arian.ZWEGERS at ec.europa.eu; Ragnar.Bergstrom at ec.europa.eu; dgr at whitestein.com; msli at icfocus.co.uk; renaud.difrancesco at eu.sony.com; irena.pavlova at isoft-technology.com Cc : INFSO-ICT-285248 at ec.europa.eu; Vanessa.VANHUMBEECK at ec.europa.eu; mcp at tid.es; NAGELLEN Thierry OLNC/OLPS; CARLOS RALLI UCENDO; jhierro >> "Juan J. Hierro" Objet : Submission of FI-WARE Deliverable D.5.1.2 Open Specifications (WP5 - IoT Chapter) Dear all, This is the official submission of D.5.1.2 Open Specifications (WP5 - IoT Chapter). You can download the corresponding file from the following link: * https://forge.fi-ware.eu/docman/view.php/7/2505/D.5.1.2+FI-WARE+GE+Open+Specifications+-+IoT+vfinal.docx Note that the FI-WARE GE Open Specifications are public, therefore you can download the first of the files without logging in FusionForge. As you know, the FI-WARE GE Open Specifications are constantly updated on the FI-WARE public wiki. You can refer to contents of the public wiki for the most up-to-date contents of public documentation associated to the FI-WARE project. Don't hesitate to contact us if you have any question. Best regards, -- Juanjo Hierro ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect You can follow FI-WARE at: 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 _________________________________________________________________________________________________________________________ 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 Wed May 29 13:45:27 2013 From: sabrina.guerra at telecomitalia.it (Guerra Sabrina) Date: Wed, 29 May 2013 13:45:27 +0200 Subject: [Fiware-iot] [FI-WARE IoT] google doc updated and NGSI considerations Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5AEDD0AFB@GRFMBX702BA020.griffon.local> Hi Thierry and Carlos, As we agreed in the conf call I updated the minutes at the following link. https://docs.google.com/document/d/15rp8NKsCvu9Q4ISXwXl2iHc8cXz3DaNyBhVLq3qhgj8/edit In this google doc you can see these topics: * the feedbacks from the UC projects related to the webinars * a comment about the status of the implementation of the NGSI interface in the Protocol Adapter. By the way there is another point that is not clear about the NGSI interface: the interface between the Data Handling GE and the Protocol Adapter GE doesn't define an actuation command. Currently this operation is only available using the TI servlet that is based on the GDA API (by Ericsson). I don't know if the actuation is comprised in the NSGI specification. Best regards, Sabrina ------------------------------------------------------------------ Telecom Italia Sabrina Guerra Innovation & Industry Relations Research & Prototyping Future Internet Technologies & Research 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: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: From fermin at tid.es Wed May 29 14:10:30 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Wed, 29 May 2013 14:10:30 +0200 Subject: [Fiware-iot] [FI-WARE IoT] google doc updated and NGSI considerations In-Reply-To: <36A93B31228D3B49B691AD31652BCAE9A5AEDD0AFB@GRFMBX702BA020.griffon.local> References: <36A93B31228D3B49B691AD31652BCAE9A5AEDD0AFB@GRFMBX702BA020.griffon.local> Message-ID: <51A5F036.60505@tid.es> Dear Sabrina, "I don't know if the actuation is comprised in the NSGI specification." Probably this question fits better in NGSI mailing list, but I do confirm that NGSI have "build-in" actuation mechanisms. However, there is a easy workaround: consider updates with side-effects. E.g. you can define an attribute e.g. "executeCommand" on a given entity, so when you do an updateContext on that "executeCommand" then a command is executed (the value used on the update for that attribute is the command to execute). If you need to capture a result for the command, you can have another attribute (eg. "executeCommandOutput") so when the command is finished, you will get the output in the attribute. I'm not sure but old good SNMP has a similar approach to execute commands in managed devices. My two cents... Best regards, ------ Ferm?n El 29/05/2013 13:45, Guerra Sabrina escribi?: Hi Thierry and Carlos, As we agreed in the conf call I updated the minutes at the following link. https://docs.google.com/document/d/15rp8NKsCvu9Q4ISXwXl2iHc8cXz3DaNyBhVLq3qhgj8/edit In this google doc you can see these topics: ? the feedbacks from the UC projects related to the webinars ? a comment about the status of the implementation of the NGSI interface in the Protocol Adapter. By the way there is another point that is not clear about the NGSI interface: the interface between the Data Handling GE and the Protocol Adapter GE doesn't define an actuation command. Currently this operation is only available using the TI servlet that is based on the GDA API (by Ericsson). I don't know if the actuation is comprised in the NSGI specification. Best regards, Sabrina ------------------------------------------------------------------ Telecom Italia Sabrina Guerra Innovation & Industry Relations Research & Prototyping Future Internet Technologies & Research 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. _______________________________________________ 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 sabrina.guerra at telecomitalia.it Wed May 29 14:30:35 2013 From: sabrina.guerra at telecomitalia.it (Guerra Sabrina) Date: Wed, 29 May 2013 14:30:35 +0200 Subject: [Fiware-iot] [FI-WARE IoT] NGSI considerations Message-ID: <36A93B31228D3B49B691AD31652BCAE9A5AEDD0B48@GRFMBX702BA020.griffon.local> Hi Fermin, Thanks for your prompt answer. The next step could be to evaluate your NGSI considerations in the interaction between the Data Handling and the Protocol Adapter GEs. Best regards, Sabrina Da: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Ferm?n Gal?n M?rquez Inviato: mercoled? 29 maggio 2013 14:11 A: fiware-iot at lists.fi-ware.eu Oggetto: Re: [Fiware-iot] [FI-WARE IoT] google doc updated and NGSI considerations Dear Sabrina, "I don't know if the actuation is comprised in the NSGI specification." Probably this question fits better in NGSI mailing list, but I do confirm that NGSI have "build-in" actuation mechanisms. However, there is a easy workaround: consider updates with side-effects. E.g. you can define an attribute e.g. "executeCommand" on a given entity, so when you do an updateContext on that "executeCommand" then a command is executed (the value used on the update for that attribute is the command to execute). If you need to capture a result for the command, you can have another attribute (eg. "executeCommandOutput") so when the command is finished, you will get the output in the attribute. I'm not sure but old good SNMP has a similar approach to execute commands in managed devices. My two cents... Best regards, ------ Ferm?n El 29/05/2013 13:45, Guerra Sabrina escribi?: Hi Thierry and Carlos, As we agreed in the conf call I updated the minutes at the following link. https://docs.google.com/document/d/15rp8NKsCvu9Q4ISXwXl2iHc8cXz3DaNyBhVLq3qhgj8/edit In this google doc you can see these topics: * the feedbacks from the UC projects related to the webinars * a comment about the status of the implementation of the NGSI interface in the Protocol Adapter. By the way there is another point that is not clear about the NGSI interface: the interface between the Data Handling GE and the Protocol Adapter GE doesn't define an actuation command. Currently this operation is only available using the TI servlet that is based on the GDA API (by Ericsson). I don't know if the actuation is comprised in the NSGI specification. Best regards, Sabrina ------------------------------------------------------------------ Telecom Italia Sabrina Guerra Innovation & Industry Relations Research & Prototyping Future Internet Technologies & Research 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. _______________________________________________ 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: