Hi, I have taken a look at the changes proposed by Boris over the document I sent. I believe almost 90% of them can be accepted regarding the sections on which we describe data elements and context elements. I'll try to produce a revised version with some of the changes accepted prior to our confcall today. However, there is a fundamental difference in what respect to definition of events and I would like to point it out here because it's a matter for discussion (indeed, I rather disagree with the changes Boris made in the section on events) Boris essentially argues that event objects can only wrap data elements and, by the way, with certain mandatory attributes and meta-data. Indeed, Boris says that "An event is a particular case of the context element that does not have the EntityId and EntityType components". But that equals to a data element with certain mandatory attributes and meta-data. I believe, that approach has severe limitations: * It wouldn't allow the programmer to use the CEP GE or the Publish/Subscribe Broker GE with data elements that do not have the mandatory attributes and meta-data that will be defined by context elements. Why should we try to impose those attributes and metadata to any type of data handled in our system ? I do not believe there is no reason why the implementation of the CEP GE or the Publish/Subscribe Broker GE cannot handle data elements as well as context elements in general. * It wouldn't allow the programmer to use the CEP GE (or the Publish/Subscribe Broker GE) establishing conditions on ECA rules that rely on the EntityId or the EntityType (subscription formulas in the case of the Publish/Subscribe Broker). Why should we impose that limitation ? I believe that an applications subscribing to reception of context elements linked to a particular EntityId or to reception of context elements of a particular EntityType would be rather common ... Since you propose that EntityId and EntityType be dropped from the structure an event object is wrapping ... How can you establish conditions on EntityId and/or EntityType in ECA-rules/subscription-formulas ? I believe the model is much cleaner, while at the same time more powerful, by simply saying that an event object is something that wraps a data element or a context element. Such wrapping takes place at the time the data element or context element is received (arrives) at the GE, either the CEP GE or the Publish/Subscribe Broker GE. And such wrapping implies adding some components (such as detection time) which, like a header, accompany the data/context element while it is being processed by the GE. Applications can use values of those components in the conditions they program (ECA rules in the CEP GE or subscription formulas in the Publish/Subscribe Broker GE). Last but not least, this wrapping would disappear when processing by the GE is finished. If it helps to understand this model, you may just assume that data elements are like context elements with the EntityId and EntityType set to null (because data elements do not necessarily be associated to an EntityId and EntityType). Then an event object wraps a context element (either a true context element with assigned EntityId and EntityType values, or a data element, that is, a context element with EntityId and EntityType components set to null). That simple. In this model, none of the above mentioned limitations exist. It might be the case that a particular asset, brought by partner as a baseline for the reference implementation of a given GE, isn't able to process any sort of data element or context element format but a predefined one. However, this shouldn't impede us to specify the GEs in FI-WARE in a more open and flexible way. The implementation may need to be enhanced to support multiple formats (I don't see so much difficult since the definition of data and context element we are introducing here probably already adapts very well to the kind of structure these concrete GEs are today using to represent context/data in memory. That would be in our roadmap (FI-WARE backlog). Besides, we may claim that there might exist particular GE implementations tied to a particular case of data element and context element format representation for performance reasons. Those GEs would be partial implementations of the GE spec. Best regards, -- Juanjo On 17/06/11 02:18, Moltchanov Boris wrote: Dear Juanjo and rest of the Folk, Please find attached the document, which might be already included as a part of our FI-WARE spec. I, personally, agree with our thoughts that Juanjo has expressed and have just tailored the below text to a specification style, excluding eventual verbosity (and somewhere correcting English, however I don’t pretend here). If you agree we may already use it as a part of official specification. I still need to improve the reference high-level pub/sub spec, not difficult job, however not sure if will have time. Let speak tomorrow morning. Best Regards, Boris From: 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: Thursday, June 16, 2011 8:29 PM To: fiware-data at lists.fi-ware.eu<mailto:fiware-data at lists.fi-ware.eu> Subject: [Fiware-data] Revised description of basic concepts: data elements, context elements and events Folks, Please find enclosed a revised version of the document with the description of basic concepts: data elements, context elements and events. Hopefully it captures what I believe every of us have in mind. I will send later tonight some additional comments elaborating a little bit further some points. For your convenience and if it helps to continue discussion over the email, I attach below the text of the document as body of this message. 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) 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. Applications may assign an identifier to Data elements in order to store them in some Data Base. However, such identifier would be generated aside and would not be considered as part of the structure of the data element. Note that a given application may decide to use the value of some attribute linked to a data element as its identifier in a given data base but, again, there is no identifier associated to the representation of a data element. The basic concepts introduced so far are represented in Figure 1. [cid:part1.00060705.09030001 at tid.es] Figure 1. Basic Model for Data A cornerstone concept in FI-WARE is that data elements are not tied to a specific format representation. They can be transferred as an XML document at some given point in time and then be translated into another XML document representation later on or be transformed into some sort of efficient binary representation as part of a message. They can be stored in a Relational Database, in a RDF Repository or as entries in a noSQL data base like MongoDB, adopting a particular storage format that may be the same or different to the format used when it is transferred. It should be possible to infer the data type associated to a given Data Element based on the XML document or the format of the message in which it is transferred (e.g., a specific element of the XML document if the same XML document type is used to represent data elements of different types or just the XML document type if a different XML document type is used per data type) or based on the structure used to store it (e.g., may be inferred from the name of the table in which the data element is stored). The way data elements are represented in memory by FI-WARE GEs is not specified. Therefore, the implementer of a FI-WARE GE may decide the way it represents data element in memory. 3. Definition of Context Context in FI-WARE is represented through context elements. A context element extends the concept of data element by associating an EntityId and EntityType to it, uniquely identifying the entity in the FI-WARE system to which the context element information refers. In other words, a context element is a data element to which we add the association to an EntityId and an EntityType. As an example, a measured temperature is a data element but in order to become a context element, has to refer to some entity which exhibits that temperature (a particular room, a particular building, etc). In addition, 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. The basic concepts behind context elements representation are represented in Figure 2. [cid:part2.07050407.02010205 at tid.es] Figure 2. Basic Model for Context Note that similar statements regarding format representation of data elements also apply to context elements. 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 created internally to some GEs like the Complex Event Processing GE or the Publish/Subscribe Broker GE. These event objects are defined as a data element (or a context element) to which a number of standard event object properties (similar to a header) are associated internally to the GE. 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 is detected by the GE (arrives to the GE). There might be other properties which may be defined and tools will be provided enabling applications or admin users to assign values to those properties based on values of data element attributes (e.g., source of the event or actual creation time) or other characteristics of the data element (i.e., DataType) or the context element (i.e., EntityId and EntityType) wrapped by the event object. Data events refer to event objects handled by the CEP GE or the Publish/Subscribe Broker GE wrapping a data element, while context events refer to event objects handled by the CEP GE or the Publish/Subscribe Broker GE wrapping a context element. ________________________________ 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. [cid:part3.06030003.00030905 at tid.es]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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110617/b4f5d1c2/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 7104 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110617/b4f5d1c2/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 8023 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110617/b4f5d1c2/attachment-0001.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 677 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110617/b4f5d1c2/attachment.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: jhierro.vcf Type: text/x-vcard Size: 429 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110617/b4f5d1c2/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy