[Fiware-data] Tentative definition of basic concepts: data, context and events

Guy Sharon GUYSH at il.ibm.com
Tue Jun 14 18:46:00 CEST 2011


OK Juanjo

That should work - as later stated in the definition there needs to be an 
explicit or implicit identification of event object from data
Meaning that (taking your example of a DB record)
The event type (name of the event) - could either come from some 
column\field in the record OR the name of the table (metadata) is the 
event type for all records.
In both cases these still would be data elements so your explanation below 
I think covers this.
On top of that though - we would need someone to explicitly 'map' the 
appropriate data element to the name of the event OR in some cases we 
could implicitly do this.

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:   Juanjo Hierro <jhierro at tid.es>
To:     fiware-data at lists.fi-ware.eu
Date:   14/06/2011 17:30
Subject:        Re: [Fiware-data] Tentative definition of basic concepts: 
data, context and events
Sent by:        fiware-data-bounces at lists.fi-ware.eu





On 14/06/11 15:54, Guy Sharon wrote: 
My only comment is regarding events 
I think our statement can be stronger about how an event object looks like 
- that we know what we want as a basic and things can be added ontop. 
The very basic is that an event object must have a type name. (one of the 
major distinctions from data), e.g rightMouseClick, buyStock 
  Note that a "data element" has an EntityId as well as a Type name.   So 
the type name you are asking for is there: matches the name of the type 
linked to the data element.
The properties (or better yet use what we already defined ... data 
element) could be multiple ones BUT the basis must contain like you have 
written the detection time which is the time the event object was created. 

With these two pieces of information we can start creating event 
processing logic - without these you can't.
  Data elements have a set of properties, but I believe we should not 
force data elements to have a property corresponding to "detection time" 
if we want to process them as events.   We want to be able to read a given 
data element (as an example, as result of retrieving a data record from a 
data base) and be able to push it to the CEP GE or the Publish/Subscribe 
Broker GE.   This would mean adding a timestamp actually, but that would 
go as a part of a sort of "header" of the event object wrapping the data 
element which would be created by the CEP GE internally to ease event 
processing.     That's why I have declared that event objects are made of 
data element plus some associated properties relevant for event processing 
(timestamp and maybe others we may find useful).   I feel like we should 
precisely add that those event objects will be created at the time a data 
element arrives to the CEP GE (and I would add ven to the 
Publish/Subscribe Broker GE).

  We don't need to attach a type name as part of the header in the event 
object wrapping a data element because the data element structure already 
contains the type name.

  I believe that the descriptions I provided were compatible with those 
you provided initially.   I just wanted to formulate them in a way that:
any sort of data elements could be transformed into event objects (would 
be just a matter of attaching info relevant to event processing)
the definition of data elements and context elements allow us to go for a 
model which is close or compliant to the model defined in the OMA standard 

  Please think about it carefully and with an open mind, not having a 
concrete product in mind.

  Best regards,

-- Juanjo


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:        Juanjo Hierro <jhierro at tid.es> 
To:        "fiware-data at lists.fi-ware.eu" <fiware-data at lists.fi-ware.eu> 
Date:        14/06/2011 14:00 
Subject:        [Fiware-data] Tentative definition of basic concepts: 
data,        context and events 
Sent by:        fiware-data-bounces at lists.fi-ware.eu 



Dear all,

 As you know, one of the action points from our last confcall had to do 
with providing a tentative definition of basic concepts in our chapter 
like data, context and event.

 Please find the document I have produced on the matter at:

https://forge.fi-ware.eu/docman/view.php/9/141/Notes+and+Thoughts+on+definition+of+data-context-event.doc


 Just in case you believe it would be more easy to run a discussion via 
email following this email, I have attached the text of this document 
below.

 Hope you find it useful.  Your feedback is welcome.

 Best regards,

-- Juanjo

1.                Motivation 

This document intends to provide a precise description of some basic 
concepts like data, context and events in FI-WARE. These concepts are 
fundamental in the description of the Data/Context Management platform in 
FI-WARE and the way applications are developed based on that platform. 
Contents of this document will be considered as baseline for a post to 
publish in our Data/Context Management blog in www.fi-ware.eu (
http://data.fi-ware.eu) 
2.                Definition of Data 

Data refers to information that is produced, generated, collected or 
observed that may be of relevance for processing, further analysis or 
information and knowledge generation. Essentially refers to information 
relevant to applications. 
Data in FI-WARE has associated a data type and a value. FI-WARE will 
support a set of built-in basic data types like in most programming 
languages. Values linked to these basic data types supported in FI-WARE 
are referred as basic data values. So we have the notion of the integer 
basic data type and basic values like ?2?, ?7? or ?365? that belong to the 
integer basic data type. 
A data element refers to data whose value is defined as a sequence of one 
or more <name, type, value> triplets referred as data element attributes, 
where the type and value of each attribute is either  linked to a basic 
data type and a basic value or is linked to the data type and value of 
another data element. Note that each data element has an associated data 
type as any data in the system. This data type determines what concrete 
sequence of attributes characterizes that data element. 
There may be meta-data (also referred as semantic data) linked to 
attributes in a data element. However, existence of meta-data linked to a 
data element attribute is optional. 
Any data element has an entity in any FI-WARE Instance and, as such, it 
has an associated EntityId which universally and unequivocally indentifies 
the data element among the whole set of existing data elements. 
The basic concepts introduced so far are represented in Figure 1. 


Figure 1.    Basic Model for Data

A cornerstone concept in FI-WARE is that data elements are not tied to a 
specific format. They can be transferred as an XML document or in some 
sort of efficient binary representation and then be stored in a Relational 
Database or as entries in a noSQL data base like MongoDB. 
  
  
  
3.                Definition of Context 

Context in FI-WARE is represented through context elements. A context 
element is just a particular case of data element. However, there may be 
some attributes as well as meta-data associated to attributes that we may 
define as mandatory for any type of context element in FI-WARE. 
4.                Definition of Event 

An event is an occurrence within a particular system or domain; it is 
something that has happened, or is contemplated as having happened in that 
domain. The word event object is used to mean a programming entity that 
represents such an occurrence (event) in a computing system [EPIA]. Events 
are represented as event objects within computing systems to distinguish 
them from other types of objects and to perform operations on them, also 
known as event processing. It is common to refer to event objects simply 
as events. 
In FI-WARE, event objects are defined as a data element to which a number 
of standard event object properties (similar to a header) are associated. 
The concrete set of standard event object properties in FI-WARE is still 
to be defined but we may anticipate that one of these properties would be 
the time at which the event object was created.  The data element and the 
standard properties linked to an event are used to describe, as mentioned 
above, something that has happened or is contemplated as having happened 
in a given domain. 
A context event 
The relationship (or difference) of the terms data and event is 
continuously debated. One summary of the philosophical and technical 
aspects of such debates is included in the background section of [Grove 
06] with several references to the different opinions and definitions. For 
the purpose of FI-WARE and in specifically of the Context and Data 
Management Generic Enablers, we need to distinguish between the semantic 
level and the technical level of such a relationship that FI-WARE wishes 
to adopt, communicate, through its interfaces, and implement. Semantically 
speaking, the term data subsumes the term event meaning that some data can 
be semantically interpreted as events. From a technical perspective data 
is the way information is communicated in FI-WARE and it needs to be 
explicitly or implicitly identified as an event object and vice versa for 
processing the data as event. 
  
  


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[attachment "jhierro.vcf" 
deleted by Guy Sharon/Haifa/IBM] 
_______________________________________________
Fiware-data mailing list
Fiware-data at lists.fi-ware.eu
http://lists.fi-ware.eu/listinfo/fiware-data

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[attachment "jhierro.vcf" 
deleted by Guy Sharon/Haifa/IBM] 
_______________________________________________
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/20110614/3260b120/attachment.html>
-------------- 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/20110614/3260b120/attachment.gif>
-------------- 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/20110614/3260b120/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 7137 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110614/3260b120/attachment-0002.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