Hi Tobias, more or less. I would call it a data (context) + provisioning (relationship) system. Application use the application relevant context, wish is not necessarily belonging to an entity involved into application. An example from the real world: 1. I have a sensor retrieving the temperature, therefore I have its context - the temperature. 2. My application is using the temperature of the room (the air) and not of the sensors. 3. Therefore I have a relationship provisioning saying that the temperature of the room A = context data from the sensor B. Then it is up to my application (as user of the context) to store the context of the room A = temperature of sensor of the room B or to keep the primary context of the sensor B and this relationship. As far as someone somewhere has to know this relationship, I prefer the second solution as well as we keep the flexibility (the relationship can be increased e.g. by a person C within this room inheriting the temperature of the room inheriting the temperature of the sensor B, etc.) without loosing PRIMARY (row) context data (NO information lost) and with NO data overhead (no need to store context_sensor_B = 15 and context_room_A = 15 and context_person_C = 15). Please, pay attention, this is NOT an intelligence, this is only a provisioning by the assignment, that's all, no more and no less. And this may be connected to a Pub/Sub GE or CB with no complex schemas or protocols, just very easy and efficient. Personally I see the attributes for META-DATA such as e.g.: PRECISION, QUALITY, TRUSTWORTH, ACCURACY, MEASUREMENT_TYPE, etc. AND NOT for relationship, which shall be still flexible and efficient. The primary context source, the sensor B in my example is NOT aware about this assignment but only the temperature, therefore you need anyway somewhere to have a relationship DB and mechanism to consult it in order to assign the temperature of the sensor B to the room A. I suggest to keep the context data as simple as possible, and enrich it with relationships flexibly on the brokering/aggregating access nodes such as pub/Sub GE because anyway the application will consume it through those nodes. Then you will NOT need attributes because you will have directly APPLICATION USED context Entity_room_A and its context Temperature=15, without any relationship attributes affecting the performance, overloading the data by USELESS information as well as application DOES NOT need it and WILL NOT use it. Best Regards, Boris From: Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] Sent: Monday, March 26, 2012 6:34 PM To: Moltchanov Boris Cc: Juanjo Hierro; fiware-ngsi at lists.fi-ware.eu Subject: RE: [Fiware-ngsi] hierarchical entities Hi Boris, Juanjo, all, Thanks for the explanations, Boris. As far as I understand, you describe are guidelines for designing intelligent systems that determine attribute values based on relationships (e.g. instead of storing the location of a person, use the information that the person carries a certain mobile phone). But if the relationship information itself is of interest to the user, one still needs to figure out a way to model it in NGSI, because this is how the user accesses the system. Juanjo, before discussing the consequences of the two modeling approaches in more details we like to make sure that we are talking about the same approaches. So in your approach, how exactly would you model that person_1 is carrying phone_13? Is it by an Entity of type "carries-relationship" with one attribute with name="carrier" and value="person_1" and another attribute with name="carried" and value="phone_13"? Best regards Tobias From: Moltchanov Boris [mailto:boris.moltchanov at telecomitalia.it] Sent: Montag, 26. März 2012 14:26 To: Tobias Jacobs Cc: Juanjo Hierro; fiware-ngsi at lists.fi-ware.eu Subject: RE: [Fiware-ngsi] hierarchical entities Hi Tobias, of course. First of all we have to share an assumption that the context is primarily belonging to one object only, such as a thermometer, light measurer, etc. and for the sake of simplicity we may primarily assign it to an "useful" or "meaningful" object, such as respectively temperature or the room's air and light strength of the room. I believe the prime context sources of the IoT world are the sensor nodes installed in the room and then for the simplicity we may say that they measure the room's parameters. This would be different in case of BAN sensors belonging and characterizing that person. So those sensors and simplified primer EntityIDs are the room (by temperature and light sensor in the example above) or the person. In TMF's (TeleManagament Forum) SID model this is called Master of data. So the sensor is master for the temperature because only this sensor is writing (mastering) this data into the context payload and all others are just reader of the data. And the master shall be one, in order to avoid confusions and racing conditions. In the contest it is very simple because only temperature sensor is reading the temp. data. Then this context could be assigned to other EntityIDs but it does not make those EntityID primer, they are secondary EntityIDs, so the temperature of the person environment is deduced from the temperature of the room where the person is located. The sensor is master and is providing (propagating) its context (temperature) to another non_master EntityID - the person. I hope this concept is clear enough. This happen everywhere. In TI example we may say that we are locating a mobile phone, then we have a phone location (master and its data) and we propagating it to a person saying about location of a person. This propagation is made by EntityID resolver keeping track that the person A has a mobile phone B, and then, when we locating the phone B we locating the person A. I suggest we have this registry of the EntityIDs and their relationship outside of the context data model because in this case we may create any relationship model dynamically, even a reasoned by an intelligence, instead of having it fixed and static (read it as LIMITED). And I suggest do not create redundant context data saying that location of phone A is N and location of the person B (equipped with and retrieved by phone A) is N, for a simple reason that most probably (in most cases) nobody cares about the location of the phone A but location of the person B, that could be retrieved by the phone A. In my model the person B could be located by many different phone A, smartphone C and GPS device Z, etc. therefore I have the relationship of them to the person B and will choose needed location relationship accordingly to a maybe QoS required, or by priority, or by user preference, or by simply by its order within the resolver, and will not need to have a context data of person B with all its related locations within the attributes. "Beside effect" of this my proposal is that, distinguishing the primer owner of the context and the secondary (inheriting) Entities we empower the OMA based NGSI with TMF, which is a huge industrial standardization delivering a lot of standards for telecommunications and IT (TLC) companies, especially in fields of OSS, BSS, CRM and Data Management. Best Regards, Boris From: Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]<mailto:[mailto:Tobias.Jacobs at neclab.eu]> Sent: Monday, March 26, 2012 11:57 AM To: Moltchanov Boris; Juanjo Hierro; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu> Subject: RE: [Fiware-ngsi] hierarchical entities Hi all, I do not have a clear preference towards one of the two approaches yet. Juanjo's proposal to model relationships as entities seems more powerful at first glance, as e.g. relationships can then again have attributes themselves. Such attributes could still be expressed as metadata in Ernoe's approach , however. Ernoe's proposal is more natural on the other hand, as here Entities still only model physical objects. As Boris points out, previously unforeseen relationship types can be added during runtime in Juanjo's approach, while the set of attributes belonging to a certain entity type is static. By the way, does it really have to be static, is this written somewhere? Registering relationships could be done in both cases, and in both cases rather via NGSI-10 than via NGSI-9 in my opinion. @Boris: sorry, I have not fully understood your proposal. Can you provide more details about the EntityID resolver you are proposing? How would relationships be modeled in you approach? Best Tobias From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu]<mailto:[mailto:fiware-ngsi-bounces at lists.fi-ware.eu]> On Behalf Of Moltchanov Boris Sent: Montag, 26. März 2012 11:07 To: Juanjo Hierro; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu> Subject: Re: [Fiware-ngsi] hierarchical entities Hi, the problem could be solved as: - Repeating of the same context data for different EntityID (useless memory overloading, inefficient) - Maintaining all not-master EntityIDs as attributes (static, while needs and additional attributes ID could appear, hence inefficient). Why do not use a 3rd party component, which is EntityID resolver, that is connected to brokers (NGSI interface or Pub/Sub) and: - Avoid data overload for the same data, hence more efficient; - Configurable dynamically, even via a GUI, hence always updated to the purpose and valid; - Is involved only when needed, hence do not adding any burden to the context data handling. This entityID resolver could be a place for a right and dynamically living containment. BR, B PS. I've already mentioned this solution to the NGSI list and never got back any comment. From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu]<mailto:[mailto:fiware-ngsi-bounces at lists.fi-ware.eu]> On Behalf Of Juanjo Hierro Sent: Sunday, March 25, 2012 8:39 PM To: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu> Subject: Re: [Fiware-ngsi] hierarchical entities Hi, We shouldn't discard the option that relationships become entities. Why not ? I would strongly push for that. I believe there are a number of advantages linked to it: * Any kind of relationship could be represented that way. Just playing with the attributes linked to "relationship" entities. * We would be able to use NSGI-9 to register relationships and even to subscribe for dynamic registration of relationships. This would be helpful in many scenarios * We would use an uniform interface for everything. Otherwise, we would need to define extensions to NGSI to deal with management of relationships. This was always in our vision at TID about how we could deal with relationships and the reason why we believe that many of the functions that the Configuration Management GE could expose could be exposed using the NGSI-9 interface. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es<http://www.tid.es> email: jhierro at tid.es<mailto:jhierro at tid.es> twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 On 24/03/12 22:57, Ernoe Kovacs wrote: Denes, I think any kind of relationship can be expressed by attributes. So building: has an attribute hasRooms with the values room_1 and room_2. Now, I think the point you are implicitly looking at is that containment hierarchies can be used for special purposes, e.g. for naming. So by making the containment relationship a special relationship, we might use this e.g. for having a hierarchical structured resource tree following the containment relationship and having respective hierarchical names. The "containment" relationship is special, but there might be also other and the might be more than one "logical" containment. Person X is in his private life meber of his family and in his business life member of his company, and in his sports life member of his sport club. Conclusion: - Relationships can be expresses - No special relationships We understand that some things can be done/expressed more efficient with special relationships. - Ernö From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Bisztray, Denes (NSN - HU/Budapest) Sent: Samstag, 24. März 2012 13:51 To: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu> Subject: [Fiware-ngsi] hierarchical entities Dear all, Let me raise a problem with NGSI: it seems it does not support containment. That is, we can have entities building_1, room_1 and room_2 with their own attributes, but no relationship between them. Is anyone aware of some solution for expressing that building_1 contains room_1 and room_2, apparently? (apart from adding metadata to bulding_1 such as childentity=room_1) Best, Dénes ________________________________ 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:image001.gif at 01CD0BF8.30896CC0]Rispetta l'ambiente. Non stampare questa mail se non è necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120327/661fa1e6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 677 bytes Desc: image001.gif URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120327/661fa1e6/attachment.gif>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy