From TALI at il.ibm.com Mon Jan 2 16:31:01 2012 From: TALI at il.ibm.com (Tali Yatzkar-Haham) Date: Mon, 2 Jan 2012 17:31:01 +0200 Subject: [Fiware-data] Need to open tickets for not yet existing GEs Message-ID: Hello Carlos, Looking at the following UC tickets we think tickets need to be open for not yet existing GEs [#310] heterogenous events - Processing of heterogeneous event provided by sources of different nature. Event generation, gathering, identification, processing and management In my opinion, the event generation, gathering, identification, processing need to be assigned to a "Massive data gathering" GE. In case pattern detection above those events are required, we can, in addition, connect this ticket to an existing CEP feature ([#76] FIWARE.Epic.Data.CEP.InboundConnectivity) [#1121] - Distributed Database - To provide storage systems for large amount of information, distributed database system (local, regional, etc.) are required In my opinion, this ticket is not relevant to CEP. It might be relevant to a storage GE Thanks, Tali Yatzkar-Haham Event-based Middleware & Solutions Group IBM Haifa Research Lab Phone: 972-4-829-6320 | Mobile: 972-54-4388482 E-mail: TALI at il.ibm.com Haifa University, Mount Carmel Haifa, 31905 Israel -------------- next part -------------- An HTML attachment was scrubbed... URL: From TALI at il.ibm.com Mon Jan 2 16:31:59 2012 From: TALI at il.ibm.com (Tali Yatzkar-Haham) Date: Mon, 2 Jan 2012 17:31:59 +0200 Subject: [Fiware-data] UC tickets - Internal discussion Message-ID: Hi All, The following ticket is assigned to CEP and is relevant to other GEs as well. I would like to open an internal discussion. [#1120] - Realtime exchange - Reading this the focus is on exchange and not processing in real time. This seems more of a requirement for the Pub\Sub and Massive Data gathering. If patterns above those events need to be identified it may involved CEP and Big Data as well Two tickets that are assigned to location platform are also need to be discussed (since they were forward by e-mail to CEP): [#321] SMARTAGRIFOOD.Epic.data.MobilityAnalysis.ProcessOfUserLocation We suggest internal discussion between the location, pub/sub and CEP GEs. Since it involves getting the location and the context, and maybe detect pattern over them [#393] SAFECITY.Theme.Data/Context.Localisation Platform GE.Event This is physical information that needs to be identified (e.g., to which gateway the device is connected and in which location). The event processing can't identify those events. If patterns need to be defined on top of those events then event processing has a role. Regards, Tali Yatzkar-Haham Event-based Middleware & Solutions Group IBM Haifa Research Lab Phone: 972-4-829-6320 | Mobile: 972-54-4388482 E-mail: TALI at il.ibm.com Haifa University, Mount Carmel Haifa, 31905 Israel -------------- next part -------------- An HTML attachment was scrubbed... URL: From fano.ramparany at orange.com Tue Jan 3 19:45:05 2012 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Tue, 3 Jan 2012 19:45:05 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Event definition - a proposed revision of the Event definition Message-ID: 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/Co ntext_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) -------------- next part -------------- An HTML attachment was scrubbed... URL: From GUYSH at il.ibm.com Tue Jan 3 20:50:30 2012 From: GUYSH at il.ibm.com (Guy Sharon) Date: Tue, 3 Jan 2012 21:50:30 +0200 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Event definition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2558 bytes Desc: not available URL: From fano.ramparany at orange.com Wed Jan 4 12:02:20 2012 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Wed, 4 Jan 2012 12:02:20 +0100 Subject: [Fiware-data] [Fiware-iot] T5.2 slides In-Reply-To: <4F0415DE.8060205@tid.es> References: <4F0415DE.8060205@tid.es> Message-ID: Thank you for this overall view of the IoT chapter Ricardo. I've got few questions about the data model. - How does the Metadata/Things/IoTResource/Event maps or relates to the Data/Context/Event schema introduced in the Vision document (Chapter "introduction")? - In the Vision document, Metadata seems to be properties about properties. Along this interpretation, timestamp might be one of this metadata, whereas in your model all properties have timestamp. - Could you give examples of "associations" among Things and between Things and IoT? - In your model, how would you represent that a TVset is placed on the table? Would this information be stored in the configuration repository? - How would you represent the events capturing a move of the TVset or the fact that the TVset has been relocated at another place? Would they be stored in the event repository? Thank you in advance for your help, Fano PS: I've put the Fiware-data mailing list in the loop as obviously both chapters should synchronize on this issue De : fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de Ricardo de las Heras Envoy? : mercredi 4 janvier 2012 10:03 ? : fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] T5.2 slides Hi all, As you know, we have to deliver an Architecture Specification by end of January and deadline is approaching. This Architecture Specification should explain how the different GEs interact together and with the applications, going a step beyond from the very high-level figures we have designed so far. Elaborating on the interfaces the conceptual models to be supported. After some internal discussions at TID, we have come up with a draft Architecture for the Things Management Layer which is explained in the slides attached to this mail. We would like to rely on these slides to launch the discussion among partners in this task as well as the WPL and WPA, also involving some of the relevant partners from the Data/Context Management Chapter which may bring some pieces of the overall picture. I may elaborate on them during the phone call now if needed. Br, -- ------------------------------------------- Ricardo de las Heras M2M Research Technological Specialist E-mail: rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telef?nica Digital ------------------------------------------- ________________________________ 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 fano.ramparany at orange.com Wed Jan 4 15:38:20 2012 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Wed, 4 Jan 2012 15:38:20 +0100 Subject: [Fiware-data] TR: [Fiware-iot] NGSI mailing list Message-ID: FYI, De : fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de Farkas, Lorant (NSN - HU/Budapest) Envoy? : mercredi 4 janvier 2012 15:31 ? : fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] NGSI mailing list Dear All, I modify my request: please be aware of the mailing list http://lists.fi-ware.eu/listinfo/fiware-ngsi and subscribe in case you are interested/concerned by it or unsubscribe if you think you should not be on it. Thanks & Br, Lorant _____________________________________________ From: Farkas, Lorant (NSN - HU/Budapest) Sent: Wednesday, January 04, 2012 3:15 PM To: 'fiware-iot at lists.fi-ware.eu' Subject: NGSI mailing list Dear All, Can you send me by EOB tomorrow names who are interested in the IoT group to be on the NGSI interest list, fiware-ngsi at lists.fiware.eu beyond the colleagues mentioned in the e-mail from Juanjo? << Message: [Fiware-ngsi] Launching mailing list dedicated to discussion on NGSI interfaces in FI-WARE >> Thierry: maybe also Laurent or Laurence? Martin, Ern?: maybe also Tobias, Salvatore? Stephan: you mentioned 3 colleagues would be interested, who are they? Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT1329842.txt URL: From jhierro at tid.es Wed Jan 4 16:04:19 2012 From: jhierro at tid.es (Juanjo Hierro) Date: Wed, 04 Jan 2012 16:04:19 +0100 Subject: [Fiware-data] TR: [Fiware-iot] NGSI mailing list In-Reply-To: References: Message-ID: <4F046A73.4080908@tid.es> Hi, I created the fiware-ngsi and included Boris, Fano and Carlos in it. If there is anyone else who wish to be included in the list, please let me know. Cheers, -- Juanjo On 04/01/12 15:38, fano.ramparany at orange.com wrote: FYI, De : fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de Farkas, Lorant (NSN - HU/Budapest) Envoy? : mercredi 4 janvier 2012 15:31 ? : fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-iot] NGSI mailing list Dear All, I modify my request: please be aware of the mailing list http://lists.fi-ware.eu/listinfo/fiware-ngsi and subscribe in case you are interested/concerned by it or unsubscribe if you think you should not be on it. Thanks & Br, Lorant _____________________________________________ From: Farkas, Lorant (NSN - HU/Budapest) Sent: Wednesday, January 04, 2012 3:15 PM To: 'fiware-iot at lists.fi-ware.eu' Subject: NGSI mailing list Dear All, Can you send me by EOB tomorrow names who are interested in the IoT group to be on the NGSI interest list, fiware-ngsi at lists.fiware.eu beyond the colleagues mentioned in the e-mail from Juanjo? << Message: [Fiware-ngsi] Launching mailing list dedicated to discussion on NGSI interfaces in FI-WARE >> Thierry: maybe also Laurent or Laurence? Martin, Ern?: maybe also Tobias, Salvatore? Stephan: you mentioned 3 colleagues would be interested, who are they? Thanks & Br, Lorant ________________________________ 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 jhierro at tid.es Wed Jan 4 16:05:43 2012 From: jhierro at tid.es (Juanjo Hierro) Date: Wed, 04 Jan 2012 16:05:43 +0100 Subject: [Fiware-data] Fwd: [Fiware-ngsi] Launching mailing list dedicated to discussion on NGSI interfaces in FI-WARE In-Reply-To: <4F0446AB.1080306@tid.es> References: <4F0446AB.1080306@tid.es> Message-ID: <4F046AC7.7050108@tid.es> This and the following email will give you some context for the discussion that will take place on the fiware-ngsi mailing list -------- Original Message -------- Subject: [Fiware-ngsi] Launching mailing list dedicated to discussion on NGSI interfaces in FI-WARE Date: Wed, 4 Jan 2012 13:31:39 +0100 From: Juanjo Hierro To: fiware-ngsi at lists.fi-ware.eu Hi all, As mentioned during the follow-up IoT confcall, we have setup a mailing list that will be focused on discussion about NGSI-based interfaces in FI-WARE. While we all agree that the final interfaces supported in FI-WARE may differ from the current OMA NGSI specs for good reasons, we all agree that FI-WARE should support only one variant of the specs, avoiding several, uncompatible, variants. We definitively have to expose a single set of APIs to applications. We won't be able to sell anything else. Thus, goal of this list is to come up with an agreement on what are going to be the specs of the NGSI-based interfaces supported in FI-WARE. One of the standardization efforts in FI-WARE would consist in going to OMA and push for fast-track adoption of anything that is different in these NGSI-based interfaces from the current standard. People displayed in the screenshot below are already members of this mailing list and should have received this email. Thierry and Lorant, from the IoT chapter, and Carlos from the Data/Context Management chapter, have been registered as administrators of the list besides me so that they can add new members directly. Please don't hesitate to invite/add anyone you believe should be involved in the discussion. Cheers, -- Juanjo [cid:part1.03030903.00080704 at tid.es] -- ------------- Juanjo Hierro Product Development and Innovation (PDI) - Telefonica Digital email: jhierro at tid.es twitter: twitter.com/JuanjoHierro ________________________________ 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: 122772 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001..txt URL: From jhierro at tid.es Wed Jan 4 16:05:59 2012 From: jhierro at tid.es (Juanjo Hierro) Date: Wed, 04 Jan 2012 16:05:59 +0100 Subject: [Fiware-data] Fwd: [Fiware-ngsi] Previous email relevant on the matter In-Reply-To: <4F0447A5.5050004@tid.es> References: <4F0447A5.5050004@tid.es> Message-ID: <4F046AD7.4000000@tid.es> ------------- Juanjo Hierro Product Development and Innovation (PDI) - Telefonica Digital email: jhierro at tid.es twitter: twitter.com/JuanjoHierro -------- Original Message -------- Subject: [Fiware-ngsi] Previous email relevant on the matter Date: Wed, 4 Jan 2012 13:35:49 +0100 From: Juanjo Hierro To: fiware-ngsi at lists.fi-ware.eu Hi, I believe that the email below, which I sent in December, is relevant to the discussion and may help to drive it in a fruitful and constructive manner. I have dropped the parts that were not substantial. Therefore, I'm resending it as to launch the discussion. Cheers, -- Juanjo -------- Original Message -------- Subject: Re: FW: DocumentationWSDL-NGSI10 Date: Fri, 09 Dec 2011 08:30:45 +0100 From: Juanjo Hierro To: 'Thierry.nagellen at orange-ftgroup.com' , Moltchanov Boris , Tobias Jacobs , laurence1.dupont at orange.com, Guy Sharon , Bisztray, Denes (NSN - HU/Budapest) , Martin Bauer , P.Barnaghi at surrey.ac.uk , RICARDO DE LAS HERAS MARTIN , Haller, Stephan , yvon.lopinto at orange.com, 'Ernoe Kovacs' , fano.ramparany at orange.com , laurent.artusio at orange.com, jan.holler at ericsson.com, Licciardi Carlo Alberto , Valla Massimo , Farkas, Lorant (NSN - HU/Budapest) CC: jhierro >> "Juan J. Hierro" , Bohnert, Thomas Michael Hi all, I have been forwarded this email and, before the discussion goes into the wrong direction, let me state a number of things that I believe may be helpful to carry out a constructive discussion and find the way to move forward: * OMA NGSI-9/10 specs may not be perfect at this stage and there might be some ingredients that may be useless and therefore not worth to implement. What we want to deliver in FI-WARE is actually software that works. However, we shouldn't see this as a problem but an opportunity: the opportunity to define a working spec that we may then fast-track for adoption in OMA either as a new version of OMA NGSI-9/10 specs or another specs that supersede them (some of us are relevant stakeholders that can really influence in the direction OMA can take) * Despite the above, OMA NGSI-9/10 supports a number of the fundamental concepts that we should support in a "Thing Management layer" and that's why I rather believe it's a good idea to adopt it as the basis for the definition of the API such layer should support not just to support event query and subscription by Applications, but also registry, query and subscription-in-inventory of things (which would map the concept of entity in OMA NGSI-9/10). This, in addition, would pave the way for a consistent model across the IoT and Data/Context Management Chapters in FI-WARE. * We may not have a fully compliant implementation of the current OMA NGSI-9/10 specs at this stage but this links to the first point above. What really matters in FI-WARE is that a) we define a consistent and single version of an API based on OMA NGSI-9/10 that we adopt in FI-WARE (note that I use "based" instead of "compliant") and b) we later fast-track its adoption in OMA. In defining and implementing this API: * We should put in practice the Agile approach and play with the fact that there will exist several FI-WARE Releases. This means we should document the target functions we want to support in the API as Features in our backlog and then try to plan their detailed specification and implementation along the different Releases (note that the detailed specification of the signature of a given operation may be addressed as WorkItem in a Sprint and then its implementation may be addressed as a User-Story in another Sprint, both linked to Release "X" while the detailed specification and implementation of another operation may be addressed in another Release) * In defining the target API, I believe we should try to go for alignment with the current NGSI-9/10 as much as possible, provided such alignment still leads to delivery of a meaningful/useful specification. This means that if a given operation is named "B" in our asset instead of "A" and that's the only difference, we may probably go for changing it to "A" unless all agree. * The implementation of OMA NGSI-9 and NGSI-10 based interfaces may not be supported by the same asset. The implementation of both interfaces may be developed in parallel by different partners on different assets. * We need to justify very well why we'll go for alternative implementations of the interfaces we will define based on OMA NGSI-9/10. I believe there may be justifications but I want to see them and I believe our reviewers and UC projects will definitively will also claim for them. And if we go for them, we definitively have to for all of them implementing the same set of APIs, with the same data model. Best regards, -- Juanjo ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001..txt URL: From jhierro at tid.es Wed Jan 4 16:06:54 2012 From: jhierro at tid.es (Juanjo Hierro) Date: Wed, 04 Jan 2012 16:06:54 +0100 Subject: [Fiware-data] Fwd: Re: [Fiware-ngsi] Launching mailing list dedicated to discussion on NGSI interfaces in FI-WARE In-Reply-To: <4F0464B2.1020807@tid.es> References: <4F0464B2.1020807@tid.es> Message-ID: <4F046B0E.3040809@tid.es> FYI. With this last email, I believe you have enough context as to decide whether you believe you should join the fiware-ngsi mailing list or not. Cheers, -- Juanjo -------- Original Message -------- Subject: Re: [Fiware-ngsi] Launching mailing list dedicated to discussion on NGSI interfaces in FI-WARE Date: Wed, 4 Jan 2012 15:39:46 +0100 From: RICARDO DE LAS HERAS MARTIN To: fiware-ngsi at lists.fi-ware.eu CC: JUAN JOSE HIERRO SUREDA Dear members of this new NGSI list, I launch the first topic to discuss here attaching you a couple of slides reflecting how within the 'IoT-T5.2-Resource management' we have come up with a draft Architecture for the Things Management Layer which is explained in the slides. I would like to rely on these slides to launch the discussion among partners in this list as well as the WPL and WPA, involving some of the relevant partners from the Data/Context Management Chapter which may bring some pieces of the overall picture. This Reference Architecture should help to show you the focus of our work within WP5 regarding development of the layer in the overall architecture coping with management of the relationship between (virtual) Things and IoT Resources (linked to sensors or actuators) and handling of events captured by IoT resources and transformed into context elements linked to Things. As you see, part of the APIs exposed to Applications would be based on OMA NGSI-9/10. The slides are accompanied by some notes (ppt notes) describing how the different pieces interact. thanks for your comments, br, RHer at s. Juanjo Hierro wrote: Hi all, As mentioned during the follow-up IoT confcall, we have setup a mailing list that will be focused on discussion about NGSI-based interfaces in FI-WARE. While we all agree that the final interfaces supported in FI-WARE may differ from the current OMA NGSI specs for good reasons, we all agree that FI-WARE should support only one variant of the specs, avoiding several, uncompatible, variants. We definitively have to expose a single set of APIs to applications. We won't be able to sell anything else. Thus, goal of this list is to come up with an agreement on what are going to be the specs of the NGSI-based interfaces supported in FI-WARE. One of the standardization efforts in FI-WARE would consist in going to OMA and push for fast-track adoption of anything that is different in these NGSI-based interfaces from the current standard. People displayed in the screenshot below are already members of this mailing list and should have received this email. Thierry and Lorant, from the IoT chapter, and Carlos from the Data/Context Management chapter, have been registered as administrators of the list besides me so that they can add new members directly. Please don't hesitate to invite/add anyone you believe should be involved in the discussion. Cheers, -- Juanjo [cid:part1.00020106.04010403 at tid.es] -- ------------- Juanjo Hierro Product Development and Innovation (PDI) - Telefonica Digital email: jhierro at tid.es twitter: twitter.com/JuanjoHierro ________________________________ 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 -- ------------------------------------------- Ricardo de las Heras M2M Research Technological Specialist E-mail: rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telef?nica Digital ------------------------------------------- ________________________________ 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: 122772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-WARE IoT - Things Management Layer-v1.1.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 126171 bytes Desc: not available URL: From rheras at tid.es Wed Jan 4 16:46:33 2012 From: rheras at tid.es (Ricardo de las Heras) Date: Wed, 04 Jan 2012 16:46:33 +0100 Subject: [Fiware-data] [Fiware-iot] T5.2 slides In-Reply-To: References: <4F0415DE.8060205@tid.es> Message-ID: <4F047459.6050004@tid.es> An HTML attachment was scrubbed... URL: From GUYSH at il.ibm.com Wed Jan 4 19:55:05 2012 From: GUYSH at il.ibm.com (Guy Sharon) Date: Wed, 4 Jan 2012 20:55:05 +0200 Subject: [Fiware-data] [Fiware-iot] T5.2 slides In-Reply-To: <4F047459.6050004@tid.es> References: <4F0415DE.8060205@tid.es> <4F047459.6050004@tid.es> Message-ID: Thank you for the examples - this helps in introducing some 'complications' to address by this method and in some sense to motivate that events should be considered to be stored\handled rather than updates to values (which is what I interpret from the presentation below) Example - TVSet moved - the event repository would hold a property of TVSet location value with timestamp. In some cases it is not enough - for example I would like to distinguish the move by an event that was the result of pushing the TVSet from an event representing the pulling of the TVSet to its new location. I would not be able to distinguish this by looking at the location value of the TVSet. Therefore based on the Vision document I think the event repository should store events (as a specific data element) with properties and not just properties. For example, PushTVSet event with property = location and property = timestamp (and could include more info such as the speed of movement) The point is that there is much more to the semantics of an event than representing the change in value or the change in transition. The change in value is more of a notification that the value changed the event represents the reason\cause of the change - for example thermometer - the change is in the temperature but the event is temperature reading. The change is in TVSet location transition but the event is pushed or pulled to the new location. Event processing reasons on the events and values and not just values in time. The TVSet was pulled 3 times during the day to the same location would give different results than 3 times during the day the location of the TVSet changed to the same value. 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: Ricardo de las Heras To: "fano.ramparany at orange.com" Cc: "fiware-iot at lists.fi-ware.eu" , "Fiware-data at lists.fi-ware.eu" Date: 04/01/2012 17:49 Subject: Re: [Fiware-data] [Fiware-iot] T5.2 slides Sent by: fiware-data-bounces at lists.fi-ware.eu Hi Fano, my reply inline: fano.ramparany at orange.com wrote: Thank you for this overall view of the IoT chapter Ricardo. I?ve got few questions about the data model. - How does the Metadata/Things/IoTResource/Event maps or relates to the Data/Context/Event schema introduced in the Vision document (Chapter ?introduction?)? - In the Vision document, Metadata seems to be properties about properties. Along this interpretation, timestamp might be one of this metadata, whereas in your model all properties have timestamp. - Well, I wouldn't like to lose the main focus (interfaces, blocks, ...) of those slides with this issue, the data model includes a timestamp in both: Properties and Observactions. I think in observations is quite clear for all of us, and Properties (associated to a Thing), as result of collecting all the capabilities (properties) of the resources associated to a single Thing. That's the idea, really I don't know how this issue is introduced in the Vision document, but if you find any contradiction please let me know. The concept of meta-data would imply the idea of 'Property'-'Value' association, as final high abstract model level of the data dictionary. - Could you give examples of ?associations? among Things and between Things and IoT? Example: - Thing: Room - Resource1: Thermometer-1 within the room. - Resource2: Pressure meter within the room. R1 and R2 are associated to the Thing 'Room', so you can ask for the temperature of the room, and the Things resolution would ask to R1 about this value and timestamp. - In your model, how would you represent that a TVset is placed on the table? Would this information be stored in the configuration repository? - In the same way, TVset is associated to a table, but if the location would be relevant for your system, it should be modelled as an additional property (on, under, in, besides, etc.), storing it as an additional feature of course. Or for example adding x,y,z coordinate. - How would you represent the events capturing a move of the TVset or the fact that the TVset has been relocated at another place? Would they be stored in the event repository? - Again depending of the requirements of the system, of course you can generate an event as result of a movement, automatically (sensor) or manually, modifying the location of the object, and therefore the information stored. In IoT we have a Resource Monitoring module for monitorizing dynamic associations between Things and Resources. Example: A car (resource) is moving along several streets (Things), changing this association in real time. other partners: please feel free to correct/complement my answers, Thank you in advance for your help, Fano you're welcome, cheers, Ricardo. PS: I?ve put the Fiware-data mailing list in the loop as obviously both chapters should synchronize on this issue De : fiware-iot-bounces at lists.fi-ware.eu [ mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de Ricardo de las Heras Envoy? : mercredi 4 janvier 2012 10:03 ? : fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] T5.2 slides Hi all, As you know, we have to deliver an Architecture Specification by end of January and deadline is approaching. This Architecture Specification should explain how the different GEs interact together and with the applications, going a step beyond from the very high-level figures we have designed so far. Elaborating on the interfaces the conceptual models to be supported. After some internal discussions at TID, we have come up with a draft Architecture for the Things Management Layer which is explained in the slides attached to this mail. We would like to rely on these slides to launch the discussion among partners in this task as well as the WPL and WPA, also involving some of the relevant partners from the Data/Context Management Chapter which may bring some pieces of the overall picture. I may elaborate on them during the phone call now if needed. Br, -- ------------------------------------------- Ricardo de las Heras M2M Research Technological Specialist E-mail: rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telef?nica Digital ------------------------------------------- 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 -- ------------------------------------------- Ricardo de las Heras M2M Research Technological Specialist E-mail: rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telef?nica Digital ------------------------------------------- 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-data mailing list Fiware-data at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-data -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 488 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: From fano.ramparany at orange.com Thu Jan 5 10:04:05 2012 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Thu, 5 Jan 2012 10:04:05 +0100 Subject: [Fiware-data] [Fiware-iot] T5.2 slides In-Reply-To: References: <4F0415DE.8060205@tid.es> <4F047459.6050004@tid.es> Message-ID: Thank you for your feedback Ricardo and Guy, My comments inline below, De : Guy Sharon [mailto:GUYSH at il.ibm.com] Envoy? : mercredi 4 janvier 2012 19:55 ? : Ricardo de las Heras Cc : RAMPARANY Fano RD-TECH-GRE; Fiware-data at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Objet : Re: [Fiware-data] [Fiware-iot] T5.2 slides Thank you for the examples - this helps in introducing some 'complications' to address by this method and in some sense to motivate that events should be considered to be stored\handled rather than updates to values (which is what I interpret from the presentation below) Example - TVSet moved - the event repository would hold a property of TVSet location value with timestamp. In some cases it is not enough - for example I would like to distinguish the move by an event that was the result of pushing the TVSet from an event representing the pulling of the TVSet to its new location. I would not be able to distinguish this by looking at the location value of the TVSet. Therefore based on the Vision document I think the event repository should store events (as a specific data element) with properties and not just properties. This is indeed an issue I raised in FIWARE-data. I was also in favor of modeling properties as events rather than data elements as events. From the assumption that a data element in the Vision Document corresponds to a Thing in T5.2 slides, its seems more intuitive to consider the (newly measured) location of the TVSet as an event than to consider the TVSet as an event. For example, PushTVSet event with property = location and property = timestamp (and could include more info such as the speed of movement) The point is that there is much more to the semantics of an event than representing the change in value or the change in transition. We could handle timestamp as what is called "meta data" in the vision document. These meta data are attached to "properties" in the vision document. For the speed of movement we could handle this as the result of processing the location property ( (currentlocation - previouslocation)/(currentlocation.timestamp - previouslocation.timestamp) ) and create a new property attached the the TVSet Thing (or TVSet Data element). More generally, any derivation of new properties based on existing properties, we could view it as "reasoning" and handled by the appropriate GE. The change in value is more of a notification that the value changed the event represents the reason\cause of the change - for example thermometer - the change is in the temperature but the event is temperature reading. The change is in TVSet location transition but the event is pushed or pulled to the new location. Event processing reasons on the events and values and not just values in time. The TVSet was pulled 3 times during the day to the same location would give different results than 3 times during the day the location of the TVSet changed to the same value. I'm not sure I fully understand your point Guy. I agree that sensor readings are modeled as events. If you mean that change detection is the result of processing (analyzing) the events flow, I also agree. Example if the flow of "measuring" the TVSet location events is: Event1: table Event2: table Event3: ground Event4: ground Event5: table Event6: table Event7: table Changes occurs only at Event3 and Event5 About the consistency between the data/context/event schema from the Vision Document and the metadata/thing/iotResource schema from the T5.2 slides. The main discrepancy I've identified so far is the metadata. We also need to agree on Thing relate to Data Element, and how the IoTRessource does map into the Vision Document schema. Kind regards, Fano 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: Ricardo de las Heras To: "fano.ramparany at orange.com" Cc: "fiware-iot at lists.fi-ware.eu" , "Fiware-data at lists.fi-ware.eu" Date: 04/01/2012 17:49 Subject: Re: [Fiware-data] [Fiware-iot] T5.2 slides Sent by: fiware-data-bounces at lists.fi-ware.eu ________________________________ Hi Fano, my reply inline: fano.ramparany at orange.com wrote: Thank you for this overall view of the IoT chapter Ricardo. I've got few questions about the data model. - How does the Metadata/Things/IoTResource/Event maps or relates to the Data/Context/Event schema introduced in the Vision document (Chapter "introduction")? - In the Vision document, Metadata seems to be properties about properties. Along this interpretation, timestamp might be one of this metadata, whereas in your model all properties have timestamp. - Well, I wouldn't like to lose the main focus (interfaces, blocks, ...) of those slides with this issue, the data model includes a timestamp in both: Properties and Observactions. I think in observations is quite clear for all of us, and Properties (associated to a Thing), as result of collecting all the capabilities (properties) of the resources associated to a single Thing. That's the idea, really I don't know how this issue is introduced in the Vision document, but if you find any contradiction please let me know. The concept of meta-data would imply the idea of 'Property'-'Value' association, as final high abstract model level of the data dictionary. - Could you give examples of "associations" among Things and between Things and IoT? Example: - Thing: Room - Resource1: Thermometer-1 within the room. - Resource2: Pressure meter within the room. R1 and R2 are associated to the Thing 'Room', so you can ask for the temperature of the room, and the Things resolution would ask to R1 about this value and timestamp. - In your model, how would you represent that a TVset is placed on the table? Would this information be stored in the configuration repository? - In the same way, TVset is associated to a table, but if the location would be relevant for your system, it should be modelled as an additional property (on, under, in, besides, etc.), storing it as an additional feature of course. Or for example adding x,y,z coordinate. - How would you represent the events capturing a move of the TVset or the fact that the TVset has been relocated at another place? Would they be stored in the event repository? - Again depending of the requirements of the system, of course you can generate an event as result of a movement, automatically (sensor) or manually, modifying the location of the object, and therefore the information stored. In IoT we have a Resource Monitoring module for monitorizing dynamic associations between Things and Resources. Example: A car (resource) is moving along several streets (Things), changing this association in real time. other partners: please feel free to correct/complement my answers, Thank you in advance for your help, Fano you're welcome, cheers, Ricardo. PS: I've put the Fiware-data mailing list in the loop as obviously both chapters should synchronize on this issue De : fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu ] De la part de Ricardo de las Heras Envoy? : mercredi 4 janvier 2012 10:03 ? : fiware-iot at lists.fi-ware.eu Objet : [Fiware-iot] T5.2 slides Hi all, As you know, we have to deliver an Architecture Specification by end of January and deadline is approaching. This Architecture Specification should explain how the different GEs interact together and with the applications, going a step beyond from the very high-level figures we have designed so far. Elaborating on the interfaces the conceptual models to be supported. After some internal discussions at TID, we have come up with a draft Architecture for the Things Management Layer which is explained in the slides attached to this mail. We would like to rely on these slides to launch the discussion among partners in this task as well as the WPL and WPA, also involving some of the relevant partners from the Data/Context Management Chapter which may bring some pieces of the overall picture. I may elaborate on them during the phone call now if needed. Br, -- ------------------------------------------- Ricardo de las Heras M2M Research Technological Specialist E-mail: rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telef?nica Digital ------------------------------------------- ________________________________ 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 -- ------------------------------------------- Ricardo de las Heras M2M Research Technological Specialist E-mail: rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telef?nica Digital ------------------------------------------- ________________________________ 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-data mailing list Fiware-data at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-data -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 518 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 488 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 467 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 494 bytes Desc: image004.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.gif Type: image/gif Size: 360 bytes Desc: image005.gif URL: From fano.ramparany at orange.com Thu Jan 5 11:13:24 2012 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Thu, 5 Jan 2012 11:13:24 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2558 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 9509 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 11456 bytes Desc: image004.jpg URL: From GUYSH at il.ibm.com Fri Jan 6 01:36:58 2012 From: GUYSH at il.ibm.com (Guy Sharon) Date: Fri, 6 Jan 2012 02:36:58 +0200 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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: To: Guy Sharon/Haifa/IBM at IBMIL Cc: , , , 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 9749 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 25563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 18440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 488 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2558 bytes Desc: not available URL: From boris.moltchanov at telecomitalia.it Fri Jan 6 16:02:57 2012 From: boris.moltchanov at telecomitalia.it (Moltchanov Boris) Date: Fri, 6 Jan 2012 16:02:57 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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 :). 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) [cid:image001.gif at 01CCCC8A.81645090] 2)[cid:image002.gif at 01CCCC8A.81645090] 3)[cid:image003.gif at 01CCCC8A.81645090] 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)[cid:image004.gif at 01CCCC8A.81645090] 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. [cid:image005.gif at 01CCCC8A.81645090] 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. [cid:image006.gif at 01CCCC8A.81645090] 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: [cid:image007.jpg at 01CCCC8A.81645090] [cid:image008.jpg at 01CCCC8A.81645090] and within IBM on: [cid:image009.jpg at 01CCCC8A.81645090] [cid:image010.jpg at 01CCCC8A.81645090] [cid:image011.gif at 01CCCC8A.81645090] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: > To: Guy Sharon/Haifa/IBM at IBMIL Cc: >, >, >, > 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: [cid:image012.png at 01CCCC8A.81645090] Which in the graphical notation corresponds to: [cid:image013.jpg at 01CCCC8A.81645090] 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 ________________________________ [cid:image014.gif at 01CCCC8A.81645090] 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. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3092 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 5210 bytes Desc: image002.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 3243 bytes Desc: image003.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.gif Type: image/gif Size: 9749 bytes Desc: image004.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.gif Type: image/gif Size: 25563 bytes Desc: image005.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.gif Type: image/gif Size: 18440 bytes Desc: image006.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 518 bytes Desc: image007.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.jpg Type: image/jpeg Size: 488 bytes Desc: image008.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.jpg Type: image/jpeg Size: 467 bytes Desc: image009.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.jpg Type: image/jpeg Size: 494 bytes Desc: image010.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image011.gif Type: image/gif Size: 360 bytes Desc: image011.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image012.png Type: image/png Size: 9509 bytes Desc: image012.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.jpg Type: image/jpeg Size: 11456 bytes Desc: image013.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.gif Type: image/gif Size: 2558 bytes Desc: image014.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From GUYSH at il.ibm.com Fri Jan 6 18:42:10 2012 From: GUYSH at il.ibm.com (Guy Sharon) Date: Fri, 6 Jan 2012 19:42:10 +0200 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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 To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" Cc: Licciardi Carlo Alberto , "Fiware-data at lists.fi-ware.eu" , "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: To: Guy Sharon/Haifa/IBM at IBMIL Cc: , < carlo.licciardi at telecomitalia.it>, , < 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 9749 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 25563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 18440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 488 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: From boris.moltchanov at telecomitalia.it Fri Jan 6 19:02:45 2012 From: boris.moltchanov at telecomitalia.it (Moltchanov Boris) Date: Fri, 6 Jan 2012 19:02:45 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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: [cid:image001.jpg at 01CCCCA5.C5FF6120] and within IBM on: [cid:image002.jpg at 01CCCCA5.C5FF6120] [cid:image003.jpg at 01CCCCA5.C5FF6120] [cid:image004.gif at 01CCCCA5.C5FF6120] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" > Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu" >, "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 :). 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) [cid:image005.gif at 01CCCCA5.C5FF6120] 2)[cid:image006.gif at 01CCCCA5.C5FF6120] 3)[cid:image007.gif at 01CCCCA5.C5FF6120] 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)[cid:image008.gif at 01CCCCA5.C5FF6120] 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. [cid:image009.gif at 01CCCCA5.C5FF6120] 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. [cid:image010.gif at 01CCCCA5.C5FF6120] 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: [cid:image001.jpg at 01CCCCA5.C5FF6120] [cid:image011.jpg at 01CCCCA5.C5FF6120] and within IBM on: [cid:image002.jpg at 01CCCCA5.C5FF6120] [cid:image003.jpg at 01CCCCA5.C5FF6120] [cid:image004.gif at 01CCCCA5.C5FF6120] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: > To: Guy Sharon/Haifa/IBM at IBMIL Cc: >, >, >, > 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: [cid:image012.png at 01CCCCA5.C5FF6120] Which in the graphical notation corresponds to: [cid:image013.jpg at 01CCCCA5.C5FF6120] 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 ________________________________ [cid:image014.gif at 01CCCCA5.C5FF6120] 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. [cid:image015.gif at 01CCCCA5.C5FF6120]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. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 518 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 467 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 494 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.gif Type: image/gif Size: 360 bytes Desc: image004.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.gif Type: image/gif Size: 3092 bytes Desc: image005.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.gif Type: image/gif Size: 5210 bytes Desc: image006.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.gif Type: image/gif Size: 3243 bytes Desc: image007.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.gif Type: image/gif Size: 9749 bytes Desc: image008.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.gif Type: image/gif Size: 25563 bytes Desc: image009.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.gif Type: image/gif Size: 18440 bytes Desc: image010.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image011.jpg Type: image/jpeg Size: 488 bytes Desc: image011.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image012.png Type: image/png Size: 9509 bytes Desc: image012.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.jpg Type: image/jpeg Size: 11456 bytes Desc: image013.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.gif Type: image/gif Size: 2558 bytes Desc: image014.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.gif Type: image/gif Size: 677 bytes Desc: image015.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From GUYSH at il.ibm.com Sat Jan 7 21:47:21 2012 From: GUYSH at il.ibm.com (Guy Sharon) Date: Sat, 7 Jan 2012 22:47:21 +0200 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: Data\Context Management GE architecture picture has data moving\flowing from Massive Data Collection GE to Processing GEs (incl. CEP) and then Pub\Sub and Query and other 'consumer' facing GEs. So there is no context resolution engine before CEP and there is no need to, in addition, no CEP 3rd party \ vendor etc. that I know of - and I am very aware in this field - treats event processing without specifically dealing with events as first class. Thats the nature of event processing. And if I am not mistaken BigData deals first and foremost with data and not context. Therefore we must keep these 3 aspects alive and not collapse them into one another. We also need to be able to provide good support for dealing with things you mention below. Data to\from Event to\from Context to\from Data 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , "fano.ramparany at orange.com" , "Fiware-data at lists.fi-ware.eu" , "jhierro at tid.es" Date: 06/01/2012 20:03 Subject: 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 To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" < fano.ramparany at orange.com> Cc: Licciardi Carlo Alberto , " Fiware-data at lists.fi-ware.eu" , " 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: To: Guy Sharon/Haifa/IBM at IBMIL Cc: , < carlo.licciardi at telecomitalia.it>, , < 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 9749 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 25563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 18440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 488 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: From ralli at tid.es Mon Jan 9 11:59:29 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 09 Jan 2012 11:59:29 +0100 Subject: [Fiware-data] Fwd: [Fiware-wpa] Creation of linkedin group References: <4F058C45.4050908@tid.es> Message-ID: <012112BD-59B0-47C3-BB88-2CC8566DC231@tid.es> Dear WP colleagues, First of all, wish you all a happy new year 2012. In 2012 we keep on leveraging the Social Networks presence of FIWARE. Please, check out Miguel's e-mail below and do join our Linkedin Group. Let me remind hereby our twitter account (@fiware) as well. Really thanks to all of you already following us and hope there are more willing to get started with it this new year ;-) Best regards, -- ------------------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------- Inicio del mensaje reenviado: De: MIGUEL CARRILLO PACHECO > Fecha: 5 de enero de 2012 12:40:53 GMT+01:00 Para: "fiware-wpl at lists.fi-ware.eu" >, "fiware-wpa at lists.fi-ware.eu" > Cc: "fiware at lists.fi-ware.eu" > Asunto: [Fiware-wpa] Creation of linkedin group Dear WPLs & WPAs, We have set up a FI-WARE Linkedin group * http://www.linkedin.com/groups/FIWARE-4239932 Please disseminate this within your respective chapters and encourage your WP members to join in! Thanks 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 ---------------------------------------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001..txt URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralli at tid.es Mon Jan 9 16:30:26 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 09 Jan 2012 16:30:26 +0100 Subject: [Fiware-data] Details for tomorrow's Data/Context Conf.Call Message-ID: <3C04A058-E507-4E57-B54C-F837905139EC@tid.es> Dear WP Colleagues, Tomorrow at 15h CET we are having the first Data/Context follow up in 2012. Please, take some time to review Action Points and previous discussions of Dec 23th meeting at: https://forge.fi-ware.eu/docman/view.php/9/713/20111223_Data-Context-Minutes.doc Note: Log in FIWARE forge prior to download it. Please ignore the document's attendants section (incomplete). **** Details to connect tomorrow: 1) Phone Bridge: We'll use powwownow. PIN: 050662. Local dial-in phone numbers at: http://pdf.powwownow.com/pdf/USA_en_pwn-dial-in-numbers.pdf 2) Webex: Topic: FIWARE Data/Context Conf.Call Date: Tuesday, January 10, 2012 Time: 3:00 pm, Europe Time (Paris, GMT+01:00) Meeting Number: 967 084 643 Meeting Password: 1234abcD ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://telefonica.webex.com/telefonica-en/j.php?ED=189660657&UID=1266842337&PW=NYmM5MzgxNGEx&RT=MiMyMw%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: 1234abcD 4. Click "Join Now". To view in other time zones or languages, please click the link: https://telefonica.webex.com/telefonica-en/j.php?ED=189660657&UID=1266842337&PW=NYmM5MzgxNGEx&ORT=MiMyMw%3D%3D Best regards. -- ------------------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From fano.ramparany at orange.com Mon Jan 9 18:05:12 2012 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Mon, 9 Jan 2012 18:05:12 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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 To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" Cc: Licciardi Carlo Alberto , "Fiware-data at lists.fi-ware.eu" , "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: > To: Guy Sharon/Haifa/IBM at IBMIL Cc: >, >, >, > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 518 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 467 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 494 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.gif Type: image/gif Size: 360 bytes Desc: image004.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.gif Type: image/gif Size: 3092 bytes Desc: image005.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.gif Type: image/gif Size: 5210 bytes Desc: image006.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.gif Type: image/gif Size: 3243 bytes Desc: image007.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.gif Type: image/gif Size: 9749 bytes Desc: image008.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.gif Type: image/gif Size: 25563 bytes Desc: image009.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.gif Type: image/gif Size: 18440 bytes Desc: image010.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image011.jpg Type: image/jpeg Size: 488 bytes Desc: image011.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image012.png Type: image/png Size: 9509 bytes Desc: image012.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.jpg Type: image/jpeg Size: 11456 bytes Desc: image013.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.gif Type: image/gif Size: 2558 bytes Desc: image014.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.gif Type: image/gif Size: 677 bytes Desc: image015.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image017.jpg Type: image/jpeg Size: 12073 bytes Desc: image017.jpg URL: From boris.moltchanov at telecomitalia.it Mon Jan 9 18:31:12 2012 From: boris.moltchanov at telecomitalia.it (Moltchanov Boris) Date: Mon, 9 Jan 2012 18:31:12 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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: [cid:image016.jpg at 01CCCEFC.DD18C410] 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: [cid:image017.jpg at 01CCCEFC.DD18C410] and within IBM on: [cid:image018.jpg at 01CCCEFC.DD18C410] [cid:image019.jpg at 01CCCEFC.DD18C410] [cid:image020.gif at 01CCCEFC.DD18C410] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" > Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu" >, "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 :). 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) [cid:image021.gif at 01CCCEFC.DD18C410] 2)[cid:image022.gif at 01CCCEFC.DD18C410] 3)[cid:image023.gif at 01CCCEFC.DD18C410] 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)[cid:image024.gif at 01CCCEFC.DD18C410] 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. [cid:image025.gif at 01CCCEFC.DD18C410] 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. [cid:image026.gif at 01CCCEFC.DD18C410] 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: [cid:image017.jpg at 01CCCEFC.DD18C410] [cid:image027.jpg at 01CCCEFC.DD18C410] and within IBM on: [cid:image018.jpg at 01CCCEFC.DD18C410] [cid:image019.jpg at 01CCCEFC.DD18C410] [cid:image020.gif at 01CCCEFC.DD18C410] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: > To: Guy Sharon/Haifa/IBM at IBMIL Cc: >, >, >, > 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: [cid:image028.png at 01CCCEFC.DD18C410] Which in the graphical notation corresponds to: [cid:image029.jpg at 01CCCEFC.DD18C410] 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 ________________________________ [cid:image030.gif at 01CCCEFC.DD18C410] 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. [cid:image031.gif at 01CCCEFC.DD18C410]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. [cid:image031.gif at 01CCCEFC.DD18C410]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. [cid:00000000000000000000000000000001 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: image016.jpg Type: image/jpeg Size: 12073 bytes Desc: image016.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image017.jpg Type: image/jpeg Size: 518 bytes Desc: image017.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image018.jpg Type: image/jpeg Size: 467 bytes Desc: image018.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image019.jpg Type: image/jpeg Size: 494 bytes Desc: image019.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image020.gif Type: image/gif Size: 360 bytes Desc: image020.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image021.gif Type: image/gif Size: 3092 bytes Desc: image021.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image022.gif Type: image/gif Size: 5210 bytes Desc: image022.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image023.gif Type: image/gif Size: 3243 bytes Desc: image023.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image024.gif Type: image/gif Size: 9749 bytes Desc: image024.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image025.gif Type: image/gif Size: 25563 bytes Desc: image025.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image026.gif Type: image/gif Size: 18440 bytes Desc: image026.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image027.jpg Type: image/jpeg Size: 488 bytes Desc: image027.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image028.png Type: image/png Size: 9509 bytes Desc: image028.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image029.jpg Type: image/jpeg Size: 11456 bytes Desc: image029.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image030.gif Type: image/gif Size: 2558 bytes Desc: image030.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image031.gif Type: image/gif Size: 677 bytes Desc: image031.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From GUYSH at il.ibm.com Mon Jan 9 20:13:45 2012 From: GUYSH at il.ibm.com (Guy Sharon) Date: Mon, 9 Jan 2012 21:13:45 +0200 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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 To: "fano.ramparany at orange.com" , Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , "Fiware-data at lists.fi-ware.eu" , "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 To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" < fano.ramparany at orange.com> Cc: Licciardi Carlo Alberto , " Fiware-data at lists.fi-ware.eu" , " 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: To: Guy Sharon/Haifa/IBM at IBMIL Cc: , < carlo.licciardi at telecomitalia.it>, , < 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 12073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 9749 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 25563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 18440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 488 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: From boris.moltchanov at telecomitalia.it Mon Jan 9 20:31:14 2012 From: boris.moltchanov at telecomitalia.it (Moltchanov Boris) Date: Mon, 9 Jan 2012 20:31:14 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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: [cid:image001.jpg at 01CCCF0D.A1FB30A0] and within IBM on: [cid:image002.jpg at 01CCCF0D.A1FB30A0] [cid:image003.jpg at 01CCCF0D.A1FB30A0] [cid:image004.gif at 01CCCF0D.A1FB30A0] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris To: "fano.ramparany at orange.com" , Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , "Fiware-data at lists.fi-ware.eu" , "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: [cid:image005.jpg at 01CCCF0D.A1FB30A0] 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: [cid:image001.jpg at 01CCCF0D.A1FB30A0] and within IBM on: [cid:image002.jpg at 01CCCF0D.A1FB30A0] [cid:image003.jpg at 01CCCF0D.A1FB30A0] [cid:image004.gif at 01CCCF0D.A1FB30A0] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" > Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu" >, "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 :). 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) [cid:image006.gif at 01CCCF0D.A1FB30A0] 2)[cid:image007.gif at 01CCCF0D.A1FB30A0] 3)[cid:image008.gif at 01CCCF0D.A1FB30A0] 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)[cid:image009.gif at 01CCCF0D.A1FB30A0] 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. [cid:image010.gif at 01CCCF0D.A1FB30A0] 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. [cid:image011.gif at 01CCCF0D.A1FB30A0] 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: [cid:image001.jpg at 01CCCF0D.A1FB30A0] [cid:image012.jpg at 01CCCF0D.A1FB30A0] and within IBM on: [cid:image002.jpg at 01CCCF0D.A1FB30A0] [cid:image003.jpg at 01CCCF0D.A1FB30A0] [cid:image004.gif at 01CCCF0D.A1FB30A0] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: > To: Guy Sharon/Haifa/IBM at IBMIL Cc: >, >, >, > 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: [cid:image013.png at 01CCCF0D.A1FB30A0] Which in the graphical notation corresponds to: [cid:image014.jpg at 01CCCF0D.A1FB30A0] 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 ________________________________ [cid:image015.gif at 01CCCF0D.A1FB30A0] 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. [cid:image016.gif at 01CCCF0D.A1FB30A0]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. [cid:image016.gif at 01CCCF0D.A1FB30A0]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. [cid:image016.gif at 01CCCF0D.A1FB30A0]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. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 518 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 467 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 494 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.gif Type: image/gif Size: 360 bytes Desc: image004.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 12073 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.gif Type: image/gif Size: 3092 bytes Desc: image006.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.gif Type: image/gif Size: 5210 bytes Desc: image007.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.gif Type: image/gif Size: 3243 bytes Desc: image008.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.gif Type: image/gif Size: 9749 bytes Desc: image009.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.gif Type: image/gif Size: 25563 bytes Desc: image010.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image011.gif Type: image/gif Size: 18440 bytes Desc: image011.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image012.jpg Type: image/jpeg Size: 488 bytes Desc: image012.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.png Type: image/png Size: 9509 bytes Desc: image013.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.jpg Type: image/jpeg Size: 11456 bytes Desc: image014.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.gif Type: image/gif Size: 2558 bytes Desc: image015.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image016.gif Type: image/gif Size: 677 bytes Desc: image016.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From GUYSH at il.ibm.com Mon Jan 9 20:47:39 2012 From: GUYSH at il.ibm.com (Guy Sharon) Date: Mon, 9 Jan 2012 21:47:39 +0200 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , "fano.ramparany at orange.com" , "Fiware-data at lists.fi-ware.eu" , "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 To: "fano.ramparany at orange.com" , Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , "Fiware-data at lists.fi-ware.eu" , "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 To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" < fano.ramparany at orange.com> Cc: Licciardi Carlo Alberto , " Fiware-data at lists.fi-ware.eu" , " 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: To: Guy Sharon/Haifa/IBM at IBMIL Cc: , < carlo.licciardi at telecomitalia.it>, , < 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 12073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 9749 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 25563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 18440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 488 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: From fano.ramparany at orange.com Tue Jan 10 11:02:18 2012 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Tue, 10 Jan 2012 11:02:18 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: Hi, If being more concrete could help, we could ask ourselves how the exchange format between a boiler thermometer and a GE would look like and check if it could solve our problems (resolution, loss of information, ...). For example, I would propose: For example, if this is sent to the P/S GE the context could be explicitely retrieved from the "contextOf" attribute. Hope it helps! De : Guy Sharon [mailto:GUYSH at il.ibm.com] Envoy? : lundi 9 janvier 2012 20:48 ? : Moltchanov Boris 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 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , "fano.ramparany at orange.com" , "Fiware-data at lists.fi-ware.eu" , "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 To: "fano.ramparany at orange.com" , Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , "Fiware-data at lists.fi-ware.eu" , "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 > To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com " > Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu " >, "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: > To: Guy Sharon/Haifa/IBM at IBMIL Cc: >, >, >, > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 518 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 467 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 494 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.gif Type: image/gif Size: 360 bytes Desc: image004.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 12073 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.gif Type: image/gif Size: 3092 bytes Desc: image006.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.gif Type: image/gif Size: 5210 bytes Desc: image007.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.gif Type: image/gif Size: 3243 bytes Desc: image008.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.gif Type: image/gif Size: 9749 bytes Desc: image009.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.gif Type: image/gif Size: 25563 bytes Desc: image010.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image011.gif Type: image/gif Size: 18440 bytes Desc: image011.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image012.jpg Type: image/jpeg Size: 488 bytes Desc: image012.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.png Type: image/png Size: 9509 bytes Desc: image013.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.jpg Type: image/jpeg Size: 11456 bytes Desc: image014.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.gif Type: image/gif Size: 2558 bytes Desc: image015.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image016.gif Type: image/gif Size: 677 bytes Desc: image016.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image019.jpg Type: image/jpeg Size: 10043 bytes Desc: image019.jpg URL: From ralli at tid.es Tue Jan 10 11:41:51 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 10 Jan 2012 11:41:51 +0100 Subject: [Fiware-data] Data/Context Action points review and request of members Message-ID: <4BD19336-F1C1-47EF-9A96-054824A05669@tid.es> Dear WP colleagues, I have just updated the previous follow up minutes correcting some typos / mistakes (thanks for your feedback!) and reflect the current status of the agreed Action Points (APs). Find the document here: https://forge.fi-ware.eu/docman/view.php/9/713/20111223_Data-Context-Minutes.doc (you need to be logged in the FIWARE forge to access the file) Guy, we have just solved today AP4.1, so the second step (AP4.2) assigned to you was obviously not feasible and therefore it will be reset today (so you don't have to take care at this point). In order to achieve AP1, I would like to request the e-mails of your collaborators that will be contributing to the "fiware-middleware" cross-chapter mailing-list. Just send me the names in a private e-mail and I will manage the subscriptions for you. Finally, to achieve AP6 we should be all ready to describe today how we updated or we plan to update the tracker to get ready to the 3rd Sprint. Thanks for your cooperation. Best regards. -- ------------------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From ralli at tid.es Tue Jan 10 14:43:35 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 10 Jan 2012 14:43:35 +0100 Subject: [Fiware-data] Details for tomorrow's Data/Context Conf.Call (We will start at 15:30) In-Reply-To: <3C04A058-E507-4E57-B54C-F837905139EC@tid.es> References: <3C04A058-E507-4E57-B54C-F837905139EC@tid.es> Message-ID: <214D8B82-89E0-45A5-9ECD-F519C35CF9EA@tid.es> Dear colleagues, I apologize for the inconvenience but due to an unexpected issue we will start half an hour later (15:30). Thanks for your understanding, Best regards, -- ------------------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------- El 09/01/2012, a las 16:30, CARLOS RALLI UCENDO escribi?: > Dear WP Colleagues, > > Tomorrow at 15h CET we are having the first Data/Context follow up in 2012. > > Please, take some time to review Action Points and previous discussions of Dec 23th meeting at: > https://forge.fi-ware.eu/docman/view.php/9/713/20111223_Data-Context-Minutes.doc > Note: Log in FIWARE forge prior to download it. Please ignore the document's attendants section (incomplete). > > **** Details to connect tomorrow: > > 1) Phone Bridge: > We'll use powwownow. PIN: 050662. Local dial-in phone numbers at: > http://pdf.powwownow.com/pdf/USA_en_pwn-dial-in-numbers.pdf > > 2) Webex: > > Topic: FIWARE Data/Context Conf.Call > Date: Tuesday, January 10, 2012 > Time: 3:00 pm, Europe Time (Paris, GMT+01:00) > Meeting Number: 967 084 643 > Meeting Password: 1234abcD > > ------------------------------------------------------- > To join the online meeting (Now from iPhones too!) > ------------------------------------------------------- > 1. Go to https://telefonica.webex.com/telefonica-en/j.php?ED=189660657&UID=1266842337&PW=NYmM5MzgxNGEx&RT=MiMyMw%3D%3D > 2. Enter your name and email address. > 3. Enter the meeting password: 1234abcD > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://telefonica.webex.com/telefonica-en/j.php?ED=189660657&UID=1266842337&PW=NYmM5MzgxNGEx&ORT=MiMyMw%3D%3D > > > Best regards. > -- > ------------------------------------------------------- > Carlos Ralli Ucendo (ralli at tid.es) > Cell: +34696923588 > Telef?nica I+D SAU > Madrid, Spain > ------------------------------------------------------- > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From ralli at tid.es Tue Jan 10 18:11:17 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 10 Jan 2012 18:11:17 +0100 Subject: [Fiware-data] Today's Follow up minutes Message-ID: Dear WP Colleagues, Find the minutes and Action Points of today's meeting in the following link: https://forge.fi-ware.eu/docman/view.php/9/716/20120110_Data-Context-Minutes.doc (Log in the FIWARE forge to be able to access it) Should you have any comment or suggestion, please let us know. Best regards, -- ------------------------------------------------------- Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From boris.moltchanov at telecomitalia.it Fri Jan 13 10:14:03 2012 From: boris.moltchanov at telecomitalia.it (Moltchanov Boris) Date: Fri, 13 Jan 2012 10:14:03 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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: [cid:image001.jpg at 01CCD1DC.13426370] and within IBM on: [cid:image002.jpg at 01CCD1DC.13426370] [cid:image003.jpg at 01CCD1DC.13426370] [cid:image004.gif at 01CCD1DC.13426370] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "fano.ramparany at orange.com" >, "Fiware-data at lists.fi-ware.eu" >, "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: [cid:image001.jpg at 01CCD1DC.13426370] and within IBM on: [cid:image002.jpg at 01CCD1DC.13426370] [cid:image003.jpg at 01CCD1DC.13426370] [cid:image004.gif at 01CCD1DC.13426370] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: "fano.ramparany at orange.com" >, Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu" >, "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: [cid:image005.jpg at 01CCD1DC.13426370] 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: [cid:image001.jpg at 01CCD1DC.13426370] and within IBM on: [cid:image002.jpg at 01CCD1DC.13426370] [cid:image003.jpg at 01CCD1DC.13426370] [cid:image004.gif at 01CCD1DC.13426370] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" > Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu" >, "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 :). 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) [cid:image006.gif at 01CCD1DC.13426370] 2)[cid:image007.gif at 01CCD1DC.13426370] 3)[cid:image008.gif at 01CCD1DC.13426370] 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)[cid:image009.gif at 01CCD1DC.13426370] 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. [cid:image010.gif at 01CCD1DC.13426370] 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. [cid:image011.gif at 01CCD1DC.13426370] 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: [cid:image001.jpg at 01CCD1DC.13426370] [cid:image012.jpg at 01CCD1DC.13426370] and within IBM on: [cid:image002.jpg at 01CCD1DC.13426370] [cid:image003.jpg at 01CCD1DC.13426370] [cid:image004.gif at 01CCD1DC.13426370] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: > To: Guy Sharon/Haifa/IBM at IBMIL Cc: >, >, >, > 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: [cid:image013.png at 01CCD1DC.13426370] Which in the graphical notation corresponds to: [cid:image014.jpg at 01CCD1DC.13426370] 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 ________________________________ [cid:image015.gif at 01CCD1DC.13426370] 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. [cid:image016.gif at 01CCD1DC.13426370]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. [cid:image016.gif at 01CCD1DC.13426370]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. [cid:image016.gif at 01CCD1DC.13426370]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. [cid:image016.gif at 01CCD1DC.13426370]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. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 518 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 467 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 494 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.gif Type: image/gif Size: 360 bytes Desc: image004.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 12073 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.gif Type: image/gif Size: 3092 bytes Desc: image006.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.gif Type: image/gif Size: 5210 bytes Desc: image007.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.gif Type: image/gif Size: 3243 bytes Desc: image008.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.gif Type: image/gif Size: 9749 bytes Desc: image009.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.gif Type: image/gif Size: 25563 bytes Desc: image010.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image011.gif Type: image/gif Size: 18440 bytes Desc: image011.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image012.jpg Type: image/jpeg Size: 488 bytes Desc: image012.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.png Type: image/png Size: 9509 bytes Desc: image013.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.jpg Type: image/jpeg Size: 11456 bytes Desc: image014.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.gif Type: image/gif Size: 2558 bytes Desc: image015.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image016.gif Type: image/gif Size: 677 bytes Desc: image016.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From GUYSH at il.ibm.com Fri Jan 13 10:35:41 2012 From: GUYSH at il.ibm.com (Guy Sharon) Date: Fri, 13 Jan 2012 11:35:41 +0200 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , "fano.ramparany at orange.com" , "Fiware-data at lists.fi-ware.eu" , "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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , " fano.ramparany at orange.com" , " Fiware-data at lists.fi-ware.eu" , " 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 To: "fano.ramparany at orange.com" , Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , " Fiware-data at lists.fi-ware.eu" , " 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 To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" < fano.ramparany at orange.com> Cc: Licciardi Carlo Alberto , " Fiware-data at lists.fi-ware.eu" , " 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: To: Guy Sharon/Haifa/IBM at IBMIL Cc: , < carlo.licciardi at telecomitalia.it>, , < 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 12073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 9749 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 25563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 18440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 488 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: From boris.moltchanov at telecomitalia.it Fri Jan 13 10:39:18 2012 From: boris.moltchanov at telecomitalia.it (Moltchanov Boris) Date: Fri, 13 Jan 2012 10:39:18 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: That was a topic of one of my previous emails in this thread: I don't know how and in which component, we may decide and find a solution. For sure if it will be there the FI will win from this, despite of our "special-purpose" existing components. Boris From: Guy Sharon [mailto:GUYSH at il.ibm.com] Sent: Friday, January 13, 2012 10:36 AM 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 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: [cid:image001.jpg at 01CCD1DF.9A505590] and within IBM on: [cid:image002.jpg at 01CCD1DF.9A505590] [cid:image003.jpg at 01CCD1DF.9A505590] [cid:image004.gif at 01CCD1DF.9A505590] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "fano.ramparany at orange.com" >, "Fiware-data at lists.fi-ware.eu" >, "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: [cid:image001.jpg at 01CCD1DF.9A505590] and within IBM on: [cid:image002.jpg at 01CCD1DF.9A505590] [cid:image003.jpg at 01CCD1DF.9A505590] [cid:image004.gif at 01CCD1DF.9A505590] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "fano.ramparany at orange.com" >, "Fiware-data at lists.fi-ware.eu" >, "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: [cid:image001.jpg at 01CCD1DF.9A505590] and within IBM on: [cid:image002.jpg at 01CCD1DF.9A505590] [cid:image003.jpg at 01CCD1DF.9A505590] [cid:image004.gif at 01CCD1DF.9A505590] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: "fano.ramparany at orange.com" >, Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu" >, "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: [cid:image005.jpg at 01CCD1DF.9A505590] 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: [cid:image001.jpg at 01CCD1DF.9A505590] and within IBM on: [cid:image002.jpg at 01CCD1DF.9A505590] [cid:image003.jpg at 01CCD1DF.9A505590] [cid:image004.gif at 01CCD1DF.9A505590] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" > Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu" >, "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 :). 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) [cid:image006.gif at 01CCD1DF.9A505590] 2)[cid:image007.gif at 01CCD1DF.9A505590] 3)[cid:image008.gif at 01CCD1DF.9A505590] 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)[cid:image009.gif at 01CCD1DF.9A505590] 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. [cid:image010.gif at 01CCD1DF.9A505590] 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. [cid:image011.gif at 01CCD1DF.9A505590] 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: [cid:image001.jpg at 01CCD1DF.9A505590] [cid:image012.jpg at 01CCD1DF.9A505590] and within IBM on: [cid:image002.jpg at 01CCD1DF.9A505590] [cid:image003.jpg at 01CCD1DF.9A505590] [cid:image004.gif at 01CCD1DF.9A505590] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: > To: Guy Sharon/Haifa/IBM at IBMIL Cc: >, >, >, > 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: [cid:image013.png at 01CCD1DF.9A505590] Which in the graphical notation corresponds to: [cid:image014.jpg at 01CCD1DF.9A505590] 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 ________________________________ [cid:image015.gif at 01CCD1DF.9A505590] 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. [cid:image016.gif at 01CCD1DF.9A505590]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. [cid:image016.gif at 01CCD1DF.9A505590]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. [cid:image016.gif at 01CCD1DF.9A505590]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. [cid:image016.gif at 01CCD1DF.9A505590]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. [cid:image016.gif at 01CCD1DF.9A505590]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. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 518 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 467 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 494 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.gif Type: image/gif Size: 360 bytes Desc: image004.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 12073 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.gif Type: image/gif Size: 3092 bytes Desc: image006.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.gif Type: image/gif Size: 5210 bytes Desc: image007.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.gif Type: image/gif Size: 3243 bytes Desc: image008.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.gif Type: image/gif Size: 9749 bytes Desc: image009.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.gif Type: image/gif Size: 25563 bytes Desc: image010.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image011.gif Type: image/gif Size: 18440 bytes Desc: image011.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image012.jpg Type: image/jpeg Size: 488 bytes Desc: image012.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.png Type: image/png Size: 9509 bytes Desc: image013.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.jpg Type: image/jpeg Size: 11456 bytes Desc: image014.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.gif Type: image/gif Size: 2558 bytes Desc: image015.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image016.gif Type: image/gif Size: 677 bytes Desc: image016.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From GUYSH at il.ibm.com Fri Jan 13 10:58:20 2012 From: GUYSH at il.ibm.com (Guy Sharon) Date: Fri, 13 Jan 2012 11:58:20 +0200 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: Ok - I think we all understand each other now. So let me try and summarize this long thread. 1. Eventually we would like to have events associated in a well defined structure with entity(ies) and vise versa - as context. 2. "Raw" data \ event \ context may and most probably wont be collected\received as we like it to (above) so there should be some resolution mechanism or a way for each relevant GE to help establish the appropriate structure until it reaches an end consumer. (Some examples were given on 'raw' data interpretation, for example, the least requirement on transforming data\event collected for CEP to process) 3.There is a need to explicitly reason on data and \or events and \ or entities and \ or context and therefore collapsing one into the other and having that as the only means of representing the data is counter productive. Did i miss something? Still something that needs to be agreed on? 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , "fano.ramparany at orange.com" , "Fiware-data at lists.fi-ware.eu" , "jhierro at tid.es" Date: 13/01/2012 11:39 Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition That was a topic of one of my previous emails in this thread: I don?t know how and in which component, we may decide and find a solution. For sure if it will be there the FI will win from this, despite of our ?special-purpose? existing components. Boris From: Guy Sharon [mailto:GUYSH at il.ibm.com] Sent: Friday, January 13, 2012 10:36 AM 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 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , " fano.ramparany at orange.com" , " Fiware-data at lists.fi-ware.eu" , " 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , " fano.ramparany at orange.com" , " Fiware-data at lists.fi-ware.eu" , " 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 To: "fano.ramparany at orange.com" , Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , " Fiware-data at lists.fi-ware.eu" , " 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 To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" < fano.ramparany at orange.com> Cc: Licciardi Carlo Alberto , " Fiware-data at lists.fi-ware.eu" , " 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: To: Guy Sharon/Haifa/IBM at IBMIL Cc: , < carlo.licciardi at telecomitalia.it>, , < 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. 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 12073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 9749 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 25563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 18440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 488 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: From boris.moltchanov at telecomitalia.it Fri Jan 13 11:06:27 2012 From: boris.moltchanov at telecomitalia.it (Moltchanov Boris) Date: Fri, 13 Jan 2012 11:06:27 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: Bingo! :) Exactly in other words. Concluding, we miss a component in the WP - entity resolution, that was the point that we have to start to think of. And I would suggest, but not insist, that the CEP, when connected to the P/S as a provider of the data automatically provides such a conversion if the primary entity (CEP's attribute as entity) is known, as well as do the same conversion backward to an event with an entity attribute when need an entity from P/S that has it represented with an entity. Of course, the reference implementation could be done by anyone, even OpenCall. I remember we already had this exercise with IBM in CCAST, maybe from there. Boris From: Guy Sharon [mailto:GUYSH at il.ibm.com] Sent: Friday, January 13, 2012 10:58 AM 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 Ok - I think we all understand each other now. So let me try and summarize this long thread. 1. Eventually we would like to have events associated in a well defined structure with entity(ies) and vise versa - as context. 2. "Raw" data \ event \ context may and most probably wont be collected\received as we like it to (above) so there should be some resolution mechanism or a way for each relevant GE to help establish the appropriate structure until it reaches an end consumer. (Some examples were given on 'raw' data interpretation, for example, the least requirement on transforming data\event collected for CEP to process) 3.There is a need to explicitly reason on data and \or events and \ or entities and \ or context and therefore collapsing one into the other and having that as the only means of representing the data is counter productive. Did i miss something? Still something that needs to be agreed on? 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: [cid:image001.jpg at 01CCD1E3.64E62ED0] and within IBM on: [cid:image002.jpg at 01CCD1E3.64E62ED0] [cid:image003.jpg at 01CCD1E3.64E62ED0] [cid:image004.gif at 01CCD1E3.64E62ED0] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "fano.ramparany at orange.com" >, "Fiware-data at lists.fi-ware.eu" >, "jhierro at tid.es" > Date: 13/01/2012 11:39 Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition ________________________________ That was a topic of one of my previous emails in this thread: I don't know how and in which component, we may decide and find a solution. For sure if it will be there the FI will win from this, despite of our "special-purpose" existing components. Boris From: Guy Sharon [mailto:GUYSH at il.ibm.com] Sent: Friday, January 13, 2012 10:36 AM 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 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: [cid:image001.jpg at 01CCD1E3.64E62ED0] and within IBM on: [cid:image002.jpg at 01CCD1E3.64E62ED0] [cid:image003.jpg at 01CCD1E3.64E62ED0] [cid:image004.gif at 01CCD1E3.64E62ED0] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "fano.ramparany at orange.com" >, "Fiware-data at lists.fi-ware.eu" >, "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: [cid:image001.jpg at 01CCD1E3.64E62ED0] and within IBM on: [cid:image002.jpg at 01CCD1E3.64E62ED0] [cid:image003.jpg at 01CCD1E3.64E62ED0] [cid:image004.gif at 01CCD1E3.64E62ED0] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "fano.ramparany at orange.com" >, "Fiware-data at lists.fi-ware.eu" >, "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: [cid:image001.jpg at 01CCD1E3.64E62ED0] and within IBM on: [cid:image002.jpg at 01CCD1E3.64E62ED0] [cid:image003.jpg at 01CCD1E3.64E62ED0] [cid:image004.gif at 01CCD1E3.64E62ED0] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: "fano.ramparany at orange.com" >, Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu" >, "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: [cid:image005.jpg at 01CCD1E3.64E62ED0] 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: [cid:image001.jpg at 01CCD1E3.64E62ED0] and within IBM on: [cid:image002.jpg at 01CCD1E3.64E62ED0] [cid:image003.jpg at 01CCD1E3.64E62ED0] [cid:image004.gif at 01CCD1E3.64E62ED0] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: Moltchanov Boris > To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" > Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu" >, "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 :). 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) [cid:image006.gif at 01CCD1E3.64E62ED0] 2)[cid:image007.gif at 01CCD1E3.64E62ED0] 3)[cid:image008.gif at 01CCD1E3.64E62ED0] 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)[cid:image009.gif at 01CCD1E3.64E62ED0] 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. [cid:image010.gif at 01CCD1E3.64E62ED0] 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. [cid:image011.gif at 01CCD1E3.64E62ED0] 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: [cid:image001.jpg at 01CCD1E3.64E62ED0] [cid:image012.jpg at 01CCD1E3.64E62ED0] and within IBM on: [cid:image002.jpg at 01CCD1E3.64E62ED0] [cid:image003.jpg at 01CCD1E3.64E62ED0] [cid:image004.gif at 01CCD1E3.64E62ED0] Haifa University, Mount Carmel Haifa, HA 31905 Israel From: > To: Guy Sharon/Haifa/IBM at IBMIL Cc: >, >, >, > 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: [cid:image013.png at 01CCD1E3.64E62ED0] Which in the graphical notation corresponds to: [cid:image014.jpg at 01CCD1E3.64E62ED0] 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 ________________________________ [cid:image015.gif at 01CCD1E3.64E62ED0] 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. [cid:image016.gif at 01CCD1E3.64E62ED0]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. [cid:image016.gif at 01CCD1E3.64E62ED0]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. [cid:image016.gif at 01CCD1E3.64E62ED0]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. [cid:image016.gif at 01CCD1E3.64E62ED0]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. [cid:image016.gif at 01CCD1E3.64E62ED0]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. [cid:image016.gif at 01CCD1E3.64E62ED0]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. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 518 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 467 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 494 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.gif Type: image/gif Size: 360 bytes Desc: image004.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 12073 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.gif Type: image/gif Size: 3092 bytes Desc: image006.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.gif Type: image/gif Size: 5210 bytes Desc: image007.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.gif Type: image/gif Size: 3243 bytes Desc: image008.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.gif Type: image/gif Size: 9749 bytes Desc: image009.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.gif Type: image/gif Size: 25563 bytes Desc: image010.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image011.gif Type: image/gif Size: 18440 bytes Desc: image011.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image012.jpg Type: image/jpeg Size: 488 bytes Desc: image012.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.png Type: image/png Size: 9509 bytes Desc: image013.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.jpg Type: image/jpeg Size: 11456 bytes Desc: image014.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.gif Type: image/gif Size: 2558 bytes Desc: image015.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image016.gif Type: image/gif Size: 677 bytes Desc: image016.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From GUYSH at il.ibm.com Fri Jan 13 11:20:32 2012 From: GUYSH at il.ibm.com (Guy Sharon) Date: Fri, 13 Jan 2012 12:20:32 +0200 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: Boris - what you suggest between CEP and P/S is not a problem - when we get to implement the integration between the 2 GEs and before - having a discussion, plan and design on how to go about this integration - this should be there as a 'line item'. Looking fwd to make this happen. 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , "fano.ramparany at orange.com" , "Fiware-data at lists.fi-ware.eu" , "jhierro at tid.es" Date: 13/01/2012 12:07 Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Bingo! J Exactly in other words. Concluding, we miss a component in the WP ? entity resolution, that was the point that we have to start to think of. And I would suggest, but not insist, that the CEP, when connected to the P/S as a provider of the data automatically provides such a conversion if the primary entity (CEP?s attribute as entity) is known, as well as do the same conversion backward to an event with an entity attribute when need an entity from P/S that has it represented with an entity. Of course, the reference implementation could be done by anyone, even OpenCall. I remember we already had this exercise with IBM in CCAST, maybe from there. Boris From: Guy Sharon [mailto:GUYSH at il.ibm.com] Sent: Friday, January 13, 2012 10:58 AM 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 Ok - I think we all understand each other now. So let me try and summarize this long thread. 1. Eventually we would like to have events associated in a well defined structure with entity(ies) and vise versa - as context. 2. "Raw" data \ event \ context may and most probably wont be collected\received as we like it to (above) so there should be some resolution mechanism or a way for each relevant GE to help establish the appropriate structure until it reaches an end consumer. (Some examples were given on 'raw' data interpretation, for example, the least requirement on transforming data\event collected for CEP to process) 3.There is a need to explicitly reason on data and \or events and \ or entities and \ or context and therefore collapsing one into the other and having that as the only means of representing the data is counter productive. Did i miss something? Still something that needs to be agreed on? 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , " fano.ramparany at orange.com" , " Fiware-data at lists.fi-ware.eu" , " jhierro at tid.es" Date: 13/01/2012 11:39 Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition That was a topic of one of my previous emails in this thread: I don?t know how and in which component, we may decide and find a solution. For sure if it will be there the FI will win from this, despite of our ?special-purpose? existing components. Boris From: Guy Sharon [mailto:GUYSH at il.ibm.com] Sent: Friday, January 13, 2012 10:36 AM 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 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , " fano.ramparany at orange.com" , " Fiware-data at lists.fi-ware.eu" , " 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , " fano.ramparany at orange.com" , " Fiware-data at lists.fi-ware.eu" , " 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 To: "fano.ramparany at orange.com" , Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , " Fiware-data at lists.fi-ware.eu" , " 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 To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" < fano.ramparany at orange.com> Cc: Licciardi Carlo Alberto , " Fiware-data at lists.fi-ware.eu" , " 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: To: Guy Sharon/Haifa/IBM at IBMIL Cc: , < carlo.licciardi at telecomitalia.it>, , < 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. 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 12073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 9749 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 25563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 18440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 488 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 677 bytes Desc: not available URL: From fano.ramparany at orange.com Fri Jan 13 13:04:06 2012 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Fri, 13 Jan 2012 13:04:06 +0100 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition In-Reply-To: References: Message-ID: So far, this sounds perfect to me. Concrete examples might certainly help avoid any ambiguity or bring up unforeseen issues. Kind regards, Fano De : Guy Sharon [mailto:GUYSH at il.ibm.com] Envoy? : vendredi 13 janvier 2012 10:58 ? : Moltchanov Boris 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 Ok - I think we all understand each other now. So let me try and summarize this long thread. 1. Eventually we would like to have events associated in a well defined structure with entity(ies) and vise versa - as context. 2. "Raw" data \ event \ context may and most probably wont be collected\received as we like it to (above) so there should be some resolution mechanism or a way for each relevant GE to help establish the appropriate structure until it reaches an end consumer. (Some examples were given on 'raw' data interpretation, for example, the least requirement on transforming data\event collected for CEP to process) 3.There is a need to explicitly reason on data and \or events and \ or entities and \ or context and therefore collapsing one into the other and having that as the only means of representing the data is counter productive. Did i miss something? Still something that needs to be agreed on? 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 To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto , "fano.ramparany at orange.com" , "Fiware-data at lists.fi-ware.eu" , "jhierro at tid.es" Date: 13/01/2012 11:39 Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition ________________________________ That was a topic of one of my previous emails in this thread: I don't know how and in which component, we may decide and find a solution. For sure if it will be there the FI will win from this, despite of our "special-purpose" existing components. Boris From: Guy Sharon [mailto:GUYSH at il.ibm.com ] Sent: Friday, January 13, 2012 10:36 AM 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 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 > To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "fano.ramparany at orange.com " >, "Fiware-data at lists.fi-ware.eu " >, "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 > To: Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "fano.ramparany at orange.com " >, "Fiware-data at lists.fi-ware.eu " >, "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 > To: "fano.ramparany at orange.com " >, Guy Sharon/Haifa/IBM at IBMIL Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu " >, "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 > To: Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com " > Cc: Licciardi Carlo Alberto >, "Fiware-data at lists.fi-ware.eu " >, "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: > To: Guy Sharon/Haifa/IBM at IBMIL Cc: >, >, >, > 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. 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 518 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 467 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 494 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.gif Type: image/gif Size: 360 bytes Desc: image004.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 12073 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.gif Type: image/gif Size: 3092 bytes Desc: image006.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.gif Type: image/gif Size: 5210 bytes Desc: image007.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.gif Type: image/gif Size: 3243 bytes Desc: image008.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.gif Type: image/gif Size: 9749 bytes Desc: image009.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.gif Type: image/gif Size: 25563 bytes Desc: image010.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image011.gif Type: image/gif Size: 18440 bytes Desc: image011.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image012.jpg Type: image/jpeg Size: 488 bytes Desc: image012.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.png Type: image/png Size: 9509 bytes Desc: image013.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.jpg Type: image/jpeg Size: 11456 bytes Desc: image014.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.gif Type: image/gif Size: 2558 bytes Desc: image015.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image016.gif Type: image/gif Size: 677 bytes Desc: image016.gif URL: From ralli at tid.es Tue Jan 17 17:33:49 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 17 Jan 2012 17:33:49 +0100 Subject: [Fiware-data] Draft proposal of Data/Context Agenda for Madrid meeting Message-ID: <5108443C-2C8A-4849-BD90-F1D9F9EE5C93@tid.es> Dear WP colleagues, Find enclosed here a first draft proposal of the Data/Context WP agenda for Madrid meeting: *************************************************************************************************** ---> Slot 1a: Data/Context Assets Status (5x30' = 2h 30'). Max Number Attendants: 14. Each Baseline asset should provide a maximum of 8 slides to make a 20' presentation covering: - Key development milestones achieved within Sprints 1, 2 & 3. - Issues/deviations occurred during this period and countermeasure actions. - Status/Roadmap/Considerations regarding alignment with the chapter context: REST API/interfaces, NGSI paradigm. ---> Slot 1b: Data/Context Assets Status (CONT. of Slot 1a). (5x30' = 2h 30'). Max Number Attendants: 14. ---> Slot 2: Architectural Roundtable. Max Number Attendants: 14 (2h 30'). Max Number Attendants: 14 - BigDATA - CEP - P/S Integration. Follow up, continuation and wrap up of previous discussions (1h30') - Middleware and REST APIs (30') - Deliverables Guidelines/Progress (30') ---> Slot 3: UC projects Backlog review (10x15' = 2h 30'). Max Number Attendants: 14 - 10 min discussions per baseline asset regarding assigned UC project tickets. Instead of going one by one, we expect here to collect the overall status, kind of requirements and issues. The feedback provided should be relevant to the cooperation tasks with UC projects (Architecture Board, dissemination, exploitation, etc...) ---> Slot 4: Action Points / Next Steps (Roundtable. 2h30'). Max Number Attendants: 14 - Specific Data/Context AP related to baseline assets, backlog, etc. - How the chapter does/will contribute to dissemination/Standardization/Exploitation/coordination with UC projects, etc - How the chapter does/will increase FIWARE impact with technical presentations, workshops, actions, etc. - Specific chapter actions/ideas for dissemination/technical impact/etc... ? *************************************************************************************************** Should you have feedback or missing key items to be discussed, just drop me an e-mail. What I need from your side at this point is each baseline asset presentation confirmation for slots 1a, 1b and 3 before this Thu evening. (we do not need the presentation files, just the confirmation of your participation). Please, remind that we are scheduling coordination meetings with other WPs too. You can see the overall current status at: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdFVQMzYzOFJvNzFncTR3YjdOVVNTVnc#gid=0 In the same link you can see all previous slots placed in the overall agenda (All on Tue, Wed and Thu). Best regards. - ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 From ralli at tid.es Wed Jan 18 12:46:20 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Wed, 18 Jan 2012 12:46:20 +0100 Subject: [Fiware-data] "D2.3 FI-WARE Architecture" - Placeholder in Data/Context WIKI READY References: <4ED64CCC.3050007@tid.es> Message-ID: <694229A6-C39F-470B-8F3F-EE4BB27A77FF@tid.es> Dear WP Colleagues, In order to start providing your contributions to the above mentioned deliverable, we have just created some placeholders or anchor points in the DATA WIKI. https://forge.fi-ware.eu/plugins/mediawiki/wiki/data/ Do not forget to log in with usual user in the forge, prior to access. The first link points to the deliverables we are contributing, where you will find D2.3 and afterwards the Sections to be completed. Please, let me recall here Juanjo's e-mail on establishing some guidelines and providing a reference example base on CORBA specs. Should you have any question/suggestion, please let me know. Best regards, ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 ------------------------------------------------------------------------------------------------------------------------ -------- Original Message -------- Subject: IMPORTANT: Approach for Architecture Specification Deliverable Date: Wed, 30 Nov 2011 15:38:42 +0100 From: Juanjo Hierro To: fiware-wpl at lists.fi-ware.eu , fiware-wpa at lists.fi-ware.eu Hi all, As you know, we have to start working on the Architecture Specifications, which is one of the deliverables that is due in month 9, that is, end of January. My intention is to adopt a pragmatic approach, trying to generate something that can be integrated as part of the GE Open Specifications that we have to produce by month 12. My vision is that all GE Open Specifications should start with a chapter where an overview of the envisioned Architecture for the GE is described. While style would be narrative, the description should be enough concrete, i.e., formulated over actual data type, interface and operation names and elaborating on the base interaction scenarios involving the different entities exporting the defined interfaces. Then, after that chapter, the detailed specification of all data types and interfaces with their operations, are provided (this including signature of operations and accurate description of expected behaviour linked to operations) Then, the Architecture Specification deliverable would be just the result of developing this overview chapter. But nothing better than an example, so let me use one taken from OMG's set of CORBA Services Specifications. Along my many years involved in different standardization efforts, I have found that OMG CORBA Service specs are rather comprehensive and close to what programmers (our ultimate customers!) love to see. Please find enclosed the CORBA Event Service Specifications. What I would then select as the Architecture description are the contents of the following sections: * The whole chapter 1 * Section 2.2 and 2.4 (which some people may have argued should have been included in chapter 1 :-) Note that anyone who reads the mentioned sections would get a CLEAR picture of what is the Architecture of the service and what are going to be the entities and interfaces/operations that will be supported in a compliant implementation. The conceptual and programming model would be also rather clear from a programmer's perspective. Therefore, rather valuable information for an application developer perspective which is what really should matter to us. A side benefit is that what will remain as pending regarding GE Open Specifications will be less, that is, the detailed specification of data types and interfaces/operations. One thing that we will have to define is the set of conventions that we should all follow whenever we need to draw any figure, like figures 1-x or 2-x. For this, Thomas and me will come soon to you with a proposal in short time. Please take your time to analyze this carefully and formulate any question you may have. From now on, I assume that you will start planning activities in Sprint 2 and 3 dealing with development of these specifications within each of your chapters. This may well take the form of Work Items in the tracker. Best regards, -- Juanjo ________________________________ 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: Event Service Specification 04-10-02.pdf Type: application/pdf Size: 515254 bytes Desc: Event Service Specification 04-10-02.pdf URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001..txt URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From TALI at il.ibm.com Thu Jan 19 14:32:37 2012 From: TALI at il.ibm.com (Tali Yatzkar-Haham) Date: Thu, 19 Jan 2012 15:32:37 +0200 Subject: [Fiware-data] Draft proposal of Data/Context Agenda for Madrid meeting In-Reply-To: <5108443C-2C8A-4849-BD90-F1D9F9EE5C93@tid.es> References: <5108443C-2C8A-4849-BD90-F1D9F9EE5C93@tid.es> Message-ID: Dear WP colleagues, Looking at the agenda, it seems that the Data WP has no meetings on Monday. I would like to check with the BigData and Pub/Sub representatives if some are available for meeting on Monday. This way, we could come with more sound directions for integration between the BigData, Pub/Sub and CEP GEs, since I'm not sure that the 1.5h planned slot in the overall agenda would be sufficient. Best Regards, Tali Yatzkar-Haham Event-based Middleware & Solutions Group IBM Haifa Research Lab Phone: 972-4-829-6320 | Mobile: 972-54-4388482 E-mail: TALI at il.ibm.com Haifa University, Mount Carmel Haifa, 31905 Israel From: CARLOS RALLI UCENDO To: "Fiware-data at lists.fi-ware.eu" Date: 17/01/2012 06:34 PM Subject: [Fiware-data] Draft proposal of Data/Context Agenda for Madrid meeting Sent by: fiware-data-bounces at lists.fi-ware.eu Dear WP colleagues, Find enclosed here a first draft proposal of the Data/Context WP agenda for Madrid meeting: *************************************************************************************************** ---> Slot 1a: Data/Context Assets Status (5x30' = 2h 30'). Max Number Attendants: 14. Each Baseline asset should provide a maximum of 8 slides to make a 20' presentation covering: - Key development milestones achieved within Sprints 1, 2 & 3. - Issues/deviations occurred during this period and countermeasure actions. - Status/Roadmap/Considerations regarding alignment with the chapter context: REST API/interfaces, NGSI paradigm. ---> Slot 1b: Data/Context Assets Status (CONT. of Slot 1a). (5x30' = 2h 30'). Max Number Attendants: 14. ---> Slot 2: Architectural Roundtable. Max Number Attendants: 14 (2h 30'). Max Number Attendants: 14 - BigDATA - CEP - P/S Integration. Follow up, continuation and wrap up of previous discussions (1h30') - Middleware and REST APIs (30') - Deliverables Guidelines/Progress (30') ---> Slot 3: UC projects Backlog review (10x15' = 2h 30'). Max Number Attendants: 14 - 10 min discussions per baseline asset regarding assigned UC project tickets. Instead of going one by one, we expect here to collect the overall status, kind of requirements and issues. The feedback provided should be relevant to the cooperation tasks with UC projects (Architecture Board, dissemination, exploitation, etc...) ---> Slot 4: Action Points / Next Steps (Roundtable. 2h30'). Max Number Attendants: 14 - Specific Data/Context AP related to baseline assets, backlog, etc. - How the chapter does/will contribute to dissemination/Standardization/Exploitation/coordination with UC projects, etc - How the chapter does/will increase FIWARE impact with technical presentations, workshops, actions, etc. - Specific chapter actions/ideas for dissemination/technical impact/etc... ? *************************************************************************************************** Should you have feedback or missing key items to be discussed, just drop me an e-mail. What I need from your side at this point is each baseline asset presentation confirmation for slots 1a, 1b and 3 before this Thu evening. (we do not need the presentation files, just the confirmation of your participation). Please, remind that we are scheduling coordination meetings with other WPs too. You can see the overall current status at: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdFVQMzYzOFJvNzFncTR3YjdOVVNTVnc#gid=0 In the same link you can see all previous slots placed in the overall agenda (All on Tue, Wed and Thu). Best regards. - ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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-data mailing list Fiware-data at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-data -------------- next part -------------- An HTML attachment was scrubbed... URL: From fano.ramparany at orange.com Thu Jan 19 14:40:44 2012 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Thu, 19 Jan 2012 14:40:44 +0100 Subject: [Fiware-data] Draft proposal of Data/Context Agenda for Madridmeeting In-Reply-To: References: <5108443C-2C8A-4849-BD90-F1D9F9EE5C93@tid.es> Message-ID: Hi Tali, I'll be there on Monday. However I'll be attending the ETSI-M2M session organized by the IoT Chapter. I think this session takes place on the afternoon. I'm in a meeting now, so I can't check right now. I'll tell you as soon as I know unless you've access to the FIWARE-IoT schedule. Regards, Fano ________________________________ From: fiware-data-bounces at lists.fi-ware.eu [mailto:fiware-data-bounces at lists.fi-ware.eu] On Behalf Of Tali Yatzkar-Haham Sent: jeudi 19 janvier 2012 14:33 To: CARLOS RALLI UCENDO; Fiware-data at lists.fi-ware.eu Subject: Re: [Fiware-data] Draft proposal of Data/Context Agenda for Madridmeeting Dear WP colleagues, Looking at the agenda, it seems that the Data WP has no meetings on Monday. I would like to check with the BigData and Pub/Sub representatives if some are available for meeting on Monday. This way, we could come with more sound directions for integration between the BigData, Pub/Sub and CEP GEs, since I'm not sure that the 1.5h planned slot in the overall agenda would be sufficient. Best Regards, Tali Yatzkar-Haham Event-based Middleware & Solutions Group IBM Haifa Research Lab ________________________________ Phone: 972-4-829-6320 | Mobile: 972-54-4388482 E-mail: TALI at il.ibm.com Haifa University, Mount Carmel Haifa, 31905 Israel From: CARLOS RALLI UCENDO To: "Fiware-data at lists.fi-ware.eu" Date: 17/01/2012 06:34 PM Subject: [Fiware-data] Draft proposal of Data/Context Agenda for Madrid meeting Sent by: fiware-data-bounces at lists.fi-ware.eu ________________________________ Dear WP colleagues, Find enclosed here a first draft proposal of the Data/Context WP agenda for Madrid meeting: *************************************************************************************************** ---> Slot 1a: Data/Context Assets Status (5x30' = 2h 30'). Max Number Attendants: 14. Each Baseline asset should provide a maximum of 8 slides to make a 20' presentation covering: - Key development milestones achieved within Sprints 1, 2 & 3. - Issues/deviations occurred during this period and countermeasure actions. - Status/Roadmap/Considerations regarding alignment with the chapter context: REST API/interfaces, NGSI paradigm. ---> Slot 1b: Data/Context Assets Status (CONT. of Slot 1a). (5x30' = 2h 30'). Max Number Attendants: 14. ---> Slot 2: Architectural Roundtable. Max Number Attendants: 14 (2h 30'). Max Number Attendants: 14 - BigDATA - CEP - P/S Integration. Follow up, continuation and wrap up of previous discussions (1h30') - Middleware and REST APIs (30') - Deliverables Guidelines/Progress (30') ---> Slot 3: UC projects Backlog review (10x15' = 2h 30'). Max Number Attendants: 14 - 10 min discussions per baseline asset regarding assigned UC project tickets. Instead of going one by one, we expect here to collect the overall status, kind of requirements and issues. The feedback provided should be relevant to the cooperation tasks with UC projects (Architecture Board, dissemination, exploitation, etc...) ---> Slot 4: Action Points / Next Steps (Roundtable. 2h30'). Max Number Attendants: 14 - Specific Data/Context AP related to baseline assets, backlog, etc. - How the chapter does/will contribute to dissemination/Standardization/Exploitation/coordination with UC projects, etc - How the chapter does/will increase FIWARE impact with technical presentations, workshops, actions, etc. - Specific chapter actions/ideas for dissemination/technical impact/etc... ? *************************************************************************************************** Should you have feedback or missing key items to be discussed, just drop me an e-mail. What I need from your side at this point is each baseline asset presentation confirmation for slots 1a, 1b and 3 before this Thu evening. (we do not need the presentation files, just the confirmation of your participation). Please, remind that we are scheduling coordination meetings with other WPs too. You can see the overall current status at: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdFVQMzYzOFJvNzFncTR3YjdOVVNTVnc#gid=0 In the same link you can see all previous slots placed in the overall agenda (All on Tue, Wed and Thu). Best regards. - ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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-data mailing list Fiware-data at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-data -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.fiware1 at tid.es Thu Jan 19 15:46:25 2012 From: e.fiware1 at tid.es (Grant Croker) Date: Thu, 19 Jan 2012 15:46:25 +0100 Subject: [Fiware-data] Draft proposal of Data/Context Agenda for Madrid meeting In-Reply-To: References: <5108443C-2C8A-4849-BD90-F1D9F9EE5C93@tid.es> Message-ID: <4F182CC1.1020808@tid.es> Hi Tali, We'll be there all Monday. With the exception of a meeting from 12.30 til 13.30 we should be free the rest of the day. regards grant El 19/01/2012 14:32, Tali Yatzkar-Haham escribi?: > Dear WP colleagues, > > Looking at the agenda, it seems that the Data WP has no meetings on Monday. > I would like to check with the BigData and Pub/Sub representatives if > some are available for meeting on Monday. > This way, we could come with more sound directions for integration > between the BigData, Pub/Sub and CEP GEs, since I'm not sure that the > 1.5h planned slot in the overall agenda would be sufficient. > > Best Regards, > > *Tali Yatzkar-Haham* > Event-based Middleware & Solutions Group > IBM Haifa Research Lab > ------------------------------------------------------------------------ > *Phone:*972-4-829-6320| *Mobile:*972-54-4388482* > E-mail:*_TALI at il.ibm.com_ > Haifa University, Mount Carmel > Haifa, 31905 > Israel > > > > > > > From: CARLOS RALLI UCENDO > To: "Fiware-data at lists.fi-ware.eu" > Date: 17/01/2012 06:34 PM > Subject: [Fiware-data] Draft proposal of Data/Context Agenda for Madrid > meeting > Sent by: fiware-data-bounces at lists.fi-ware.eu > ------------------------------------------------------------------------ > > > > Dear WP colleagues, > > Find enclosed here a first draft proposal of the Data/Context WP agenda > for Madrid meeting: > > *************************************************************************************************** > ---> Slot 1a: Data/Context Assets Status (5x30' = 2h 30'). Max Number > Attendants: 14. > > Each Baseline asset should provide a maximum of 8 slides to make a 20' > presentation covering: > - Key development milestones achieved within Sprints 1, 2 & 3. > - Issues/deviations occurred during this period and countermeasure actions. > - Status/Roadmap/Considerations regarding alignment with the chapter > context: REST API/interfaces, NGSI paradigm. > > ---> Slot 1b: Data/Context Assets Status (CONT. of Slot 1a). (5x30' = 2h > 30'). Max Number Attendants: 14. > > ---> Slot 2: Architectural Roundtable. Max Number Attendants: 14 (2h > 30'). Max Number Attendants: 14 > - BigDATA - CEP - P/S Integration. Follow up, continuation and wrap up > of previous discussions (1h30') > - Middleware and REST APIs (30') > - Deliverables Guidelines/Progress (30') > > ---> Slot 3: UC projects Backlog review (10x15' = 2h 30'). Max Number > Attendants: 14 > - 10 min discussions per baseline asset regarding assigned UC project > tickets. > Instead of going one by one, we expect here to collect the overall > status, kind of requirements and issues. > The feedback provided should be relevant to the cooperation tasks with > UC projects (Architecture Board, dissemination, exploitation, etc...) > > ---> Slot 4: Action Points / Next Steps (Roundtable. 2h30'). Max Number > Attendants: 14 > - Specific Data/Context AP related to baseline assets, backlog, etc. > - How the chapter does/will contribute to > dissemination/Standardization/Exploitation/coordination with UC > projects, etc > - How the chapter does/will increase FIWARE impact with technical > presentations, workshops, actions, etc. > - Specific chapter actions/ideas for dissemination/technical impact/etc... ? > *************************************************************************************************** > > Should you have feedback or missing key items to be discussed, just drop > me an e-mail. > What I need from your side at this point is each baseline asset > presentation confirmation for slots 1a, 1b and 3 before this Thu evening. > (we do not need the presentation files, just the confirmation of your > participation). > > Please, remind that we are scheduling coordination meetings with other > WPs too. You can see the overall current status at: > https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdFVQMzYzOFJvNzFncTR3YjdOVVNTVnc#gid=0 > > In the same link you can see all previous slots placed in the overall > agenda (All on Tue, Wed and Thu). > > Best regards. > - > ------------------------------------------------------------------------------------------------------------------------ > Carlos Ralli Ucendo (ralli at tid.es) > Cell: +34696923588 > Twitter: @carlosralli > 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-data mailing list > Fiware-data at lists.fi-ware.eu > http://lists.fi-ware.eu/listinfo/fiware-data > > -- -- Grant Croker Telef?nica Digital Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx From ralli at tid.es Fri Jan 20 09:38:33 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Fri, 20 Jan 2012 09:38:33 +0100 Subject: [Fiware-data] Reminder: Data/Context Call now Message-ID: <9913B77D-5D6E-4F47-AAA2-6596D1AEB71D@tid.es> Dear WP Colleagues, We are some of us already connected, please do join us. Thanks, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 From ralli at tid.es Fri Jan 20 09:38:40 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Fri, 20 Jan 2012 09:38:40 +0100 Subject: [Fiware-data] Reminder: Data/Context Call now Message-ID: <7EB9935B-13C9-426D-A944-5F67FECBB5E8@tid.es> Dear WP Colleagues, We are some of us already connected, please do join us. Thanks, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 From ralli at tid.es Fri Jan 20 09:49:44 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Fri, 20 Jan 2012 09:49:44 +0100 Subject: [Fiware-data] Material for the call Message-ID: Hi All, The googledocs with the agenda is here: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdFVQMzYzOFJvNzFncTR3YjdOVVNTVnc#gid=0 Find attached a pdf I've just generated with that excel sheet. ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 -------------- A non-text attachment was scrubbed... Name: Madrid%20Meeting%20Agenda%20-%20Sheet1-1.pdf Type: application/pdf Size: 74918 bytes Desc: Madrid%20Meeting%20Agenda%20-%20Sheet1-1.pdf URL: From fano.ramparany at orange.com Fri Jan 20 10:42:26 2012 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Fri, 20 Jan 2012 10:42:26 +0100 Subject: [Fiware-data] info about the GA Message-ID: Hi Carlos, Just a reminder of a suggestion to have all information (agenda, logistics, phonenumber) about the GA in a single place (e.g. in the same googledoc file). Fano -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcp at tid.es Fri Jan 20 11:01:53 2012 From: mcp at tid.es (Miguel Carrillo) Date: Fri, 20 Jan 2012 11:01:53 +0100 Subject: [Fiware-data] info about the GA In-Reply-To: References: Message-ID: <4F193B91.7090906@tid.es> Hi I do not understand what you mean. Have you not received my messages? I've sent it more that 5 times. If so, you are not on the fiware general mailing list! https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/MadridGeneralAssembly Or you mean anything else? Regards, Miguel El 20/01/2012 10:42, fano.ramparany at orange.com escribi?: Hi Carlos, Just a reminder of a suggestion to have all information (agenda, logistics, phonenumber) about the GA in a single place (e.g. in the same googledoc file). Fano -- ---------------------------------------------------------------------- _/ _/_/ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fano.ramparany at orange.com Fri Jan 20 11:12:33 2012 From: fano.ramparany at orange.com (fano.ramparany at orange.com) Date: Fri, 20 Jan 2012 11:12:33 +0100 Subject: [Fiware-data] info about the GA In-Reply-To: <4F193B91.7090906@tid.es> References: <4F193B91.7090906@tid.es> Message-ID: Thank you, this is perfect. I knew it of course, but I hadn't it in mind when somebody at the WP6 PhC meeting this morning, asked about how to get the phonenumber of the participants. So I just added, in the "Agenda" section this line: There's a second sheet in the Google docs with participants contact information that you can provide if you want. Kind regards, Fano De : Miguel Carrillo [mailto:mcp at tid.es] Envoy? : vendredi 20 janvier 2012 11:02 ? : RAMPARANY Fano RD-TECH-GRE Cc : CARLOS RALLI UCENDO; Fiware-data at lists.fi-ware.eu Objet : Re: info about the GA Hi I do not understand what you mean. Have you not received my messages? I've sent it more that 5 times. If so, you are not on the fiware general mailing list! https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/MadridGeneralAssembly Or you mean anything else? Regards, Miguel El 20/01/2012 10:42, fano.ramparany at orange.com escribi?: Hi Carlos, Just a reminder of a suggestion to have all information (agenda, logistics, phonenumber) about the GA in a single place (e.g. in the same googledoc file). Fano -- ---------------------------------------------------------------------- _/ _/_/ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralli at tid.es Fri Jan 20 11:33:42 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Fri, 20 Jan 2012 11:33:42 +0100 Subject: [Fiware-data] Minutes of today's Data/Context Follow-up Call Message-ID: Dear WP colleagues, I have just uploaded the minutes of today's call: https://forge.fi-ware.eu/docman/view.php/9/735/20120120_Data-Context-Minutes.doc (Just remind to be logged in, prior to access the file with this link) I encourage Thales and Telecom Italia not present in the conference to have a look to this file to understand the overall picture of our meetings next week. Thanks to all present today for your contributions and help to go on. Best regards -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 From mcp at tid.es Fri Jan 20 14:48:14 2012 From: mcp at tid.es (Miguel Carrillo) Date: Fri, 20 Jan 2012 14:48:14 +0100 Subject: [Fiware-data] info about the GA In-Reply-To: References: <4F193B91.7090906@tid.es> Message-ID: <4F19709E.10708@tid.es> Ah, I understand now. Ok, fine! Thanks. Have a nice week and a safe journey to Madrid. Miguel El 20/01/2012 11:12, fano.ramparany at orange.com escribi?: Thank you, this is perfect. I knew it of course, but I hadn?t it in mind when somebody at the WP6 PhC meeting this morning, asked about how to get the phonenumber of the participants. So I just added, in the ?Agenda? section this line: There's a second sheet in the Google docs with participants contact information that you can provide if you want. Kind regards, Fano De : Miguel Carrillo [mailto:mcp at tid.es] Envoy? : vendredi 20 janvier 2012 11:02 ? : RAMPARANY Fano RD-TECH-GRE Cc : CARLOS RALLI UCENDO; Fiware-data at lists.fi-ware.eu Objet : Re: info about the GA Hi I do not understand what you mean. Have you not received my messages? I've sent it more that 5 times. If so, you are not on the fiware general mailing list! https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/MadridGeneralAssembly Or you mean anything else? Regards, Miguel El 20/01/2012 10:42, fano.ramparany at orange.com escribi?: Hi Carlos, Just a reminder of a suggestion to have all information (agenda, logistics, phonenumber) about the GA in a single place (e.g. in the same googledoc file). Fano -- ---------------------------------------------------------------------- _/ _/_/ 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 -- ---------------------------------------------------------------------- _/ _/_/ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcp at tid.es Fri Jan 20 18:53:14 2012 From: mcp at tid.es (Miguel Carrillo) Date: Fri, 20 Jan 2012 18:53:14 +0100 Subject: [Fiware-data] Inscription to the Social Event In-Reply-To: <4F105890.7080000@tid.es> References: <4F105890.7080000@tid.es> Message-ID: <4F19AA0A.7070704@tid.es> Dear all, Just a kind reminder. You can join the social event that will take place in Wednesday. See the instructions underneath. Something that I have been asked repeatedly. that needs clarifying: * TID will invite to the lunches at the canteen. * Each one will need to pay for the Social Event (30 eur - it's quite reasonable if you see what they offer) I hope to see you all there. In any case, see you in Madrid!!! Miguel -------- Mensaje original -------- Asunto: Inscription to the Social Event Fecha: Fri, 13 Jan 2012 17:15:12 +0100 De: Miguel Carrillo A: fiware-wpl at lists.fi-ware.eu , fiware-wpa at lists.fi-ware.eu CC: fiware at lists.fi-ware.eu, JAVIER DE PEDRO SANCHEZ Dear all, The social event will take place on Wednesday the 25th at 9pm. We have looked for a reasonably priced and typical spot very near the Spanish Parlament in a quaint area of the town. We need numbers to book the place in advance. As you can guess, it is somewhat complicated to find room for so many people. Those who are going to make it please put your name & company on the following link. If someone really really has a problem with any type of food (for religious matters, allergies or whatever) there is an extra field to state it and we will ensure that he/she finds an acceptable alternative. The deadline to provide this info is Monday, the 23rd at 11am. Those not providing this info on time will have no guarantee of having a place at the table. * Inscription to the Social Event Details (also reflected on https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/MadridGeneralAssembly#Social_event in the private wiki): Date: January, 25 Time: 9:00 pm Venue: Restaurante Villagodio (http://restaurantevillagodio.com) Price: 30 eur Menu: STARTERS (1 plate of each to share between 4 people) Spanish ham and manchego cheese Red pepper stuffed with calamari and prawns Grilled Mushrooms Lac?n (a type of ham) Torreznos (fried fat, Spanish style, quite nice!) Grilled praws with salt Grilled ribs MAIN COURSE (one to choose) Baked Gilthead (bream) Baked Turbot Ox Entrec?te Entra?a (a type of meat) This includes french bread, desserts and coffee Drinks: included up to 2 beers or 2 soft drinks or half a bottle of wine per person If you need further details I am at your disposal. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralli at tid.es Sun Jan 22 22:48:03 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Sun, 22 Jan 2012 22:48:03 +0100 Subject: [Fiware-data] Final Data/Context Agenda Message-ID: <53E5A5D4-809C-454D-8067-3ABC77052C2B@tid.es> Dear WP Colleagues, As you know you can see in the overall Agenda of Madrid meeting (including assigned meeting rooms until Wednesday) at: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdFVQMzYzOFJvNzFncTR3YjdOVVNTVnc#gid=0 Regarding Data/Context Management, find hereby the final version: **** Data/Context meetings: ----> Slot 0: BigDATA - CEP - P/S Integration 2h. We scheduled this one for Monday 10:00-12:30 but We have moved it to: Tuesday morning (10:00 - 12:30) so that TI may participate now. ---> Slot 1a/1b: Data/Context Assets Status (5h). Max Number Attendants: 14. (2h on Monday 10:00-12:30 + 3h on Tuesday 14:00-17:30) Each Baseline asset should provide a maximum of 8 slides to make a 20' presentation covering: - Key development milestones achieved within Sprints 1, 2 & 3. - Issues/deviations occurred during this period and countermeasure actions. - Status/Roadmap/Considerations regarding alignment with the chapter context: REST API/interfaces, NGSI paradigm. Confirmed Slots: CEP-Tali-IBM, PubSub-Fano-Orange, Query-Broker;Metadata-preprocessing;MMAnalysis-Peter-Siemens, BigData-Telefonica ---> Slot 2: Architectural Roundtable. Max Number Attendants: 14 (3h). Max Number Attendants: 14 (Now on Monday 14:00 - 17:30) Middleware, REST APIs and "How we could develop dummy use-cases" (1h30 +10 min wrap up). 50 minutes at the end should be enough to review deliverables progress (mainly focused on D2.3). ---> Slot 3: UC projects Backlog review (2h). Max Number Attendants: 14 (Now on Wed 14-15h + Thu 11:30-12:30) 10 min discussions per baseline asset regarding assigned UC project tickets. Instead of going one by one, we expect here to collect the overall status, kind of requirements and issues. The feedback provided should be relevant to the cooperation tasks with UC projects (Architecture Board, dissemination, exploitation, etc.) ---> Slot 4: Action Points / Next Steps (Roundtable. 3h'). Max Number Attendants: 14 (Now 2h on Thu 14:00-17:30) We should be able to cover here: - Needs for the FI-WARE testbed (45') - Sprint 3 retrospective and Planning of Sprint 4 (45') - Standardization Plan (30') - How the chapter does/will contribute to dissemination & exploitation (30') How the chapter does/will increase FIWARE impact with technical presentations, workshops, actions, etc. **** Meetings with other WPs (Check dates in the googledoc above linked). -> Apps: Interface with apps, marketplace, make sure on a uniform way to invoke/treat data by apps -> IoT: Gathering massive data from sensors/devices, issue of their solutions overlapping CEP, PubSub, Data ... -> Tools: We will be told what is needed from each baseline asset to build a framework of tools for "FI-WARE developers" (plugin of Eclipse to build a set of tools up). Providing there is enough time, we might kick-off with a specific example. -> Cloud: Monitoring, Scaling. (TBC) Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli Telef?nica I+D SAU Madrid, Spain ------------------------------------------------------------------------------------------------------------------------ Follow FI-WARE project (Future Internet Services Core Platform): Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: @fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ------------------------------------------------------------------------------------------------------------------------ ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralli at tid.es Mon Jan 23 10:48:46 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 23 Jan 2012 10:48:46 +0100 Subject: [Fiware-data] [Suspected Spam] Our meeting now is at Building East 1, floor 0, room 61 + link for minutes Message-ID: <32A08677-EB6A-43A5-9A4F-BD1450040446@tid.es> Dear WP Colleagues, Find hereby the link to the minutes in Googledoc: https://docs.google.com/document/d/1Nzdav43evbNgoxWVW7fA0qb-flG0JUiIn6eyI85tV6U/edit We have not started as most attendees have not arrived yet. Our plan is to wait until 11AM and no more partners arrive we will delay slot 1a for the next slot and we will have some sort of initial BigData/PubSub/CEP discussions. If you arrive to Telef?nica City, do call me at +34696923588. Thanks, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 From jose.fuentesl at atosresearch.eu Mon Jan 23 11:39:18 2012 From: jose.fuentesl at atosresearch.eu (Jose Maria Fuentes Lopez) Date: Mon, 23 Jan 2012 11:39:18 +0100 Subject: [Fiware-data] [Suspected Spam] Our meeting now is at Building East 1, floor 0, room 61 + link for minutes In-Reply-To: <32A08677-EB6A-43A5-9A4F-BD1450040446@tid.es> References: <32A08677-EB6A-43A5-9A4F-BD1450040446@tid.es> Message-ID: <899C2CC8F93F6C46A7187C81852522933D7B65@INTMAIL03.es.int.atosorigin.com> Dear Carlos, all According to agenda sent on 20/01 there were not Data/Context sessions scheduled for today. It seems to me that agenda was rescheduled on last Friday telco. I sent you and email explaining that we couldn't attend to this telco, and asking about its content. I still do not know if you receive it as we had no answer. Finally, I have got the minutes of the telco on 22/01, including the changes in the agenda. Unfortunately, I will not be able to join the sessions today because of previous commitments. I will join tomorrow morning. Bests, Chema Fuentes. -----Original Message----- From: fiware-data-bounces at lists.fi-ware.eu [mailto:fiware-data-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: lunes, 23 de enero de 2012 10:49 To: Fiware-data at lists.fi-ware.eu Subject: [Fiware-data] [Suspected Spam] Our meeting now is at Building East 1, floor 0, room 61 + link for minutes Dear WP Colleagues, Find hereby the link to the minutes in Googledoc: https://docs.google.com/document/d/1Nzdav43evbNgoxWVW7fA0qb-flG0JUiIn6eyI85tV6U/edit We have not started as most attendees have not arrived yet. Our plan is to wait until 11AM and no more partners arrive we will delay slot 1a for the next slot and we will have some sort of initial BigData/PubSub/CEP discussions. If you arrive to Telef?nica City, do call me at +34696923588. Thanks, Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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-data mailing list Fiware-data at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-data ------------------------------------------------------------------ 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. ------------------------------------------------------------------ From ralli at tid.es Tue Jan 24 17:42:53 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Tue, 24 Jan 2012 17:42:53 +0100 Subject: [Fiware-data] Reminder: Data meeting minutes Message-ID: Dear WP colleagues, Just to remind you that all minutes of Data meetings during these days are available at: https://docs.google.com/document/d/1Nzdav43evbNgoxWVW7fA0qb-flG0JUiIn6eyI85tV6U/edit You can see the are the minutes of Data-Apps meeting. I have just made a local copy in my laptop as back-up. I suggest you have a look at them and improve the parts related to your assets, comments, etc. However, if you feel any decision or action point is not correct, please do not update and let me know first incase we need further clarifications/discussions. Thanks for your cooperation. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 From boris.moltchanov at telecomitalia.it Thu Jan 26 16:16:06 2012 From: boris.moltchanov at telecomitalia.it (Moltchanov Boris) Date: Thu, 26 Jan 2012 16:16:06 +0100 Subject: [Fiware-data] "D2.3 FI-WARE Architecture" - Placeholder in Data/Context WIKI READY In-Reply-To: <694229A6-C39F-470B-8F3F-EE4BB27A77FF@tid.es> References: <4ED64CCC.3050007@tid.es> <694229A6-C39F-470B-8F3F-EE4BB27A77FF@tid.es> Message-ID: Hi Carlos, I logged me in and tried to open that placeholder again and got again page-not-found. What's up? BR, Boris From: fiware-data-bounces at lists.fi-ware.eu [mailto:fiware-data-bounces at lists.fi-ware.eu] On Behalf Of CARLOS RALLI UCENDO Sent: Wednesday, January 18, 2012 12:46 PM To: Fiware-data at lists.fi-ware.eu Subject: [Fiware-data] "D2.3 FI-WARE Architecture" - Placeholder in Data/Context WIKI READY Dear WP Colleagues, In order to start providing your contributions to the above mentioned deliverable, we have just created some placeholders or anchor points in the DATA WIKI. https://forge.fi-ware.eu/plugins/mediawiki/wiki/data/ Do not forget to log in with usual user in the forge, prior to access. The first link points to the deliverables we are contributing, where you will find D2.3 and afterwards the Sections to be completed. Please, let me recall here Juanjo's e-mail on establishing some guidelines and providing a reference example base on CORBA specs. Should you have any question/suggestion, please let me know. Best regards, ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 ------------------------------------------------------------------------------------------------------------------------ -------- Original Message -------- Subject: IMPORTANT: Approach for Architecture Specification Deliverable Date: Wed, 30 Nov 2011 15:38:42 +0100 From: Juanjo Hierro To: fiware-wpl at lists.fi-ware.eu , fiware-wpa at lists.fi-ware.eu Hi all, As you know, we have to start working on the Architecture Specifications, which is one of the deliverables that is due in month 9, that is, end of January. My intention is to adopt a pragmatic approach, trying to generate something that can be integrated as part of the GE Open Specifications that we have to produce by month 12. My vision is that all GE Open Specifications should start with a chapter where an overview of the envisioned Architecture for the GE is described. While style would be narrative, the description should be enough concrete, i.e., formulated over actual data type, interface and operation names and elaborating on the base interaction scenarios involving the different entities exporting the defined interfaces. Then, after that chapter, the detailed specification of all data types and interfaces with their operations, are provided (this including signature of operations and accurate description of expected behaviour linked to operations) Then, the Architecture Specification deliverable would be just the result of developing this overview chapter. But nothing better than an example, so let me use one taken from OMG's set of CORBA Services Specifications. Along my many years involved in different standardization efforts, I have found that OMG CORBA Service specs are rather comprehensive and close to what programmers (our ultimate customers!) love to see. Please find enclosed the CORBA Event Service Specifications. What I would then select as the Architecture description are the contents of the following sections: * The whole chapter 1 * Section 2.2 and 2.4 (which some people may have argued should have been included in chapter 1 :-) Note that anyone who reads the mentioned sections would get a CLEAR picture of what is the Architecture of the service and what are going to be the entities and interfaces/operations that will be supported in a compliant implementation. The conceptual and programming model would be also rather clear from a programmer's perspective. Therefore, rather valuable information for an application developer perspective which is what really should matter to us. A side benefit is that what will remain as pending regarding GE Open Specifications will be less, that is, the detailed specification of data types and interfaces/operations. One thing that we will have to define is the set of conventions that we should all follow whenever we need to draw any figure, like figures 1-x or 2-x. For this, Thomas and me will come soon to you with a proposal in short time. Please take your time to analyze this carefully and formulate any question you may have. From now on, I assume that you will start planning activities in Sprint 2 and 3 dealing with development of these specifications within each of your chapters. This may well take the form of Work Items in the tracker. Best regards, -- Juanjo ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000001 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_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From ralli at tid.es Thu Jan 26 18:08:47 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Thu, 26 Jan 2012 18:08:47 +0100 Subject: [Fiware-data] Madrid meetings Data/Contetx Minutes + Action Points Message-ID: Dear colleagues, Find the minutes of the sessions during these days (also available as a googledoc) at: https://docs.google.com/document/d/1Nzdav43evbNgoxWVW7fA0qb-flG0JUiIn6eyI85tV6U/edit Please, read them carefully and note that APs at the end are just high-level APs and there are more within each slot minutes. Thanks for your participation and nice discussions. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 -------------- A non-text attachment was scrubbed... Name: FI-WAREDataContextManagementChapterminutes-8.doc Type: application/msword Size: 101376 bytes Desc: FI-WAREDataContextManagementChapterminutes-8.doc URL: From ralli at tid.es Fri Jan 27 09:02:25 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Fri, 27 Jan 2012 09:02:25 +0100 Subject: [Fiware-data] Madrid meetings Data/Contetx Minutes + Action Points Message-ID: Dear colleagues, Find the minutes of the sessions during these days (also available as a googledoc) at: https://docs.google.com/document/d/1Nzdav43evbNgoxWVW7fA0qb-flG0JUiIn6eyI85tV6U/edit Please, read them carefully and note that APs at the end are just high-level APs and there are more within each slot minutes. Thanks f Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 -------------- A non-text attachment was scrubbed... Name: FI-WAREDataContextManagementChapterminutes-8.doc Type: application/msword Size: 101376 bytes Desc: FI-WAREDataContextManagementChapterminutes-8.doc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-WAREDataContextManagementChapterminutes-8.doc Type: application/msword Size: 101376 bytes Desc: FI-WAREDataContextManagementChapterminutes-8.doc URL: From e.fiware1 at tid.es Thu Jan 26 16:13:36 2012 From: e.fiware1 at tid.es (Grant Croker) Date: Thu, 26 Jan 2012 16:13:36 +0100 Subject: [Fiware-data] FMC models for the Architecture Specification [Was RV: [tid-fiware] Fwd: GUIDELINE: FI-WARE Architecture Specifications: proposed solution for some of the pending questions] Message-ID: <000901ccdc3d$136d7cc0$3a487640$%fiware1@tid.es> As discussed during the Architectural Specification meeting, Thursday 25/1 De: fiware-bounces at tid.es [mailto:fiware-bounces at tid.es] En nombre de Juanjo Hierro Enviado el: mi?rcoles, 07 de diciembre de 2011 10:39 Para: fiware at tid.es Asunto: [tid-fiware] Fwd: GUIDELINE: FI-WARE Architecture Specifications: proposed solution for some of the pending questions FYI -------- Original Message -------- Subject: GUIDELINE: FI-WARE Architecture Specifications: proposed solution for some of the pending questions Date: Wed, 07 Dec 2011 08:55:25 +0100 From: Juanjo Hierro To: fiware-wpl at lists.fi-ware.eu , fiware-wpa at lists.fi-ware.eu Hi all, On Nov 30th, I sent a detailed email describing how I think we should approach development of the next major deliverable, i.e., the deliverable on FI-WARE Architecture Specifications. I hope that all of you had already read carefully its contents so that we all are on the same page. There were two questions that were pending to solve before starting the actual writing of the deliverable on the Wiki. I elaborate on the proposed approach for both of them here. 1. Conventions for figures to include in Architecture Specifications In order to get an harmonized set of specifications a convention for figures describing aspects of the Functional Architecture linked to a GE has to be adopted. After some analysis, Thomas and me have decided to propose following FMC conventions for "Block Diagrams - Compositional Structures" defined in [1]. Note that the adoption of FMC conventions is limited to these Block Diagrams. Rest is not mandatory at all (nor indeed needed for this deliverable). Unless we hear about any objection, this will be the adopted recommendation you should forward to your teams. The gallery of basic elements used in FMC Block Diagrams is pretty simple, so I'm sure you could use any of your favorite editing tools for creating Architecture Description Diagrams, even powerpoint. For those who may not want to use powerpoint but a drawing tool that is better tailored to draw Diagrams, we may recommend yED (see [2]) 2. Uploading contents on the Wiki As already explained in one of my previous mails in response to a question made by Torsten, we will definitively go for developing contents of this deliverable on the Wiki. Therefore, one of the questions we should answer first is where on the Wiki. Here you are a list of points that describe the approach I suggest we should follow: * A new entry on the main home page of the FI-WARE Wiki will be created titled "FI-WARE Architecture". This will lead to a Wiki page were we will provide: * a short introduction of the goal of the Architecture Specifications * links to specific Wiki pages, one per chapter of FI-WARE. Each of these Wiki pages will be structured so that it includes an Introduction section (we will decide what comes here later) and a section per GE who should follow the structure we described in the email I sent on Nov 30 (note that the CORBA Event Service example I provided would map to the concept of a single GE in FI-WARE like the Pub/Sub Broker GE) * a link to a Wiki page to be titled "Bringing all pieces together", were we will elaborate on the description of how the different chapters will connect together from an architectural point of view, serving example (but generic) use case scenarios. * We should include a section titled "Open Specifications" at each of the GE sections we have under the "Materializing the FI-WARE Vision" part of the Wiki. This section will contain a bullet list of two items, each one linking to a Wiki page. The first one will be titled "Architecture Specification" and the second one will be titled "Detailed Interface Specifications". The first one will be a direct link to the section dedicated to the GE under the "FI-WARE Architecture" part of the Wiki described in the point above (note this will allow to navigate to concrete GE Architecture Specifications from the "Materializing the FI-WARE Vision" part of the Wiki, but that is precisely something we want to achieve). The second one will be where the detailed description of what remains regarding the complete set of Open Specifications linked to a GE, that is, the detailed description (signature and behaviour description of provided APIs, definition of protocols, non-functional mandatory features, etc) of interfaces introduced in the Architecture Specification. A draft of the guidelines, based on the above descriptive text, will be made soon available on the FI-WARE Project Handbook available on the Wiki. Please don't hesitate to make any question or formulate any doubt so that answers can help to enrich the guidelines. Please share this email with members of your team. Cheers, -- Juanjo References: [1] - http://www.fmc-modeling.org/notation_reference [2] - http://www.yworks.com/en/products_yed_about.html ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From e.fiware1 at tid.es Thu Jan 26 16:43:45 2012 From: e.fiware1 at tid.es (Grant Croker) Date: Thu, 26 Jan 2012 16:43:45 +0100 Subject: [Fiware-data] FMC modeling software [Was:Fwd: RV: [tid-fiware] Fwd: GUIDELINE: FI-WARE Architecture Specifications: proposed solution for some of the pending questions] In-Reply-To: <2A6B76AF12C9794683898EA4B720C52E02F0BA4AF26D@SRV-MADMX.mad.tecsidel.es> References: <2A6B76AF12C9794683898EA4B720C52E02F0BA4AF26D@SRV-MADMX.mad.tecsidel.es> Message-ID: <4F2174B1.7000709@tid.es> As discussed in the Arch meeting in Madrid on 25/1 -------- Mensaje original -------- Asunto: RV: [tid-fiware] Fwd: GUIDELINE: FI-WARE Architecture Specifications: proposed solution for some of the pending questions Fecha: Thu, 26 Jan 2012 16:06:27 +0100 De: Croker, Grant Para: e.fiware1 *De:*fiware-bounces at tid.es [mailto:fiware-bounces at tid.es] *En nombre de *Juanjo Hierro *Enviado el:* mi?rcoles, 07 de diciembre de 2011 10:39 *Para:* fiware at tid.es *Asunto:* [tid-fiware] Fwd: GUIDELINE: FI-WARE Architecture Specifications: proposed solution for some of the pending questions FYI -------- Original Message -------- *Subject: * GUIDELINE: FI-WARE Architecture Specifications: proposed solution for some of the pending questions *Date: * Wed, 07 Dec 2011 08:55:25 +0100 *From: * Juanjo Hierro *To: * fiware-wpl at lists.fi-ware.eu , fiware-wpa at lists.fi-ware.eu Hi all, On Nov 30th, I sent a detailed email describing how I think we should approach development of the next major deliverable, i.e., the deliverable on FI-WARE Architecture Specifications. I hope that all of you had already read carefully its contents so that we all are on the same page. There were two questions that were pending to solve before starting the actual writing of the deliverable on the Wiki. I elaborate on the proposed approach for both of them here. 1. Conventions for figures to include in Architecture Specifications In order to get an harmonized set of specifications a convention for figures describing aspects of the Functional Architecture linked to a GE has to be adopted. After some analysis, Thomas and me have decided to propose following FMC conventions for "Block Diagrams - Compositional Structures" defined in [1]. Note that the adoption of FMC conventions is limited to these Block Diagrams. Rest is not mandatory at all (nor indeed needed for this deliverable). Unless we hear about any objection, this will be the adopted recommendation you should forward to your teams. The gallery of basic elements used in FMC Block Diagrams is pretty simple, so I'm sure you could use any of your favorite editing tools for creating Architecture Description Diagrams, even powerpoint. For those who may not want to use powerpoint but a drawing tool that is better tailored to draw Diagrams, we may recommend yED (see [2]) 2. Uploading contents on the Wiki As already explained in one of my previous mails in response to a question made by Torsten, we will definitively go for developing contents of this deliverable on the Wiki. Therefore, one of the questions we should answer first is where on the Wiki. Here you are a list of points that describe the approach I suggest we should follow: * A new entry on the main home page of the FI-WARE Wiki will be created titled "FI-WARE Architecture". This will lead to a Wiki page were we will provide: o a short introduction of the goal of the Architecture Specifications o links to specific Wiki pages, one per chapter of FI-WARE. Each of these Wiki pages will be structured so that it includes an Introduction section (we will decide what comes here later) and a section per GE who should follow the structure we described in the email I sent on Nov 30 (note that the CORBA Event Service example I provided would map to the concept of a single GE in FI-WARE like the Pub/Sub Broker GE) o a link to a Wiki page to be titled "Bringing all pieces together", were we will elaborate on the description of how the different chapters will connect together from an architectural point of view, serving example (but generic) use case scenarios. * We should include a section titled "Open Specifications" at each of the GE sections we have under the "Materializing the FI-WARE Vision" part of the Wiki. This section will contain a bullet list of two items, each one linking to a Wiki page. The first one will be titled "Architecture Specification" and the second one will be titled "Detailed Interface Specifications". The first one will be a direct link to the section dedicated to the GE under the "FI-WARE Architecture" part of the Wiki described in the point above (note this will allow to navigate to concrete GE Architecture Specifications from the "Materializing the FI-WARE Vision" part of the Wiki, but that is precisely something we want to achieve). The second one will be where the detailed description of what remains regarding the complete set of Open Specifications linked to a GE, that is, the detailed description (signature and behaviour description of provided APIs, definition of protocols, non-functional mandatory features, etc) of interfaces introduced in the Architecture Specification. A draft of the guidelines, based on the above descriptive text, will be made soon available on the FI-WARE Project Handbook available on the Wiki. Please don't hesitate to make any question or formulate any doubt so that answers can help to enrich the guidelines. Please share this email with members of your team. Cheers, -- Juanjo References: [1] - http://www.fmc-modeling.org/notation_reference [2] - http://www.yworks.com/en/products_yed_about.html 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 embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From ralli at tid.es Mon Jan 30 23:42:41 2012 From: ralli at tid.es (CARLOS RALLI UCENDO) Date: Mon, 30 Jan 2012 23:42:41 +0100 Subject: [Fiware-data] Fwd: [Fiware-wpa] Contributions to testbed References: Message-ID: <8ACCF214-D374-4614-9674-4CB5B85E28DD@tid.es> Dear WP Colleagues, Stefano is asking all assets in all WPs to fill in the Wiki form for the testbed available at: https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/FI-WARE_Testbed_Fact_Finding_Investigation For Data/Context I filled it with the organization name of the main assets and my colleague Grant made the work for BigData/Samson row. Let me ask you now to complete the rows related with your assets. If you are also providing an asset and I did not identify you as owner, please complete it too. Please, note deadline is end of this week. However it shouldn't take so much time for you to do it. Thanks in advance. Best regards, -- ------------------------------------------------------------------------------------------------------------------------ Carlos Ralli Ucendo (ralli at tid.es) Cell: +34696923588 Twitter: @carlosralli 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 ------------------------------------------------------------------------------------------------------------------------ Inicio del mensaje reenviado: De: stefano de panfilis > Fecha: 29 de enero de 2012 17:26:33 GMT+01:00 Para: "fiware-wpl at lists.fi-ware.eu" >, "fiware-wpa at lists.fi-ware.eu" >, "fiware-testbed at lists.fi-ware.eu" > Asunto: [Fiware-wpa] Contributions to testbed dear all, first of all let me thank you those who promptly provided the needed info for setting-up the testbed and participated in very interesting and constructive discussions giving us, wp10 team, important feedback for our work. as also said during various meetings the last days in madrid, the questions we put forward to all of you have been fine tuned, so even for those who already provided the info, please check them again. but certainly this email is mostly addressed to whom as Apps, IoT, and Data provided very little info even if any!!! i really ask you to fill promptly, and certainly within this week (3 feb 2012), the required info. i kindly ask the help of wp10 team members to check for their colleagues in other wps to provide the info. in order to provide the info please go to the wp10 wiki (https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/FI-WARE_Testbed_Fact_Finding_Investigation) where you have the questions and the already provided answers. what is red is what is missing!!! for your convenience you can send me your inputs also in text form or with the attached excel file, but please send it! anyway, on 10 feb the testbed design deliverable v1 will be released to the ec with the info i'll have at the moment. please consider that the deliverable is a matching between yours ges and the testbed components (both hw and sw), so without your inputs it is impossible to do such matching. i'm sure of your understanding. 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 ________________________________ 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: GE_HW_req_20120126.xlsx Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet Size: 18000 bytes Desc: GE_HW_req_20120126.xlsx URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001..txt URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcp at tid.es Tue Jan 31 11:52:40 2012 From: mcp at tid.es (Miguel Carrillo) Date: Tue, 31 Jan 2012 11:52:40 +0100 Subject: [Fiware-data] Owners of GEs in the Data Chapter Message-ID: <4F27C7F8.40608@tid.es> Dear Data Chapter partners, We need to have identified the owners of the GEs on the Testbed wiki. Please each one of you check and fill in the "organisation" column specifying the enablers that each company owns in the Data Chapter. The link is here: * https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/FI-WARE_Testbed_Fact_Finding_Investigation#WP6_Data Those with no access to this link may need to apply for access (see enclosed message) This comes a bit late, it should have been finished by monday (yesterday) and it takes a minute! So please proceed asap. The other columns must be filled in by the end of the week, I assume that Carlos will instruct you to do so in due course. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: Miguel Carrillo Subject: Access to Testbed wiki (and other wikis in general) Date: Tue, 31 Jan 2012 09:53:23 +0100 Size: 6201 URL: