Dear Fano, I got perfectly you use-case from the previous email. I would ensure you that I have some certain inside understanding of WSN tech and apps;). I'm not sure if we really need to include another timestamps, even partials, within the data structure we are defining. You're right saying that the event occurrence is not the context unless this is sent immediately therefore become a context generation by the event occurrence. Moreover we are going to handle the event streams in a real-time. Then, for a WSN device communications stand-by-wake-up-send/receive-stand-by-again we may threat the event time generation on a higher data structure true layer, saying that once events (more then one collected within radio-silent WSN device) are sent to the gateway or application this is the context of that decide and inside we may have more events with probably their respective timestamps. Then, if an application requires them: - as pure events, even if stored and not real-time we have the structure right data structure for that (all of them stored). If device doesn't have an internal clock it should be higher level application or gateway handle the conversion issue; - as a context, we have a right data structure also for this, and only the last one, fresher and if still valid data will be taken into consideration; - a mix of two or conversions, it should be handled at application/service layer outside of enabler, or, you said, if we will have STRONG and CLEAR requirement from our FIWARE IoT or UA FI-Projects, we could embed it into our FI-FARE WP6 enabler. Let wait and see what others think about this matter. Best Regards, Boris 16/giu/2011, в 10:28, "fano.ramparany at orange.com<mailto:fano.ramparany at orange.com>" <fano.ramparany at orange-ftgroup.com<mailto:fano.ramparany at orange-ftgroup.com>> написал(а): Dear Boris, I was perhaps too extrem with the daily sporadic connection. But they are some lowpower WSN protocols which make it possible to set the sensors radio component idle most of the time, and synchronize their wakening during short period to have all communication occur during that period. If the sensor is able to date its measurements, it might make sense to use this date for event processing (my concern was more on event processing than on context management). Maybe one solution (introduced in an earlier document or discussion) is to distinguish the event object creation time from the event occurence time. The event creation time being the default one and the event occurence time being the one the real event occured. May be concrete use-cases analysis (from UA scenarios) could determine if this is necessary or not. Fano ________________________________ De : Moltchanov Boris [mailto:boris.moltchanov at telecomitalia.it] Envoyé : jeudi 16 juin 2011 00:25 À : RAMPARANY Fano RD-TECH-GRE; <mailto:jhierro at tid.es> jhierro at tid.es<mailto:jhierro at tid.es> Cc : <mailto:fiware-data at lists.fi-ware.eu> fiware-data at lists.fi-ware.eu<mailto:fiware-data at lists.fi-ware.eu> Objet : RE: [Fiware-data] Tentative definition of basic concepts: data,context and events Dear Fano, Why do you believe we need another value among the context creation (generation) timestamp. The context is real or near real-time, therefore shall have a timestamp and a validity period or expiration time for this context. I believe in your mentioned use-case with the sensor the data collected during a day and sent in a bunch as a “sporadic packet” are not the context anymore. Only the last, more fresh one, could be taken as a context (if it still valid and reasonable). The rest of that sensor collected data are the context history, so is not the context anymore and could be treated at the “application” level, for example, adding a new context_scope=increasing order. For example, a sensor collecting temperature reading its onboard sensor each 5 minutes: 1. 10dgC 2. 11dgC 3. 12dgC 4. Opening TX window to send the data and sending the data to gateway or broker. 5. Only final value 12dgC is set as context, the rest 2 are recorder into the history as “previous” context from timestamp “a”, when previous TX window was opened, or with a Context_scope=<order_number> and context_type = previous context. Or a gateway or broker could know that that context was collected by the sensor each 5minutes and calculate back the timestamp in the history. 6. Reset the context in the sensor and again: 7. 12dgC 8. 11dgC 9. … until the next TX window Otherwise I’m afraid we will “encode” generic data representation scheme with too much “application” dependent (particularity of that sensor) and, again, formally speaking, collected previous data, is not the context, but the history of previous, already passed and overwritten, reality. Best Regards, Boris From: fano.ramparany at orange-ftgroup.com<mailto:fano.ramparany at orange-ftgroup.com> [mailto:fano.ramparany at orange-ftgroup.com] Sent: Wednesday, June 15, 2011 5:09 PM To: jhierro at tid.es<mailto:jhierro at tid.es>; Moltchanov Boris Cc: <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 Dear all, I agree with the first part of your message which state the consensual view. Here is my feedback on the second part where Juanjo request our opinion: - I agree with the process of assigning the time of creation of the event to the timestamp value by default, but making it possible to set the timestamp with another value. Use case: a sensor with sporadic connection (e.g. daily connection) but which store locally its measurement with the date of measure. - I second the approach making it possible to choose your preferred representation language (XML, RDF,...) for all GEs which will process data (data, event, context). As I'm personnally a supporter of RDF, I've checked that the data model discussed so far can be easily mapped onto RDF. Regards, Fano ________________________________ De : 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] De la part de Juanjo Hierro Envoyé : mercredi 15 juin 2011 15:56 À : Moltchanov Boris Cc : <mailto:fiware-data at lists.fi-ware.eu> fiware-data at lists.fi-ware.eu<mailto:fiware-data at lists.fi-ware.eu> Objet : Re: [Fiware-data] Tentative definition of basic concepts: data,context and events ... 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. * 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.) The advantages for the model I have described so far is: * We comply with OMA specs * 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 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: <!--[if !supportLists]-->1. <!--[endif]-->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)). <!--[if !supportLists]-->2. <!--[endif]-->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. <!--[if !supportLists]-->1. <!--[endif]-->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; <!--[if !supportLists]-->2. <!--[endif]-->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; <!--[if !supportLists]-->3. <!--[endif]-->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 <image001.gif> Guy Sharon Manager Event-based Middleware & Solutions Group ________________________________ <image002.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. <image003.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. <image004.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. <image004.gif>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 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. <logo Ambiente_foglia.jpg>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: <https://lists.fiware.org/private/old-fiware-data/attachments/20110616/f3b412c3/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/20110616/f3b412c3/attachment.jpg>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy