Ok, Make sense that the event produced by the sensor can\may have the sensor as an entity included some how in the data transport structure. However - this could be just as a simple attribute or element in that transport. Expecting the sensor\thing or application to put this information in some predefined format (NGSI?) to explicitly point out the entity reference or inline info so that every processing mechanism can identify the entity immediately without resolution is a bit of a harsh assumption. In CEP we let the rule designer the one who understands the business or the infrastructure to point out from the data in the event what is the entity by which he wants to associate\correlate a particular event with another event for example. We don't expect the source to do this work for us only report all that we may need in the simplest way possible. Regards, Guy Sharon Manager Event-based Middleware & Solutions Phone: 972-4-8296587 | Mobile: 972-54-6976417 E-mail: GUYSH at il.ibm.com Website: www.research.ibm.com/haifa/dept/services/soms_ebs.html Find me on: and within IBM on: Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris <boris.moltchanov at telecomitalia.it> To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto <carlo.licciardi at telecomitalia.it>, "fano.ramparany at orange.com" <fano.ramparany at orange.com>, "Fiware-data at lists.fi-ware.eu" <Fiware-data at lists.fi-ware.eu>, "jhierro at tid.es" <jhierro at tid.es> Date: 13/01/2012 11:14 Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Hi Guy, sorry for delay. Any producer of anything know *at least* itself, if not explicitly by its name (I am a sensor B) but at least by the connection (that connection providing to me the data is a sensor B), otherwise ?nude? data do not have any sense (only arithmetic meaning that 2+2=4, but we don?t need a calculator in FI, right?), so the sensor producing the data, as well as event generator knows its own identity. This is a glue. And this is the entity. Then it is an issue for the entity resolution how to convey the temperature of the sensor attached to a sensor node to a room?s temperature or an event happened in a device to the owner of this device. This is how the current P/S GE with entity resolution is working. Best Regards, Boris From: Guy Sharon [mailto:GUYSH at il.ibm.com] Sent: Monday, January 09, 2012 8:48 PM To: Moltchanov Boris Cc: Licciardi Carlo Alberto; fano.ramparany at orange.com; Fiware-data at lists.fi-ware.eu; jhierro at tid.es Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Sorry Boris - I might be a bit slow here as I am not 100% sure I follow. How for example would the exchange format look like between a producer of data \ event to a CEP GE or P\S GE as you suggest? And would a producer of event or data need to make this conversion as you expect this as input? What if the producer doesnt know how to do this or are we constraining producers to adopt a specific way to notify on events or data or context. Who does the resolution about event to entity? I think that if something knows to do this resolution lets say before the event gets into CEP GE (either by the producer itself or something else) then I am sure we would be able to support such a structure that P\S GE needs to interpret as a context. What I mean is that Entity <-> event relationship could be more explicitly supported in the exchange format and we would still be able to process events. What was missing before this discussion was events altogether - they were kind of inferred through value updates - and that we wouldn't be able to deal with and its too narrow. Regards, Guy Sharon Manager Event-based Middleware & Solutions Phone: 972-4-8296587 | Mobile: 972-54-6976417 E-mail: GUYSH at il.ibm.com Website: www.research.ibm.com/haifa/dept/services/soms_ebs.html Find me on: and within IBM on: Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris <boris.moltchanov at telecomitalia.it> To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto <carlo.licciardi at telecomitalia.it>, " fano.ramparany at orange.com" <fano.ramparany at orange.com>, " Fiware-data at lists.fi-ware.eu" <Fiware-data at lists.fi-ware.eu>, " jhierro at tid.es" <jhierro at tid.es> Date: 09/01/2012 21:31 Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition The main advantage of event to context conversion is: once an event is provided with an entity it converts to the context data structure for sake of simplicity and autonomously of P/S GE to treat as an event or as a context element in the last case (provided with the entity). Otherwise P/S GE will be not aware that the event with entity attached is a context elements and we would lose its value. However maybe a dedicated component will be needed for such a conversion between an event + entity as your component outputs and the context as an input to the P/S GE. It could be integrated into CEP GE, into P/S GE or be a dedicated (3rd) component. BR, Boris From: Guy Sharon [mailto:GUYSH at il.ibm.com] Sent: Monday, January 09, 2012 8:14 PM To: Moltchanov Boris Cc: Licciardi Carlo Alberto; fano.ramparany at orange.com; Fiware-data at lists.fi-ware.eu; jhierro at tid.es Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Boris, I consider the discussion so far as one that established a base-line of understanding of each other's interpretation. And based on Fano's last email and yours I now think we understand each other "Vision Document would give the format of data that should be exchanged between Applications and GEs and among GEs, no more more, no less." This doesn't necessarily mean that this is what it should be. If you don't mind - I would like you now to explain from this basis what is different \ advantages of what you are proposing \ adopting. Regards, Guy Sharon Manager Event-based Middleware & Solutions Phone: 972-4-8296587 | Mobile: 972-54-6976417 E-mail: GUYSH at il.ibm.com Website: www.research.ibm.com/haifa/dept/services/soms_ebs.html Find me on: and within IBM on: Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris <boris.moltchanov at telecomitalia.it> To: "fano.ramparany at orange.com" <fano.ramparany at orange.com>, Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto <carlo.licciardi at telecomitalia.it>, " Fiware-data at lists.fi-ware.eu" <Fiware-data at lists.fi-ware.eu>, " jhierro at tid.es" <jhierro at tid.es> Date: 09/01/2012 20:45 Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition I believe after the discussion with Guy we have decided that no relation will be done within FI-WARE between two data structures, thus the events are just events and the context data are context as well as the entity for the context is not a data element attribute but the entity. And if this is true, also eventual entity resolvers attached to the P/S GE will be affected further decoupling the events from the context. It is a pity where we lose a great value in the Pub/Sub GE. BR, Boris From: fano.ramparany at orange.com [mailto:fano.ramparany at orange.com] Sent: Monday, January 09, 2012 6:05 PM To: Moltchanov Boris; GUYSH at il.ibm.com Cc: Licciardi Carlo Alberto; Fiware-data at lists.fi-ware.eu; jhierro at tid.es Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Dear all, I just realized that there?s another way to interpret the data/context/event modeling presented in the Vision document [Overview section of the Chapter ?Data/Context management?]. In this interpretation an event is a specific type of data, and then can be characterized in term of data properties , each properties being itself characterized in terms of metadata. This interpretation is pretty close to the first view introduced by Guy which he calls ?through the eyes of the entities? in the 2nd group of drawings contained in his mail dated Friday, January 06, 2012 1:37 AM. So if we take Guy last drawing (with the TV set location example), this interpretation would produce the following diagram: It would then be left to the various GEs to further interpret this according their own ontology. The first group of drawings in Guy?s mail would be one possible interpretation. The EntityID needed by Boris to interpret it as a context event should then be searched in the DataElementAttributed (actually the TVSetID with the value MyTVSet) instead of using the EntityID slot in the DataElement box as defined in the Vision document. Thus, the data/context/event model introduced in the Vision Document would give the format of data that should be exchanged between Applications and GEs and among GEs, no more more, no less. Would this be an agreeable common basis? Fano De : Moltchanov Boris [mailto:boris.moltchanov at telecomitalia.it] Envoyé : vendredi 6 janvier 2012 19:03 À : Guy Sharon Cc : Licciardi Carlo Alberto; RAMPARANY Fano RD-TECH-GRE; Fiware-data at lists.fi-ware.eu; jhierro at tid.es Objet : RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Hi Guy, have a successful 2012. What I was saying, sorry for too long email: - The events don?t need to be context (no entity attached), and so a reasoning could be performed. - Once we have an entity attached to an event it could become a context, not necessarily, we may still treat it as an event with an entity in attributes attached, but I suggest we convert it into context data type, I mean convert it to the context type. From the event processing it doesn?t change anything. You may still treat it as an event. But for the P/S GE it does make sense to convert it into context; - Nevertheless, the events could be created from the context, when the last is changing! Not necessarily thought, because if we have an event with not entity attached, it is still an event, and any type of reasoning is possible, creating another event probably. This is fine. - And any event, once attached for example as you shown with attributes to en entity become a context, therefore should be converted into context data for enabling it processing as a P/S data structure. Of course we can allow to P/S GE treat events and context data independently, this is not a problem at technology level. BUT we are losing a serious advantage of our FI GE P/S component ? which is the ability to autonomously retrieve the context data from the events and contrary ? create the events from the context data. If we handle these data structures independently we have to apply an artificial intelligence for this conversion, while I was thinking why do not do it in a natural way when the event data once attached to an entity become the context data therefore could be used as such by other components and applications. It worth a good and reasonable decision, I?m just giving a hint from a FI perspective for customers and 3rd parties, which will enable a more high-level services instead of being just another set of vertical solution available together that probably will be more difficult to use due to its diverse native nature. Thanks for your answer anyway! Best Regards, Boris From: Guy Sharon [mailto:GUYSH at il.ibm.com] Sent: Friday, January 06, 2012 6:42 PM To: Moltchanov Boris Cc: Licciardi Carlo Alberto; fano.ramparany at orange.com; Fiware-data at lists.fi-ware.eu; jhierro at tid.es Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Hi Boris - good to see you in 2012. I don't think we have a serious conflict. If I understand your points below correctly I can agree with almost everything. Putting it in my own words. All information \ updates on entities is coming from events that we know to model and monitor - unrealistic! There is information \ context that is just given \ exists without events being involved. However, the opposite is true as well - the reasoning on events requires no entity what so ever - because the entity itself may be superficial or that the entity is of no interest and doesn't need to be modeled. For example - react to 3 check deposits during the last hour - don't care about the person, or the bank account or the check itself. Just that these events occurred 3 times. What I am actually saying is that it will be very very wrong and we will just create big troubles in the future (as you say) if we collapse entity\context into events and vise versa collapse events into context and generate events from context (your suggestion). We need to allow 2 different views and that is what I drew in my email before. Regards, Guy Sharon Manager Event-based Middleware & Solutions Phone: 972-4-8296587 | Mobile: 972-54-6976417 E-mail: GUYSH at il.ibm.com Website: www.research.ibm.com/haifa/dept/services/soms_ebs.html Find me on: and within IBM on: Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris <boris.moltchanov at telecomitalia.it> To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" < fano.ramparany at orange.com> Cc: Licciardi Carlo Alberto <carlo.licciardi at telecomitalia.it>, " Fiware-data at lists.fi-ware.eu" <Fiware-data at lists.fi-ware.eu>, " jhierro at tid.es" <jhierro at tid.es> Date: 06/01/2012 17:05 Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition I agree with one point, that an event could be impersonated, such as for example ?it?s getting dark?, even if I don?t understand the sense of such a structure unless a context (environment of the event) is defined (therefore the event is belonging to this environment by default). That event becomes a context once we connect (attach) to some entity (environment, personal, object, etc.), e.g. ?Boris is observing that Turin is getting dark?, thus it becomes the context of Turin and transitionally of Boris located (by location) in Turin. Until here we don?t have conflict. But then for the rest, we have a serious conflict in basic foundation of data structures. An entity is an attribute of an event from event-centric world, while an event as a context is an attribute of an entity-centric context-aware world. I am not a guru, what I may just say that the event may never happen (never getting dark), while the context will still exist (Turin is in light) and such that I would prefer to convert (eventual) events to the context and not vice-versa starting the context from events that may never exist as from example before), otherwise we risk to lose important data (context). However I don?t exclude that events might be generated by the context, when that context is changing, thus we have Turin?s context, which is changing from light to dark and this generates the event ?getting dark?, which we may detach from Turin (impersonate) and say that the default environment is Turin, then there is no need to explicitly say ?Turin is getting dark?, which is also a context (status of Turin). Of course it depends on definition of the event and we may say that the measurement of the light leading to the context of Turin (Turin is in light) is also an event, but then we may say that Turin is in light (therefore don?t need a measurement as event) is a fact without any measurement (no events). Thus, materialism or idealism, chicken/egg problem J. Please pay attention to this, otherwise we risk to create troubles for ourselves in future. I suggest we take a decision, and make an assertion in certain sense, saying that an event may become a context when assigned to an entity and not that event has an attribute, which is an entity assigned to this event. Then we would have an event (no entities ? no attributes), once this even obtains an entity it become a context. I see only this solution to solve this. Then everything become clear, changing in the context may generate an event, and if we cancel the entity from the event it transforms back to the event. I don?t know however how to realize and achieve it on the practical level, I believe products will be impacted. But we have to do this, otherwise we will have probably some difficulties in the P/S GE as well, that will be confused what is the data structure and where are the attributes. Boris From: Guy Sharon [mailto:GUYSH at il.ibm.com] Sent: Friday, January 06, 2012 1:37 AM To: fano.ramparany at orange.com Cc: Moltchanov Boris; Licciardi Carlo Alberto; Fiware-data at lists.fi-ware.eu; jhierro at tid.es Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Good idea to start drawing things. But this is far from what I was trying to convey. In fact, I now understand that we need to touch \ sync on a fundamental point about events. Events must be treated as first class citizens in models and transports - not incorporated into entities\things and collapsed into properties rather they should exist alongside entities and may be associated with entities. I will try to give an example through three cases - 1) the simple one with the boiler, 2) an event to many entities with a check deposit, and 3) many events to one entity with the TVSet. If needed a drawing board and a discussion could be a good idea to resolve this in Madrid. First a simplified ontology view of the three cases 1) 2) 3) Now lets look at how an event then should be represented as in the Vision of the chapter and how they would be stored or communicated versus entities. 1) These may actually be 2 different views on all the data that gets collected (repository) First view through the eye of an entity - you would see all the temperature values over time Second view through the eye of an event - you would see all the TemperatureMeasured events over time and what temperature reading they provided to what Boiler 2) Here - it is IMPORTANT to keep all the 'properties' of the event together (even though they are associated to different entities) for proper event processing - this is for some event processing implementation a real big issue when they decouple especially when you need to reason over the events and not over the entities it may have been associated with. These may actually be 2 different views on all the data that gets collected (repository) First view through the eye of the entities - each entity will show all its properties by property over time Second view through the eye of an event - you would see all the events over time with all the relevant 'properties' that are associated to different entities - together. 3) Here - it is IMPORTANT to distinguish between different events with 'properties' that are associated to the same entity property. These may actually be 2 different views on all the data that gets collected (repository) First view through the eye of an entity - you would see all the location values over time regardless of the type of event Second view through the eye of an event - you would see all the events over time and what location the TVSet is according to the event types. Regards, Guy Sharon Manager Event-based Middleware & Solutions Phone: 972-4-8296587 | Mobile: 972-54-6976417 E-mail: GUYSH at il.ibm.com Website: www.research.ibm.com/haifa/dept/services/soms_ebs.html Find me on: and within IBM on: Haifa University, Mount Carmel Haifa, HA 31905 Israel From: <fano.ramparany at orange.com> To: Guy Sharon/Haifa/IBM at IBMIL Cc: <boris.moltchanov at telecomitalia.it>, < carlo.licciardi at telecomitalia.it>, <Fiware-data at lists.fi-ware.eu>, < jhierro at tid.es> Date: 05/01/2012 12:13 Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Hi Guy, Thank you for your comments. Most of my feedback are covered in the joint IoT/Data discussion. I?d just like to bounce on your attempt to describe the boiler example using the data/context/event schema. When you say ?you treat temperature and pressure as attribute?. Is fine with me ? but is irrelevant to the above representation?, do you mean that you would handle this differently? In which case could you elaborate? Here is my proposal: Which in the graphical notation corresponds to: My point is that it seems more natural to consider the 3 ?DataElementAttribute? boxes in the middle as events, than to call the entire graph an event. In my proposal the links are bidirectional, which makes It possible to retrieve the DataElement from the DataElementAttribute. Any comment or alternative viewpoint welcome, Kind regards, Fano De : Guy Sharon [mailto:GUYSH at il.ibm.com] Envoyé : mardi 3 janvier 2012 20:51 À : RAMPARANY Fano RD-TECH-GRE Cc : boris.moltchanov at telecomitalia.it; carlo.licciardi at telecomitalia.it; Fiware-data at lists.fi-ware.eu; fiware-data-bounces at lists.fi-ware.eu; jhierro at tid.es Objet : Re: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Fano, I think the discussion you raise brings up the aspect of the semantic meaning of an event and the representation of an event. In the definition of an event in our chapter we discuss the representation of an event and not the semantic meaning of an event. An event may represent change of and attribute value of some entity. It can also mean a change in state \ transition. But how do you communicate the event of an attribute change for example... You would provide an event which is a specific Data Element that consists of Data Element attributes that may include info on the entity for an attribute is being changed, the attribute that is being change, the old value of the attribute, the new value of the attribute, the time during which the change occurred, etc. Therefore the event representation - how the event is communicated between GEs for example is a specific Data Element. In your example there are 2 types of events - TemperatureMeasured and PressureMeasured TemperatureMeasured consists of tempValue, timeStamp and boilerID attributes - for example I think you refer more to the semantical or ontology level of the event which in my opinion is not covered by the whole Data Element discussion. >From that point based on the example - we have an event associated with temperature of a boiler and another associated with the pressure of the boiler - here you treat temperature and pressure as attributes of the boiler and events associated to these attributes - which is fine with me - but is irrelevant to the above representation. In other words - event element attributes tempValue, boilerID of the event element TemperatureMeasured are semantically mapped to the Boiler. An event could carry information relevant to more than one entity you wish to model which in that case the event does not represent a change in attribute but perhaps something more abstract - a situation! The output of event processing is also an event - a complex event - that may not be associable to an attribute or rather is associated to multiple attributes of multiple entities. Regards, Guy Sharon Manager Event-based Middleware & Solutions Group Event-based Middleware & Solutions phone : +972 4 8296587 mobile : +972 54 6976417 address : IBM R&D Labs in Israel, Haifa University Campus, Mount Carmel, Haifa, 31905, Israel email : guysh at il.ibm.com From: fano.ramparany at orange.com To: boris.moltchanov at telecomitalia.it, carlo.licciardi at telecomitalia.it, jhierro at tid.es Cc: Fiware-data at lists.fi-ware.eu Date: 03/01/2012 20:45 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Event definition - a proposed revision of the Event definition Sent by: fiware-data-bounces at lists.fi-ware.eu Hi, I wish you the best for 2012 and in particular much success to our FIWARE project and to the FI PPP program in general! FT is involved in adding a semantic extension to the Publish/Subscribe GE. One step required is to define a ?semantic aware? data schema (*) able to capture the Data-Context-Event model that has been defined in the Vision Document. While revisiting this chapter (the overview chapter: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Data/Context_Management#Overview ), I felt uncomfortable with the definition of an event, which according to the current version is ?specific Data Element? with a timestamp to represent its date/time occurence. However, events are generally related to the creation of ?element attributes? or changes in the values of ?element attributes? (for example, if the temperature of the boiler has been measured 2 times and its pressure 1 times. There will be 3 events, each of them will correspond to a Context Element attribute. More precisely, 2 context attributes for the two temperature measurements and 1 context attribute for the pressure measurements. The timestamps of those 3 measurements would probably be all different because the measurements would be done at different times. The ?element attribute? corresponding to the 2nd temperature measurement will supercede the one corresponding to the 1rst temperature measurement. (Note: with the approach proposed in the working document I refer to below (**), the timestamp is a meta-data associated to the ?element attribute?). For this reason I?d like to propose a slight revision of the event definition and state that ?an event is a specific Data Element attribute? (with a mandatory timestamp meta data to capture its date/time occurrence). This definition would replace this one: ?an event is a specific Data Element?. Any comment/feedback on this and on the working document which proposes a flexible ontology which aligns with our data model, is more than welcome, Best regards, Fano (* called an Ontology in the semantic web framework) (** This document proposes an Ontology for Defining Ontologies for the Pu ReleaseV0. In case the link doesn?t work, the document is in FI-WARE->files->OntologyV0.pdf on the FI-WARE fusion forge web site) _______________________________________________ Fiware-data mailing list Fiware-data at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-data 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. Non stampare questa mail se non è necessario. 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. Non stampare questa mail se non è necessario. 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. Non stampare questa mail se non è necessario. 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. Non stampare questa mail se non è necessario. 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. Non stampare questa mail se non è necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0001.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0002.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0003.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0004.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0005.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0001.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0006.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0007.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0008.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0002.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 12073 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0009.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0010.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0011.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0012.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0003.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3092 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0004.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5210 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0005.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3243 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0006.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 9749 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0007.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 25563 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0008.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 18440 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0009.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0013.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 488 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0014.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0015.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0016.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0010.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9509 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11456 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0017.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2558 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0011.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0012.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0013.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0014.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0015.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120113/5cc8293f/attachment-0016.gif>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy