Thank you for your feedback Ricardo and Guy,
My comments inline below,
De : Guy Sharon [mailto:GUYSH at il.ibm.com]
Envoyé : mercredi 4 janvier 2012 19:55
À : Ricardo de las Heras
Cc : RAMPARANY Fano RD-TECH-GRE; Fiware-data at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu
Objet : Re: [Fiware-data] [Fiware-iot] T5.2 slides
Thank you for the examples - this helps in introducing some 'complications' to address by this method and in some sense to motivate that events should be considered to be stored\handled rather than updates to values (which is what I interpret from the presentation below)
Example - TVSet moved - the event repository would hold a property of TVSet location value with timestamp. In some cases it is not enough - for example I would like to distinguish the move by an event that was the result of pushing the TVSet from an event representing the pulling of the TVSet to its new location. I would not be able to distinguish this by looking at the location value of the TVSet.
Therefore based on the Vision document I think the event repository should store events (as a specific data element) with properties and not just properties.
This is indeed an issue I raised in FIWARE-data. I was also in favor of modeling properties as events rather than data elements as events. From the assumption that a data element in the Vision Document corresponds to a Thing in T5.2 slides, its seems more intuitive to consider the (newly measured) location of the TVSet as an event than to consider the TVSet as an event.
For example, PushTVSet event with property = location and property = timestamp (and could include more info such as the speed of movement)
The point is that there is much more to the semantics of an event than representing the change in value or the change in transition.
We could handle timestamp as what is called "meta data" in the vision document. These meta data are attached to "properties" in the vision document. For the speed of movement we could handle this as the result of processing the location property ( (currentlocation - previouslocation)/(currentlocation.timestamp - previouslocation.timestamp) ) and create a new property attached the the TVSet Thing (or TVSet Data element). More generally, any derivation of new properties based on existing properties, we could view it as "reasoning" and handled by the appropriate GE.
The change in value is more of a notification that the value changed the event represents the reason\cause of the change - for example thermometer - the change is in the temperature but the event is temperature reading. The change is in TVSet location transition but the event is pushed or pulled to the new location.
Event processing reasons on the events and values and not just values in time. The TVSet was pulled 3 times during the day to the same location would give different results than 3 times during the day the location of the TVSet changed to the same value.
I'm not sure I fully understand your point Guy. I agree that sensor readings are modeled as events. If you mean that change detection is the result of processing (analyzing) the events flow, I also agree. Example if the flow of "measuring" the TVSet location events is:
Event1: table
Event2: table
Event3: ground
Event4: ground
Event5: table
Event6: table
Event7: table
Changes occurs only at Event3 and Event5
About the consistency between the data/context/event schema from the Vision Document and the metadata/thing/iotResource schema from the T5.2 slides. The main discrepancy I've identified so far is the metadata. We also need to agree on Thing relate to Data Element, and how the IoTRessource does map into the Vision Document schema.
Kind regards,
Fano
Regards,
Guy Sharon
Manager
Event-based Middleware & Solutions
________________________________
Phone: 972-4-8296587 | Mobile: 972-54-6976417
E-mail: GUYSH at il.ibm.com <mailto:GUYSH at il.ibm.com>
Website: www.research.ibm.com/haifa/dept/services/soms_ebs.html <https://www.research.ibm.com/haifa/dept/services/soms_ebs.html>
Find me on: <http://www.linkedin.com/profile/view?id=3618230&authType=name&authToken=7XaO&locale=en_US&pvs=pp&trk=ppro_viewmore> <http://www.twitter.com/#!/@guyoser> and within IBM on: <https://w3-connections.ibm.com/profiles/html/profileView.do?key=c22fdae3-0bc2-4626-a30b-095a0eb63ec8&lang=en> <http://cattail.boulder.ibm.com/cattail/#view=guysh@il.ibm.com>
Haifa University, Mount Carmel
Haifa, HA 31905
Israel
From: Ricardo de las Heras <rheras at tid.es>
To: "fano.ramparany at orange.com" <fano.ramparany at orange.com>
Cc: "fiware-iot at lists.fi-ware.eu" <fiware-iot at lists.fi-ware.eu>, "Fiware-data at lists.fi-ware.eu" <Fiware-data at lists.fi-ware.eu>
Date: 04/01/2012 17:49
Subject: Re: [Fiware-data] [Fiware-iot] T5.2 slides
Sent by: fiware-data-bounces at lists.fi-ware.eu
________________________________
Hi Fano,
my reply inline:
fano.ramparany at orange.com wrote:
Thank you for this overall view of the IoT chapter Ricardo.
I've got few questions about the data model.
- How does the Metadata/Things/IoTResource/Event maps or relates to the Data/Context/Event schema introduced in the Vision document (Chapter "introduction")?
- In the Vision document, Metadata seems to be properties about properties. Along this interpretation, timestamp might be one of this metadata, whereas in your model all properties have timestamp.
- Well, I wouldn't like to lose the main focus (interfaces, blocks, ...) of those slides with this issue, the data model includes a timestamp in both: Properties and Observactions. I think in observations is quite clear for all of us, and Properties (associated to a Thing), as result of collecting all the capabilities (properties) of the resources associated to a single Thing.
That's the idea, really I don't know how this issue is introduced in the Vision document, but if you find any contradiction please let me know.
The concept of meta-data would imply the idea of 'Property'-'Value' association, as final high abstract model level of the data dictionary.
- Could you give examples of "associations" among Things and between Things and IoT?
Example:
- Thing: Room
- Resource1: Thermometer-1 within the room.
- Resource2: Pressure meter within the room.
R1 and R2 are associated to the Thing 'Room', so you can ask for the temperature of the room, and the Things resolution would ask to R1 about this value and timestamp.
- In your model, how would you represent that a TVset is placed on the table? Would this information be stored in the configuration repository?
- In the same way, TVset is associated to a table, but if the location would be relevant for your system, it should be modelled as an additional property (on, under, in, besides, etc.), storing it as an additional feature of course.
Or for example adding x,y,z coordinate.
- How would you represent the events capturing a move of the TVset or the fact that the TVset has been relocated at another place? Would they be stored in the event repository?
- Again depending of the requirements of the system, of course you can generate an event as result of a movement, automatically (sensor) or manually, modifying the location of the object, and therefore the information stored.
In IoT we have a Resource Monitoring module for monitorizing dynamic associations between Things and Resources.
Example: A car (resource) is moving along several streets (Things), changing this association in real time.
other partners: please feel free to correct/complement my answers,
Thank you in advance for your help,
Fano
you're welcome,
cheers,
Ricardo.
PS: I've put the Fiware-data mailing list in the loop as obviously both chapters should synchronize on this issue
De : fiware-iot-bounces at lists.fi-ware.eu <mailto:fiware-iot-bounces at lists.fi-ware.eu> [mailto:fiware-iot-bounces at lists.fi-ware.eu <mailto:fiware-iot-bounces at lists.fi-ware.eu> ] De la part de Ricardo de las Heras
Envoyé : mercredi 4 janvier 2012 10:03
À : fiware-iot at lists.fi-ware.eu <mailto:fiware-iot at lists.fi-ware.eu>
Objet : [Fiware-iot] T5.2 slides
Hi all,
As you know, we have to deliver an Architecture Specification by end of January and deadline is approaching.
This Architecture Specification should explain how the different GEs interact together and with the applications, going a step beyond from the very high-level figures we have designed so far. Elaborating on the interfaces the conceptual models to be supported.
After some internal discussions at TID, we have come up with a draft Architecture for the Things Management Layer which is explained in the slides attached to this mail. We would like to rely on these slides to launch the discussion among partners in this task as well as the WPL and WPA, also involving some of the relevant partners from the Data/Context
Management Chapter which may bring some pieces of the overall picture.
I may elaborate on them during the phone call now if needed.
Br,
--
-------------------------------------------
Ricardo de las Heras
M2M Research Technological Specialist
E-mail: <mailto:rheras at tid.es> rheras at tid.es <mailto:rheras at tid.es>
Phone1: (+34) 983 367625
Phone2 OCS: (+34) 91 31 29511
Telefónica Digital <http://www.tid.es/>
-------------------------------------------
________________________________
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>
--
-------------------------------------------
Ricardo de las Heras
M2M Research Technological Specialist
E-mail: <mailto:rheras at tid.es> rheras at tid.es <mailto:rheras at tid.es>
Phone1: (+34) 983 367625
Phone2 OCS: (+34) 91 31 29511
Telefónica Digital <http://www.tid.es/>
-------------------------------------------
________________________________
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> _______________________________________________
Fiware-data mailing list
Fiware-data at lists.fi-ware.eu
http://lists.fi-ware.eu/listinfo/fiware-data <http://lists.fi-ware.eu/listinfo/fiware-data>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120105/afbef238/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 518 bytes
Desc: image001.jpg
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120105/afbef238/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 488 bytes
Desc: image002.jpg
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120105/afbef238/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 467 bytes
Desc: image003.jpg
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120105/afbef238/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 494 bytes
Desc: image004.jpg
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120105/afbef238/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.gif
Type: image/gif
Size: 360 bytes
Desc: image005.gif
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120105/afbef238/attachment.gif>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy