[Fiware-ngsi] hierarchical entities

[Moltchanov Boris]

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] On Behalf Of Juanjo Hierro
Sent: Sunday, March 25, 2012 8:39 PM
To: 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:00000000000000000000000000000003 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/fiware-ngsi/attachments/20120326/d7eca210/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia2.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia2.jpg
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120326/d7eca210/attachment.jpg>