Good idea to start drawing things. But this is far from what I was trying to convey. In fact, I now understand that we need to touch \ sync on a fundamental point about events. Events must be treated as first class citizens in models and transports - not incorporated into entities\things and collapsed into properties rather they should exist alongside entities and may be associated with entities. I will try to give an example through three cases - 1) the simple one with the boiler, 2) an event to many entities with a check deposit, and 3) many events to one entity with the TVSet. If needed a drawing board and a discussion could be a good idea to resolve this in Madrid. First a simplified ontology view of the three cases 1) 2) 3) Now lets look at how an event then should be represented as in the Vision of the chapter and how they would be stored or communicated versus entities. 1) These may actually be 2 different views on all the data that gets collected (repository) First view through the eye of an entity - you would see all the temperature values over time Second view through the eye of an event - you would see all the TemperatureMeasured events over time and what temperature reading they provided to what Boiler 2) Here - it is IMPORTANT to keep all the 'properties' of the event together (even though they are associated to different entities) for proper event processing - this is for some event processing implementation a real big issue when they decouple especially when you need to reason over the events and not over the entities it may have been associated with. These may actually be 2 different views on all the data that gets collected (repository) First view through the eye of the entities - each entity will show all its properties by property over time Second view through the eye of an event - you would see all the events over time with all the relevant 'properties' that are associated to different entities - together. 3) Here - it is IMPORTANT to distinguish between different events with 'properties' that are associated to the same entity property. These may actually be 2 different views on all the data that gets collected (repository) First view through the eye of an entity - you would see all the location values over time regardless of the type of event Second view through the eye of an event - you would see all the events over time and what location the TVSet is according to the event types. Regards, Guy Sharon Manager Event-based Middleware & Solutions Phone: 972-4-8296587 | Mobile: 972-54-6976417 E-mail: GUYSH at il.ibm.com Website: www.research.ibm.com/haifa/dept/services/soms_ebs.html Find me on: and within IBM on: Haifa University, Mount Carmel Haifa, HA 31905 Israel From: <fano.ramparany at orange.com> To: Guy Sharon/Haifa/IBM at IBMIL Cc: <boris.moltchanov at telecomitalia.it>, <carlo.licciardi at telecomitalia.it>, <Fiware-data at lists.fi-ware.eu>, <jhierro at tid.es> Date: 05/01/2012 12:13 Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Hi Guy, Thank you for your comments. Most of my feedback are covered in the joint IoT/Data discussion. I?d just like to bounce on your attempt to describe the boiler example using the data/context/event schema. When you say ?you treat temperature and pressure as attribute?. Is fine with me ? but is irrelevant to the above representation?, do you mean that you would handle this differently? In which case could you elaborate? Here is my proposal: Which in the graphical notation corresponds to: My point is that it seems more natural to consider the 3 ?DataElementAttribute? boxes in the middle as events, than to call the entire graph an event. In my proposal the links are bidirectional, which makes It possible to retrieve the DataElement from the DataElementAttribute. Any comment or alternative viewpoint welcome, Kind regards, Fano De : Guy Sharon [mailto:GUYSH at il.ibm.com] Envoyé : mardi 3 janvier 2012 20:51 À : RAMPARANY Fano RD-TECH-GRE Cc : boris.moltchanov at telecomitalia.it; carlo.licciardi at telecomitalia.it; Fiware-data at lists.fi-ware.eu; fiware-data-bounces at lists.fi-ware.eu; jhierro at tid.es Objet : Re: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition Fano, I think the discussion you raise brings up the aspect of the semantic meaning of an event and the representation of an event. In the definition of an event in our chapter we discuss the representation of an event and not the semantic meaning of an event. An event may represent change of and attribute value of some entity. It can also mean a change in state \ transition. But how do you communicate the event of an attribute change for example... You would provide an event which is a specific Data Element that consists of Data Element attributes that may include info on the entity for an attribute is being changed, the attribute that is being change, the old value of the attribute, the new value of the attribute, the time during which the change occurred, etc. Therefore the event representation - how the event is communicated between GEs for example is a specific Data Element. In your example there are 2 types of events - TemperatureMeasured and PressureMeasured TemperatureMeasured consists of tempValue, timeStamp and boilerID attributes - for example I think you refer more to the semantical or ontology level of the event which in my opinion is not covered by the whole Data Element discussion. >From that point based on the example - we have an event associated with temperature of a boiler and another associated with the pressure of the boiler - here you treat temperature and pressure as attributes of the boiler and events associated to these attributes - which is fine with me - but is irrelevant to the above representation. In other words - event element attributes tempValue, boilerID of the event element TemperatureMeasured are semantically mapped to the Boiler. An event could carry information relevant to more than one entity you wish to model which in that case the event does not represent a change in attribute but perhaps something more abstract - a situation! The output of event processing is also an event - a complex event - that may not be associable to an attribute or rather is associated to multiple attributes of multiple entities. Regards, Guy Sharon Manager Event-based Middleware & Solutions Group Event-based Middleware & Solutions phone : +972 4 8296587 mobile : +972 54 6976417 address : IBM R&D Labs in Israel, Haifa University Campus, Mount Carmel, Haifa, 31905, Israel email : guysh at il.ibm.com From: fano.ramparany at orange.com To: boris.moltchanov at telecomitalia.it, carlo.licciardi at telecomitalia.it, jhierro at tid.es Cc: Fiware-data at lists.fi-ware.eu Date: 03/01/2012 20:45 Subject: [Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Event definition - a proposed revision of the Event definition Sent by: fiware-data-bounces at lists.fi-ware.eu Hi, I wish you the best for 2012 and in particular much success to our FIWARE project and to the FI PPP program in general! FT is involved in adding a semantic extension to the Publish/Subscribe GE. One step required is to define a ?semantic aware? data schema (*) able to capture the Data-Context-Event model that has been defined in the Vision Document. While revisiting this chapter (the overview chapter: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Data/Context_Management#Overview ), I felt uncomfortable with the definition of an event, which according to the current version is ?specific Data Element? with a timestamp to represent its date/time occurence. However, events are generally related to the creation of ?element attributes? or changes in the values of ?element attributes? (for example, if the temperature of the boiler has been measured 2 times and its pressure 1 times. There will be 3 events, each of them will correspond to a Context Element attribute. More precisely, 2 context attributes for the two temperature measurements and 1 context attribute for the pressure measurements. The timestamps of those 3 measurements would probably be all different because the measurements would be done at different times. The ?element attribute? corresponding to the 2nd temperature measurement will supercede the one corresponding to the 1rst temperature measurement. (Note: with the approach proposed in the working document I refer to below (**), the timestamp is a meta-data associated to the ?element attribute?). For this reason I?d like to propose a slight revision of the event definition and state that ?an event is a specific Data Element attribute? (with a mandatory timestamp meta data to capture its date/time occurrence). This definition would replace this one: ?an event is a specific Data Element?. Any comment/feedback on this and on the working document which proposes a flexible ontology which aligns with our data model, is more than welcome, Best regards, Fano (* called an Ontology in the semantic web framework) (** This document proposes an Ontology for Defining Ontologies for the Pu ReleaseV0. In case the link doesn?t work, the document is in FI-WARE->files->OntologyV0.pdf on the FI-WARE fusion forge web site) _______________________________________________ Fiware-data mailing list Fiware-data at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-data -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3092 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5210 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment-0001.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3243 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment-0002.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 9749 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment-0003.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 25563 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment-0004.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 18440 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment-0005.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 488 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment-0001.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 467 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment-0002.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 494 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment-0003.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 360 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment-0006.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9509 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11456 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment-0004.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2558 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/5bfae0b7/attachment-0007.gif>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy