[Fiware-data] FI-WARE-data / VisionDocument / Data-Context-Eventdefinition - a proposed revision of the Event definition

Guy Sharon GUYSH at il.ibm.com
Fri Jan 6 18:42:10 CET 2012


Hi Boris - good to see you in 2012.

I don't think we have a serious conflict. If I understand your points 
below correctly I can agree with almost everything.
Putting it in my own words.
All information \ updates on entities is coming from events that we know 
to model and monitor - unrealistic! There is information \ context that is 
just given \ exists without events being involved. However, the opposite 
is true as well - the reasoning on events requires no entity what so ever 
- because the entity itself may be superficial or that the entity is of no 
interest and doesn't need to be modeled. For example - react to 3 check 
deposits during the last hour - don't care about the person, or the bank 
account or the check itself. Just that these events occurred 3 times.

What I am actually saying is that it will be very very wrong and we will 
just create big troubles in the future (as you say) if we collapse 
entity\context into events and vise versa collapse events into context and 
generate events from context (your suggestion).
We need to allow 2 different views and that is what I drew in my email 
before.


Regards,

Guy Sharon
Manager
Event-based Middleware & Solutions

Phone: 972-4-8296587 | Mobile: 972-54-6976417
E-mail: GUYSH at il.ibm.com
Website: www.research.ibm.com/haifa/dept/services/soms_ebs.html


Find me on:  and within IBM on:   


Haifa University, Mount Carmel
Haifa, HA 31905
Israel




From:   Moltchanov Boris <boris.moltchanov at telecomitalia.it>
To:     Guy Sharon/Haifa/IBM at IBMIL, "fano.ramparany at orange.com" 
<fano.ramparany at orange.com>
Cc:     Licciardi Carlo Alberto <carlo.licciardi at telecomitalia.it>, 
"Fiware-data at lists.fi-ware.eu" <Fiware-data at lists.fi-ware.eu>, 
"jhierro at tid.es" <jhierro at tid.es>
Date:   06/01/2012 17:05
Subject:        RE: [Fiware-data] FI-WARE-data / VisionDocument / 
Data-Context-Eventdefinition - a proposed revision of the Event definition



I agree with one point, that an event could be impersonated, such as for 
example ?it?s getting dark?, even if I don?t understand the sense of such 
a structure unless a context (environment of the event) is defined 
(therefore the event is belonging to this environment by default). 
 
That event becomes a context once we connect (attach) to some entity 
(environment, personal, object, etc.), e.g. ?Boris is observing that Turin 
is getting dark?, thus it becomes the context of Turin and transitionally 
of Boris located (by location) in Turin.
 
Until here we don?t have conflict.
 
But then for the rest, we have a serious conflict in basic foundation of 
data structures. An entity is an attribute of an event from event-centric 
world, while an event as a context is an attribute of an entity-centric 
context-aware world. I am not a guru, what I may just say that the event 
may never happen (never getting dark), while the context will still exist 
(Turin is in light) and such that I would prefer to convert (eventual) 
events to the context and not vice-versa starting the context from events 
that may never exist as from example before), otherwise we risk to lose 
important data (context). However I don?t exclude that events might be 
generated by the context, when that context is changing, thus we have 
Turin?s context, which is changing from light to dark and this generates 
the event ?getting dark?, which we may detach from Turin (impersonate) and 
say that the default environment is Turin, then there is no need to 
explicitly say ?Turin is getting dark?, which is also a context (status of 
Turin). 
 
Of course it depends on definition of the event and we may say that the 
measurement of the light leading to the context of Turin (Turin is in 
light) is also an event, but then we may say that Turin is in light 
(therefore don?t need a measurement as event) is a fact without any 
measurement (no events). Thus, materialism or idealism, chicken/egg 
problem J.
 
Please pay attention to this, otherwise we risk to create troubles for 
ourselves in future.  I suggest we take a decision, and make an assertion 
in certain sense, saying that an event may become a context when assigned 
to an entity and not that event has an attribute, which is an entity 
assigned to this event. Then we would have an event (no entities ? no 
attributes), once this even obtains an entity it become a context. I see 
only this solution to solve this. Then everything become clear, changing 
in the context may generate an event, and if we cancel the entity from the 
event it transforms back to the event.
 
I don?t know however how to realize and achieve it on the practical level, 
I believe products will be impacted. But we have to do this, otherwise we 
will have probably some difficulties in the P/S GE as well, that will be 
confused what is the data structure and where are the attributes.
 
Boris
 
From: Guy Sharon [mailto:GUYSH at il.ibm.com] 
Sent: Friday, January 06, 2012 1:37 AM
To: fano.ramparany at orange.com
Cc: Moltchanov Boris; Licciardi Carlo Alberto; 
Fiware-data at lists.fi-ware.eu; jhierro at tid.es
Subject: RE: [Fiware-data] FI-WARE-data / VisionDocument / 
Data-Context-Eventdefinition - a proposed revision of the Event definition
 
Good idea to start drawing things. 
But this is far from what I was trying to convey. In fact, I now 
understand that we need to touch \ sync on a fundamental point about 
events. 
Events must be treated as first class citizens in models and transports - 
not incorporated into entities\things and collapsed into properties rather 
they should exist alongside entities and may be associated with entities. 
I will try to give an example through three cases - 1) the simple one with 
the boiler, 2) an event to many entities with a check deposit, and 3) many 
events to one entity with the TVSet. 
If needed a drawing board and a discussion could be a good idea to resolve 
this in Madrid. 

First a simplified ontology view of the three cases 
1) 
2) 
3) 
   

Now lets look at how an event then should be represented as in the Vision 
of the chapter and how they would be stored or communicated versus 
entities. 
1) 
These may actually be 2 different views on all the data that gets 
collected (repository) 
First view through the eye of an entity - you would see all the 
temperature values over time 
Second view through the eye of an event - you would see all the 
TemperatureMeasured events over time and what temperature reading they 
provided to what Boiler 

2) Here - it is IMPORTANT to keep all the 'properties' of the event 
together (even though they are associated to different entities) for 
proper event processing - this is for some event processing implementation 
a real big issue when they decouple especially when you need to reason 
over the events and not over the entities it may have been associated 
with. 


These may actually be 2 different views on all the data that gets 
collected (repository) 
First view through the eye of the entities - each entity will show all its 
properties by property over time 
Second view through the eye of an event - you would see all the events 
over time with all the relevant 'properties' that are associated to 
different entities - together. 

3) Here - it is IMPORTANT to distinguish between different events with 
'properties' that are associated to the same entity property. 


These may actually be 2 different views on all the data that gets 
collected (repository) 
First view through the eye of an entity - you would see all the location 
values over time regardless of the type of event 
Second view through the eye of an event - you would see all the events 
over time and what location the TVSet is according to the event types. 


Regards, 

Guy Sharon
Manager
Event-based Middleware & Solutions 


Phone: 972-4-8296587 | Mobile: 972-54-6976417
E-mail: GUYSH at il.ibm.com
Website: www.research.ibm.com/haifa/dept/services/soms_ebs.html


Find me on:   and within IBM on:   


Haifa University, Mount Carmel
Haifa, HA 31905
Israel





From:        <fano.ramparany at orange.com> 
To:        Guy Sharon/Haifa/IBM at IBMIL 
Cc:        <boris.moltchanov at telecomitalia.it>, <
carlo.licciardi at telecomitalia.it>, <Fiware-data at lists.fi-ware.eu>, <
jhierro at tid.es> 
Date:        05/01/2012 12:13 
Subject:        RE: [Fiware-data] FI-WARE-data / VisionDocument / 
Data-Context-Eventdefinition - a proposed revision of the Event definition 





Hi Guy, 
  
Thank you for your comments. Most of my feedback are covered in the joint 
IoT/Data discussion. 
I?d just like to bounce on your attempt to describe the boiler example 
using the data/context/event schema. 
  
When you say ?you treat temperature and pressure as attribute?. Is fine 
with me ? but is irrelevant to the above representation?, do you mean that 
you would handle this differently? 
In which case could you elaborate? 
  
Here is my proposal: 
  

Which in the graphical notation corresponds to: 
  

  
My point is that it seems more natural to consider the 3 
?DataElementAttribute? boxes in the middle as events,  than to call the 
entire graph an event. In my proposal the links are bidirectional, which 
makes It possible to retrieve the DataElement from the 
DataElementAttribute. 
  
Any comment or  alternative viewpoint welcome, 
  
Kind regards, 
  
Fano 
  
  
De : Guy Sharon [mailto:GUYSH at il.ibm.com] 
Envoyé : mardi 3 janvier 2012 20:51
À : RAMPARANY Fano RD-TECH-GRE
Cc : boris.moltchanov at telecomitalia.it; carlo.licciardi at telecomitalia.it; 
Fiware-data at lists.fi-ware.eu; fiware-data-bounces at lists.fi-ware.eu; 
jhierro at tid.es
Objet : Re: [Fiware-data] FI-WARE-data / VisionDocument / 
Data-Context-Eventdefinition - a proposed revision of the Event definition 

  
Fano, 

I think the discussion you raise brings up the aspect of the semantic 
meaning of an event and the representation of an event. 
In the definition of an event in our chapter we discuss the representation 
of an event and not the semantic meaning of an event. 
An event may represent change of and attribute value of some entity. It 
can also mean a change in state \ transition. 
But how do you communicate the event of an attribute change for example... 

You would provide an event which is a specific Data Element that consists 
of Data Element attributes that may include info on the entity for an 
attribute is being changed, the attribute that is being change, the old 
value of the attribute, the new value of the attribute, the time during 
which the change occurred, etc. 
Therefore the event representation - how the event is communicated between 
GEs for example is a specific Data Element. 
In your example there are 2 types of events - TemperatureMeasured and 
PressureMeasured 
TemperatureMeasured consists of tempValue, timeStamp and boilerID 
attributes - for example 

I think you refer more to the semantical or ontology level of the event 
which in my opinion is not covered by the whole Data Element discussion. 
>From that point based on the example -  we have an event associated with 
temperature of a boiler and another associated with the pressure of the 
boiler - here you treat temperature and pressure as attributes of the 
boiler and events associated to these attributes - which is fine with me - 
but is irrelevant to the above representation. 
In other words - event element attributes tempValue, boilerID of the event 
element TemperatureMeasured are semantically mapped to the Boiler. 
An event could carry information relevant to more than one entity you wish 
to model which in that case the event does not represent a change in 
attribute but perhaps something more abstract - a situation! 
The output of event processing is also an event - a complex event - that 
may not be associable to an attribute or rather is associated to multiple 
attributes of multiple entities. 

Regards, 

Guy Sharon 
Manager 
Event-based Middleware & Solutions Group 


Event-based Middleware & Solutions 

phone : 
+972 4 8296587 
mobile : 
+972 54 6976417 
address : 
IBM R&D Labs in Israel, Haifa University Campus, Mount Carmel, Haifa, 
31905, Israel 
email : 
guysh at il.ibm.com






From:        fano.ramparany at orange.com 
To:        boris.moltchanov at telecomitalia.it, 
carlo.licciardi at telecomitalia.it, jhierro at tid.es 
Cc:        Fiware-data at lists.fi-ware.eu 
Date:        03/01/2012 20:45 
Subject:        [Fiware-data] FI-WARE-data / VisionDocument / 
Data-Context-Event        definition - a proposed revision of the Event 
definition 
Sent by:        fiware-data-bounces at lists.fi-ware.eu 
 





Hi, 
I wish you the best for 2012 and in particular much success to our FIWARE 
project and to the FI PPP program in general! 
FT is involved in adding a semantic extension to the Publish/Subscribe GE. 
One step required is to define a ?semantic aware? data schema (*) able to 
capture the Data-Context-Event model that has been defined in the Vision 
Document. 
While revisiting this chapter (the overview chapter: 
https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Data/Context_Management#Overview
), I felt uncomfortable with the definition of an event, which according 
to the current version is ?specific Data Element? with a timestamp to 
represent its date/time occurence. 
However, events are generally related to the creation of ?element 
attributes? or changes in the values of ?element attributes? (for example, 
if the temperature of the boiler has been measured 2 times and its 
pressure 1 times. There will be 3 events, each of them will correspond to 
a Context Element attribute. More precisely, 2 context attributes for the 
two temperature measurements and 1 context attribute for the pressure 
measurements. The timestamps of those 3 measurements would probably be all 
different because the measurements would be done at different times. The 
?element attribute? corresponding to the 2nd temperature measurement will 
supercede the one corresponding to the 1rst temperature measurement. 
(Note: with the approach proposed in the working document I refer to below 
(**), the timestamp is a meta-data associated to the ?element attribute?). 

For this reason I?d like to propose a slight revision of the event 
definition and state that ?an event is a specific Data Element attribute? 
(with a mandatory timestamp meta data to capture its date/time 
occurrence). This definition would replace this one: ?an event is a 
specific Data Element?. 
Any comment/feedback on this and on the working document which proposes a 
flexible ontology which aligns with our data model, is more than welcome, 
Best regards, 
Fano 
(* called an Ontology in the semantic web framework) 
(** This document proposes an Ontology for Defining Ontologies for the Pu 
ReleaseV0. In case the link doesn?t work, the document is in 
FI-WARE->files->OntologyV0.pdf on the FI-WARE fusion forge web site)
_______________________________________________
Fiware-data mailing list
Fiware-data at lists.fi-ware.eu
http://lists.fi-ware.eu/listinfo/fiware-data 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle 
persone indicate. La diffusione, copia o qualsiasi altra azione derivante 
dalla conoscenza di queste informazioni sono rigorosamente vietate. 
Qualora abbiate ricevuto questo documento per errore siete cortesemente 
pregati di darne immediata comunicazione al mittente e di provvedere alla 
sua distruzione, Grazie. 
This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the 
intended recipient, please delete this message and any attachments and 
advise the sender by return e-mail, Thanks. 
Rispetta l'ambiente. Non stampare questa mail se non è necessario. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/b90bf914/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/b90bf914/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 467 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/b90bf914/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 494 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/b90bf914/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/b90bf914/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3092 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/b90bf914/attachment-0001.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/b90bf914/attachment-0002.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/b90bf914/attachment-0003.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/b90bf914/attachment-0004.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/b90bf914/attachment-0005.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/b90bf914/attachment-0006.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/b90bf914/attachment-0003.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/b90bf914/attachment-0004.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/b90bf914/attachment-0005.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/b90bf914/attachment-0006.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/b90bf914/attachment-0007.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/b90bf914/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/b90bf914/attachment-0007.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/b90bf914/attachment-0008.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 677 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20120106/b90bf914/attachment-0009.gif>


More information about the Old-Fiware-data mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy