Hi Fermin,
I hope you had some nice vacations.
I understand your need to have a flexible model for entity-entity relationships, but I am not yet convinced that associations in particular and NGSI-9 in general are the appropriate vehicle for it.
Could you give an example of a relationship that would actually need the "symmetry" between source and target?
(As said, the backup example can be easily modeled by the "asymmetric" solution using station2 --> station1 and then even the IoT Broker could understand it correctly.)
Best
Tobias
From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Montag, 6. Mai 2013 17:15
To: Tobias Jacobs
Cc: Raihan Ul-Islam; fiware-ngsi at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu
Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations
Dear Tobias,
I think that you are mostly right in your "motivations" analysis. To complete it, take into account that the piece of software that implements ConfMan in IoT chapter (named Orion Context Broker) is used in other places. So, what I'm trying to avoid is to develop a functionality (with the cost in design, coding and testing that it involves) that is only useful in a single use case, i.e. the one from IoT chapter. Note that from Orion Context Broker point of view, IoT Broker is just an application and I would like to avoid "hardwire" a semantic only needed by a particular application (because in that case, every application will potentially needs modifications in the Orion Context Broker code).
Thus, we have to find a way that at the same time doesn't hardwire predefined semantics in the Orion Context Broker only useful in IoT chapter (due to, as I mention before, the development of Orion Context Broker is not driven exclusively by IoT chapter requirements) and at the same time fulfills the IoTBroker-ConfMan case. I honestly think the way I propose matches both objectives. In particular, I think it that it fulfills the IoTBroker-ConfMan in the definition you did in the .doc with the query and update cases, but given that I have mention that before in several emails but this discussion continues maybe I'm wrong (in that case, please tell me the case/step/etc. in which I'm wrong).
You are right in that the "stations backups" case is not supported by IoT Broker but it has been never supposed to support it. However, other applications build on top the Orion Context Broker will take advantage of flexible association semantics to support it, without breaking the IoT Broker use case.
Regarding the OWL+SPARQL alternative, I don't know the technology well enough in order to have an opinion on that and how it compares with the one that we are currently on the table.
Best regards,
-------
Fermín
El 29/04/2013 13:09, Tobias Jacobs escribió:
Hi Fermin,
Sorry for the late reply; I have been absent Thursday and Friday.
I think our different opinions are coming from two different underlying assumptions.
What you have in mind (correct me if I am wrong) is to define associations purely syntactically and leave it to the application how to use it. They can use it to model backup, colocation, as sensor-thing relationships, as A-contains-B relationship etc. I guess this is what you mean by "flexibility".
Under this assumption I would support your approach. I would even suggest then to distinguish between scope keywords for including and excluding providers. And I would maybe not use the words "source" and "target", although I have no alternative in my mind right now.
However, what we have in mind is to predefine the semantics of associations, namely "A --> B means that attribute values for A can be interpreted as attribute values for B". Under this assumption it always makes sense to include providers of SOURCES and it never makes sense to include providers of TARGETS. In other words, the asymmetry here comes naturally from this predefined semantics and is nothing artificial.
Under our assumption the correct way to model your example is station2 --> station1. This is because every attribute value of station2 can be interpreted as one of station1, but not vice versa.
Then asking for SOURCES of station1 should do exactly what is required.
Under your assumption of flexible semantics it is not important if station1 --> station2 or station2 --> station1 is used, as long as it is consistent.
Do you share my view that the underlying disagreement is on "fixed vs. flexible semantics of associations"? If yes, we can continue the discussion on this basis, please find my argumentation below.
- The reason why I am supporting the predefined semantics is that within the IoT Chapter the way to interpret associations will have to be predefined anyway - the IoT Broker needs to know what to do with associations.
For example, your modeling with station1 --> station2 could not be processed correctly by the IoT Broker, because when receiving a request for station1 it would ask ConfMan for SOURCES of station1 and would not receive anything.
- I would not design associations as a generic way of connecting pairs of entities to each other. There are more suitable standards than NGSI (e.g. OWL+SPARQL) for these things.
Best regards
Tobias
From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Mittwoch, 24. April 2013 17:29
To: Tobias Jacobs
Cc: Raihan Ul-Islam; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations
Dear Tobias,
I'm not meaning symmetric in the sense of "symetric relationships" but in the sense of symmetric processing of TARGETS and SOURCES scopes.
Consider the following case: station2 is the backup of station1, but station1 is not the backup of station2. In this case, the relationship "backup" is clearly asymmetric station1->station2 but, even so, a client may want to query ConfMan for "all the providers of entities associated with entity1", that is a discoverContextAttribute on station1 with scope=TARGETS that not only has to include the station1->station2 association, but also the provider for station2.
Of course, you can model the association in the opossite way ("backed_by" station2->station1) but why to impose a restriction in the way the user of the ConfMan has to model its associations? Why to introduce artificial asymmetries in the processing of both ends when we don't need it (I stress the point that your IoT Broker case will work exactly the same)? On the contrary, they reduce the flexibility.
Best regards,
------
Fermín
El 23/04/2013 10:07, Tobias Jacobs escribió:
Hi Fermin,
I understand your use case of symmetric associations, but this is a different kind of association with different semantics from as we have defined it up to now.
The way we have defined associations up to now is that there is a specified source and a specified target. The semantics is that attribute values of the source can be interpreted as attribute values of the target, but not every attribute value of the target is can be interpreted as one of the source. So there is an inherent asymmetry. This distinction between the source and the target is where the difference in the SOURCES and TARGETS keyword comes from.
In order to model symmetric associations like in your use case I see two possibilities:
1) Use the defined asymmetric associations and insert both station1 --> station2 and station2 --> station1. Then you have expressed what you want: each attribute value of station1 is one from station2 and vice versa.
2) Define a new metadata type for symmetric associations, and correspondingly a new scope type for querying those kind of associations. Note that here it is not necessary to distinguish between SOURCES and TARGETS, but you either include all associations or not.
Best
Tobias
From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Dienstag, 23. April 2013 09:35
To: Tobias Jacobs
Cc: Raihan Ul-Islam; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations
Dear Tobias,
Even if beauty or clearness weren't enough (for many people, they are :), we see associations as a generic concept that goes much beyond device-thing relationships. For example, you can use associations to define symmetric relationships such as redundancy: let's think in a couple of entities (station1 and station2) at the same abstraction level (i.e. none of them is the "device" of the "thing" represented by the other) each one representing the same set of meteorological station providing a set of metrics (temperature, humidity, etc.) so if station1 fails, station2 could be used or viceversa. In this case, having the ability to get the provider of one end traversing the association from the other, no matter if the the starting end is target of source, can be very useful.
I haven't dig into detailed used cases, but there are probably many others. Our point is that we want to be as flexible as possible with associations in Orion Context Broker (the piece of software the implements ConfMan GE), beyond the use case with the IoT Broker. As long as the proposed interpretation doesn't "hurt" the IoT Broker case (i.e. there is no change in the XML you propose to use for the query or update cases) we understand that there is no problem on adopting it.
Best regards,
------
Fermín
El 22/04/2013 13:32, Tobias Jacobs escribió:
Hi Fermin,
Raihan is on holiday, so I answer instead.
The reason why we propose not to include providers in the target set is that we see no use case where someone would ask for targets and needs context providers. The typical use case is when the IoT Broker receives an attribute value of an entity via the update operation and wants to find out which for which higher-level entity/attribute combinations the received update is relevant. The context providers are not needed for that.
I understand that making it symmetric would make it somehow more beautiful and clear, but could you explain what you mean by more flexible?
Best regards
Tobias
From: 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] On Behalf Of Fermín Galán Márquez
Sent: Montag, 22. April 2013 12:21
To: Raihan Ul-Islam
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Subject: Re: [Fiware-iot] [Fiware-ngsi] how to represent associations
Dear Raihan,
I haven been reading the detail the reference you send and I have realize of the slight asymmetry in TARGET and SOURCE scopes. I would propose a more symmetric processing way:
* TARGETS is used when the requestor wishes to find out about the target set of a given set of entity/attribute combinations. The target set of an entity/attribute combination set is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the target set and (2) if there is an association <sourceEntity>.<sourceAttribute> --> <targetEntity>.<targetAttribute> and <sourceEntity>.<sourceAttribute> is in the target set, then also <targetEntity>.<targetAttribute> is in the target set. The TARGETS keyword is used to request any association between entity/attribute combinations from the target set, and, additionally, any context provider of any entity/attribute combination from the target set.
* SOURCES is used when the requestor wishes to find out where and how information about a given set of entity/attribute combinations can be retrieved. The source set of a set of entity/attribute combinations is recursively defined as the smallest set such that (1) the original entity/attribute combinations are part of the source set and (2) if there is an association <sourceEntity>.<sourceAttribute> --> <targetEntity>.<targetAttribute> and <targetEntity>.<targetAttribute> is in the source set, then also <sourceEntity>.<sourceAttribute> is in the source set. The SOURCES keyword is used to request any association between entity/attribute combinations from the source set and, additionally, any context provider of any entity/attribute combination from the source set.
For your XML use case, it doesn't changes anything, as there are no providers registered for house3 in any step. However, I think is better that way, as it provides and analogous way of working for TARGET and HOUSE and more flexibility.
Best regards,
------
Fermín
El 18/04/2013 18:15, Raihan Ul-Islam escribió:
Hi Fermin,
Thanks for your questions.
Your interpretation of "basic implementation of associations" matches with us.
Regarding your second question, If you look into the section "Retrieving Associations using NGSI-9" in the following link https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept you can get more clear view.
In short, the TARGETS keyword is used to request any association between entity/attribute combinations from the target set. Therefore, only association is expected in the response of discoverContextAvailabilityRequest with target as scope. No information of context provider of any entity/attribute combination from the target set is required.
I hope understand you question properly.
Thanks
Raihan
From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: 18 April 2013 15:16
To: Raihan Ul-Islam
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] how to represent associations
Dear Raihan,
Thank you for you new update. However, I would like to clarify "for the next release we can go for the basic implementation of associations."
Our interpretation of "basic implementation of associations" is:
* ALL scope not required
* Entity associations not required. Only attribute associations are required.
* Recursive associations not required.
Does that matches your opinion?
In addition, I have one more doubt regarding the .doc example, please.
In the query case, we have the following discovery:
<?xml version="1.0" encoding="UTF-8"?>
<discoverContextAvailabilityRequest>
<entityIdList>
<entityId type="House" isPattern="false">
<id>house_3</id>
</entityId>
</entityIdList>
<attributeList>
<attribute>indoorTemperature</attribute>
</attributeList>
<restriction>
<scope>
<operationScope>
<scopeType> Include Associations </scopeType>
<scopeValue>SOURCES</scopeValue>
</operationScope>
</scope>
</restriction>
</discoverContextAvailabilityRequest>
with the following associated response:
<?xml version="1.0" encoding="UTF-8"?>
<discoverContextAvailabilityResponse>
<contextRegistrationResponseList>
<contextRegistrationResponse>
<contextRegistration>
<entityIdList>
<entityId type="TemperatureSensor" isPattern="false">
<id>Sensor5</id>
</entityId>
</entityIdList>
<contextRegistrationAttributeList>
<contextRegistrationAttribute>
<name>measurement</name>
<isDomain>false</isDomain>
</contextRegistrationAttribute>
</contextRegistrationAttributeList>
<providingApplication>http://myHomeGateway22.org</providingApplication>
</contextRegistration>
</contextRegistrationResponse>
<contextRegistrationResponse>
<contextRegistration>
<registrationMetaData>
<contextMetadata>
<name>association1</name>
<type>Association</type>
<value>[...]</value>
</contextMetadata>
</registrationMetaData>
<providingApplication>http://www.fi-ware.eu/NGSI/association</providingApplication>
</contextRegistration>
</contextRegistrationResponse>
</contextRegistrationResponseList>
</discoverContextAvailabilityResponse>
And the following discovery in the update case:
<?xml version="1.0" encoding="UTF-8"?>
<discoverContextAvailabilityRequest>
<entityIdList>
<entityId type=" TemperatureSensor " isPattern="false">
<id>Sensor5</id>
</entityId>
</entityIdList>
<attributeList>
<attribute>indoorTemperature</attribute>
</attributeList>
<restriction>
<scope>
<operationScope>
<scopeType> Include Associations </scopeType>
<scopeValue>TARGETS</scopeValue>
</operationScope>
</scope>
</restriction>
</discoverContextAvailabilityRequest>
with the following associated response:
<?xml version="1.0" encoding="UTF-8"?>
<discoverContextAvailabilityResponse>
<contextRegistrationResponseList>
<contextRegistrationResponse>
<contextRegistration>
<registrationMetaData>
<contextMetadata>
<name>association1</name>
<type>Association</type>
<value>[...]</value>
</contextMetadata>
</registrationMetaData>
<providingApplication>http://www.fi-ware.eu/NGSI/association</providingApplication>
</contextRegistration>
</contextRegistrationResponse>
</contextRegistrationResponseList>
</discoverContextAvailabilityResponse>
What is interesting to note is that in the first case, the discoverContextAvailability response includes 2 ContextRestristationResponses (one for the Sensor_5 -marked in blue- and other with the metadata describing the associations) while in the second case it includes only one ContextRegistrationResponse (the one with the metadata describing association). I guess that this is due to Sensor_5 has been registered previosly with registerContext (query case 1.a step) while house_3 hasn't. In other words, if a registerContext for house_3 entity has would been done before the discoverContextAvailability, then 2 ContextRegistrations would have been included (one for house_3 and other for the metadata describing the association).
So, if I'm understanding correctly, the behavior of discoverContexAvailability should be returning the following "sum":
* The ContextRegistrationsResponses that would be returned applying NGSI standard default behavior
* If scope is not NONE, the ContextRegistrationsResponses that results of calculating TARGET and/or SOURCE (depending on the scope) associations on the entities in the discoverContextAvailability request.
I understand that probably in your use case it doesn't matters (because you don't have actual providingApplicaitons for house_3, it is only a "logical entity" which makes sense only as association end for sensors) but we are interested in defining precisely the behavior of discoverContextAvailablity.
Thanks!
Best regards,
------
Fermín
El 17/04/2013 11:25, Raihan Ul-Islam escribió:
Hi Fermin,
Please find my remark below marked with ">>"
Thanks
Raihan
From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: 15 April 2013 18:13
To: Raihan Ul-Islam
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] how to represent associations
Dear Raihan,
Thank you for your document update. Things are getting clearer in each new iteration :)
I have some feedback/comments on the document. I think all them are minor ones.
* In the picture in page 1 you use bidirectional arrows. I think it would be clearer to use uni-directional arrows (from source to target).
>> I modified the bidirectional arrows to unidirectional arrows.
* I understand that you propose "recursive" associations in both senses. I mean, your example only shows that for the "SOURCES" scope, but I understand that if the example also include an association foo1 -> sensor5, then a discoverContextAvailability on room2 will return both sensor5 and foo1, isnt't it?
>>In update scenario I also explained for scope "TARGET". In the scope of discoverContextAvailability request says "SOURCES" then discoverContextAvailability response will return both sensor5 and foo1.
* I understand that the default scope (the one that a NGSI9 server instance will use if no <scope> is included in the <restriction>) is "NONE" to preserver interoperability among NGSI implementations. I mean, the normal behaviour that a client implement standard NGSI but not the association extension we are discussing correspond to the "NONE" case. Right?
>> yes.
* In query case iteration 4 you use SOURCES as scope. However, according to the scope description (if I'm understanding correctly :) this should return the entities to which house_3/indoorTemperature is a source. An house_3/indoorTemperature is not a source of any entity in your example. Thus, I think this is an errata and that to be coherent you should change the document in either one of the following ways:
* Fix the errata in page 1 in the case it works in the oposite way
* Use TARGET scope in XML in iteration 4
* Define the association in the opposite way in registerContext (iteration 2)
>> Sorry for the error in the example of "Concept of scoping" scenario. I have updated it in the attach document
* I think a similar problem happens in update case.
>> As above
In addition, in order to set implementation expectations, I would like to know until which extend your use case needs the following:
* Do you plan to use recursive associations? (query and update cases don't use such recursion)
* Do you plan to use the ALL scope? (query and update cases don't use ALL scope)
* Do you plan to use entity associations (i.e. not using the AttributeAssociationList in registerContext time or AttributeList in discoverContextAvailability with scopes TARGET or SOURCE)? (query and update cases always use attribute associations)
>> for the next release we can go for the basic implementation of associations.
Thanks!
Best regards,
------
Fermín
El 10/04/2013 9:59, Raihan Ul-Islam escribió:
Hi Fermin,
Thanks for your feedback. Please find our view below respectively on the feedback
* Associations are both ways. It is not only B to A. It can be also A to B. For better understanding I am adding an example of update scenario in the attached document.
* About the second feedback. We are suggesting a ScopeType named "IncludeAssociations". Details about is also described in the attached document.
Thanks
Raihan
==========================================================
Raihan Ul Islam Software Engineer
NEC Europe Ltd. NEC Laboratories Europe
Kurfürsten-Anlage 36 D-69115 Heidelberg, Germany
Phone: +49 (6221) 4342 - 256
Fax: +49 (6221) 4342 - 155
Mobile: +49 (0) 17679030334
EMail: raihan.ul-islam at neclab.eu<mailto:raihan.ul-islam at neclab.eu>
http://www.netlab.nec.de
==========================================================
| NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB | Registered in England 2832014
From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: 05 April 2013 16:06
To: Raihan Ul-Islam
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] how to represent associations
Dear Raihan,
Just to check if I'm understanding correctly your proposal (please, tell me otherwise):
* Apart from registerContext and discoverContextAvailability it doesn't affect any other NGSI operation.
* For registerContext, the NGSI server processing the request has to record the association expressed in the metadata
* For discoverContextAvailability on entity/attribute B (assuming that A->B association has been previously created with registerContext), the NGSI server process the request of in the following way:
* If B is not the end of an association, then B is returned (standard NGSI behavior)
* If B is the end of an association, then the start of the association (A) is returned along with association information as metadata.
Now, assuming that above is correct, this is our (TID's) feedback:
* The usual semantics for an A->B association (e.g. a UML-like association) is that navigability goes from A to B. I mean, that from A I'm able to reach B. Thus, we think is a bit strange that a discoverContextAvailability on B results in A. In our opinion, the natural way should be in the opposite way, so the algorithm for discoverContextAvailability should be as follows:
* For discoverContextAvailability on entity/attribute B (assuming that B->A association has been previously created with registerContext), the NGSI server process the request of in the following way:
* If B is not the start of an association, then B is returned (standard NGSI behavior)
* If B is the start of an association, then the end of the association (A) is returned along with association information as metadata.
* How this would affect to the scenario is shown in the attached file, using Word change control.
* An orthogonal problem (no matter if your original algorithm or our modified version in the previous bullet) is how to retrieve the "entity itself" when it is the end (in your original algorithm) or the end (in our modified version) of the association. For example, in your scenario, which discoverContextAvailability request (I mean, the XML) should the client send in the case it wants to get house_3 (not the associated sensor_5)? How to solve this problem? Maybe using the Scope field within discoverContextAvailability request Restriction?
I hope this feedback be useful.
Best regards,
------
Fermín
El 02/04/2013 14:14, Raihan Ul-Islam escribió:
Hi All,
For representing the association we are proposing a metadata type "Association". It will have two elements "entityAssociation" and "attributeAssociationList".
The "entityAssociation" has two elements "sourceEntityId" and "targetEntityId". Usually devices will be used as "sourceEntityId" and things will be used as "targetEntityId". The elements "sourceEntityId" and "targetEntityId" are of "EntityId" type. But the attribute "isPattern" of "EntityId" will be omitted. Therefore, it will always have the value false. (As for example, if we consider the below scenario "sourceEntityId" will be he sensor5 and "targetEntityId" will be house_3.)
The "attributeAssociationList" is a list of "attributeAssociation" element . It also has two elements. These are "sourceAttribute" and "targetAttribute". The elements are a type of "xs:string". The "sourceAttribute" and "targetAttribute" will contain the attribute of the corresponding "sourceEntityId" and "targetEntityId".
We proposed two types of associations(https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/NGSI_association). These are entity and attribute association.
An entity association will be represented by "entityAssociation" element of the metadata. "entityAssociation" and "attributeAssociationList" both are needed to represent an attribute association.
For better understanding association the following scenario is considered.
Scenario
In this scenario, pop/sub broker asks for the indoor temperature of a house(e.g. house_3) and a sensor (e.g. sensor5) available in house_3. The sensor5 provides the indoor temperature as an attribute "measurement". "indoorTemperature" attribute of house_3 provides indoor temperature. Therefore, to get the indoor temperature of the house_3 there should be an association between "indoorTemperature" attribute of house_3 and "measurement" attribute of sensor5. I am attaching a complete example of an association scenario in the attachment with sample request and response. Also attaching the xsd file for the metadata tag.
I am looking forward for your opinion about this topic.
Thanks
Raihan
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 Tobias Jacobs
Sent: 22 March 2013 09:58
To: Fermín Galán Márquez
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] how to represent associations
Hi Fermin,
Thanks for your feedback.
We will come up with a proposal of a metadata type definition for representing associations in the week before Easter.
I think also from an implementation point of view this approach is easier than the previous ones, because there is a more clear distinction between association registrations and context provider registrations.
Best regards
Tobias
From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Freitag, 22. März 2013 09:00
To: Tobias Jacobs
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: how to represent associations
Dear Tobias,
In principle, it seems more flexible than the original approach. However, in order to get a complete understanding of the idea and its implications (specially from the implementation point of view) we would need to have a look to a more detailed definition and examples (something in the same style as in https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_Association_concept).
Are you planning to provide that definition/examples?
Best regards,
------
Fermín
El 20/03/2013 16:01, Tobias Jacobs escribió:
Dear Fermin, dear all,
In the IoT F2F meeting last week we have been discussing about how to represent associations using the NGSI ContextRegistration structure, and we had not reached a conclusion yet.
I would like to take the chance to propose a radically new and simplistic concept of doing this. How about we simply define some structured metadata types for associations where both the Thing-level entities/attributes and the Device-level entities/attributes are mentioned. These pieces of metadata are then put into the RegistrationMetadata list of the ContextRegistration structure, and the entityList and attributeList fields can stay empty.
This gives us any flexibility of how to structure the associations. We can start with simple entityAssociations and attributeAssociations as metadata types, but further and more complex associations can be defined later in the same way.
What do you think?
Best
Tobias
________________________________
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
________________________________
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/fiware-ngsi/attachments/20130507/5cdd2d55/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy