Hi Everyone,
First of all for this attempt trying to understand what I meant in emails, is not easy neither to express nor to understand for the persons getting first knowledge about the context matter.
I put my comments in the body of below email.
15/giu/2011, в 15:56, "Juanjo Hierro" <jhierro at tid.es<mailto:jhierro at tid.es>> написал(а):
Hi Boris, Guy,
I believe the picture is getting clear and we can reach soon a consensus here ...
Thanks Boris for clarifying the meaning of the EntityId field in the description of a Context Element in OMA specs. This is helpful to close the final model.
Let's use then EntityId as a field identifying the entity to which a given Context Element is relevant. That's fine. Then this field would be specific to Context Element and would not be present in Data Elements. I guess we would agree here.
Fine.
One thing I wouldn't agree with Boris is that EntityId and timestamp can be used as the Id in a DB. There might be two Context Elements produced at the very exact time (this might be not than frequent but still possible.) Therefore, the combination of the two fields cannot be used as a unique id.
Sorry, probably I made an explanation mistake here, the DataID - unique identifier for the context might be obtained by combination of EntityID+context_scope+timestamp. it must be univocal as far as the same context must come from the same context source at the same time for the same EntityID. Otherwise it creates an uncertainty in the data. However, as you correctly said, we don't need this element for the context at all. It was just a suggestion in a case we need a specific reference key.
I believe that issue can be solved in a simpler manner. We may just say that Data Elements have no id. In case that is needed, for storage purpose as an example, it's up to the application to generate it (of course, value of some property in the Data Element can be used for that purpose.)
Yes, agree.
A similar thing applies to the "EntityType" field defined in OMA. I guess this actually refers to the Type associated to the Entity identified by the "EntityId" field. Therefore, it doesn't match to the name of the type linked to the Data. I would handle this field similarly to the "EntityId" field in OMA. We may just say that Data Elements have no data type id (name). In this case, the only exception that I would made is that I would make it an optional field.
Your understanding is correct. The people dealing with the data would decide if have a metadata such as data type or data name or less.
Based on the above, I believe that we may define a model where:
* Data Elements exist and have:
* an optional "DataType" associated (universal name used to identify the type linked to the data)
* a sequence of attributes, defined as <name, type, value> triplets
* per each attribute, a sequence of meta-data, each meta-data defined as <name, type, value>
* (note: value is a basic data value or a data element
Ok
*
* Context Elements inherit from Data Elements (that is, are a specialized case of Data Elements) where:
* they have an additional mandatory "EntityId" associated which referes to the entity the context element is related to
* they have an additional mandatory "EntityType" associated which refers to the type of the entity identified by the previous "EntityId"
* certain attributes (to be defined in the FI-WARE specification) will be mandatory
Correct.
*
*
* Events are objects that contain a Data Element (therefore, may also contain a Context Element) and have associated a timestamp relevant for event processing.
I would inverse it in sense to say that the event element inherits a data element plus some meta-data and attributes plus a timestamp
And then that context element inherits event element and extending it with entityID, entityID type and some other elements to be defined.
*
What I believe it is not appropriate is to say that the Context are special kind of events. I see Context Elements as a special case of Data Elements. Both being able to be treated as events, that is, being able to be pushed into the CEP Generic Enabler or the Publish/Subscribe Broker GE.
Probably we may say that a context element is extended version of data element as well as of data element but I don't exist:).
A point about which we have to agree is that of the right interpretation of the timestamp for event processing. The way I see it is as follows:
* Data Elements (or Context Elements since they would be a special case of Data Elements) will be treated as events at the time at which they are pushed into any of the Event-oriented Generic Enablers we will provide: the CEP GE and the Publish/Subscribe Broker GE. So, in other words, event objects become created and are kind of a internal structure used for both GEs to wrap the Data Elements they receive and be able to perform part of their processing.
Context cannot be without EntityID therefore an event cannot be a context as is but shall be provided with EntityID and type to become a context.
* The event object created when a Data Element arrives at the CEP GE or the Publish/Subscribe Broker GE, includes of course the Data Element itself but additional info is added (like if it were a kind of a header). One info that is added is the time at which the event "is created". By default, this time would match the time at which the Data Element arrived the GE (i.e., the time at which the event object that wraps it was created). However, the programmer would be able to setup rules that would allow him/her to establish that the value of a given attribute is used instead.
* The internal structure used for represent event objects in memory would be hidden to the application programmer but he/she would know that a timestamp would be linked to the Data Element and, therefore, he may use that info in its formulas for conditions in the programming of the CEP GE or in subscriptions to the Publish/Subscribe Broker GE.
A crucial point not raised in this thread of discussion but introduced in the document I send is that the description of Data Elements and Context Elements doesn't prescribe a particular format for transfering or storing them. There might be multiple XML document formats that could be defined for sending Data Elements or Context Elements in messages. In addition, a given Data Element or Context Element can be stored in different ways (e.g., as RDF triplets in an RDF repository, as entries in MongoDB, as entries in a RDBMS, etc.)
If we are not losing the meaning of triplets during this representation and triplets, it may be truth.
The advantages for the model I have described so far is:
* We comply with OMA specs
Not complete maybe because only part of threaten spec is compliant, the rest will not, therefore not compliant formally.
* We can treat as events both Data Elements and Context Elements. Data Elements and Context Elements can be processed by the CEP GE and can be distributed by the Publish/Subscribe GE
* It's generic. We do not mandate a particular format to represent Data Elements and Context Elements
These two points seem to be ok.
Best regards,
Boris
Hope that we can agree in all the above and close a definition for this basic concepts.
Best regards,
-- Juanjo
On 15/06/11 13:17, Moltchanov Boris wrote:
Hi Juanjo,
Let me first answer the simpler email (simpler questions without complexity or ambiguity):
I think both a) and b) interpretations are correct, with mentioning that:
1. EntityID for the context is not the data key reference number (just like in a DB in case a) in order to retrieve a data and make the references to that ID from other DBs or tables), but this is ID of an Entity to whom those data (context) belong to, so a person, a device (owner or the data = Entity and this owner has its own EntityID as in case b)).
2. An key reference EntityID (as in DB, case a)) might be built for the context data taking EntityID of the context and adding time-stamp, in that case you obtain Data ID for referencing as a unique key. I think the same could be done for the event, but not sure, Guy might correct me.
Again, as in my email to Guy, I am speaking about the data structure, that will have the data and the meta-data.
1. the Data VALUE (as part of the structure, thus just like a number “5”) is a must for the DATA; we may add Data ID as another must to work over Data in DBs; so we have Data_Value<->Data_ID;
2. the Data meta-data named “data_type” is a must for both the events (data_type=event_name) and for the context (data _type=context_scope). Here we obtain EVENT and CONTEXT increasing of complexity of DATA by the same structural element data_type. And in both cases EVENT and CONTEXT we need a time-stamp, therefove we have still the same data-structure. So we have: Data_Value<->Data_ID && Data_Type<->context_scope||event_name && timestamp;
3. but the structure above is not sufficient for the context, we need one more – EntityID (data owner or object to whom the data are referred to). Therefore we have Data_Value<->Data_ID && Data_Type=context_scope||event_name && timestamp && EntityID<->data_owner/actor/subject/object
then vice versa:
event element may have more data elements inside;
context element may have more data and events inside;
in the 3. case we don’t need Data_ID therefore we may omit is saying that it could be built based on EntityID+timestamp+context_name. I think also in event structure something similar may be done.
I mean that DataID is not the EntityID for the context therefore e.g. in context we may loose DataID as far as that is not needed, and the data may be univocally identified by the triplet (EntityID, context_scope, timestamp).
Probably in order to avoid mixing and merging for the moment something that we are not let sure if it will be useful, we may just say that everything is a data and it has meta-data and then go deeper defining the structure model for the events and for the context putting mandatory and optional, similar as OMA defines. What I was trying to explain in my previous emails is: the Data Value is must everywhere in data, events and context, otherwise the data become metadata only, therefore semantic or ontology, which is knowledge but I don’t know if to call it then data or events, for sure not context. And if the Data Value is provided with event_name and timestamp it become and Event, if you add there EntitID (not DataID, but the “owner” if that data) it become Context.
That was the matter of my previous communications. TI follows OMA context definition however some Mandatory structure elements defined there are omitted for sake of simplicity and because there are implicity, or because we are missing them, such as quality of context data meta-data. Therefore those, as quality of context meta-data, shall be marked as optional in FI-WARE.
What do you think?
As far as another Juanjo’s mail followed the same thoughts, that I’ve tried to clarify know I will wait for your opinion before answering that email, and avoid useless if not harmful confusion.
Best Regards,
Boris
From: <mailto:fiware-data-bounces at lists.fi-ware.eu> fiware-data-bounces at lists.fi-ware.eu<mailto:fiware-data-bounces at lists.fi-ware.eu> [<mailto:fiware-data-bounces at lists.fi-ware.eu>mailto:fiware-data-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro
Sent: Tuesday, June 14, 2011 7:47 PM
To: <mailto:fiware-data at lists.fi-ware.eu> fiware-data at lists.fi-ware.eu<mailto:fiware-data at lists.fi-ware.eu>
Subject: Re: [Fiware-data] Tentative definition of basic concepts: data, context and events
Hi,
This is a crucial point with respect to which, a clarification from Boris would help.
In the OMA specification of the Context Management (Publish/Subscribe) Service, Context Elements have a field called "EntityId".
There are two interpretations of what this "EntityId" means. Depending on which one is the correct one, we need to adjust our definitions:
a) "EntityId" is just a "key" or "identifier" of the Context Element (for instance, used as key in a RDBMS). This was the interpretation I give in my document, so I Just explained that a Data Element had an "EntityId" associated to it.
b) "EntityId" is an id of an entity the Context Element provides some information about. So, for example, "EntityId" in a Context Element could be "MyVillage" and then, there could be several ContextElements describing aspects about "Prado Museum". For example, I may have a Context Element describing Location (with attributes latitude and altitude) while another Context Element may have Temperature (with attributes temperature, and time at which the temperature was measured).
If a) is the right interpretation, Context Elements would just be a special case of Data Element and, therefore, they would have an "EntityId" associated to them. As simple as that.
If b) is the right interpretation, then I believe that "EntityId" and "EntityType" would not make sense in Data Elements. I still believe that we should link an "Id" and "DataType" to Data Elements. Then Context Elements would "extend" Data Elements so that they also add "EntityId" and "EntityType".
What is rather clear to me is that events are just things that wrap data/context and link a time to them. In this respect, it makes sense to talk about data events or context events if we want to precise when an event is linked to a data element or a context element.
Feedback from Boris about what is the right interpretation (a) or b) above) would allow us to perform the next iteration in this definition.
Best regards,
-- Juanjo
On 14/06/11 18:38, Guy Sharon wrote:
Boris - wouldn't it be also true to be able to obtain context by associating data with entity?
i.e. No need to go through an event to get to context?
So something like this
<ATT00001..gif>
Guy Sharon
Manager
Event-based Middleware & Solutions Group
________________________________
<ATT00002..gif><http://www.ibm.com/smarterplanet>
Event-based Middleware & Solutions<http://www.haifa.il.ibm.com/dept/services/soms_ebs.html>
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<mailto:guysh at il.ibm.com>
From: Moltchanov Boris <<mailto:boris.moltchanov at telecomitalia.it>boris.moltchanov at telecomitalia.it<mailto:boris.moltchanov at telecomitalia.it>>
To: Juanjo Hierro <<mailto:jhierro at tid.es>jhierro at tid.es<mailto:jhierro at tid.es>>, "<mailto:fiware-data at lists.fi-ware.eu>fiware-data at lists.fi-ware.eu<mailto:fiware-data at lists.fi-ware.eu>" <<mailto:fiware-data at lists.fi-ware.eu>fiware-data at lists.fi-ware.eu<mailto:fiware-data at lists.fi-ware.eu>>
Date: 14/06/2011 18:51
Subject: Re: [Fiware-data] Tentative definition of basic concepts: data, context and events
Sent by: <mailto:fiware-data-bounces at lists.fi-ware.eu> fiware-data-bounces at lists.fi-ware.eu<mailto:fiware-data-bounces at lists.fi-ware.eu>
________________________________
Dear Juajo,
I would put the event definition before the Context. As I’ve said during the last conf-call, the data (including everything related to numbers and values) is a most generic case where only number (value) is the must. Everything else (meta-data, types, etc.) is optional.
Then we would have an event as data + time when happened (the object referred by the data is implicit therefore could be omitted).
Then adding the subject or object (referenced entity) we obtain the context, which inherit legacy properties of both the data (value) and event (when happened) as must and adding another must – explicit object or subject (entity) making it the context.
I hope I’ve succeeded to explain my point of view.
Thank you.
Best Regards,
Boris
From: <mailto:fiware-data-bounces at lists.fi-ware.eu> fiware-data-bounces at lists.fi-ware.eu<mailto:fiware-data-bounces at lists.fi-ware.eu> [mailto:fiware-data-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro
Sent: Tuesday, June 14, 2011 12:58 PM
To: <mailto:fiware-data at lists.fi-ware.eu> fiware-data at lists.fi-ware.eu<mailto:fiware-data at lists.fi-ware.eu>
Subject: [Fiware-data] Tentative definition of basic concepts: data, context and events
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://www.fi-ware.eu/> (http://data.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.
<ATT00003..gif>
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
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.
<ATT00004..gif>Rispetta l'ambiente. Non stampare questa mail se non è necessario.
_______________________________________________
Fiware-data mailing list
<mailto:Fiware-data at lists.fi-ware.eu>Fiware-data at lists.fi-ware.eu<mailto: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>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.
<ATT00005..jpg>Rispetta l'ambiente. Non stampare questa mail se non è necessario.
________________________________
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>http://www.tid.es/ES/PAGINAS/disclaimer.aspx
<jhierro.vcf>
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: <https://lists.fiware.org/private/old-fiware-data/attachments/20110615/841d28aa/attachment.html>
-------------- 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: <https://lists.fiware.org/private/old-fiware-data/attachments/20110615/841d28aa/attachment.jpg>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy